There is a particular kind of cloud diagram that makes reviewers uneasy without their quite knowing why. Everything is a grey rectangle. The load balancer, the queue, the object store and the managed database all look identical, distinguishable only by the words typed inside them. Technically it is correct. But nobody can skim it, and a diagram you have to read word by word is barely faster than the paragraph it replaced.
The reason the good cloud diagrams feel effortless is that they lean on a shared visual language. An engineer who has worked on the platform knows the shape of a compute service, an object store, a managed queue, before reading a single label. When your diagram uses the provider's own iconography, it plugs straight into that shared memory, and the picture becomes skimmable. That is the whole difference between a diagram people trust and one they squint at.
Icons carry meaning, not decoration
It is tempting to treat icons as polish you add at the end. They are not; they are how a cloud diagram encodes type. The moment a box wears the object-storage icon, the reader knows its durability story, its access pattern and its cost model without you writing any of it down. A managed-database icon says "someone else runs this" in a way a plain rectangle never will. Strip the icons out and you have thrown away a layer of information, which is why the all-grey diagram feels so flat.
Use the provider's real icon set
LetDraw includes the official-style icon libraries for the big three clouds (AWS, Azure and GCP), so you are not approximating a compute service with a generic server glyph. Open the shape library, pick your provider, and drop the actual services onto the canvas: the load balancer that looks like that provider's load balancer, the queue that looks like its queue. A diagram built from the right set reads correctly to anyone who works on that platform, which is usually the exact audience for the diagram.
Mixing providers is fine too, and honest when your system really does span them. The icons make the boundary obvious (this half is on one cloud, that half on another) instead of hiding a multi-cloud reality behind uniform grey boxes.
The right icon tells the reader what a box is before they read a single word. That is the whole job of a cloud diagram.
Start from the infrastructure you already declared
You do not have to place every service by hand. If your infrastructure lives in Terraform or a similar declaration, that file already lists the resources and how they connect. Paste it into Generate from Code and LetDraw lays out the components for you; then stamp the correct provider icons onto the boxes so the generated draft reads like a real architecture rather than a dependency graph.
resource "aws_lb" "web" { # → load balancer icon } resource "aws_ecs_service" "api" { # → compute icon } resource "aws_db_instance" "main" { # → managed DB icon } resource "aws_s3_bucket" "assets" { # → object-store icon }
Keep it legible as it grows
Real cloud diagrams get busy, and the thing that ruins them is arrows drawn straight through whatever is in the way. Let the canvas route connectors around your services instead, group each tier or region into a container, and the picture stays readable at thirty boxes the way it was at five. When you need it as code (for a doc, a wiki, a pull request), export to Mermaid or D2 and commit it next to the Terraform it describes.
A good cloud diagram is not prettier than a bad one; it is faster to read. Use the real icons, generate the first draft from your infrastructure, and give your reviewers a picture they recognise on sight.