3-Tier AWS Architecture

TL;DR

• Three-tier separates presentation, application logic, and data layers; enables independent scaling, team ownership, and feature velocity.
• Ingress: Route 53 + CloudFront (for caching) or ALB (direct routing), with ACM TLS and WAF.
• Application tier: Stateless compute (EC2/ECS/Lambda) in private subnets, Multiple AZs, Auto Scaling based on metrics.
• Data tier: Aurora/RDS Multi-AZ with read replicas, private subnets, secrets management, encryption at-rest and in-transit.
• Observability: CloudWatch metrics/logs, CloudTrail audit trails, AWS Config compliance, GuardDuty threat detection, Security Hub aggregation.
• Deployment: Blue/green or canary with health checks, CloudFormation/CDK IaC, database migration safety, automated rollback.

Core Concepts

Three-Tier Architecture: Separation of Concerns

Three-tier structure:

• Tier 1 (Presentation): Web servers, CDN, API gateways. Handles HTTP/HTTPS, static assets, request routing.
• Tier 2 (Application/Logic): Application servers, microservices, business logic. Processes requests, orchestrates workflows.
• Tier 3 (Data): Relational databases, data warehouses, caches. Persistent storage, query execution.

Separation benefits:

• Independent scaling: web tier scales on request volume; application tier scales on CPU; database tier scales on I/O.
• Independent team ownership: web team manages ingress; application team owns business logic; data team manages database.
• Feature velocity: teams can deploy independently without coordinating releases.
• Security boundaries: each tier has distinct security requirements and access controls.

Trade-off: Increased complexity. More services to monitor, coordinate, deploy. More operational overhead.

Reference Design

Tier 1: Ingress (Public)

• Route 53: DNS with failover/latency/geolocation routing.
• CloudFront (optional): edge caching for static assets and cacheable API responses; WAF at edge for DDoS protection.
• Application Load Balancer (required): TLS termination, path-based routing, host-based routing, request/response modification.
• ACM: auto-renewed public certificates.
• WAF: rate limiting, IP reputation filtering, SQL injection/XSS protection.

Tier 2: Application (Private Subnets, Multiple AZs)

• Stateless compute: EC2 instances, ECS services, Fargate tasks, Lambda. No local state; scales horizontally.
• Auto Scaling: target tracking (CPU 70%), step scaling (queue depth), or schedule-based.
• Service discovery: ALB/NLB for internal routing, or AWS Cloud Map.
• Circuit breaker/bulkhead: resilience libraries (Resilience4j, Spring Cloud Circuit Breaker) to prevent cascading failures.
• IAM roles: least-privilege per service (database read/write, S3 access, SQS send).
• Security groups: inbound from ALB/NLB, outbound to data tier, optional NAT/VPC endpoint for egress.

Tier 3: Data (Private Subnets, Multiple AZs)

• Aurora/RDS Multi-AZ: primary + standby in different AZ, automatic failover.
• Read replicas: offload read traffic from primary; scale read-heavy workloads.
• Secrets Manager: database credentials, rotated automatically.
• KMS encryption: at-rest (EBS, RDS), in-transit (TLS).
• Parameter Store: non-sensitive configuration (API endpoints, feature flags).
• Security groups: inbound only from application tier security group.

Observability

• CloudWatch: application metrics (latency p50/p95/p99, error rate, throughput), infrastructure metrics (CPU, memory, disk).
• CloudWatch Logs: application logs (structured JSON), ALB access logs, database slow query logs.
• CloudTrail: API audit trail (who, what, when) for compliance and security investigation.
• AWS Config: resource compliance (is encryption enabled, is Multi-AZ configured, are tags present).
• GuardDuty: threat detection (suspicious API calls, unusual network activity).
• Security Hub: centralized compliance dashboard (CIS benchmarks, PCI-DSS, HIPAA).
• X-Ray: distributed tracing; understand request flow across services, identify latency bottlenecks.

Deployment

• Blue/green: two identical production environments. Switch traffic at once (instant but high-risk) or gradually (canary).
• Canary: 5% traffic to new version, monitor for errors, gradually increase to 100%.
• Health checks: ALB health check on application endpoint. If failing, instance is drained and replaced.
• Rollback: if health check fails or custom metric (error rate) exceeds threshold, CodeDeploy automatically rolls back.
• IaC: CloudFormation or CDK for repeatable deployments.
• Database migrations: DMS for schema changes with zero-downtime (CDC replication).

Failure Analysis: Layers of Control

Preventive controls (prevent failures):

• Network segmentation (security groups, NACLs) prevent unauthorized access.
• Encryption prevents data exposure if storage is compromised.
• Authentication/authorization prevent unauthorized API calls.
• Input validation prevents malformed requests.

Detective controls (detect failures when they occur):

• CloudWatch alarms alert when latency is high, error rate is high, or resources are exhausted.
• CloudTrail logs provide audit trail; can detect unauthorized API calls after the fact.
• AWS Config detects drift (encryption disabled, Multi-AZ turned off).

Responsive controls (respond to failures):

• Auto Scaling replaces failing instances.
• ALB health checks drain unhealthy instances.
• SNS notifications trigger on-call engineer.
• Lambda functions run remediation (restart service, clear cache).

Production Scenario: Payments Checkout

Requirement: PCI-DSS compliant payment processing. 10K transactions/second, 99.99% uptime (52.6 minutes downtime/year), <100ms latency p99.

Architecture:

• Tier 1: ALB with WAF, CloudFront for checkout form (static HTML + JS), ACM TLS v1.3.
• Tier 2: Fargate tasks (CPU-optimized, 4 vCPU) across 3 AZs. Auto Scaling target: 80% CPU. Min 10 tasks, max 100. Target tracking on custom metric (transactions/second).
• Tier 3: Aurora MySQL Multi-AZ + read replica. Provisioned IOPS (40K) to guarantee <10ms query latency. Secrets Manager rotates credentials every 90 days. KMS encryption (CMK, customer-managed keys for PCI compliance).
• Observability: X-Ray traces each transaction for latency debugging. CloudWatch alarm if p99 latency > 100ms or error rate > 0.01%. GuardDuty detects unusual API activity. Security Hub reports PCI-DSS compliance.
• Deployment: Canary (5% traffic for 5 minutes, then 50%, then 100%). Database schema changes use DMS CDC replication; zero downtime.
• DR: Active-passive multi-region. Secondary region in us-west-2; RTO 1 hour, RPO 5 minutes (Aurora cross-region read replica + automated backup restore).

Common Pitfalls

Interview Questions

• Design the architecture for a PCI-DSS payment processing service requiring 99.99% uptime and <100ms p99 latency at 5K transactions/second. — Tests three-tier separation, Multi-AZ redundancy, health checks, monitoring, and compliance requirements (encryption, audit trails).

• Walk me through a primary database failure scenario. What happens to transactions in flight? What’s the RTO? — Tests understanding of Aurora Multi-AZ failover, in-flight request handling, ALB connection draining, client retry logic.

• Your canary deployment detects a 2% error rate spike on 5% of traffic. What happens next? — Tests understanding of automated rollback (health check failure triggers rollback), impact (only 5% affected), and next steps (investigate, deploy fix).

• How would you design this system to survive a full AWS region failure? — Tests active-passive/active-active multi-region design, cross-region read replicas, Route 53 failover, RTO/RPO trade-offs, cost implications.