Cloud / Amazon LightSail Interview questions

Amazon Lightsail is an AWS service that gives you a virtual private server (VPS) with the supporting pieces already bundled: SSD storage, a monthly data transfer allowance, a static IP option, DNS, and a simple console. You pick an operating system or app, pick a size, and the server is running in a couple of minutes.

It targets people who want AWS reliability without learning VPC design, security groups, EBS volume types, and instance families first. Pricing is a flat monthly figure per bundle, so the bill is easy to predict.

Beyond servers, Lightsail also offers containers, managed MySQL/PostgreSQL databases, load balancers, CDN distributions, and object storage buckets.

Lightsail packs the common building blocks of a small web workload into one console:

• Instances with preconfigured OS and application blueprints
• Containers through a managed container service
• Managed databases for MySQL and PostgreSQL
• Load balancers with free TLS certificates
• CDN distributions for caching static and dynamic content
• Object storage buckets and attachable block storage disks
• Static IPs, DNS zones, snapshots, alarms, and firewall rules

Everything is also reachable through the AWS CLI, SDKs, and CloudFormation, so you are not limited to clicking in the console.

Lightsail suits developers, small businesses, students, and agencies who need a simple, low-cost server and do not want to manage a large AWS architecture. Typical workloads are blogs, WordPress and Magento sites, small web apps, dev and test environments, and hobby projects.

It is also a sensible first step into AWS. You can start small, and later connect to other AWS services or move to EC2 when needs grow.

It is a weaker fit for workloads that need auto scaling groups, custom VPC layouts, specialized instance families, or fine-grained IAM integration. Those belong on EC2 or container services built for scale.

A Lightsail instance is a virtual private server running in an AWS Region and Availability Zone you choose. It is created from a blueprint (the OS or app image) and a bundle (the size and price plan).

Each instance has a private IP, a public IP, a SSD system disk, and its own firewall rules. You manage it with SSH for Linux or RDP for Windows, either from your own client or from the browser-based client in the console.

Instances can be stopped, started, rebooted, snapshotted, and resized by building a new instance from a snapshot.

A blueprint is the software image Lightsail installs on a new instance. There are two kinds:

1. OS only - for example Amazon Linux, Ubuntu, Debian, AlmaLinux, CentOS, and Windows Server
2. Apps + OS - WordPress, LAMP, Node.js, MEAN, Ruby on Rails, Drupal, Magento, cPanel & WHM, Plesk, and others

App blueprints save setup time because the stack is installed and configured at first boot. In January 2026 AWS refreshed the Node.js, LAMP, and Ruby on Rails blueprints and enforced IMDSv2 on them by default.

A bundle is a prepackaged plan that sets the instance size and price. Each bundle fixes the number of vCPUs, the memory, the SSD size, and the monthly data transfer allowance.

Bundles are billed hourly but capped at the monthly price, so running an instance all month costs the listed monthly amount. Bundles come in different networking types too: dual-stack (IPv4 + IPv6) and IPv6-only, with IPv6-only generally cheaper.

You cannot tweak a single value, such as adding only RAM. To change size you move to a different bundle.

Lightsail groups instance bundles by workload profile:

Compute-optimized bundles were added in April 2026 and scale up to 72 vCPUs in seven sizes, with IPv6-only and dual-stack options. They support all Lightsail blueprints, Windows included.

Pick general purpose first. Move to compute-optimized or memory-optimized only when metrics show sustained CPU or memory pressure, since larger specialized bundles cost more.

A static IP is a fixed public IPv4 address you reserve and attach to an instance. Without it, an instance's public IP can change when you stop and start it.

Attach a static IP before you create DNS records, so your domain keeps pointing at the right server. It stays with the instance across stop/start cycles, and you can detach it and attach it to a replacement instance.

A static IP is free while attached to a running resource. If you leave it unattached, AWS charges for it, so release it when you no longer need it.

A snapshot is a point-in-time backup of a Lightsail resource. You can snapshot instances, block storage disks, and managed databases.

Instance snapshots capture the system disk and attached disks. You can use one to launch a copy of the instance, even in a different Availability Zone or Region, or to upgrade to a larger bundle.

Snapshots are stored in AWS and billed per GB-month. You can create them manually before risky changes or let Lightsail create them automatically each day.

