AWS Lightsail: Simple Cloud Hosting for Small Projects and Startups (2026)

AWS Lightsail Simple Cloud Hosting

AWS Lightsail is the part of AWS that most enterprise architects never touch — and the part that most startup founders should reach for first. It bundles virtual private servers, managed databases, container hosting, object storage, DNS management, load balancers, and CDN distributions into a single flat-rate service with predictable monthly pricing. Instead of pricing by the millisecond across a dozen separate services, you pay a fixed monthly fee for each resource you provision.

That simplicity is the entire value proposition. A $5/month Lightsail instance gives you a 1 vCPU, 512 MB RAM server with 20 GB SSD, 1 TB of data transfer, a static IP, and a DNS zone — fully configured in under five minutes from a browser. Compare that to an equivalent EC2 setup: choose instance type, configure VPC and subnets, set up an internet gateway, configure security groups, allocate an Elastic IP, and manually provision the application stack. The EC2 path is more powerful and more flexible. Lightsail is faster, cheaper for predictable workloads, and far less operational overhead.

This guide covers every dimension of Lightsail: comparing it honestly against EC2, App Runner, and Heroku; launching and configuring instances; managed databases; container services; object and block storage; networking and DNS; VPC peering with the rest of your AWS account; snapshots and backups; and the migration path to EC2 when you outgrow Lightsail's limits.

Lightsail vs EC2 vs App Runner vs Heroku

Before committing to Lightsail, it is worth placing it precisely in the AWS compute landscape. Each service has a distinct use case profile, and choosing the wrong one early means either paying too much or hitting hard limits at the worst possible time.

The fundamental difference between Lightsail and EC2 is abstraction. EC2 gives you a raw virtual machine and zero opinions about what goes on it. You configure the VPC, subnets, routing tables, security groups, key pairs, instance profiles, and the software stack. Lightsail wraps all of that into a wizard-driven experience with sensible defaults and a flat monthly price. Under the hood, Lightsail instances run on the same hypervisor as EC2 — they are just EC2 instances with a simplified control plane in front of them.

App Runner is a fully managed container platform. You give it a Docker image; it handles load balancing, TLS, auto scaling, and health checks. App Runner has no SSH access, no OS-level configuration, and no persistent disks. It is the right choice for stateless HTTP services that need to scale to zero. Lightsail is the right choice when you need a full server environment: OS access, persistent storage, application blueprints, and a static IP that does not change between deployments.

Heroku is the traditional comparison for Lightsail because both target the "I just want to deploy an app" audience. But Heroku's pricing has increased dramatically since Salesforce's acquisition removed the free tier. A Heroku Basic dyno ($7/month) gives you 512 MB RAM and no persistent storage. A comparable Lightsail instance is $5/month with 512 MB RAM, 20 GB SSD, and 1 TB bandwidth. More importantly, Lightsail keeps you inside AWS, where you can peer with RDS, use S3, and eventually migrate to EC2 without changing hosting providers.

DimensionLightsailEC2App RunnerHeroku
Pricing modelFlat monthlyPer secondPer second (active)Flat monthly (dyno)
Cheapest option$3.50/mo~$3.50/mo (t4g.nano)~$0–$5/mo (low traffic)$7/mo
SSH/OS accessYesYesNoNo
Persistent diskYes (included)Yes (EBS, separate cost)NoNo (ephemeral)
Auto scalingNo (manual resize)Yes (ASG)Yes (built-in)Manual dyno count
Setup complexityLowHighMediumLow
Managed DB includedYes (separate plan)No (use RDS)No (use RDS)Yes (Postgres add-on)
Stays inside AWSYesYesYesNo
Best forWordPress, APIs, small appsProduction workloadsStateless containersHobby projects
When Lightsail's flat pricing wins: Lightsail is cheapest when your traffic is steady and predictable — a blog, a portfolio site, a small SaaS application, an internal tool. If your traffic is spiky (near zero most of the time, high peaks occasionally), App Runner's pay-per-request model can be cheaper. If you need advanced AWS features like IAM roles for service accounts, placement groups, or custom AMIs, EC2 is necessary. For everything in between — a startup MVP, a client site, a development environment that needs to be always-on — Lightsail wins on simplicity and cost.

