Deconstructing Enterprise Architecture: The Case Study Method
How senior cloud architects reverse-engineer ambiguous business requirements into high-availability, cost-effective AWS topologies.
1. Business Problem & Context
When organizations build on AWS, engineering teams often jump straight to provisioning services before clarifying quantitative constraints. A typical ambiguous request sounds like: “Build us an API backend that is scalable, fast, and cheap.”
Without architectural rigor, teams over-provision expensive dedicated instances or under-design resilience against Availability Zone outages, leading to budget blowouts and downtime.
2. Requirements & Constraints
| Constraint Dimension | Unclear Request | Architectural Translation |
|---|---|---|
| Availability | ”High uptime” | 99.95% SLA (≤ 21.9 mins downtime/month), Multi-AZ active-active compute. |
| Performance | ”Must be fast” | p99 Latency < 80ms at 5,000 requests/second peak. |
| Disaster Recovery | ”Don’t lose data” | RPO ≤ 5 mins (point-in-time recovery), RTO ≤ 30 mins. |
| Budget Boundary | ”Cost-effective” | Maximum $450/month baseline spend with auto-scale ceilings. |
3. Architecture Overview & Data Flow
Interactive Architecture Diagram (Use controls to zoom & pan)
- Extract Hard SLOs: Convert business language into numbers (latency, RTO, RPO, concurrency).
- Isolate State from Compute: Ensure application compute tiers are completely stateless.
- Evaluate Managed vs Unmanaged: Default to serverless/managed platforms unless specific runtime controls are required.
- Audit Failure Modes: Verify how the system behaves if any single AWS AZ or service API experiences degradation.
4. AWS Services Used & Rationales
AWS Services Architecture Rationale
Concrete reasons why these specific services were chosen over alternatives
| Service | Category | Architectural Rationale ("Why this service?") |
|---|---|---|
| AWS Organizations | Security | Provides multi-account structure (Core, Dev, Staging, Prod) preventing cross-environment blast radiuses. |
| AWS Cost Explorer | Management | Tracks cost trends and sets automated anomaly detection alerts. |
| IAM Identity Center | Security | Enforces temporary least-privilege credentials via single sign-on. |
5. Key Design Trade-offs
Architecture Decision & Trade-Off Matrix
Evaluating alternative approaches under real-world constraints
Single-Account Ad-Hoc Setup
- + Quickest initial setup
- + Zero organizational overhead
- − Huge blast radius
- − Accidental production teardowns
- − Messy IAM
Multi-Account AWS Organizations (Chosen)
✓ Chosen Design- + Isolated blast radius per environment
- + Fine-grained Service Control Policies
- + Consolidated billing
- − Requires initial Landing Zone setup
6. Implementation Highlights
Security Architecture AWS Organizations Multi-Account Topology
In a production setup, you should split accounts using AWS Control Tower or AWS Organizations:
- Management Account: Dedicated purely to billing and consolidated reporting (zero application workloads).
- Security Tooling Account: Houses GuardDuty master, AWS Config aggregators, and central KMS keys.
- Log Archive Account: Immutable S3 bucket holding all CloudTrail and VPC Flow Logs with Object Lock enabled.
- Workload Accounts: Separate accounts for
Development,Staging, andProduction.
7. Results & Key Metrics
- Architecture Review Speed: 60% faster sign-offs through structured requirements extraction.
- Blast Radius Containment: 100% isolation between developer testing and production infrastructure.
8. Key Architectural Takeaways
Core Principle: Never choose a service because it is popular; choose it because its operational model, failure characteristics, and pricing curve match your specific SLOs.
