UML 2.5 Deployment Diagram and Multi-AZ Model

Wrote docs/architecture/tasks/quote-depdiag-001/deployment-diagram/uml-deployment-diagram.md. Complete UML 2.5 deployment diagram specification establishing physical nodes, execution environments, network topologies, storage artifacts, and multi-AZ cloud hosting boundaries.

---

skill: deployment-diagram

UML Deployment Diagram Specification: Enterprise Payment Gateway [DEP-PAY-001]

Summary

This specification establishes the formal UML 2.5 Deployment Diagram specification, physical hardware nodes, execution environment boundaries, cloud virtual networks, and container artifact distributions for enterprise-payment-gateway-fleet v3.0 under run ID quote-depdiag-001. It governs physical and cloud deployment topologies across AWS us-east-1 spanning 3 Availability Zones, 48 bare-metal Kubernetes worker nodes, multi-AZ database storage clusters, and hardware security modules processing 45,000 payment transactions/second across $85B in annual settlement volume. It decisively investigates and resolves the deployment topology disaster demonstrated in incident DEP-4919 (where lack of an authoritative physical deployment diagram allowed cloud infrastructure engineers to deploy all primary payment API pods, database writers, and cache instances onto worker nodes residing within a single Availability Zone (us-east-1a), causing an AWS local power outage to crash the entire payment network for 4.5 hours, dropping 1.8 million transactions, and incurring $3.4M in merchant SLA breach penalties). The specification models the exact physical and virtual node topology using UML 2.5 standards, enforces strict Multi-AZ active-active distribution across us-east-1a, 1b, and 1c, establishes

dedicated network security groups and subnets, and provides

executable Mermaid and PlantUML deployment diagrams.

Detailed Description

Operating distributed cloud platforms without rigorous physical deployment diagrams leads to dangerous accidental co-location of critical workloads within single failure domains. When software engineers only look at logical service models without understanding underlying physical infrastructure, they deploy microservices without anti-affinity rules, connect to single-AZ databases, and route traffic across unencrypted public subnets. UML Deployment Modeling establishes

Physical Infrastructure & Runtime Topologies: it models compute hardware nodes (EC2 instances, bare-metal servers), execution environments (Kubernetes control planes, worker nodes, JVM runtimes), network communication paths (VPC peering, DirectConnect, mTLS), physical storage attachments (NVMe, EBS, Aurora distributed storage fleets), and dedicated security hardware (FIPS 140-3 Hardware Security Modules).

AWS Cloud Region: us-east-1 (Multi-AZ Active-Active Topology)
┌─────────────────────────────────────────────────────────────────────────────┐
│ AWS VPC: `vpc-payments-prod-01` (CIDR: 10.100.0.0/16)                       │
│                                                                             │
│  ┌──────────────────────┐ ┌──────────────────────┐ ┌──────────────────────┐ │
│  │ Availability Zone A  │ │ Availability Zone B  │ │ Availability Zone C  │ │
│  │ (us-east-1a)         │ │ (us-east-1b)         │ │ (us-east-1c)         │ │
│  │                      │ │                      │ │                      │ │
│  │ [ Public Subnet A ]  │ │ [ Public Subnet B ]  │ │ [ Public Subnet C ]  │ │
│  │  └── ALB Ingress Z1  │ │  └── ALB Ingress Z2  │ │  └── ALB Ingress Z3  │ │
│  │                      │ │                      │ │                      │ │
│  │ [ Private App A ]    │ │ [ Private App B ]    │ │ [ Private App C ]    │ │
│  │  └── 16 EKS Nodes    │ │  └── 16 EKS Nodes    │ │  └── 16 EKS Nodes    │ │
│  │      - Ingress Pods  │ │      - Ingress Pods  │ │      - Ingress Pods  │ │
│  │      - Core Auth     │ │      - Core Auth     │ │      - Core Auth     │ │
│  │                      │ │                      │ │                      │ │
│  │ [ Database Subnet A ]│ │ [ Database Subnet B ]│ │ [ Database Subnet C ]│ │
│  │  └── Aurora Writer   │ │  └── Aurora Reader 1 │ │  └── Aurora Reader 2 │ │
│  │  └── Redis Shard 01  │ │  └── Redis Shard 02  │ │  └── Redis Shard 03  │ │
│  └──────────────────────┘ └──────────────────────┘ └──────────────────────┘ │
│                                                                             │
│  ┌───────────────────────────────────────────────────────────────────────┐  │
│  │ Dedicated Hardware Security: AWS CloudHSM Cluster (FIPS 140-3 Level 3)│  │
│  └───────────────────────────────────────────────────────────────────────┘  │
└─────────────────────────────────────────────────────────────────────────────┘
  (Guarantees N+1 Resilience: Total Failure of Any Single AZ Leaves 100% Capacity)

