Deployment Diagram: What It Is, When to Use It, and How to Create One with AI (2026)

A deployment diagram shows the physical or logical deployment of software artifacts — services, containers, compiled binaries, configuration files — onto infrastructure nodes such as servers, virtual machines, containers, availability zones, and cloud regions. Where a component diagram answers "what exists in the system?" and a sequence diagram answers "what happens when a user takes action X?", a deployment diagram answers the more operational question: where does it run? That question matters every time a new service goes to production, a team plans a cloud migration, or a security engineer wants to understand which workloads cross network boundaries.

In 2026, deployment diagrams have evolved well beyond the simple server-to-service box diagrams of the early 2010s. Modern deployments span multiple cloud regions, multiple Kubernetes clusters, dozens of managed services, and a mix of containerized workloads and serverless functions — all of which need to be legible to engineers, architects, and operations teams at once. AI-powered diagram generators have made it practical to keep deployment diagrams up to date: instead of spending an afternoon in a drag-and-drop tool, you describe the topology in plain English and get a structured diagram in seconds.

What a deployment diagram shows — and what it does not

Understanding the scope of a deployment diagram helps you decide when to reach for it versus another diagram type.

What it shows

• Nodes: The execution environments where software runs — physical servers, virtual machines, Docker containers, Kubernetes nodes, cloud availability zones, and cloud regions. In UML notation, nodes are rendered as three-dimensional boxes.
• Artifacts: The deployable units hosted on each node — JAR and WAR files, Docker images, compiled binaries, and configuration files. Artifacts are nested inside the node that hosts them.
• Communication paths: The connections between nodes, labeled with the protocol in use — HTTPS, gRPC, AMQP, WebSocket, TCP — and optionally the port number. These paths make network segmentation and data flow immediately visible.
• Replication factors: Multiplicity annotations (e.g., "3 replicas" or "n instances") that indicate how many copies of a node or artifact exist.
• Environment boundaries: Swimlanes or grouping boxes that delineate VPCs, subnets, namespaces, accounts, or environment stages (dev / staging / prod).

What it does not show

• Internal component structure: For that, reach for a component diagram. A deployment diagram tells you that a microservice is deployed on a node; it does not show the internal classes or modules of that service.
• Sequence of events: Deployment diagrams are structural, not behavioral. For request flows and interaction timing, use a sequence diagram.
• Data schema: An ER diagram or data model diagram is the right tool for describing tables, columns, and foreign-key relationships. A deployment diagram simply shows that a database node exists and is reachable from a given application node.

In UML terms, deployment diagrams are one of the seven structural diagram types — alongside class, object, component, composite structure, package, and profile diagrams. They sit at the infrastructure layer of a system's structural view, making them a natural complement to component diagrams (which sit one level of abstraction higher).

Deployment diagram notations

Three notations dominate in practice. The right choice depends on your audience and tooling.

UML deployment diagram

The formal UML 2.x notation uses three-dimensional boxes for nodes and stereotypes (e.g., «device», «executionEnvironment») to classify them. Artifacts appear as document-shaped icons nested inside nodes. Dependency arrows with «deploy» stereotypes indicate which artifact is deployed on which node. UML notation is precise and tool-friendly but can feel heavy for modern cloud-native stacks where the interesting topology is at the container and managed-service level, not the device level.

C4 Level 4 (Deployment)

The C4 model's fourth and final level is explicitly a deployment diagram. It layers infrastructure onto the Level 3 component view by mapping container instances (not Docker containers — C4's term for independently deployable units) onto deployment nodes. A C4 Level 4 diagram reads: environment (production, staging) → deployment node (AWS region, Kubernetes cluster, Azure App Service Plan) → container instance (the running copy of a C4 container) → infrastructure node (load balancer, CDN, managed database). C4 Level 4 is ideal for teams already using C4 for their other diagram levels because it shares the same vocabulary and abstraction conventions. See our C4 model guide for a full walkthrough.

Informal / cloud-native notation