A Lightsail managed database is a MySQL or PostgreSQL database that Lightsail provisions, patches, and backs up for you. You choose a bundle with set vCPU, memory, storage, and transfer, then connect with the endpoint, port, and master credentials.

It comes in two plans: standard (one Availability Zone) and high availability (a standby in another zone with automatic failover). In January 2026 AWS added two larger bundles, up to 8 vCPUs, 32 GB of memory, and 960 GB of SSD.

Automatic backups and point-in-time restore are built in.

The Lightsail container service lets you run Docker containers without managing servers. You create a service, choose a power (CPU and memory per node) and a scale (number of nodes), then deploy one or more containers.

The service provides a public HTTPS endpoint with a default domain, and you can attach your own domain and certificate. Images can come from public registries, from private Amazon ECR repositories, or be pushed from your machine with the Lightsail Control (lightsailctl) plugin.

Each deployment is versioned, and failed deployments can be rolled back to the last working one.

A Lightsail load balancer spreads incoming HTTP and HTTPS traffic across several instances in the same Region. It performs health checks and sends requests only to healthy targets.

It terminates TLS using free certificates you create in Lightsail, can redirect HTTP to HTTPS, and supports optional session persistence through cookies.

It improves availability and lets you scale horizontally by adding instances. Note that it works at the application layer, so it is not a general TCP load balancer.

Instances must sit in the same Region as the balancer, and you can attach several of them at once. Removing one for maintenance does not interrupt visitors.

A Lightsail CDN distribution is a content delivery network, powered by Amazon CloudFront, that caches your content at edge locations around the world. Visitors are served from a location near them, which lowers latency and reduces load on the origin.

Supported origins are Lightsail instances, container services, buckets, and load balancers. In May 2026, IPv6-only instances were added as supported origins too.

Each distribution includes a monthly transfer allowance, and you can attach a custom domain with a certificate.

You choose what gets cached: everything, static files only, or nothing. That lets images and scripts load fast while dynamic pages still reach the origin on every request.

Lightsail object storage gives you buckets that store files such as images, backups, and static site assets. A bucket plan bundles a set amount of storage and data transfer for a flat monthly price.

Buckets are private by default. You can make objects public read-only, grant access to specific Lightsail instances, or create access keys for programmatic use. Versioning protects against accidental overwrites.

The API is S3-compatible, so common tools and SDKs work. A bucket can also be a CDN origin for faster global delivery.

A block storage disk is extra SSD storage you attach to an instance, like adding a second drive. Disks are useful when the system disk is too small or when data should live apart from the OS.

Key points:

• A disk must be in the same Availability Zone as the instance.
• Up to 16 TB per disk, and up to 15 disks per instance.
• On Linux you must format and mount it yourself before use.
• Disks can be snapshotted and detached, then reattached elsewhere.

A DNS zone holds the DNS records for a domain you own, such as A, AAAA, CNAME, MX, and TXT records. Lightsail hosts the zone on its own name servers, at no extra charge.

After creating the zone, you update your registrar's name servers to the four Lightsail values. Then you add records, for example an A record pointing the domain at a static IP, or MX records for email.

You can also register a domain directly from Lightsail, and the service can create the zone for you.

The quickest route is the browser-based SSH or RDP client in the console. For a terminal, download the default key pair for the Region and run SSH with the right username:

chmod 400 LightsailDefaultKey-us-east-1.pem
ssh -i LightsailDefaultKey-us-east-1.pem ubuntu@203.0.113.10

The username depends on the image: ubuntu on Ubuntu, ec2-user on Amazon Linux, admin on Debian, and bitnami on Bitnami-based app blueprints.

Windows instances use RDP: you retrieve the administrator password from the console, then connect on port 3389. Make sure the firewall allows SSH (22) or RDP (3389) from your IP.

In the console, choose Create instance and follow these steps:

1. Select the AWS Region and Availability Zone.
2. Pick the platform (Linux/Unix or Windows) and a blueprint.
3. Optionally add a launch script that runs at first boot.
4. Choose or upload an SSH key pair.
5. Choose the networking type (dual-stack or IPv6-only).
6. Select a bundle, name the instance, and click create.

The same task from the CLI:

aws lightsail create-instances \
  --instance-names web-1 \
  --availability-zone us-east-1a \
  --blueprint-id ubuntu_24_04 \
  --bundle-id nano_3_0

Run aws lightsail get-blueprints and get-bundles to list valid IDs.