Instances: Blueprints, Plans, and SSH Key Pairs

A Lightsail instance is a virtual private server with a fixed hardware configuration and a pre-installed software stack called a blueprint. Blueprints eliminate the setup time for common application stacks — instead of installing and configuring WordPress, LAMP, or Node.js from scratch, you choose a blueprint and Lightsail provisions a fully configured server in about 90 seconds.

Available Blueprints

Lightsail blueprints fall into two categories: application blueprints (pre-installed software) and OS blueprints (clean operating systems).

Application blueprints include WordPress, WordPress Multisite, LAMP (Linux, Apache, MySQL, PHP), MEAN (MongoDB, Express, Angular, Node.js), Node.js, Django, cPanel & WHM (for web hosting resellers), Ghost, Joomla, Drupal, Redmine, GitLab, Nginx, and Plesk. Each application blueprint comes with all dependencies installed, a sample configuration, and Bitnami's documentation for post-installation steps.

OS blueprints give you a clean operating system: Amazon Linux 2023, Amazon Linux 2, Ubuntu 22.04, Ubuntu 20.04, Debian 11, CentOS 7, FreeBSD 12, and Windows Server 2022/2019/2016 (Windows instances are available at higher price points due to licensing).

Instance Plans and Pricing (Linux, us-east-1, 2026)

PlanvCPURAMSSDTransferPrice/mo
Nano2 burst512 MB20 GB1 TB$3.50
Micro2 burst1 GB40 GB2 TB$5.00
Small2 burst2 GB60 GB3 TB$10.00
Medium2 burst4 GB80 GB4 TB$20.00
Large2 burst8 GB160 GB5 TB$40.00
XLarge4 burst16 GB320 GB6 TB$80.00
2XLarge8 burst32 GB640 GB7 TB$160.00
Burst vs dedicated vCPU: Lightsail instances use burstable CPU, similar to EC2 T-class instances. Under normal load they perform well; under sustained high CPU they deplete CPU credits and throttle. If your application runs CPU-intensive workloads continuously (video transcoding, ML inference, heavy compilation), consider the XLarge or 2XLarge plans with 4–8 vCPUs, or migrate to a compute-optimized EC2 instance type.

SSH Key Pairs

Each Lightsail instance is accessed via SSH key pair authentication. You can use Lightsail's browser-based SSH terminal (no local setup required) or download the key pair and connect from your local machine.

# Download your key pair from the Lightsail console, then:
chmod 400 ~/Downloads/LightsailDefaultKey-us-east-1.pem

# Connect to your instance
ssh -i ~/Downloads/LightsailDefaultKey-us-east-1.pem ubuntu@203.0.113.45

# For Amazon Linux instances (bitnami user for application blueprints):
ssh -i ~/Downloads/LightsailDefaultKey-us-east-1.pem bitnami@203.0.113.45

Launching and Connecting: CLI, Static IPs, Firewall Rules

You can provision Lightsail resources from the AWS console, the AWS CLI, or infrastructure-as-code tools. The CLI is particularly useful for automating instance creation in scripts and CI/CD pipelines.

Creating an Instance via AWS CLI

# Create a Ubuntu 22.04 instance in us-east-1a
aws lightsail create-instances \
  --instance-names "my-web-server" \
  --availability-zone "us-east-1a" \
  --blueprint-id "ubuntu_22_04" \
  --bundle-id "small_3_0" \
  --key-pair-name "LightsailDefaultKeyPair"

# Create a WordPress instance
aws lightsail create-instances \
  --instance-names "my-wordpress" \
  --availability-zone "us-east-1a" \
  --blueprint-id "wordpress" \
  --bundle-id "micro_3_0" \
  --key-pair-name "LightsailDefaultKeyPair"

# Check instance state
aws lightsail get-instance-state \
  --instance-name "my-web-server"

# List all instances
aws lightsail get-instances \
  --query "instances[*].{Name:name,State:state.name,IP:publicIpAddress,Blueprint:blueprintId}"