In practice, most teams working with AWS, Azure, or GCP use the cloud provider's own icon set with labeled arrows and grouping boxes for VPCs, subnets, and regions. This is the most pragmatic notation for modern deployments: engineers recognise the icons immediately, the diagrams map directly to the infrastructure-as-code they write, and AI generators can produce them from a plain-English description. The trade-off is that the notation is less formal and not standardized across providers.

Cloud deployment diagram — AWS three-tier example

The most common AWS deployment pattern for web applications is a three-tier topology: a CDN and DNS layer at the edge, a compute tier in private subnets, and a data tier in isolated subnets. A deployment diagram for this pattern should show the following components.

• Route 53: DNS entry point. Maps the domain to CloudFront or directly to the Application Load Balancer.
• CloudFront: CDN distribution in front of the load balancer. Serves static assets from S3 and caches dynamic responses at edge locations. Origin shield sits between CloudFront and the ALB.
• S3 bucket: Hosts static assets (JavaScript bundles, images, fonts). Served via CloudFront, not directly to the internet.
• VPC with public and private subnets: The Application Load Balancer lives in the public subnet and accepts HTTPS on port 443. ECS tasks (or EC2 instances) live in the private subnet and accept traffic only from the ALB security group. Multi-AZ deployment means both subnets span two or three availability zones.
• Application Load Balancer: Terminates TLS, routes requests to the target group of ECS tasks, and runs health checks. Sits in the public subnet.
• ECS / Fargate tasks: Application containers in the private subnet. The deployment diagram shows the task definition (image, CPU, memory), the service (desired count, autoscaling policy), and the cluster they belong to.
• RDS (isolated subnet): A managed PostgreSQL or MySQL instance in an isolated subnet with no route to the internet. Multi-AZ standby replica shown as a secondary node.
• ElastiCache (Redis): Session store and cache layer in the private subnet. Accessible only from the ECS task security group.

When generating this diagram with AI, be explicit about the subnet placement of each component and the protocol and port on each connection arrow. Vague prompts produce diagrams that flatten everything into a single layer — useful for a high-level overview, but not useful for an infrastructure review or security audit.

Kubernetes deployment diagram

Kubernetes introduces its own abstraction hierarchy that maps cleanly onto a deployment diagram: clusters contain nodes, nodes run pods, pods contain containers, and higher-level objects (Services, Ingresses, PersistentVolumes) manage networking and storage. A Kubernetes deployment diagram should show all of these layers without collapsing them into a single "Kubernetes cluster" box — the value of the diagram is precisely in making the relationship between these layers visible.

Key components to include

• Cluster and node pools: Show the cluster as an outer boundary. Inside it, group worker nodes into node pools (e.g., general-purpose pool, GPU pool, spot pool). Each node is a VM.
• Namespaces: Use swimlanes or nested boxes to delineate namespaces. At minimum show the application namespace and the infrastructure namespace (ingress controller, cert-manager, monitoring).
• Pods and container images: Pods are the atomic deployment unit. Show the container image name (and tag) inside each pod. For Deployments with multiple replicas, annotate with "n replicas" rather than drawing each pod individually.
• Services: ClusterIP Services are internal load balancers. NodePort and LoadBalancer Services expose workloads outside the cluster. Draw Services as routing nodes between the Ingress and the pods.
• Ingress controller: The entry point for external HTTP/HTTPS traffic. Show the Ingress resource routing to Services based on host and path rules. The Ingress controller pod (nginx, Envoy, Traefik) lives in the infrastructure namespace.
• PersistentVolumes and PVCs: Show PersistentVolumeClaims attached to stateful pods and the underlying PersistentVolume bound to cloud storage (EBS, GCP Persistent Disk, Azure Disk).
• ConfigMaps and Secrets: Reference them as annotations on the pods that consume them rather than drawing them as first-class nodes — this keeps the diagram readable.
• Horizontal Pod Autoscaler: Annotate Deployments that have an HPA attached, showing the min and max replica range.

Showing multiple environments

For teams that run dev, staging, and production in the same cluster (via namespaces) or in separate clusters, the deployment diagram has two common approaches:

• Swimlane approach (same cluster): Use horizontal swimlanes for each namespace / environment. This works well when the topology is identical across environments and you want to show them in one view.
• Separate cluster boxes (multi-cluster): Draw each cluster as a separate bounded box and use a global load balancer (e.g., AWS Route 53 weighted routing, GKE Multi-cluster Ingress) above them to show traffic distribution.

Multi-region deployment diagram

Multi-region deployments are among the most complex topologies to document because they involve two or more full copies of an infrastructure stack connected by global routing and data replication. A deployment diagram is the clearest way to communicate the active-active or active-passive pattern to engineers, SREs, and leadership.

Components to show

• Global load balancer: The entry point above all regions. On AWS this is Route 53 with latency-based or failover routing records. On Azure it is Traffic Manager or Azure Front Door. On GCP it is Cloud Load Balancing with anycast. Show this as a top-level node with routing policy labeled (latency-based, weighted, failover).
• CDN edge nodes: CloudFront, Azure CDN, or Cloudflare in front of the regional stacks. Edge nodes sit between the global load balancer and each region's origin.
• Primary region (active): The full production stack — load balancer, compute tier, and data tier — labeled as the write region or primary region.
• Secondary region (warm standby or active-active): A mirror of the primary stack. In an active-passive (warm standby) setup, the secondary accepts no traffic until failover is triggered. In an active-active setup, both regions serve live traffic and write to their local database replica.
• Data replication: Show the replication link between the primary and secondary data tiers. Label it with the replication technology (RDS Read Replica with promotion lag, DynamoDB Global Tables with <1s replication, Spanner multi-region commit) and the direction of replication (unidirectional for active-passive, bidirectional for active-active).
• RPO/RTO annotations: Optionally annotate the replication link with the recovery point objective and recovery time objective — this makes the diagram immediately useful for disaster recovery planning.

Active-active vs. active-passive

The most important thing a multi-region deployment diagram communicates is which pattern is in use. In an active-passive diagram, the traffic arrow from the global load balancer points only to the primary region; a dashed standby arrow to the secondary region indicates it receives traffic only on failover. In an active-active diagram, traffic arrows point to both regions, and the data replication arrows are bidirectional. Keeping these patterns visually distinct — for example using solid arrows for active traffic and dashed arrows for standby paths — prevents the diagram from being misread.

When to use a deployment diagram vs. other diagram types

Deployment diagrams fill a specific slot in a documentation suite. The table below shows what each major diagram type covers across five dimensions.

The key differentiator of a deployment diagram is the physical placement column. No other standard diagram type makes the mapping from software artifact to infrastructure node its primary concern. Architecture overview diagrams often show some placement information, but they typically elide subnet boundaries, replication topology, and port numbers — exactly the details that matter for infrastructure review and security audits.

When to create a deployment diagram

Deployment diagrams are most valuable at inflection points — when the topology is about to change, when a new set of eyes needs to understand it, or when the current state needs to be formally documented for compliance or review purposes.

• Before a new service goes to production: An infrastructure review needs a current-state diagram and a target-state diagram. Reviewers can identify misconfigurations (e.g., a database accidentally in a public subnet, a missing security group rule) in a diagram far faster than in Terraform code.
• Before a cloud migration: Document the current on-premises or legacy cloud topology as the "as-is" deployment diagram, then draft the target cloud topology as the "to-be" diagram. The gap between the two drives the migration workstream.
• During disaster recovery planning: DR exercises require participants to understand which components fail over, in what order, and how data replication works. A deployment diagram with failover annotations and RPO/RTO labels is the fastest way to align the team before a drill.
• For a security review: Network segmentation, boundary crossing, and attack surface analysis all depend on knowing where services run and which paths connect them. A deployment diagram that clearly shows public vs. private subnets, security group boundaries, and ingress points is the foundation of a security review. See our zero-trust architecture guide for how to extend this to zero-trust network segmentation.
• For onboarding new engineers: "Where does it run?" is one of the first questions a new backend or platform engineer asks. A deployment diagram answers it in a single view, without requiring them to read through Terraform modules, Helm charts, and Kubernetes manifests.
• For compliance documentation: SOC 2, HIPAA, PCI-DSS, and ISO 27001 audits frequently require network topology diagrams that show data flows and environment boundaries. A deployment diagram produced from an AI generator is far easier to keep current than one hand-drawn in Visio or Lucidchart.