Lightsail offers Linux and Windows images. Linux options include Amazon Linux, Ubuntu, Debian, AlmaLinux, CentOS, and others, while Windows Server images are available for .NET and other Windows workloads.

On top of those are application blueprints such as WordPress, LAMP, Node.js, MEAN, Ruby on Rails, Drupal, Magento, cPanel & WHM, and Plesk.

The available list changes over time as images are added or retired, so check the blueprint list in your Region before planning a deployment. Compute-optimized bundles support all of them.

Every instance has its own firewall that controls inbound traffic by protocol, port, and source. Rules only allow traffic. There are no deny rules, so anything not allowed is blocked.

New Linux instances open SSH (22) and HTTP (80). Windows instances open RDP (3389) and HTTP (80). You add rules for HTTPS (443), databases, or custom ports.

Good habits:

• Restrict SSH and RDP to your own IP address.
• Manage IPv4 and IPv6 rules separately, since both lists apply.
• Remember that the OS firewall (ufw, iptables, Windows Firewall) is a second layer.

Lightsail trades flexibility for simplicity. You pick from fixed bundles with predictable monthly prices, while EC2 exposes the full AWS toolbox and you assemble and pay for each piece.

Use Lightsail for small, steady workloads. Choose EC2 when you need fine control, advanced networking, or elasticity.

Both aim to ease deployment, but they work differently. Elastic Beanstalk orchestrates standard AWS resources (EC2, Auto Scaling, load balancer) for an application you upload, and you pay for those resources individually. Lightsail gives you a server or container service with a bundled flat price, and you manage the app yourself.

If the app must grow and shrink automatically, Beanstalk fits better. For one predictable site, Lightsail is simpler and often cheaper.

Instances are sold as bundles with a flat monthly price that already includes compute, SSD storage, and a data transfer allowance. Billing is hourly but capped at the monthly price.

Other resources are priced on their own:

• Load balancers, CDN distributions, and container services have fixed monthly plans.
• Managed databases use bundles with included storage and transfer.
• Extra block storage disks and snapshots are billed per GB-month.
• Unattached static IPs and data transfer beyond the allowance are charged.

A key gotcha: a stopped instance still bills. To stop paying, delete the resource. New customers can often use a free trial on selected bundles, so verify the current offer on the pricing page.

Each bundle includes a monthly outbound data transfer allowance. Inbound traffic is free. The allowances from your instances in the account are pooled, so one quiet server can cover for a busy one.

When total outbound traffic passes the pooled allowance, the excess is billed per GB at the rate on the pricing page. Traffic between Lightsail resources over private IPs in the same Region does not count against it.

To keep transfer under control:

1. Put static files in a bucket behind a CDN distribution.
2. Set up a network-out alarm so you hear about spikes.
3. Compress responses and cache aggressively.

Dual-stack instances get both a public IPv4 and an IPv6 address, so any client can reach them. IPv6-only instances have no public IPv4 address, which lowers the bundle price.

If you want IPv6-only savings but still serve visitors on IPv4-only networks, put a Lightsail CDN distribution in front. Since May 2026 distributions accept IPv6-only instances as origins and translate for those visitors.

The default public IP is tied to the running instance and can change after a stop/start. Any DNS record, allowlist, or third-party integration that uses the old address then breaks.

A static IP fixes this in three ways:

• The address survives stop/start cycles.
• You can move it to a new instance during a rebuild or resize, with no DNS change.
• Partners can safely allowlist it.

Create the static IP in the same Region, attach it to the instance, then use it in your A record. Remember to release it if you delete the instance, since an unattached static IP is charged.

When you enable automatic snapshots on an instance or a disk, Lightsail takes one snapshot per day at the time you choose. It keeps the seven most recent daily copies and deletes older ones.

The first automatic snapshot appears shortly after you enable the feature, then follows the daily schedule. You can restore from any retained copy, or create a new instance from it.

Important limits:

• Automatic snapshots expire; copy one to a manual snapshot to keep it long term.
• They are billed like regular snapshot storage.
• They protect against loss of the instance, but do not replace application-level or database-level backups.

Lightsail does not overwrite the running server. You create a new instance from the snapshot, which gives a clean copy of the saved state.

1. Open the snapshot in the console and choose Create new instance.
2. Pick the Region, Availability Zone, and a bundle the same size or larger.
3. Name it, create it, and test it.
4. Move the static IP from the old instance to the new one.
5. Delete the old instance once you are satisfied.

