Cloud systems are judged on where things run, how they talk, and what happens when part of them fails. The samples in this section show the four diagrams teams draw most often to answer those questions, each drawn for a realistic AWS or Kubernetes scenario with a walkthrough, a legend, a second variant, and diagrams-as-code you can copy.
Most of these are not UML. UML covers software structure and behaviour; cloud topology, event-flow and failover diagrams are the other standard notations used alongside it. Where UML fits naturally, the samples use it: the Kubernetes page is a UML deployment diagram, and the serverless page includes a UML sequence diagram of its retry path.
A topology diagram nests boxes inside boundaries (region, Availability Zone, VPC, subnet) so that reachability and redundancy are visible. A deployment diagram shows which software lands on which machine. An event-flow diagram follows messages through queues and functions, including the retry and dead-letter routes. A failover diagram is a topology diagram drawn twice, before and after a failure, with recovery objectives written on it.
| Question | Diagram | Sample page |
|---|---|---|
| What is public, what is private, and is every tier in two zones? | Cloud topology (architecture) diagram | AWS three-tier architecture |
| Which pods run on which node, and where do config and storage come from? | UML deployment diagram | Kubernetes deployment diagram |
| Where does a message go when processing fails? | Event-flow diagram plus UML sequence diagram | Serverless event flow |
| What happens to users and data if a whole region goes down? | Before/after failover topology | Multi-region failover diagram |
diagrams library) so it is reviewed with every change.