12 AWS Services We Set Up on Almost Every Project
Introduction
Hundreds of services in the console, and thirteen of them do most of the work in a production setup. Here is what our team builds, in what order, with the prices and limits that catch people out.
By the JET BI engineering team
Figure 1. The 12 AWS services inside one production-ready AWS architecture.
Clients ask us this early, usually in the first call: which AWS services does this thing actually need? Fair question. The console answers it with a catalogue sorted by category and no hint about which dozen you will touch. So, we drew it instead. One cloud architecture, thirteen AWS services, roughly the shape we end up with on most projects. This is the order we build them in.
IAM first, before anything else
IAM decides who can do what, and it says no to everything until somebody writes a policy that says otherwise. Two rules we don’t bend. Roles instead of access keys, because a role gives an instance credentials that expire and rotate on their own, while a static key in a config file lives forever and eventually lands in a Git history. Scanners find those in hours. And MFA on the root account today, then stop logging in as root at all.
S3 object storage, not a disk
S3 stores files as objects in a bucket, and every object has a key. In S3 we store static files, user files, backups and logs, because storage is cheap and the durability comes from AWS copying objects across availability zones for you.
Three main settings in S3. Versioning, so a bad deploy overwrites nothing you might need tomorrow. And Block Public Access, which AWS now leaves enabled on new buckets; switch it off only for a bucket that genuinely has to serve files to the internet, and use a bucket policy for that instead of opening everything. And a lifecycle rule so logs move to a cheaper storage class instead of sitting in Standard for years.
EC2, and the IP address that bills you for doing nothing
An instance keeps its private IP for life. The public one vanishes the moment you stop the machine, which is how hand-written DNS records are easy to break. If you need a stable public address, take an Elastic IP and remember that AWS now charges about half a cent an hour for public IPv4, working or idle. Call it $3.60 a month per address. Not too much, but twenty forgotten addresses across four accounts are a different conversation.
One load balancer, one Auto Scaling Group, no heroics
The load balancer checks every target on a 30-second interval and stops sending traffic to failed instances. The Auto Scaling Group replaces it. Two things get skipped here. First, a health check that touches something real: a path returning 200 from nginx tells you nothing about the database. Second, a cooldown long enough that the group stops flapping. Then go terminate an instance yourself, during business hours, before launch. If response times stay flat, that part is done.
Default VPC already Public
Launch an EC2 instance without thinking about networking and it lands in the default VPC: 172.31.0.0/16, one /20 subnet per availability zone, an internet gateway already attached, and 0.0.0.0/0 in the main route table already pointing at it. Auto-assign public IPv4 is on. So, the throwaway box you started "just to test something" has a public address and is reachable from the internet, and the only thing between it and the world is its security group. That is what a public subnet really is: not a checkbox on the subnet, but a route to an internet gateway plus a public address on the instance. Build your own VPC and you make that decision per subnet instead of inheriting it from AWS.
RDS, and two words people mix up
RDS costs more than the same PostgreSQL on a bare instance, and it's usually worth it: backups, minor version patching, a failover nobody has to script. Multi-AZ is about availability. It holds a synchronous standby in another zone, roughly doubles the instance bill, and takes over in a minute or two behind the same endpoint. A read replica is about throughput. It's asynchronous, it can lag, and it isn't a backup. Similar checkboxes, very different jobs.
Lambda, SNS, SQS, Route 53, Secrets Manager
Lambda handles work that has no business blocking a web request: thumbnails, webhooks, the nightly tidy-up. Fifteen minutes is the hard ceiling, so a job that needs more isn't a Lambda job. SNS pushes one message to many subscribers. SQS sends messages, up to 256 KB each and four days by default, until a worker gets to them, retries when the worker chokes, then drops the hopeless ones into a dead-letter queue that somebody should actually read. Publish to a topic, subscribe the queues to it, and a slow consumer stops being an outage. Route 53 points an alias record at the load balancer, and alias queries to AWS targets aren't billed. Secrets Manager keeps the database password out of your environment variables for $0.40 per secret per month and rotates it on a schedule.
The bit nobody puts in the diagram: the bill
Everything above switches on in a few clicks and then never asks for attention again. That's the trap. A NAT gateway, a multi-AZ standby and a handful of stray Elastic IPs will quietly add a few hundred dollars a month to a project that has not launched yet. Set a budget alarm on day one, tag every resource you create, and open Cost Explorer on Fridays. It takes four minutes. It's rescued more projects than any architecture diagram we've drawn, including this one.
We build this same stack for clients every month, and no two accounts end up looking identical — industry, compliance, traffic patterns all move the pieces around. If you want a second pair of eyes on your own setup, get in touch: https://jetbi.com/contacts