Allocating a Static IP

By default, Lightsail instances get a dynamic public IP that changes when the instance stops and starts. A static IP is free as long as it is attached to a running instance, and essential for DNS records to remain stable.

# Allocate a static IP
aws lightsail allocate-static-ip \
  --static-ip-name "my-web-server-static-ip"

# Attach it to your instance
aws lightsail attach-static-ip \
  --static-ip-name "my-web-server-static-ip" \
  --instance-name "my-web-server"

# Verify
aws lightsail get-static-ip \
  --static-ip-name "my-web-server-static-ip" \
  --query "staticIp.{Name:name,IP:ipAddress,AttachedTo:attachedTo}"

Firewall Rules

Lightsail uses a simplified firewall (not VPC security groups). You define inbound rules by port and protocol. By default, SSH (22) and HTTP (80) are open. You typically also need to open HTTPS (443) and any custom application ports.

# Open HTTPS (443) on your instance
aws lightsail open-instance-public-ports \
  --instance-name "my-web-server" \
  --port-info fromPort=443,toPort=443,protocol=TCP

# Open a custom application port (e.g., 3000 for Node.js)
aws lightsail open-instance-public-ports \
  --instance-name "my-web-server" \
  --port-info fromPort=3000,toPort=3000,protocol=TCP

# Close a port (e.g., close SSH access after initial setup)
aws lightsail close-instance-public-ports \
  --instance-name "my-web-server" \
  --port-info fromPort=22,toPort=22,protocol=TCP

# View current firewall rules
aws lightsail get-instance \
  --instance-name "my-web-server" \
  --query "instance.networking.ports"
Firewall vs security groups: Lightsail's built-in firewall is simpler than VPC security groups — it only supports inbound rules (outbound is unrestricted by default), no security group references, and no CIDR-based source IP ranges per rule in the console UI. For source IP restriction via CLI, use the cidrs parameter: --port-info fromPort=22,toPort=22,protocol=TCP,cidrs=203.0.113.0/24. This restricts SSH to a specific IP range, which is a critical security best practice.

Managed Databases: MySQL and PostgreSQL

Lightsail managed databases are purpose-built relational database instances that handle automated backups, software patching, minor version upgrades, and high-availability failover. They are similar in concept to Amazon RDS but simpler to configure and priced on Lightsail's flat-rate model instead of RDS's per-hour billing.

Database Plans and Pricing (us-east-1, 2026)

PlanRAMvCPUSSDTransferPrice/mo
Micro1 GB2 burst40 GB100 GB$15.00
Small2 GB2 burst80 GB100 GB$30.00
Medium4 GB2 burst120 GB100 GB$60.00
Large8 GB2 burst240 GB100 GB$115.00

Creating a Managed Database

# Create a MySQL 8.0 database
aws lightsail create-relational-database \
  --relational-database-name "myapp-db" \
  --availability-zone "us-east-1a" \
  --relational-database-blueprint-id "mysql_8_0" \
  --relational-database-bundle-id "micro_2_0" \
  --master-database-name "myapp_production" \
  --master-username "dbadmin" \
  --no-publicly-accessible

# Create a PostgreSQL 14 database
aws lightsail create-relational-database \
  --relational-database-name "myapp-pg" \
  --availability-zone "us-east-1a" \
  --relational-database-blueprint-id "postgres_14" \
  --relational-database-bundle-id "small_2_0" \
  --master-database-name "myapp_production" \
  --master-username "dbadmin" \
  --no-publicly-accessible

# Get the connection endpoint
aws lightsail get-relational-database \
  --relational-database-name "myapp-db" \
  --query "relationalDatabase.{Endpoint:masterEndpoint.address,Port:masterEndpoint.port,State:state}"

Connecting Your Application

# Retrieve the master password (set during creation or auto-generated)
aws lightsail get-relational-database-master-user-password \
  --relational-database-name "myapp-db" \
  --password-version CURRENT

# Connection string examples:
# MySQL (from your Lightsail instance — same region, peering enabled)
mysql -h ls-abc123def456.czowadgeezs0.us-east-1.rds.amazonaws.com \
      -P 3306 -u dbadmin -p myapp_production

