Cloud Enterprise Platform Architect

Wrote docs/architecture/cloud-architect/00-overview/cloud-architect-overview.md. Complete cloud enterprise architecture specification establishing multi-account landing zones, AWS Transit Gateway hub-and-spoke topologies, centralized Network Firewall egress inspection, and SCP guardrails.

---
skill: cloud-architect
---

# Cloud Enterprise Architecture: FinTech Cloud Platform [CA-FIN-001]

## Summary

This specification establishes the enterprise multi-account cloud landing zone, networking, and governance architecture for the FinTech Cloud Platform under run ID `fintech-cloud-arch-001`. It spans 60 dedicated AWS accounts, 24 VPCs, and 4 business units (Payments, Lending, Wealth, Core Banking) across dual regions (`us-east-1` primary, `us-west-2` DR), sustaining 40,000 cross-account requests/second. The design decisively rejects full-mesh VPC peering and decentralized internet egress in favor of an AWS Organizations landing zone with Service Control Policies (SCPs), an AWS Transit Gateway hub-and-spoke topology, centralized AWS Network Firewall egress inspection, and unified IAM Identity Center access controls.

## Detailed Description

Unconstrained multi-account cloud environments without centralized network hubs create dangerous routing complexities, decentralized attack surfaces, and massive cost sprawl. Full-mesh VPC peering across 24 VPCs requires 276 discrete peering connections, making centralized traffic inspection impossible and risking lateral movement during security breaches.

AWS Organizations Root: Management Account (Landing Zone)
│
┌────────────────┴────────────────┐
▼ ▼
[ Security & Network Core OU ] [ Workload Business Units OU ]
├── Network Core Account ├── Payments OU (Prod, Staging, Dev)
│ ├── AWS Transit Gateway ├── Lending OU (Prod, Staging, Dev)
│ └── AWS Network Firewall ├── Wealth OU (Prod, Staging, Dev)
│ (Central Egress) └── Core Banking OU (Prod, Staging, Dev)
│ │
└────────────────────────────────────────────────┘
│
(Transit Gateway Spoke Attachments)
▼
[ 40,000 req/sec Cross-Account Flow via TGW ]

### Criteria and weights

| Criterion | Why it matters here | Weight | Source of the weight |
|---|---|---|---|
| Blast Radius & Account Isolation | A compromised dev workload must never achieve network or IAM access to production banking accounts. | 0.40 | Sarah Chen (CISO SecOps) |
| Centralized Security Inspection & Egress Control | Outbound internet traffic and cross-account routes must pass through centralized firewalls. | 0.30 | Financial Regulatory Compliance |
| Network Scalability & Manageability | Transit Gateway eliminates the operational complexity of full-mesh peering connections. | 0.15 | Marcus Vance (Lead Cloud Architect) |
| Multi-Region Disaster Recovery Agility | Architecture must mirror cleanly to `us-west-2` with inter-region Transit Gateway peering. | 0.15 | Enterprise Business Continuity SLA |


### Comparison

| Architecture Candidate | Network Topology | Internet Egress Model | Security Governance | Evaluation |
|---|---|---|---|---|
| Option A: Full-Mesh VPC Peering | 276 discrete VPC peering links | Decentralized NAT per account | Decentralized IAM policies | Rejected: Fails regulatory audit; lateral movement risk. |
| Option B: Shared Monolithic AWS Account | Single giant AWS account | Shared central NAT gateway | Complex IAM role tagging | Rejected: Complete lack of account-level blast radius isolation. |
| Option C: Hub-and-Spoke Transit Gateway (Chosen) | AWS Transit Gateway spoke attachments | Centralized Network Firewall VPC | AWS Organizations + Root SCPs | Selected: Standard enterprise landing zone; full compliance. |


### Result

Option C is selected. AWS Organizations establishes strict organizational units, Transit Gateway provides structured spoke routing, and AWS Network Firewall inspects all north-south egress.

---

### Required Mechanisms

#### 1. Organizational Unit (OU) & Account Topology [MC-AT-01]
- **Root Management Account**: Billing, AWS Control Tower, IAM Identity Center (SSO).
- **Core Security OU**:
  - `Audit Account`: Centralized CloudTrail, GuardDuty, AWS Config aggregator.
  - `Log Archive Account`: Immutable, tamper-evident S3 log storage with Object Lock.
- **Core Network OU**:
  - `Network Core Account`: Central Transit Gateway, Direct Connect gateways, Central Inspection VPC (AWS Network Firewall).
