An AWS Cheatsheet for Builders: What to Use, When, and Why
Introduction
AWS can feel overwhelming, especially when you’re trying to build and ship something real.
There are hundreds of services, detailed documentation, and many “best practices.” But most builders don’t need all of that on day one. What we need is clarity: what to use, when to use it, and why.
This article is a practical AWS cheatsheet for builders. It’s not complete, and it’s not meant to be. It focuses on the small set of decisions that matter most when you’re actually building.
Compute: Where Your Code Runs
EC2
Use EC2 if:
- Your app runs all the time
- You need full control over the environment
- You’re okay managing servers
If you’re choosing EC2 by default, pause. It’s powerful, but it also comes with responsibility.
Lambda
Use Lambda if:
- Your logic is event-based
- Execution time is short
- You don’t want to manage servers
Lambda is a great default for APIs, background tasks, and automation.
ECS / Fargate
Use ECS or Fargate if:
- You like containers
- You want scaling without managing servers directly
Simple rule:
If you don’t know why you need EC2, start with Lambda or Fargate.
Storage: Files and Assets
S3
Use S3 for:
- File uploads
- Images and videos
- Static website assets
- Backups
Most applications only need S3. It’s simple, reliable, and scales quietly in the background.
EBS
- Disk storage attached to EC2
EFS
- Shared file storage across multiple instances
Builder tip:
If you’re early, don’t design complex storage. Start with S3 and move on.
Databases: Where Data Lives
DynamoDB
Use DynamoDB if:
- Your access patterns are simple
- You want high scale
- You want minimal maintenance
RDS
Use RDS if:
- You need SQL
- Your data is relational
- You want familiar database behavior
Aurora
Use Aurora if:
- Your app is growing
- You need higher performance with SQL
Rule of thumb:
DynamoDB for simplicity, RDS for structure.
Authentication and Secrets
IAM
- Permissions between AWS services
- Internal access control
Cognito
- User sign-up and login
- Token-based authentication
Secrets Manager
- API keys
- Database credentials
Never:
- Hardcode secrets
- Commit credentials to a repo
This mistake is common—and expensive.
Deployment and Automation
Amplify
- Great for frontends
- Fast MVP setups
- Works well with modern frameworks
CodePipeline
- Simple CI/CD inside AWS
GitHub Actions + AWS
- Flexible
- Popular with builders
- Easy to grow with
Minimum goal:
One push = one deployment.
Monitoring and Cost Awareness
CloudWatch
- Logs
- Errors
- Basic metrics
AWS Budgets
- Set monthly limits
- Get alerts early
Cost Explorer
- See where money goes
- Spot unexpected usage
Builder mindset:
Think in cost per user, not service prices.
Quick Decision Table
| You need | Use this |
|---|---|
| Static website | S3 + CloudFront |
| API backend | Lambda + API Gateway |
| User authentication | Cognito |
| File uploads | S3 |
| Fast MVP backend | Amplify |
Closing Thoughts
You don’t need to know every AWS service to build effectively.
Most progress comes from making a few clear decisions, shipping early, and adjusting as you learn. AWS supports that approach well—if you keep things simple.
This cheatsheet is not a rulebook. It’s a starting point.
If you found this useful, you can follow me on DEV and the AWS Builder Community as @azmaldev.
I share short notes and lessons while building with AWS.
Tags: aws cloud devops backend cheatsheet
Top comments (0)