Article 12
An AWS production architecture: from the internet to the database
Walk through Route 53, CloudFront, WAF, load balancing, ECS, RDS, S3, queues, monitoring and backup with the security, availability, scale and cost decisions behind them.
How one request travels through the system
Architecture is not a shopping list
Start with the people using the system
Every AWS service needs a reason and an owner
A diagram full of service names can look convincing, but good architecture is not measured by box count. Start from outage impact, data sensitivity, workload, recovery expectations and team capability. This is a baseline for a typical business web/API workload, not a universal template.
Terms before you begin
Technical language, explained by what each part does
You do not need to memorize every term. Use this section as a map while reading the detailed explanation.
- Region
- An AWS geographic area containing multiple Availability Zones.
- Availability Zone (AZ)
- An isolated failure domain within a Region with high-speed regional connectivity.
- VPC
- A virtual network boundary containing subnets, routes and network controls.
- Public / Private Subnet
- A public subnet routes to an internet gateway; a private subnet does not accept direct internet ingress.
- WAF
- A web application firewall filtering HTTP requests by attack, bot and rate rules.
- Auto Scaling
- Adding or removing instances according to metrics and defined bounds.
- Multi-AZ
- Redundant capability across Availability Zones for zonal failure.
- IAM
- AWS identity and access management for people and workloads.
Summary for business and everyday users
An AWS production architecture: from the internet to the database
Use DNS, TLS, CDN and WAF at the public edge when justified by threat and load.
Keep applications and databases private; expose only intended entry points and restrict paths with security groups.
Distribute application capacity across Availability Zones and use managed database recovery controls.
Design monitoring, delivery, secrets, cost allocation and disaster recovery with the architecture.
Interactive explanation
See how the stages connect before reading the detail
Select a stage to understand what happens, what evidence to inspect and how one decision affects the next stage.
Step 01 / 05
01 / The edge
Route 53 directs the name; CloudFront and WAF handle the public edge
Route 53 resolves the domain. CloudFront terminates TLS near users, caches allowed content and offloads the origin. WAF filters known attack, reputation and rate patterns, but cannot replace application authorization. Cache policies must prevent private responses from being shared.
In-depth explanation
Work through each issue in real operating context
Each section connects business impact with what a Tech Lead needs to inspect, including examples, evidence and constraints.
01 / The edge
01Route 53 directs the name; CloudFront and WAF handle the public edge
Route 53 resolves the domain. CloudFront terminates TLS near users, caches allowed content and offloads the origin. WAF filters known attack, reputation and rate patterns, but cannot replace application authorization. Cache policies must prevent private responses from being shared.
02 / Network and compute
02The load balancer is the gate; ECS/Fargate supplies replaceable capacity
An Application Load Balancer health-checks and distributes requests to ECS tasks in private subnets across at least two AZs. Fargate removes host management, not workload configuration. Security groups permit only intended ALB-to-app and app-to-data paths; public SSH and database access are avoided.
Traffic path
Web request path
Route 53 → CloudFront + WAF → Application Load Balancer → ECS Fargate → RDS / ElastiCache / SQS
03 / Data
03Choose storage by data type and keep databases off the public edge
RDS fits relational transactions, S3 fits objects, ElastiCache reduces repeat reads, and SQS decouples slow work. Cache and queues add consistency and retry concerns, requiring idempotency and dead-letter handling. Encrypt RDS, use Multi-AZ as justified, retain automated backups and test restoration; a replica is not a backup.
04 / Control and observe
04IAM, secrets and observability must connect to accountable owners
Use workload IAM roles instead of long-lived keys. Store and rotate credentials in Secrets Manager with narrow access. CloudTrail records AWS API activity; CloudWatch carries service metrics, logs and alarms. Correlate requests, assign alert owners and retention, and mask sensitive data.
05 / Deliver and recover
05Delivery, disaster recovery and cost controls need evidence, not just a diagram
Build traceable artifacts and deploy with health-based rolling or blue/green controls. Map business RPO/RTO to backups, protected copies and rehearsed runbooks. Tag costs, set budgets and anomaly alerts, and right-size regularly. Removing redundancy is a business risk decision, not an invisible optimization.
Review all six AWS Well-Architected pillars and record trade-offs: operational excellence, security, reliability, performance efficiency, cost optimization and sustainability.
Checklist before action
Define impact, RPO, RTO and load
Design public/private subnets
Distribute apps across AZs
Restrict security groups
Use least-privilege IAM roles
Keep secrets out of source
Encrypt and test restore
Bound autoscaling
Assign alerts and runbooks
Tag, budget and detect anomalies
Test deployment and rollback
Review Well-Architected regularly
References
Figures and examples create a discussion framework. Validate them against the real system and its constraints before deciding.
- Reviewed by
- SIS Cloud Architecture
- Last reviewed
- 2026-07-17
Not sure where to start the review?
Use a preliminary tool or share the system context with SIS so the highest-priority work can be identified.