Amazon Lightsail sells servers as fixed-price monthly bundles. What is actually included in that price, and what does an engineer give up compared with running the same workload on EC2?
answer
- fixed monthly price, bundled resources
- transfer allowance is the distinctive part
- not in your own VPC
- peering only with the default VPC
- snapshot exports to EC2
basics
~20 sA Lightsail bundle rolls vCPU, memory, SSD storage and a monthly data-transfer allowance into one predictable price, with a simplified console and prebuilt blueprints. What you give up is the surrounding AWS ecosystem: your own VPC, Auto Scaling, and fine-grained integration.
solid answer
~50 sA Lightsail *bundle* is a fixed monthly price covering an instance's vCPU, RAM and SSD storage plus an included outbound **data-transfer allowance**; transfer beyond that allowance is billed per GB, and snapshots, extra block storage and unattached static IPs bill separately. Instances start from *blueprints* — a bare OS, or an OS with an application preinstalled — and the console gives you SSH in the browser, DNS zones and firewall rules without touching the EC2 console. Managed databases, load balancers, container services and CDN distributions are sold the same way, as their own bundles. The trade is integration: Lightsail instances live in an **AWS-managed VPC**, not yours, so reaching resources in your own network means enabling peering with that region's default VPC. There are no Auto Scaling groups and no deep service wiring. The exit is real, though — a Lightsail snapshot can be exported to EC2.
go deeper
Know that a Lightsail bundle is a fixed monthly price covering the instance, its storage and an included data-transfer allowance, with prebuilt blueprints to launch from.
Explain the trade precisely: instances live in an AWS-managed VPC rather than yours, peering reaches only the region's default VPC, and there is no Auto Scaling.
Judge when the simplicity is worth it and when it is a trap — cost predictability for a small predictable workload, versus the moment private networking or scaling requirements make EC2 the right call. Know the snapshot-export exit.
Own the policy angle: whether an organisation should allow Lightsail at all, given that it sits outside the VPC, tagging and networking conventions the rest of the estate is governed by.
## What Lightsail is for Lightsail is AWS's answer to the flat-rate VPS market: a small server at a price you can quote to a client, with a console that hides almost all of AWS. The target user is someone standing up a blog, a small internal tool, a staging box, or a low-traffic application, who does not want to make a dozen decisions to get a machine on the internet. ## What the bundle price covers One monthly number covers: - **vCPU and memory** at a fixed size — you choose from a short menu of bundles rather than a long instance-family catalogue; - **SSD storage** attached to the instance; - an **outbound data-transfer allowance** measured in TB per month, which is the genuinely distinctive part. Elsewhere in AWS, egress is metered from the first gigabyte, and it is the line item that surprises people. Lightsail folds a generous allowance into the price and bills per GB only above it; - a **static IP** while it is attached to a running instance, plus DNS zone hosting. Billing is prorated hourly up to the monthly cap, so a machine that runs for a week costs a week. ## What it does not cover - **Overage on data transfer** — the fixed price stops being fixed once you exceed the allowance. - **Snapshots and extra block storage**, which are billed per GB-month. - **A static IP that is not attached to a running instance**, which carries a charge precisely so unused addresses are released. - **Other Lightsail resources**: managed databases, load balancers, container services and CDN distributions are each their own bundle on top. ## Blueprints An instance is created from a *blueprint*: either an operating system alone, or an OS with an application stack preinstalled and configured — a CMS, a LAMP stack, a Node.js or Django environment. That is the real time saving for the target audience, and it is also why Lightsail attracts workloads that later turn out to need more than Lightsail. ## The networking trade This is the fact interviewers actually probe. **Lightsail instances do not run in your VPC.** They live in an AWS-managed VPC associated with your account in that region, with their own simplified firewall rules rather than the security groups and NACLs you would use elsewhere. To reach something in your own network — an RDS database, an internal service — you enable **VPC peering between the Lightsail VPC and that region's default VPC**, then allow the Lightsail address range in the target's security group. Note the constraint hiding inside that sentence: peering is with the *default* VPC of the region. If the resources you need are in a custom VPC, the neat one-click bridge does not apply, and you are into either moving the workload or exposing the dependency more publicly than you should. ## What else you give up No Auto Scaling groups. No control of a load balancer's listener rules beyond what Lightsail's own load balancer bundle offers. A short menu of sizes with no burstable-credit tuning, no spot or commitment-based pricing, and no placement control. Coarser integration with the wider AWS control plane generally: Lightsail is deliberately a small, self-contained corner of the account. ## The exit path The answer that separates a thoughtful candidate from a dismissive one: Lightsail is not a dead end. Take a **snapshot of the instance and export it to EC2**, and you get an AMI you can launch inside your own VPC with security groups, Auto Scaling and everything else. So the honest framing is that Lightsail is a fine starting point for something small and predictable, with a documented door out when it grows — as long as nobody has built the application to depend on the simplified environment. ## When it is the wrong answer in an interview If the question involves autoscaling, multi-AZ resilience, private networking to existing resources, or fine-grained IAM, Lightsail is not the service to name. Reaching for it there signals that you have optimised for simplicity in a scenario that was explicitly about scale or integration.
- A Lightsail instance needs to reach an RDS database that lives in your own VPC. What are your options?Enable Lightsail's VPC peering, which connects the AWS-managed Lightsail VPC to that region's **default** VPC, then allow the Lightsail address range in the database's security group. The limitation is in the word default: if the database sits in a custom VPC, that bridge does not exist, and the sane answer becomes moving the workload onto EC2 in the right VPC rather than exposing the database publicly.
- When does a Lightsail bill stop being predictable?When outbound data transfer exceeds the bundle's allowance — the excess is billed per GB, which a traffic spike or a large download can trigger. Snapshots and extra block storage bill per GB-month, an unattached static IP carries a charge, and managed databases, load balancers, container services and CDN distributions are separate bundles. The instance price is fixed; the account total is not.
- Is a workload started on Lightsail stuck there?No — take a snapshot of the instance and export it to EC2, which yields an AMI you can launch in your own VPC with security groups, Auto Scaling and the rest of the ecosystem. The practical risk is not the export mechanism but the application: anything that assumed the simplified networking or the preinstalled blueprint stack needs revisiting on the way out.
saying these in an interview costs you the question
- Thinks Lightsail instances sit in your own VPC by default
- Assumes the monthly price includes unlimited data transfer
- Says Lightsail is simply EC2 with a nicer console
- Believes a Lightsail workload can never move to EC2
- Expects Auto Scaling groups to work with Lightsail instances