Amazon Web Services (AWS) gives you a Lego bin the size of a warehouse. Powerful, but overwhelming when you just want a website online. Before you can decide whether the full stack is worth the complexity, it helps to know what the core pieces actually do. ☁️
Virtual Private Cloud (VPC)
A VPC is your own private network inside AWS. You pick the address range, carve it into subnets, decide what is public-facing and what stays internal, and attach firewall rules through security groups and network ACLs. Nothing in AWS runs in a vacuum — almost every other service ends up inside a VPC somewhere.
Elastic Compute Cloud (EC2)
EC2 is virtual machines on demand. You choose an instance type (CPU, RAM, network), an Amazon Machine Image (AMI), and a region, and a few seconds later you have a Linux or Windows server. Pay by the second, terminate when you are done. It is the workhorse of AWS — every shortcut service is, somewhere underneath, EC2 in a trench coat.
Relational Database Service (RDS)
RDS is managed databases — MySQL, PostgreSQL, MariaDB, Oracle, SQL Server, Aurora. AWS handles backups, patching, replication, and failover. You still write your own queries and tune your own indexes, but you do not have to babysit the operating system. For most teams this is worth it on day one. 🗄️
Elastic Load Balancer (ELB)
An ELB sits in front of a pool of EC2 instances (or containers) and spreads traffic across them. It also handles Transport Layer Security (TLS) termination, health checks, and graceful failover when an instance dies. The Application Load Balancer (ALB) speaks HTTP, the Network Load Balancer (NLB) speaks TCP. Without one, scaling horizontally is a do-it-yourself project.
Route 53
Route 53 is the Domain Name System (DNS) service. Register domains, host zones, point records at your load balancer, and use latency-based or geolocation routing if you want users to land on the closest region. The number is a nod to the standard DNS port — port 53. 🌐
Elastic File System (EFS)
EFS is a managed Network File System (NFS) share — a real file system that multiple EC2 instances can mount at the same time. It is the bridge between a single disk attached to one server (EBS) and object storage (S3). If you have a fleet of web servers behind an ALB and they all need to read and write the same uploads folder, EFS is the boring correct answer. 📁
EFS is arguably the more important storage service of the two for an application. It is your main file system — where uploads, session files, generated thumbnails, plugin directories, and shared application state live. Two perks worth calling out:
- Auto Infrequent Access detection. EFS watches access patterns per file and shuffles cold files into a cheaper Infrequent Access tier on its own. You set the threshold (7, 14, 30, 60, or 90 days of no access) and AWS does the migration. The first access pulls a file back to the standard tier automatically. No lifecycle rules to write, no cron jobs, no did I forget to archive that?.
- Automatic backups. EFS integrates with AWS Backup and turns on a default daily backup plan when you create the file system — retention defaults to 35 days. You can disable it or replace it with a custom plan, but the safe option is on out of the box.
Simple Storage Service (S3)
S3 is object storage. Buckets hold files, files have URLs, and the durability is famously high (11 nines). It is cheap, effectively infinite, and the right home for archival data — old database dumps, log shipments, build artifacts, finished video renders, static site assets you serve through a Content Delivery Network (CDN).
The mental model is: EFS is your live filesystem, S3 is your archive and your public asset bucket. S3 will not give you POSIX semantics or a mount point your application can fopen(). EFS will not give you 11 nines of durability across regions for pennies a gigabyte. Use both, for different things.
Putting it together
A boring-but-correct production setup looks like this: a VPC with public and private subnets, an ALB in the public subnets, EC2 instances in the private subnets behind the ALB, RDS in another private subnet, EFS mounted on the EC2 fleet for shared application state, Route 53 pointing your domain at the ALB, and S3 holding archives and assets.
1 2 3 4 5 | Route 53 --> ALB --> EC2 (private subnet) --> RDS (private subnet) | | | +--> EFS (live filesystem: uploads, sessions) | +--> S3 (archives, static assets, backups) |
That works. It also takes a weekend to wire up the first time, and you will read more Identity and Access Management (IAM) documentation than you wanted to.
Then there is Lightsail
AWS Lightsail is the same company saying: what if we hid all of that? 💡 A Lightsail instance is a virtual private server with a flat monthly price, a pre-installed stack (WordPress, LAMP, Node.js, etc.), a managed database option, a built-in load balancer, snapshots, and a one-click static IP. The pricing is predictable — no surprise bill from a forgotten NAT Gateway.
Under the hood it is still EC2, Elastic Block Store (EBS), and friends. Lightsail just buries the dials. You get a simpler console, fewer choices, and a price that fits on a sticky note.
When to pick which
Pick Lightsail when you want a single server (or a small fleet) running a well-known stack, you value predictable pricing over flexibility, and your scaling story is “resize the instance” rather than “auto-scale across availability zones”. Personal projects, small business sites, internal tools, and side hustles all live happily on Lightsail.
Pick the full AWS stack when you need fine-grained networking, multiple environments, custom IAM policies, autoscaling groups, multi-region failover, or any of the hundred services that only plug into a real VPC. The moment you say “we need a private link to another account” or “this has to scale to a million requests a second”, Lightsail is no longer the answer.
A useful escape hatch: Lightsail can peer with a VPC. You can start simple and reach into the bigger toolbox later without rebuilding from scratch. 🚀
A few useful additions.
RDS auto-backup deserves more billing. Automated backups are on by default: RDS takes a daily snapshot plus continuous transaction log capture, which gives you point-in-time recovery anywhere inside the retention window (1 to 35 days). For most teams this alone justifies paying the RDS premium over running MySQL on a raw EC2 box.
Selling points at a glance
If you only remember one thing per service:
- VPC — your private network, with isolation, subnets, and firewall rules you actually control.
- EC2 — any server you want, by the second, in any region.
- RDS — managed databases with automated backups and point-in-time recovery built in.
- ELB — traffic spreading, TLS termination, and health-checked failover without writing your own load balancer.
- Route 53 — DNS with latency, geo, weighted, and failover routing baked in.
- EFS — shared file system across many EC2 instances, auto-tiering for cold files, automatic backups by default. Your live filesystem.
- S3 — durable, cheap, effectively infinite object storage with Intelligent-Tiering for cost control. Your archive and public asset bucket.
- Lightsail — most of the above hidden behind a sticky-note price, when you want to ship instead of architect.
The pattern is the same across all of them: AWS sells you a primitive you could probably build yourself, then quietly adds the operational features (backups, tiering, failover, monitoring) that you would forget to build until the night you needed them. ✨