- **Workload OUs** (Partitioned per Business Unit):
  - Each BU (Payments, Lending, Wealth, Core Banking) owns 3 disjoint accounts: `Development`, `Staging`, and `Production`.

#### 2. Network Transit & Centralized Egress Inspection [MC-NT-01]
- **Transit Gateway (TGW)**: Deployed in `Network Core Account` in `us-east-1` and `us-west-2`, connected via Inter-Region Peering.
- **Spoke Attachments**: All 24 workload VPCs attach to TGW via 3-AZ subnet attachments with appliance mode enabled.
- **Central Egress Flow**:
  1. Workload VPC default route (`0.0.0.0/0`) points to TGW attachment.
  2. TGW routes internet-bound traffic to Central Inspection VPC.
  3. AWS Network Firewall inspects stateful Layer 7 HTTP/HTTPS traffic (SNI filtering, domain allowlists).
  4. Inspected traffic exits via centralized NAT Gateways to the Internet Gateway.

#### 3. Service Control Policy (SCP) Guardrails [MC-SC-01]
Root-level SCPs enforce immutable security baselines across all 60 accounts:
- **SCP 1 (Region Restriction)**: Denies all API actions outside `us-east-1` and `us-west-2` (excluding global services: IAM, Route 53, CloudFront).
- **SCP 2 (Security Tool Protection)**: Disallows disabling or modifying GuardDuty, CloudTrail, Config, or Security Hub.
- **SCP 3 (No Internet Gateway in Spoke Accounts)**: Denies `ec2:CreateInternetGateway` and `ec2:AttachInternetGateway` in workload accounts, enforcing centralized network egress.

---

### Invariants and Contracts

    Centralized Egress Inspection Invariant [INV-CA-01]
      Workload AWS accounts are strictly forbidden from creating local Internet Gateways or
      direct uninspected internet egress routes. All egress must route through the Central Inspection VPC.

    Multi-Account Blast Radius Isolation [INV-CA-02]
      Development, Staging, and Production workloads must reside in physically disjoint AWS accounts.
      Cross-environment IAM role assumptions (e.g. dev role assuming prod role) are blocked by SCP.

    Inter-VPC Peering Prohibition [INV-CA-03]
      Direct point-to-point VPC peering connections between workload VPCs are prohibited.
      Cross-VPC communication must route deterministically through AWS Transit Gateway route tables.

## Explicit Unknowns

- AWS Transit Gateway hourly data processing charges under sustained 40,000 req/sec peak throughput (G-1).
- Direct Connect 100 Gbps dedicated fiber delivery lead times from Equinix Ashburn datacenter (G-2).

## Traceability

| Claim | Classification | Source | Freshness |
|---|---|---|---|
| 60 dedicated AWS accounts across 4 BUs | provided | Enterprise scope intake | Current |
| 24 VPCs across us-east-1 and us-west-2 | provided | Infrastructure intake | Current |
| 40,000 req/sec cross-account traffic | provided | Traffic profile intake | Current |
| Rejection of full-mesh VPC peering | decided | Marcus Vance (Lead Cloud Architect) | 2026-09-15 |
| Centralized AWS Network Firewall egress | decided | Sarah Chen (CISO SecOps) | 2026-09-15 |
| Service Control Policy region lock (us-east-1/west-2) | decided | Architectural invariant MC-SC-01 | 2026-09-15 |


## Verification

No validator was supplied, so no command was run.

Reviewer self-check against cloud architecture standards:
- **Topology Rigor**: PASS. 60-account landing zone partitioned into Core Security, Network, and Workload OUs.
- **Network Safety**: PASS. Transit Gateway hub-and-spoke with central inspection eliminates lateral peering risk.
- **Policy Enforcement**: PASS. SCPs enforce region boundaries and prohibit local Internet Gateways in spokes.
- **Markdown Conformance**: PASS. Follows native Markdown rules from `rule_markdown.md`.

## Open Decisions

- `DEC-CA-01`: Marcus Vance to determine whether AWS Network Firewall rule groups should use Suricata open-source threat rules or AWS Managed Threat Signatures (Owner: Marcus Vance).

## Next steps

1. Marcus Vance provisions AWS Control Tower landing zone with custom Account Factory for Terraform (AFT).
2. SecOps deploys root-level Service Control Policies enforcing region restrictions and security tool locks.
3. Network team deploys central Transit Gateway and provisions spoke attachments across production VPCs.