AWS Architecture Diagram Symbols and Icons: A Reference Guide
AWS ships hundreds of service icons and a set of grouping conventions that carry real meaning. Reading them fluently is what separates a diagram that communicates from one that just looks technical.
An AWS architecture diagram is only as clear as the vocabulary it is drawn in, and that vocabulary is a specific set of icons and grouping conventions that AWS publishes and maintains. Each compute, storage, database, and networking service has its own icon, and the boxes those icons sit inside - a VPC boundary, an Availability Zone, a Region - are not decoration but meaning. When everyone on a team reads the same symbols the same way, a diagram becomes a shared source of truth instead of a picture someone has to explain out loud.
This guide is a practical reference to that symbol set: how the icons are categorized, what the grouping boxes represent, how color is used, and how to avoid the mistakes that make a technically detailed diagram misleading. You can draw everything described here in Atlas Diagram Studio at /diagrams, which ships AWS, Azure, GCP, and Kubernetes stencils alongside a library of over 1000 shapes, and the dedicated network and cloud diagram tool at /diagram-tools/network-diagram gives you the region, VPC, and subnet containers pre-built so the structure is correct before you place a single service.
How the AWS icon set is organized
The official AWS icon set is grouped by service category, which mirrors how the console itself is organized. Compute icons cover EC2, Lambda, and the container services like ECS and EKS. Storage covers S3, EBS, and EFS. Database covers RDS, DynamoDB, and Aurora. Networking and content delivery covers the VPC, Elastic Load Balancing including the Application Load Balancer, Route 53, CloudFront, and API Gateway. There are further categories for security, analytics, machine learning, and management, but most architecture diagrams draw heavily from compute, storage, database, and networking.
Each service icon is a distinct pictogram, and the visual family a service belongs to is signalled by a consistent background color square in the modern icon set - for example networking services share one accent color and storage services another. This means a reader can often tell the category of a component at a glance even before reading its label, which is exactly the kind of fast comprehension a good notation gives you. When you place these icons in Atlas Diagram Studio from the AWS stencil, they arrive already styled to the current AWS conventions so you are not reinventing the palette.
Grouping boxes carry the real structure
The service icons get the attention, but the containers around them carry most of the architectural meaning. AWS defines a set of group shapes - nested boxes with specific borders and corner labels - that represent the boundaries every real deployment lives inside. Getting these right is what makes a diagram accurate rather than merely busy.
- AWS Cloud: the outermost boundary that says everything inside runs in AWS rather than on-premises or another provider.
- Region: a box representing a geographic Region such as us-east-1, inside which all the Availability Zones sit.
- Availability Zone: a box inside the Region for an isolated data-center group; resources are placed in a specific AZ for fault tolerance.
- VPC: the virtual private cloud boundary that defines your isolated network, drawn inside the Region and usually spanning multiple AZs.
- Public and private subnet: nested inside the VPC and inside an AZ, distinguishing resources that are internet-reachable from those that are not.
- Security group and Auto Scaling group: logical boundaries drawn around the resources they govern, showing what is protected or scaled together.
- Corporate data center: an on-premises boundary used when the diagram shows hybrid connectivity over VPN or Direct Connect.
Color, labels, and connection lines
Color in an AWS diagram should follow the icon set rather than personal taste. The category accent colors are meaningful, so recoloring a Lambda icon to match your brand palette destroys information a reader would otherwise get for free. Reserve custom color for annotation layers - highlighting a request path, marking a component under discussion, or flagging something that is planned rather than built - and keep the service icons in their standard colors so the categories stay legible.
Labels and connection lines finish the picture. Every icon should carry a short, specific label - not just "database" but the role it plays, like "orders RDS (PostgreSQL)" - because two RDS instances in the same diagram are otherwise indistinguishable. Connection lines represent relationships: a solid arrow for a request or data flow, with a direction that matches reality, and a label on the arrow when the protocol or purpose is not obvious. The guide on how to make an AWS architecture diagram at /guides/system-architecture-diagram-guide walks through assembling these into a full picture, and the AI diagram generator at /diagram-tools/ai-diagram-generator can rough out a first draft you then correct.
Common mistakes that mislead readers
The most damaging mistakes are structural, not cosmetic. Placing a database in a public subnet on the diagram when it actually lives in a private one is not a stylistic slip - it tells the reader the security posture is different from reality. Similarly, drawing a single resource when the deployment actually runs one per Availability Zone hides the redundancy the architecture depends on. Because the grouping boxes encode the network and fault-tolerance design, an error in them is an error in the story the diagram tells.
Other frequent problems are subtler. Mixing icon-set generations makes a diagram look inconsistent and dates it. Omitting the Region and AZ boxes flattens a multi-AZ design into something that looks single-homed. Leaving arrows undirected or unlabeled forces the reader to guess the data flow. The fix for all of these is discipline: use one current icon set, always draw the boundary boxes that actually apply, label every icon and every non-obvious arrow, and keep the diagram in an editable tool like Atlas Diagram Studio at /diagrams so it can be corrected the moment the architecture changes rather than frozen as a stale image. For validating the network layer specifically, the network diagram tool at /diagram-tools/network-diagram keeps subnets and routing explicit.