Cloud architecture diagram

Cloud diagrams have a pull towards official icons, and there is a real reason for it: an icon that everyone recognises removes a label. The cost is that icon-heavy diagrams have to be drawn by hand.

Both routes are here. Use icons when the audience is broad, and text when the diagram changes weekly.


#When to reach for one

  • Design documents and architecture reviews.

  • Cost or security reviews, where the boundaries matter more than the icons.

  • Explaining a deployment to somebody who will operate it.


#How to draw it in Capable

Route

Use when

draw.io

Official AWS, Azure and Google Cloud icon libraries.

D2 or Mermaid

Text that lays itself out, for diagrams that change often.


#A worked example

A cloud deployment drawn as text, with boundaries as containers:

Cloud architecture diagram

The source, which you can paste into a new diagram and edit:

direction: right

internet: Internet

cloud: Production account {
  lb: Load balancer
  vpc: VPC {
    web: Web tier {
      shape: rectangle
    }
    app: App tier
    db: Managed database {
      shape: cylinder
    }
  }
  store: Object storage {
    shape: cylinder
  }
}

internet -> cloud.lb: HTTPS
cloud.lb -> cloud.vpc.web
cloud.vpc.web -> cloud.vpc.app
cloud.vpc.app -> cloud.vpc.db
cloud.vpc.app -> cloud.store

#A few things that catch people out

  • Draw the trust boundary, not just the services. It is the most useful line on a cloud diagram.

  • Managed services still fail. Draw them as components, not as background.

  • One diagram per environment, or one diagram with the differences called out. Not one diagram pretending they are identical.



Draw the trust boundary.