# PostgreSQL
psql "postgresql://dbadmin:password@ls-abc123def456.czowadgeezs0.us-east-1.rds.amazonaws.com:5432/myapp_production"

# In a Node.js app (environment variables):
# DATABASE_URL=mysql://dbadmin:password@ls-abc123def456.czowadgeezs0.us-east-1.rds.amazonaws.com:3306/myapp_production
High availability option: Lightsail managed databases support a high-availability (HA) mode that provisions a standby replica in a different Availability Zone. Failover is automatic — if the primary fails, Lightsail promotes the standby within 1–2 minutes. HA mode doubles the monthly cost. Enable it for any production database where downtime is unacceptable. Note that HA mode in Lightsail is read replica + automatic failover only; it does not support read scaling from the standby like RDS Multi-AZ.

Enabling Automatic Backups

# Enable automatic backups with 7-day retention
aws lightsail update-relational-database \
  --relational-database-name "myapp-db" \
  --enable-backup-retention \
  --backup-retention-enabled

# Create a manual snapshot before a major schema migration
aws lightsail create-relational-database-snapshot \
  --relational-database-name "myapp-db" \
  --relational-database-snapshot-name "pre-migration-2026-06-09"

Container Service: Deploying Docker Images

Lightsail container service lets you run Docker containers without managing servers. It is simpler than ECS Fargate: you define a container deployment with a Docker image, environment variables, ports, and health checks — and Lightsail handles the underlying infrastructure. Container services have a public HTTPS endpoint generated automatically, and you can scale up by adding nodes to the service.

Container Service Plans

PowerRAM/nodevCPU/nodePrice/node/mo
Nano512 MB0.25$7.00
Micro1 GB0.25$10.00
Small2 GB0.5$25.00
Medium4 GB1$50.00
Large8 GB2$100.00
XLarge16 GB4$200.00

Creating a Container Service

# Create a Micro container service with 1 node
aws lightsail create-container-service \
  --service-name "myapp-api" \
  --power micro \
  --scale 1

# Push an image to the Lightsail container registry
# First, get the push credentials
aws lightsail create-container-service-registry-login

# Tag and push your image
docker tag myapp:latest \
  amazonaws.com/v1/123456789012:container-service.myapp-api.us-east-1/myapp:latest

# Or pull from Docker Hub directly in the deployment config (public images)

Deploying a Docker Compose-style Configuration

Lightsail container deployments use a JSON configuration that is conceptually similar to Docker Compose. You define containers with images, environment variables, ports, and health check commands.

{
  "containers": {
    "api": {
      "image": "public.ecr.aws/nginx/nginx:latest",
      "ports": {
        "80": "HTTP"
      },
      "environment": {
        "NODE_ENV": "production",
        "DB_HOST": "ls-abc123.czowadgeezs0.us-east-1.rds.amazonaws.com",
        "DB_PORT": "5432",
        "DB_NAME": "myapp_production"
      },
      "command": ["nginx", "-g", "daemon off;"]
    }
  },
  "publicEndpoint": {
    "containerName": "api",
    "containerPort": 80,
    "healthCheck": {
      "healthyThreshold": 2,
      "unhealthyThreshold": 2,
      "timeoutSeconds": 5,
      "intervalSeconds": 30,
      "path": "/health",
      "successCodes": "200-299"
    }
  }
}
# Deploy the container configuration
aws lightsail create-container-service-deployment \
  --service-name "myapp-api" \
  --cli-input-json file://deployment.json

# Check deployment status
aws lightsail get-container-service-deployments \
  --service-name "myapp-api" \
  --query "deployments[0].{State:state,Version:version,Created:createdAt}"

# Get the public endpoint URL
aws lightsail get-container-services \
  --service-name "myapp-api" \
  --query "containerServices[0].url"

# Scale up to 3 nodes (horizontal scaling)
aws lightsail update-container-service \
  --service-name "myapp-api" \
  --scale 3