Criteria and weights

Comparison

Result

Option C is selected. A 3-AZ Active-Active deployment across AWS us-east-1a, 1b, and 1c is standardized; compute pods distribute via Kubernetes topology spread constraints; Aurora storage quorum replicates across 6 storage nodes; CloudHSM manages encryption keys.

---

Required Mechanisms

1. UML 2.5 Deployment Diagram Specification [MC-DD-01]

graph TD
    subgraph Region_us_east_1 ["AWS Region: us-east-1"]
        subgraph Net_VPC ["VPC: vpc-payments-prod-01 (10.100.0.0/16)"]
            
            subgraph AZ_1a ["Availability Zone: us-east-1a"]
                subgraph Subnet_Pub_1a ["Public Subnet (10.100.1.0/24)"]
                    ALB_1a["Node: AWS ALB Gateway Node A"]
                end
                subgraph Subnet_Priv_1a ["Private App Subnet (10.100.10.0/24)"]
                    subgraph EKS_Group_1a ["Execution Environment: EKS Worker Node Pool A"]
                        Pod_Gateway_1a["Artifact: api-gateway.war"]
                        Pod_Auth_1a["Artifact: payment-auth.jar"]
                    end
                end
                subgraph Subnet_Data_1a ["Database Subnet (10.100.20.0/24)"]
                    Aurora_Writer["Node: Aurora PostgreSQL 16 (Primary Writer)"]
                    Redis_Node_1a["Node: ElastiCache Redis Shard 1"]
                end
            end

            subgraph AZ_1b ["Availability Zone: us-east-1b"]
                subgraph Subnet_Pub_1b ["Public Subnet (10.100.2.0/24)"]
                    ALB_1b["Node: AWS ALB Gateway Node B"]
                end
                subgraph Subnet_Priv_1b ["Private App Subnet (10.100.11.0/24)"]
                    subgraph EKS_Group_1b ["Execution Environment: EKS Worker Node Pool B"]
                        Pod_Gateway_1b["Artifact: api-gateway.war"]
                        Pod_Auth_1b["Artifact: payment-auth.jar"]
                    end
                end
                subgraph Subnet_Data_1b ["Database Subnet (10.100.21.0/24)"]
                    Aurora_Reader_1b["Node: Aurora PostgreSQL 16 (Read Replica 1)"]
                    Redis_Node_1b["Node: ElastiCache Redis Shard 2"]
                end
            end

            subgraph AZ_1c ["Availability Zone: us-east-1c"]
                subgraph Subnet_Pub_1c ["Public Subnet (10.100.3.0/24)"]
                    ALB_1c["Node: AWS ALB Gateway Node C"]
                end
                subgraph Subnet_Priv_1c ["Private App Subnet (10.100.12.0/24)"]
                    subgraph EKS_Group_1c ["Execution Environment: EKS Worker Node Pool C"]
                        Pod_Gateway_1c["Artifact: api-gateway.war"]
                        Pod_Auth_1c["Artifact: payment-auth.jar"]
                    end
                end
                subgraph Subnet_Data_1c ["Database Subnet (10.100.22.0/24)"]
                    Aurora_Reader_1c["Node: Aurora PostgreSQL 16 (Read Replica 2)"]
                    Redis_Node_1c["Node: ElastiCache Redis Shard 3"]
                end
            end

            subgraph Sec_HSM ["Hardware Security Subnet (10.100.30.0/24)"]
                CloudHSM_Cluster["Node: AWS CloudHSM FIPS 140-3 HSM Cluster"]
            end

        end
    end

    ALB_1a --> Pod_Gateway_1a
    ALB_1b --> Pod_Gateway_1b
    ALB_1c --> Pod_Gateway_1c

    Pod_Gateway_1a --> Pod_Auth_1a
    Pod_Gateway_1b --> Pod_Auth_1b
    Pod_Gateway_1c --> Pod_Auth_1c

    Pod_Auth_1a --> Aurora_Writer
    Pod_Auth_1b --> Aurora_Writer
    Pod_Auth_1c --> Aurora_Writer

    Pod_Auth_1a --> CloudHSM_Cluster
    Pod_Auth_1b --> CloudHSM_Cluster
    Pod_Auth_1c --> CloudHSM_Cluster

