Visualizing how containers map to physical or virtual infrastructure (Level 2/Deployment synergy)
The Deployment Diagram (one of the three supporting views in the C4 Model) bridges the logical architecture defined in Level 2 (Container Diagram) with the real-world runtime environment. It shows how the containers are actually deployed, hosted, scaled, and connected in production — mapping the abstract, technology-focused containers to concrete infrastructure elements such as servers, cloud services, clusters, networks, and availability zones.
This view is essential because logical architecture (what containers exist and how they communicate) does not always match physical reality. A single container might run as multiple replicas, a database might be clustered across regions, or several containers might share the same Kubernetes namespace. The Deployment Diagram makes these decisions visible and explicit.
Purpose of the Deployment Diagram
It answers critical operational and infrastructure-related questions:
- Where (physically or virtually) do each container’s instances run?
- How is scaling, high availability, and fault tolerance achieved?
- What infrastructure components (load balancers, gateways, firewalls, CDNs) sit between containers or between containers and users?
- How are environments separated (dev, staging, production)?
- What are the network boundaries, security groups, or trust zones?
- How does the deployment topology affect latency, resilience, cost, or compliance?
This diagram is the natural companion to the Container Diagram — they are often created together or iteratively refined as infrastructure evolves.
Key Elements of a Deployment Diagram
- Deployment Nodes
- Represent physical or virtual infrastructure hosts.
- Common types:
- Physical servers (“On-prem Server”)
- Virtual machines (“EC2 Instance m5.large”)
- Kubernetes clusters (“EKS Cluster – us-east-1”)
- Cloud regions or availability zones (“AWS us-west-2a”)
- Serverless execution environments (“AWS Lambda”)
- PaaS platforms (“Heroku Dyno”, “Azure App Service”)
- Containers (from Level 2)
- Placed inside deployment nodes to show where they run.
- Show instances/replicas when relevant:
- “Order Service (3 replicas)”
- “PostgreSQL – Primary + 2 Replicas”
- Multiple containers can run on the same node (e.g., in a monolith or shared VM).
- A single container type can appear in multiple nodes (e.g., scaled horizontally).
- Infrastructure Supporting Elements
- Load balancers (“ALB – Application Load Balancer”)
- API gateways / ingress controllers (“Kong Ingress”, “NGINX Ingress”)
- Message brokers when deployed separately (“Kafka Cluster – 3 brokers”)
- Databases with clustering (“Aurora PostgreSQL – Multi-AZ”)
- CDNs, firewalls, VPNs, service meshes (“Istio”, “AWS WAF”)
- External services treated as nodes (“Stripe – Payment Service – External”)
- Relationships & Communication Paths
- Show runtime connections between nodes or between containers across nodes.
- Label with protocols when different from Level 2 (e.g., “Internal VPC traffic”, “HTTPS over public internet”, “PrivateLink”).
- Indicate redundancy or failover paths (e.g., dashed lines for standby replicas).
Level 2 / Deployment Synergy — How They Work Together
The Container Diagram (Level 2) and Deployment Diagram are tightly coupled:
- Container Diagram answers: “What are the major deployable units, their technologies, and how do they logically interact?” → Focus: responsibility, protocol, abstraction
- Deployment Diagram answers: “How are those units physically/virtualized deployed, scaled, and networked in the real world?” → Focus: instances, hosts, redundancy, infrastructure topology
Example synergy:
- Container Diagram shows “Order Service (Spring Boot)” ↔ “PostgreSQL – Orders” via “JDBC”
- Deployment Diagram shows:
- “Order Service” running as 5 pods in “EKS Cluster – prod-us-east-1”
- “PostgreSQL” as Aurora cluster with primary in us-east-1a and replicas in us-east-1b/c
- Traffic routed via “ALB” → “Ingress Controller” → pods
- Database access via “RDS Proxy” inside VPC
This pairing reveals:
- Horizontal scaling realities
- Single points of failure (e.g., all pods in one AZ)
- Network hops and latency sources
- Security boundaries (public vs. private subnets)
- Cost drivers (number of instances, reserved capacity)
When to Create a Deployment Diagram
- You are operating in cloud-native, containerized, or hybrid environments (Kubernetes, ECS, serverless, VMs).
- Infrastructure decisions impact architecture (multi-region, high availability, cost optimization).
- Conducting security reviews, compliance audits, disaster recovery planning, or capacity analysis.
- Onboarding DevOps/SRE teams or explaining production topology to developers.
- Migrating between environments (on-prem → cloud, monolithic → Kubernetes).
Skip or keep very simple if:
- Everything runs on a single traditional server
- The system is purely serverless with no custom topology
- Infrastructure is trivial or fully managed
Best Practices
- Keep one diagram per major environment (e.g., “Production Deployment”, “Staging”) or one high-level overview.
- Use icons or colors to distinguish node types (cloud provider logos, server vs. container symbols).
- Show redundancy explicitly (replicas, AZs, failover arrows).
- Avoid low-level details like exact IP addresses, pod names, or Helm values — stay at logical infrastructure level.
- Generate or maintain via tools (C4-PlantUML, Structurizr, IcePanel) for version control alongside code.
The Deployment Diagram turns your logical architecture into an operational reality — making invisible infrastructure choices visible, actionable, and communicable. It completes the story: from business purpose (Level 1), through technical building blocks (Level 2), to how everything actually runs in the real world.
In the hands-on section ahead, you’ll take a Container Diagram from earlier modules, map its containers to realistic infrastructure (cloud or hybrid), add scaling/redundancy, and draw the deployment topology that brings the architecture to life in production.