Container service vs Lightsail instance: Use a container service when you want zero OS management — no SSH, no patching, no disk maintenance. Use an instance when you need persistent local storage, OS-level configuration, or applications that are not containerized. Container services are ideal for stateless APIs, microservices, and background workers that can be deployed as Docker images. The public endpoint is a subdomain of *.{region}.cs.amazonlightsail.com with automatic TLS — similar to App Runner's generated URL.

Storage: Object Storage, Block Disks, and Snapshots

Lightsail provides three types of storage: the root SSD included with each instance, attachable block storage disks for additional capacity, and object storage buckets for unstructured data. All three have flat monthly pricing.

Object Storage Buckets

Lightsail object storage is S3-compatible — it exposes the same S3 API, so any SDK or tool that works with S3 works with Lightsail buckets. The pricing model is simpler: flat monthly fee for a storage tier rather than per-GB per-request charges.

# Create an object storage bucket
aws lightsail create-bucket \
  --bucket-name "myapp-assets" \
  --bundle-id "small_1_0"
# Bundles: small_1_0 (5 GB, 25 GB transfer, $1/mo)
#          medium_1_0 (100 GB, 250 GB transfer, $3/mo)
#          large_1_0 (250 GB, 500 GB transfer, $7/mo)

# Make bucket publicly readable (for static assets)
aws lightsail update-bucket \
  --bucket-name "myapp-assets" \
  --access-rules '{"getObject":"public","allowPublicOverrides":true}'

# Upload a file using the S3 CLI (Lightsail buckets are S3-compatible)
aws s3 cp ./logo.png s3://myapp-assets/images/logo.png \
  --endpoint-url https://s3.us-east-1.amazonaws.com

# Generate a pre-signed URL for private file access
aws lightsail get-bucket-access-keys \
  --bucket-name "myapp-assets"

Block Storage Disks

When your application needs more disk space than the instance's included SSD provides, attach a block storage disk. Disks are independent resources — they persist independently of the instance and can be detached and reattached to a different instance in the same Availability Zone.

# Create a 32 GB block disk
aws lightsail create-disk \
  --disk-name "myapp-data-disk" \
  --availability-zone "us-east-1a" \
  --size-in-gb 32

# Attach the disk to your instance
aws lightsail attach-disk \
  --disk-name "myapp-data-disk" \
  --instance-name "my-web-server" \
  --disk-path "/dev/xvdf"

# On the instance: format and mount the disk
sudo mkfs -t ext4 /dev/xvdf
sudo mkdir -p /data
sudo mount /dev/xvdf /data

# Make the mount persistent across reboots
echo '/dev/xvdf /data ext4 defaults,nofail 0 2' | sudo tee -a /etc/fstab
Disk pricing: Lightsail block disks cost $0.10/GB/month — the same as EBS gp2 on EC2. However, disk I/O is included in the flat Lightsail billing, whereas EBS charges separately for IOPS on io1/io2 volumes. For write-heavy workloads (database data directories, log aggregation), the Lightsail included pricing is predictable. For IOPS-critical workloads (high-performance databases), the EC2 + EBS combination with provisioned IOPS gives you more control.

Networking: DNS, Load Balancers, SSL, and CloudFront

Lightsail includes a full networking stack: DNS zone management, HTTP/HTTPS load balancers with built-in TLS certificate provisioning, and integration with CloudFront for CDN distribution. These are all flat-rate resources included in the Lightsail pricing model.

DNS Zones

Create a DNS zone for your domain in Lightsail, then delegate the domain to Lightsail's nameservers at your domain registrar. Lightsail DNS is free — no per-query charges unlike Route 53.

# Create a DNS zone
aws lightsail create-domain \
  --domain-name "example.com"

# The response includes nameserver entries to configure at your registrar:
# ns-1234.awsdns-56.org
# ns-789.awsdns-01.co.uk
# ns-012.awsdns-34.com
# ns-345.awsdns-67.net

# Add an A record pointing to your static IP
aws lightsail create-domain-entry \
  --domain-name "example.com" \
  --domain-entry '{
    "name": "www.example.com",
    "target": "203.0.113.45",
    "type": "A",
    "isAlias": false
  }'

