DevOps on AWS, part 1: The map — services and how they fit together

Part 1from the DevOps on AWS series · 6 parts in all

This series teaches DevOps on AWS by building infrastructure for three sample companies we will follow throughout: MapleCart, a growing e-commerce store; FleetView, a B2B SaaS for logistics dashboards; and NewsGrid, a news site whose traffic spikes 50x when a story goes viral. Same three clouds concepts, three very different constraints. Part 1 is the map: what the pieces are and how they relate.

The layered model

Every AWS deployment answers the same six questions, in the same order:

1. Who can touch anything? — IAM (Identity and Access Management) sits outside the diagram because everything else calls it. Users, roles, and policies; nothing inside AWS may act without a role granting it.
2. Where does it run? — Compute: EC2 (VMs), ECS/Fargate (containers), Lambda (functions).
3. Where does data live? — S3 (objects), RDS/Aurora (relational), DynamoDB (key-value), EBS (disks attached to EC2).
4. How do the pieces talk? — VPC (your private network), subnets, security groups, load balancers, Route 53 (DNS).
5. How does code get there? — CI/CD: CodePipeline/CodeBuild or GitHub Actions pushing artifacts into the compute layer.
6. How do you know it works? — CloudWatch (metrics, logs, alarms).

The relationships, drawn in prose

A request from a customer travels: Route 53 resolves the domain to CloudFront (CDN), which forwards to an Application Load Balancer inside your VPC; the ALB picks a healthy target (EC2 instance, ECS task, or Lambda) in a private subnet; that target reads/writes RDS and S3 using an IAM role attached to it — never stored credentials; everything it logs lands in CloudWatch, whose alarms can trigger autoscaling or wake a human. One sentence, six services, and it is the skeleton of 90% of AWS architectures.

Internet -> Route 53 (DNS) -> CloudFront (CDN) -> ALB (load balancer)
   -> private subnet targets: [EC2 | ECS tasks | Lambda]
        |            |
        |            +-- S3 (files, backups, static assets)
        +-- RDS/Aurora (SQL) -- via IAM role, no passwords in code
All logs -> CloudWatch -> alarms -> autoscaling / SNS notification

How our three companies map onto it

• MapleCart: classic three-tier. ALB → ECS containers → RDS Postgres; S3 for product images behind CloudFront; sessions in ElastiCache (Redis). Consistency matters more than raw scale.
• FleetView: multi-tenant SaaS. ECS Fargate for the API, DynamoDB for per-tenant telemetry (unbounded, key-shaped data), Cognito for customer login. Predictable load, so reserved capacity saves money.
• NewsGrid: read-mostly, spiky. Static pages on S3 + CloudFront (the origin is just files), API on Lambda so idle time costs nothing, autoscaling absorbs the viral spike. Cost follows traffic almost linearly.

The DevOps workflow on AWS

The day-to-day loop: write Terraform/CloudFormation for infrastructure; push code through a pipeline (GitHub Actions or CodePipeline) that builds a container image, runs tests, and deploys to ECS or Lambda; CloudWatch alarms watch the result; roll back by redeploying the previous image tag. Everything is API-driven, which is the point: if it isn't in code, it isn't real. The following parts walk each layer with commands and configs, and the finale assembles MapleCart's whole stack in one terraform apply.