Since the new instance gets a new private IP and possibly a new public IP, update anything that referenced the old addresses.

Lightsail has no in-place resize. You build a bigger copy from a snapshot and swap over.

flowchart LR
A["Running instance"] --> B["Create snapshot"]
B --> C["New instance from snapshot with larger bundle"]
C --> D["Move static IP"]
D --> E["Test, then delete old instance"]

Steps:

1. Take a snapshot of the current instance.
2. Create a new instance from it and pick a larger bundle.
3. Reattach the static IP, or update DNS.
4. Verify the app, then delete the old instance.

You can move to the same size or larger, but not to a smaller bundle. To downsize, build a fresh smaller instance and migrate the data manually. Schedule a short maintenance window, since data written after the snapshot is not copied.

An instance snapshot captures the system disk and any attached disks, so you can recreate the full server. A disk snapshot captures a single block storage disk.

Use instance snapshots for cloning and resizing. Use disk snapshots when the data disk needs its own backup schedule or must be attached to a different instance.

Attach a block storage disk. It is the easiest way to add space without changing the bundle.

1. Create a disk in the same Availability Zone as the instance.
2. Attach it to the instance in the console or CLI.
3. Connect over SSH, find the device, format it, and mount it.
4. Add an entry to /etc/fstab so it mounts after reboot.

lsblk
sudo mkfs -t ext4 /dev/nvme1n1
sudo mkdir /data
sudo mount /dev/nvme1n1 /data

Device names vary, so confirm with lsblk before formatting. Formatting the wrong device destroys data. For files that do not need a filesystem, a bucket is cheaper.

Lightsail issues free TLS certificates for load balancers. The process uses DNS validation:

1. Create a certificate for your domain in the load balancer's Inbound traffic tab.
2. Add the CNAME validation records that Lightsail shows to your DNS zone.
3. Wait until the certificate status becomes valid.
4. Attach it, then enable the HTTPS redirect if you want HTTP to forward to HTTPS.

Certificates renew automatically as long as the validation record stays in DNS. Do not delete it. Backend instances can still speak plain HTTP behind the load balancer, because TLS ends at the balancer.

The balancer sends each request to one of the attached healthy instances using a round-robin style approach. Health is decided by a health check on a path you set, such as /health. An instance that fails repeatedly is removed from rotation until it passes again.

Points to configure:

• Health check path - return HTTP 200 only when the app is truly ready.
• Session persistence - cookie-based stickiness, useful when sessions live in memory.
• Instances - up to 20 per balancer, in the same Region.

Prefer keeping session state outside the servers, for example in a managed database, so any instance can serve any request.

A distribution places copies of your content at edge locations. A visitor's request reaches the nearest edge. On a cache hit it is answered right there. On a miss, the edge fetches from your origin, stores the result, and serves it.

sequenceDiagram
participant U as Visitor
participant E as Edge location
participant O as Origin
U->>E: Request
alt Cache hit
E-->>U: Cached response
else Cache miss
E->>O: Fetch
O-->>E: Response
E-->>U: Response, now cached
end

You control behavior with cache settings: cache everything, cache only static files, or cache nothing for dynamic paths. Use per-path behaviors so images are cached for a long time while the login page is not. For HTTPS on a custom domain, attach a certificate to the distribution.

You create a container service, then submit a deployment that describes the containers and the public endpoint.

1. Create the service and pick its power and scale.
2. Build the image locally and push it with lightsailctl.
3. Create a deployment: image, ports, environment variables, and the container that receives public traffic.
4. Set the health check path, then deploy.

aws lightsail push-container-image \
  --service-name my-app \
  --label web \
  --image my-app:latest

The command returns an image reference such as :my-app.web.1, which you use in the deployment. Lightsail launches the new version, waits for health checks, and then switches traffic. If it fails, the previous deployment stays active.

Power sets the CPU and memory of each node, ranging from nano to xlarge. Scale sets how many nodes run, from 1 up to 20.

Total capacity is power multiplied by scale, and the monthly price follows the same product. For example, a medium power service at scale 3 costs three times the price of a single medium node.

Changing either value triggers a new deployment. Raise power when one container needs more memory or CPU. Raise scale for more concurrency and redundancy across nodes. Lightsail does not auto scale, so you adjust these values yourself, based on metrics.