# Add a CNAME for a subdomain
aws lightsail create-domain-entry \
  --domain-name "example.com" \
  --domain-entry '{
    "name": "api.example.com",
    "target": "myapp-api.us-east-1.cs.amazonlightsail.com",
    "type": "CNAME",
    "isAlias": false
  }'

# Add MX records for email
aws lightsail create-domain-entry \
  --domain-name "example.com" \
  --domain-entry '{
    "name": "example.com",
    "target": "10 mail.example.com",
    "type": "MX",
    "isAlias": false
  }'

Load Balancers and SSL Certificates

Lightsail load balancers distribute traffic across multiple instances and terminate TLS. SSL certificates are provisioned automatically via ACM at no additional cost beyond the load balancer fee ($18/month).

# Create a load balancer
aws lightsail create-load-balancer \
  --load-balancer-name "myapp-lb" \
  --instance-port 80 \
  --health-check-path "/health"

# Attach instances to the load balancer
aws lightsail attach-instances-to-load-balancer \
  --load-balancer-name "myapp-lb" \
  --instance-names "web-server-1" "web-server-2"

# Create a TLS certificate for your domain
aws lightsail create-load-balancer-tls-certificate \
  --load-balancer-name "myapp-lb" \
  --certificate-name "example-com-cert" \
  --certificate-domain-name "example.com" \
  --certificate-alternative-names "www.example.com"

# Attach the certificate to the load balancer
aws lightsail attach-load-balancer-tls-certificate \
  --load-balancer-name "myapp-lb" \
  --certificate-name "example-com-cert"

# Get load balancer DNS name (use this in your CNAME record)
aws lightsail get-load-balancer \
  --load-balancer-name "myapp-lb" \
  --query "loadBalancer.dnsName"

CloudFront Distribution from Lightsail

Lightsail integrates with CloudFront to create a CDN distribution in front of your instance or load balancer. This reduces latency globally and offloads static asset delivery from your server.

# Create a CloudFront distribution for a Lightsail instance
aws lightsail create-distribution \
  --distribution-name "myapp-cdn" \
  --origin '{
    "name": "my-web-server",
    "resourceType": "Instance",
    "regionName": "us-east-1",
    "protocolPolicy": "https-only"
  }' \
  --default-cache-behavior '{"behavior": "cache"}' \
  --bundle-id "small_1_0"

# Get the distribution domain name
aws lightsail get-distribution \
  --distribution-name "myapp-cdn" \
  --query "distribution.domainName"

VPC Peering: Connecting Lightsail to Your AWS Account

By default, Lightsail resources live in a separate, isolated network. They cannot directly communicate with resources in your AWS account's default VPC — EC2 instances, RDS databases, ElastiCache clusters, or any other VPC-based service. VPC peering creates a private network connection between the Lightsail network and your default VPC, enabling private IP communication without traffic traversing the public internet.

VPC peering is free and takes about 60 seconds to enable. It is a one-time operation per AWS Region, and once enabled, all Lightsail instances in that region can communicate with your default VPC resources using private IP addresses.

# Enable VPC peering (one command — it's that simple)
aws lightsail peer-vpc

# Verify peering status
aws lightsail get-vpc-peering \
  --query "isPeered"

# After peering is enabled, your Lightsail instance can connect to
# EC2 or RDS resources using their private IPs or DNS names.

# Example: Connect from a Lightsail instance to an RDS database in the default VPC
# (From within the Lightsail instance via SSH)
mysql -h mydb.cxxx.us-east-1.rds.amazonaws.com \
      -u admin -p \
      --ssl-ca=/etc/ssl/certs/Amazon_RDS_CA.pem

Use Cases for VPC Peering

VPC peering unlocks several hybrid patterns where Lightsail handles the simple, cost-effective front end and your main VPC handles the complex or data-intensive back end.

  • WordPress on Lightsail + RDS MySQL in VPC: Use Lightsail's $5/month instance for the WordPress application tier, but point it at an RDS Multi-AZ MySQL instance for the database. You get Lightsail's simplicity for the web server with RDS's superior durability and read replica support for the database.
  • Lightsail API + ElastiCache Redis: Cache session data and API responses in an ElastiCache cluster, which cannot be accessed publicly — requires VPC peering for Lightsail instances to reach it.
  • Lightsail instance + EC2 private services: A Lightsail instance can act as a front-end web server while EC2 instances in the VPC run background processing services that are not publicly accessible.
  • Development environment isolation: Keep development Lightsail instances separate from production VPC resources, but peer them to access shared development databases.