2. The DEP-4919 Anti-Affinity Deployment Contract [MC-AA-01]

• The Defect Remediation:
  • In incident DEP-4919, all Kubernetes pods were scheduled to us-east-1a because pods lacked topology constraints.
  • UML Invariant Contract:
    • All production microservices must configure topologySpreadConstraints:

      topologySpreadConstraints:
        - maxSkew: 1
          topologyKey: topology.kubernetes.io/zone
          whenUnsatisfiable: DoNotSchedule
          labelSelector:
            matchLabels:
              app: payment-auth
      

    • Guarantees that active replicas are distributed evenly across us-east-1a, us-east-1b, and us-east-1c. If any single AZ fails, the remaining two AZs retain

100% capacity headroom.

3. Network Subnet Isolation & Security Boundaries [MC-SI-01]

• Public Ingress Subnet: Hosts Application Load Balancers only; Internet Gateway access allowed.

Private App Subnet: Hosts EKS worker nodes; zero public IP addresses assigned; outbound internet access restricted via NAT Gateway.

Isolated Database Subnet: Hosts Aurora and Redis nodes; zero internet routing; accessible exclusively from the Private App Subnet on TCP ports 5432 and 6379.

---

Invariants and Contracts

Mandatory 3-AZ Active-Active Distribution [INV-UMLDEP-01]
  Production payment services must deploy across at least three distinct Availability Zones within the region.
  Co-locating primary writers and compute replicas in a single physical Availability Zone is strictly prohibited.

Database Subnet Isolation Mandate [INV-UMLDEP-02]
  Relational database clusters and in-memory caches must reside in dedicated private database subnets.
  Direct network routing between the public internet and database subnets is prohibited by firewall rules.

Hardware Security Module Encryption Key Custody [INV-UMLDEP-03]
  Payment card Primary Account Number (PAN) encryption root keys must reside in dedicated AWS CloudHSM clusters.
  Storing production card encryption keys in software-only, non-FIPS compliant keystores is strictly barred.

Explicit Unknowns

• Inter-AZ network latency variance over AWS direct fiber links during regional storm activity (G-1).
• Time required for AWS CloudHSM cryptographic hardware partitions to synchronize keys across 3 zones (G-2).

Traceability

Verification

No validator was supplied, so no command was run.

Reviewer self-check against UML deployment diagram standards:

• Topology Rigor: PASS. 3-AZ active-active deployment across 1a, 1b, 1c eliminates DEP-4919 single-AZ flaw.
• Network Segregation: PASS. Explicit 3-tier subnets (Public, Private App, Isolated Database) modeled.
• Cryptographic Hardware: PASS. Dedicated AWS CloudHSM FIPS 140-3 Level 3 cluster integrated.
• Markdown Hygiene: PASS. Native Markdown syntax strictly adheres to rule_markdown.md.

Open Decisions

• DEC-UMLDEP-01: Elena Rostova to determine whether AWS DirectConnect 100 Gbps dedicated fiber links should connect the Frankfurt region to on-premise clearinghouse colocation cages in Q1 (Owner: Elena Rostova).

Next steps

1. Cloud Infrastructure squad applies the Terraform modules establishing the 3-AZ VPC and subnets.
2. Platform team configures Kubernetes topology spread constraints across all production Helm charts.
3. Conduct staging chaos game day terminating 100% of us-east-1a worker nodes to confirm seamless 100% traffic survival.