Frequently asked questions

What is the difference between a deployment diagram and a system architecture diagram?

A system architecture diagram is a broad, often informal term for any diagram that shows how the components of a system relate to each other. It typically operates at a higher abstraction level: services, APIs, databases, and their logical connections. A deployment diagram is more specific — it shows where those components run, meaning which physical or virtual infrastructure nodes host them, which network boundaries separate them, and how traffic flows between nodes at the protocol and port level. A system architecture diagram might show "the API connects to the database"; a deployment diagram shows "the API service runs on ECS Fargate in the private subnet and connects to RDS PostgreSQL on port 5432 in the isolated subnet." In practice, many teams produce one combined diagram that covers both concerns — but keeping them separate produces more useful documentation because the audiences are different (architects for the logical view, platform engineers and SREs for the deployment view).

What does a C4 Level 4 deployment diagram show?

A C4 Level 4 diagram — the Deployment diagram in Simon Brown's C4 model — maps the runtime instances of C4 containers (independently deployable units, not Docker containers) onto deployment nodes. A deployment node is any infrastructure element that can host something: an AWS region, an availability zone, an EC2 instance, a Kubernetes cluster, a Kubernetes node, a Docker container runtime, or even a mobile device. The diagram shows which container instance is running on which deployment node, along with infrastructure nodes (load balancers, CDNs, managed databases) that support but don't contain C4 containers. C4 Level 4 is particularly useful because it builds on the same named containers introduced in the Level 2 (Container) diagram, so readers can trace from "what is this service?" (Level 2) to "where does it run?" (Level 4) using a consistent vocabulary. Read our full C4 model guide for worked examples at all four levels.

How do I create a Kubernetes deployment diagram?

The most effective approach in 2026 is to use an AI diagram generator with a detailed prompt that specifies the cluster structure, node pools, namespaces, workloads, services, and ingress configuration. Start with the outer boundary (the cluster and its node pools), then add namespaces as swimlanes, then add the workloads within each namespace (Deployments, StatefulSets, DaemonSets), then add the Services and Ingress that route traffic to them, and finally add storage (PVCs, PersistentVolumes) and configuration (ConfigMaps, Secrets). The prompt in the Kubernetes section of this post is a good starting template. For multi-cluster setups, draw each cluster as a separate box and show the global routing layer (Route 53, GKE Multi-cluster Ingress, Argo CD) above them. See our dedicated Kubernetes architecture diagram guide for ten specific examples.

What is the difference between a deployment diagram and an infrastructure diagram?

The terms overlap significantly in practice, but there is a useful distinction. A deployment diagram is software-centric: its primary purpose is to show which software artifacts (services, container images, binaries) are deployed on which infrastructure nodes. An infrastructure diagram is infrastructure-centric: it focuses on the infrastructure itself (VPCs, subnets, route tables, transit gateways, IAM roles, DNS zones) and may or may not show the software running on top of it. In a deployment diagram, a VPC is a boundary that gives context to the services inside it. In an infrastructure diagram, the VPC is a primary subject with its own CIDR ranges, peering connections, and security groups drawn out in detail. For most software teams, the deployment diagram is the more useful artifact. For network engineers and cloud infrastructure teams, an infrastructure diagram is more appropriate.

Related guides

• Kubernetes Architecture Diagram Examples (with AI Prompts, 2026) — ten production-grade Kubernetes diagrams with copy-paste AI prompts.
• Cloud Architecture Diagram Best Practices — how to structure, label, and maintain cloud architecture diagrams for real teams.
• How to Create AWS Architecture Diagrams — step-by-step guide to generating accurate AWS diagrams with AI, including VPC, ECS, and RDS examples.
• C4 Model Architecture Diagrams — complete guide to all four C4 levels, including the Level 4 deployment diagram.