Peering limitation — only the default VPC: Lightsail VPC peering only works with the default VPC in each region. If you have moved all your resources to custom VPCs (which is best practice for production AWS accounts), you cannot peer Lightsail directly with those VPCs. The workaround is to keep a transit EC2 instance in the default VPC that bridges traffic, or to use a VPN or Direct Connect-based architecture. This is one of the significant reasons to eventually migrate from Lightsail to EC2 if your infrastructure complexity grows.

Snapshots and Backups: Manual, Automatic, Cross-Region

Lightsail snapshots are point-in-time backups of your instances, block disks, and managed databases. Snapshots capture the entire state of a resource — the OS, installed software, configuration files, and data — and store it in S3 behind the scenes. You can restore a snapshot to create a new instance, which is useful for disaster recovery, testing, and scaling (launch N identical instances from the same snapshot).

Manual Snapshots

# Create a manual instance snapshot
aws lightsail create-instance-snapshot \
  --instance-name "my-web-server" \
  --instance-snapshot-name "my-web-server-2026-06-09"

# Create a disk snapshot
aws lightsail create-disk-snapshot \
  --disk-name "myapp-data-disk" \
  --disk-snapshot-name "data-disk-2026-06-09"

# List all snapshots
aws lightsail get-instance-snapshots \
  --query "instanceSnapshots[*].{Name:name,State:state,Size:sizeInGb,Created:createdAt}"

# Restore a snapshot to a new instance
aws lightsail create-instances-from-snapshot \
  --instance-snapshot-name "my-web-server-2026-06-09" \
  --instance-names "my-web-server-restored" \
  --availability-zone "us-east-1b" \
  --bundle-id "small_3_0"

Automatic Snapshots

# Enable automatic daily snapshots
aws lightsail enable-add-on \
  --resource-name "my-web-server" \
  --add-on-request '{
    "addOnType": "AutoSnapshot",
    "autoSnapshotAddOnRequest": {
      "snapshotTimeOfDay": "02:00"
    }
  }'

# Automatic snapshots are retained for 7 days. You cannot change the retention
# period — for longer retention, promote a snapshot to a manual snapshot:
aws lightsail copy-snapshot \
  --source-snapshot-name "my-web-server-2026-06-09" \
  --source-region "us-east-1" \
  --target-snapshot-name "my-web-server-monthly-2026-06" \
  --target-region "us-east-1"

Cross-Region Snapshot Copy

# Copy a snapshot to another region for disaster recovery
aws lightsail copy-snapshot \
  --source-snapshot-name "my-web-server-2026-06-09" \
  --source-region "us-east-1" \
  --target-snapshot-name "my-web-server-dr-2026-06-09" \
  --target-region "eu-west-1"

# Verify the copy in the target region
aws lightsail get-instance-snapshots \
  --region "eu-west-1" \
  --query "instanceSnapshots[?name=='my-web-server-dr-2026-06-09']"
Snapshot pricing: Lightsail snapshots cost $0.05/GB/month — the same as EBS snapshot pricing. A 60 GB instance snapshot costs about $3/month. Automatic snapshots are included in this pricing; you pay only for storage consumed. Cross-region copies incur the snapshot storage cost in the destination region plus a one-time data transfer fee. For critical production workloads, maintain at least one cross-region snapshot copy in addition to automatic daily snapshots.

Migration Path: Graduating from Lightsail to EC2

Lightsail is designed for straightforward workloads. As your startup scales — needing auto scaling groups, custom VPCs, IAM instance profiles, RDS read replicas, or EC2 instance types tuned for specific workloads — you will eventually outgrow it. AWS provides official migration paths: exporting a Lightsail instance snapshot as an EC2 AMI, and migrating a Lightsail database to RDS.