The standard plan runs one database node in a single Availability Zone. If that zone has a problem, the database is unavailable until it recovers. The high-availability plan adds a standby in a second zone and fails over automatically.

Use HA when downtime costs more than the extra monthly price, such as for stores and SaaS products. Both plans keep automatic backups, so HA is about availability rather than backup safety.

Both must be in the same Region. Take the database endpoint, port, and master credentials from the database's Connect tab, then use them from the instance.

mysql -h ls-abc123.xyz.us-east-1.rds.amazonaws.com \
  -P 3306 -u dbmasteruser -p

Lightsail databases are reachable from instances in your Lightsail VPC over the private network. That is the setup to prefer, because the database never touches the public internet.

Public mode opens the endpoint to outside clients, such as your laptop or a service in another cloud. Turn it on only when needed and for short periods, and combine it with strong passwords. The default ports are 3306 for MySQL and 5432 for PostgreSQL.

VPC peering creates a private network link between the Lightsail VPC and the default Amazon VPC in the same AWS Region. Resources then talk over private IPs, not the public internet.

Use it when a Lightsail instance needs to reach services running in your regular AWS account, such as an EC2 server, an RDS database, or an internal API.

To use it:

1. Enable VPC peering for the Region in the Lightsail account settings (Advanced).
2. Update security groups and firewall rules so the traffic is allowed.
3. Connect using private IP addresses.

Peering is per Region and not transitive. It reaches the default VPC, not every custom VPC.

Lightsail takes automatic daily backups of a managed database and keeps transaction logs, which enables point-in-time restore to any moment within the retention window, normally seven days.

A restore never overwrites the original. It creates a new database from the chosen time, and you then point your application at the new endpoint.

For longer retention, create manual snapshots, which stay until you delete them. Take one before a risky schema change or major version upgrade.

Test restores regularly. Also remember that a restore gives a new endpoint, so keep connection strings in config rather than hard-coded.

Lightsail metric alarms watch a metric and notify you when it crosses a threshold. For instances, you can alarm on CPU utilization, network in and out, status check failures, and burst capacity.

Setup:

1. Add a notification contact by email or, in supported Regions, SMS, and verify it.
2. Choose the resource and metric.
3. Set the comparison, threshold, and number of data points.
4. Decide how missing data should be treated.

Databases, load balancers, and container services also expose metrics you can alarm on. Pick thresholds from observed baselines, not guesses, so alerts stay meaningful instead of noisy.

General-purpose Lightsail instances are burstable. Each one has a baseline CPU level it can sustain, and it can go above that for a while using stored burst capacity. When the capacity runs out, the CPU is throttled to the baseline.

That is why a site can feel fine for weeks, then slow down after a traffic spike or a heavy cron job. The instance is not broken. It has spent its burst.

Watch the burst capacity percentage and burst capacity time metrics and set alarms on them. If capacity stays low, move to a larger bundle, or to a compute-optimized bundle, which offers dedicated CPU performance.

Start with the network, then the OS, then the application:

• Firewall: open only needed ports and restrict SSH or RDP to trusted IPs.
• SSH keys: use key authentication, disable password login, and avoid sharing the default key.
• Patching: apply OS updates regularly and keep apps like WordPress and plugins current.
• IMDSv2: require token-based metadata access to limit SSRF damage.
• HTTPS: use TLS through a load balancer certificate or on the server.
• Backups: enable automatic snapshots and test restores.
• Databases: keep public mode off unless you need it.

Add alarms for unusual CPU and network use, since a compromised server often shows up as odd traffic.

The Instance Metadata Service at 169.254.169.254 lets software on the instance read details about itself. With version 1, a simple GET request is enough. That makes it a target for SSRF attacks, where a flaw in the app tricks the server into fetching the metadata URL and leaking data.

IMDSv2 requires a session token. The client first sends a PUT request to obtain a token, then includes it in a header on every metadata call.

TOKEN=$(curl -s -X PUT http://169.254.169.254/latest/api/token \
  -H "X-aws-ec2-metadata-token-ttl-seconds: 60")
curl -s -H "X-aws-ec2-metadata-token: $TOKEN" \
  http://169.254.169.254/latest/meta-data/

Simple SSRF bugs cannot make that PUT with the custom header, so they fail. Since January 2026 the Node.js, LAMP, and Ruby on Rails blueprints enforce it by default. On older instances you can change the setting with the CLI, but test old scripts first because anything still using IMDSv1 will break.

