Two-Tier AWS Architecture

TL;DR

• Two-tier separates application tier from data tier; suitable for smaller systems, internal tools, early SaaS where business logic can coexist with web/API.
• Application tier: ALB ingress, EC2/ECS/Lambda compute in private subnets, Multi-AZ for redundancy.
• Data tier: RDS/Aurora/DynamoDB in private subnets, accessible only from application security groups.
• Security: ACM TLS, Secrets Manager for credentials, KMS encryption, WAF, least-privilege IAM roles and database users.
• Operations: CloudWatch alarms for latency/errors/CPU, CloudTrail audit logs, AWS Config compliance, backups and health checks.

Core Concepts

Two-Tier Architecture: Boundaries and Trade-Offs

Two-tier structure:

• Tier 1 (Application): Web tier, API tier, business logic. Handles HTTP/HTTPS requests, performs computation, reads/writes data.
• Tier 2 (Data): Relational database, key-value store, cache. Stores persistent data.

Separation principle: Each tier operates independently. Application tier can be scaled horizontally; database tier is protected and isolated.

When it’s appropriate: The application is monolithic enough that web, API, and business logic can ship together as a single unit. Independent scaling of web vs. API is not a requirement. Team ownership is unified.

When it becomes a problem:

• Different teams own web vs. API vs. business logic; they need independent release cycles.
• Web tier scales differently from API tier (e.g., API is compute-intensive; web is I/O-light).
• Asynchronous workloads, batch processing, background jobs don’t fit the synchronous web request model.
• Security review requires stricter segmentation (e.g., public web handlers can’t talk to internal business logic).

Reference Design

Ingress (Public-Facing):

• Route 53 resolves custom domain (app.example.com) to either:
  • CloudFront distribution (if static assets, edge caching needed).
  • Application Load Balancer (direct HTTP routing to application tier).
• ACM issues and auto-renews public TLS certificates.
• WAF (optional) attaches to ALB for DDoS/SQL injection/XSS protection.

Application Tier (Private Subnets, Multiple AZs):

• ALB in public subnets routes traffic to application targets in private subnets.
• Application targets: EC2 instances in Auto Scaling group, ECS services, Fargate tasks, or Lambda.
• Multi-AZ deployment: targets span at least 2 AZs for redundancy.
• IAM roles grant least-privilege permissions (database read/write, S3 access, etc.).
• Security groups allow inbound from ALB, outbound to database, NAT Gateway (for external API calls).

Data Tier (Private Subnets, Multiple AZs):

• RDS/Aurora in private database subnets.
• Multi-AZ failover: read replicas and automated failover to standby in different AZ.
• Inbound security group rule: allow traffic only from application security group.
• No inbound from public subnets or internet.
• Secrets Manager stores and rotates database credentials.
• KMS encryption: at-rest (EBS, RDS), in-transit (TLS from application to database).

Observability and Operations:

• CloudWatch metrics: ALB response time, HTTP status codes, target health, CPU, memory, disk.
• CloudWatch Logs: application logs, database query logs, ALB access logs.
• CloudTrail: audit trail of IAM API calls (who did what when).
• AWS Config: compliance tracking (e.g., is encryption enabled, is database multi-AZ).
• Alarms: high latency (p95 > 1s), 5xx errors (>1%), CPU saturation (>80%), database connection pressure.
• Backups: Aurora automated backups (retained 7 days), AWS Backup for long-term retention.
• Health checks: ALB health check on application endpoint (/health); database connectivity checks.
• Deployment: Blue/green or canary via CodeDeploy; automatic rollback on health check failure.

Production Scenario: Internal Finance Portal

Requirement: Build an internal finance approval workflow. Users login, submit expenses, managers approve. Moderate traffic (50 concurrent users), 99.5% uptime SLA.

Design:

1. Users visit finance.example.com over TLS.
2. Route 53 A record points to ALB (no CDN; internal users, no edge caching benefit).
3. ALB health check pings /health every 30 seconds; drains unhealthy targets over 30 seconds.
4. Application tier: 2 ECS tasks (Fargate) across 2 AZs, minimum 1 per AZ, maximum 4 for scaling.
5. Database tier: Aurora PostgreSQL Multi-AZ (primary in us-east-1a, standby in us-east-1b).
6. Secrets Manager: database credentials rotated every 30 days.
7. CloudWatch alarm: if 5xx errors >5/minute for 2 minutes, alert ops team; if average latency >2 seconds for 5 minutes, scale out.
8. Aurora automated backups retained 7 days; weekly snapshots exported to S3 for archive.
9. Disaster recovery: Aurora promotion to read replica in us-west-2 (manual failover for RTO ~1 hour).

Common Pitfalls

Interview Questions

• You inherit a two-tier app with public EC2 and public RDS. Redesign it for production without overengineering. — Tests ability to identify security gaps (public database), propose fixes (private subnets, ALB, security groups), and justify trade-offs (Multi-AZ vs. cost).

• Design a two-tier architecture for an internal SaaS tool expecting 100 concurrent users, requiring 99.5% uptime. — Tests whether Multi-AZ, Auto Scaling, health checks, and observability are included; candidate’s justification of RTO/RPO.

• When would you evolve this two-tier design to three-tier or microservices? — Tests understanding of when two-tier becomes limiting (independent team ownership, different scaling needs, asynchronous workloads).

• Walk me through a database failover scenario. What happens? How long is downtime? — Tests understanding of Aurora Multi-AZ automatic failover, RTO, and health check propagation delay.