When to Migrate from Lightsail to EC2

The decision to migrate is driven by specific capabilities you need that Lightsail cannot provide:

  • Auto scaling: Lightsail has no Auto Scaling Group equivalent. You scale manually or via scripted CLI commands. When you need automatic horizontal scaling based on CPU, memory, or request count metrics, migrate to EC2 + ASG or ECS Fargate.
  • Custom VPC with private subnets: Lightsail VPC peering only reaches the default VPC. Production architectures typically use custom VPCs with public and private subnets. If you need your application tier in a private subnet with NAT gateway access, migrate to EC2.
  • Specialized EC2 instance types: Lightsail's burstable instances are fine for web workloads. GPU instances (for ML inference), compute-optimized instances (for CPU-heavy processing), or memory-optimized instances (for in-memory databases) require EC2.
  • Advanced IAM: EC2 instance profiles let you assign fine-grained IAM roles to instances. Lightsail instances can only access AWS services via access keys — not instance-profile-based authentication.

Exporting a Lightsail Snapshot to EC2 AMI

# Step 1: Create a final instance snapshot
aws lightsail create-instance-snapshot \
  --instance-name "my-web-server" \
  --instance-snapshot-name "migration-snapshot-final"

# Step 2: Export the snapshot to EC2
aws lightsail export-snapshot \
  --source-snapshot-name "migration-snapshot-final"

# This creates an EC2 AMI. Find it in the EC2 console under AMIs,
# or list it with:
aws ec2 describe-images \
  --owners self \
  --filters "Name=name,Values=*Lightsail*" \
  --query "Images[*].{ID:ImageId,Name:Name,State:State,Created:CreationDate}"

# Step 3: Launch an EC2 instance from the AMI
aws ec2 run-instances \
  --image-id ami-0abc1234def567890 \
  --instance-type t3.small \
  --key-name my-ec2-keypair \
  --security-group-ids sg-0abc123 \
  --subnet-id subnet-0abc123 \
  --iam-instance-profile Name=WebServerInstanceProfile \
  --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=migrated-web-server}]'

Migrating a Lightsail Database to RDS

# Lightsail does not support direct snapshot export to RDS.
# Use mysqldump / pg_dump for database migration.

# Step 1: Create a final database snapshot
aws lightsail create-relational-database-snapshot \
  --relational-database-name "myapp-db" \
  --relational-database-snapshot-name "migration-db-final"

# Step 2: Enable public access temporarily for the dump (or use VPC peering from an EC2 instance)
aws lightsail update-relational-database \
  --relational-database-name "myapp-db" \
  --publicly-accessible

# Step 3: Dump the database from your local machine or a migration EC2 instance
mysqldump \
  -h ls-abc123.czowadgeezs0.us-east-1.rds.amazonaws.com \
  -u dbadmin -p \
  --single-transaction \
  --all-databases \
  > lightsail_dump.sql

# Step 4: Create a new RDS instance in your target VPC
aws rds create-db-instance \
  --db-instance-identifier myapp-rds \
  --db-instance-class db.t3.small \
  --engine mysql \
  --engine-version 8.0 \
  --master-username dbadmin \
  --master-user-password securepassword \
  --allocated-storage 100 \
  --db-subnet-group-name myapp-subnet-group \
  --vpc-security-group-ids sg-0abc123 \
  --multi-az \
  --no-publicly-accessible

# Step 5: Restore the dump to RDS
mysql \
  -h myapp-rds.cxxx.us-east-1.rds.amazonaws.com \
  -u dbadmin -p \
  < lightsail_dump.sql

# Step 6: Update application configuration to point to RDS endpoint
# Step 7: Disable public access on Lightsail DB and schedule deletion
Zero-downtime migration strategy: For production databases, use AWS Database Migration Service (DMS) instead of mysqldump to perform a live migration with minimal downtime. DMS can replicate data continuously from the Lightsail database to the RDS target, keeping them in sync while you update and test your application configuration. When you are ready to cut over, update the database connection string and DNS records simultaneously. Total downtime with DMS is typically under 30 seconds — versus the hours of downtime that a large mysqldump restore would cause.