Create an instance with the WordPress blueprint. WordPress, the web server, PHP, and the database come preinstalled, so the site is up shortly after launch.

1. Choose a bundle. A small one works for light traffic, but grow it if pages become slow.
2. Attach a static IP.
3. Connect over SSH to retrieve the generated admin password. The docs name the file for your blueprint version.
4. Point your domain to the static IP using a DNS zone, then open /wp-admin.
5. Enable HTTPS, for example with Let's Encrypt on Bitnami-based blueprints, or put a CDN distribution in front.

After that, enable automatic snapshots, keep plugins updated, and move media files to a bucket if storage or transfer grows.

Give the instance a fixed address, then tell the world to use it.

flowchart LR
A["Attach static IP"] --> B["Create DNS zone"]
B --> C["Add A record to static IP"]
C --> D["Set Lightsail name servers at registrar"]
D --> E["Wait for DNS propagation"]

1. Create and attach a static IP to the instance.
2. Create a DNS zone for the domain in Lightsail.
3. Add an A record for the root (@) and for www, pointing to the static IP. Add AAAA records if you use IPv6.
4. At the registrar, replace the name servers with the four Lightsail values.

Propagation can take from minutes to a day. Check with dig example.com. If you registered the domain with a different provider, you can also keep their DNS and simply add the A record there.

Work from the outside in, so you rule out the cheap causes first.

1. State and status checks: confirm the instance is running and check the status-check metric.
2. Address: after a stop/start the public IP may have changed if no static IP is attached.
3. Lightsail firewall: verify the port is open for your source IP, in both the IPv4 and IPv6 rule lists.
4. Browser SSH: if that works and your client does not, suspect your key, username, or local network.
5. Inside the OS: check the service is running and listening on the right interface, and review ufw or iptables.
6. Resources: look for exhausted memory, full disk, or depleted burst capacity.
7. DNS: make sure records point to the current address.

If the OS is damaged, snapshot it, build a new instance from the snapshot, or attach the disk to a rescue instance to repair files.

Costs are predictable, but waste still creeps in. Check these areas:

• Delete unused resources. A stopped instance still bills, as do idle disks, old snapshots, and unattached static IPs.
• Right-size bundles. Use CPU and burst metrics to find servers that are over- or under-provisioned.
• Use IPv6-only bundles where clients and dependencies allow it.
• Cut transfer. Serve static assets from a bucket behind a CDN distribution and compress responses.
• Prune snapshots. Keep a sensible retention rather than every copy forever.
• Set budgets and alarms in AWS Billing so overages surface early.

Review the bill monthly. Small orphaned items add up faster than people expect.

Every console action has an API call, so you can script servers with the aws lightsail commands, SDKs, CloudFormation, or Terraform.

A basic provisioning script:

aws lightsail create-instances --instance-names web-1 \
  --availability-zone us-east-1a \
  --blueprint-id ubuntu_24_04 --bundle-id nano_3_0

aws lightsail allocate-static-ip --static-ip-name web-1-ip
aws lightsail attach-static-ip --static-ip-name web-1-ip --instance-name web-1

aws lightsail open-instance-public-ports --instance-name web-1 \
  --port-info fromPort=443,toPort=443,protocol=TCP

aws lightsail create-instance-snapshot \
  --instance-name web-1 --instance-snapshot-name web-1-pre-deploy

Use a launch script to install packages at first boot. Store scripts in version control, and run them from CI to get repeatable environments. Check bundle and blueprint IDs with get-bundles and get-blueprints, as they change over time.

Move when you hit Lightsail's limits. Common triggers:

• You need Auto Scaling or spot capacity.
• You need an instance type that no bundle offers.
• You need custom VPC design, IAM instance roles, or advanced networking.
• Your architecture is growing into many AWS services.

Lightsail can export an instance snapshot to Amazon EC2. The export creates an Amazon EC2 image from the snapshot, which you then launch as an EC2 instance.

1. Create a fresh instance snapshot.
2. Choose Export to Amazon EC2 and confirm the IAM permissions.
3. Launch an EC2 instance from the exported image, picking the instance type and VPC.
4. Reconfigure security groups, test, then cut over DNS.

Keep the Lightsail server running until the EC2 copy is verified, and plan for a short sync of data written after the snapshot.