Aws Architecture Diagram

Read the relevant reference files to get exact shape names and colors:

• references/aws-icons-compute.md — EC2, Lambda, ECS, EKS, Fargate, ELB
• references/aws-icons-storage-database.md — S3, EBS, RDS, DynamoDB, Aurora, ElastiCache
• references/aws-icons-networking.md — VPC, CloudFront, Route 53, API Gateway, Direct Connect
• references/aws-icons-app-integration.md — SNS, SQS, EventBridge, Step Functions, CloudWatch, CloudFormation
• references/aws-icons-analytics-ml.md — Athena, Glue, Kinesis, OpenSearch, Bedrock, SageMaker
• references/aws-icons-security.md — IAM, Cognito, WAF, Shield, KMS, GuardDuty
• references/aws-icons-common.md — Users, servers, internet, groups, arrows

CRITICAL: Always look up icons before generating XML. Never guess icon names.

3. Plan the layout

Read references/layout-guidelines.md for spacing, nesting, and style rules.

Key layout decisions:

• Group nesting: AWS Cloud → Region → VPC → Subnet
• Primary flow direction (usually left-to-right)
• Where to place auxiliary services

4. Generate the Draw.io XML

Use templates/base.drawio.xml as the skeleton. Build XML with these patterns:

Service icon (colored background, white glyph)

<mxCell id="svc-lambda" value="Lambda" style="sketch=0;points=[[0,0,0],[0.25,0,0],[0.5,0,0],[0.75,0,0],[1,0,0],[0,1,0],[0.25,1,0],[0.5,1,0],[0.75,1,0],[1,1,0],[0,0.25,0],[0,0.5,0],[0,0.75,0],[1,0.25,0],[1,0.5,0],[1,0.75,0]];outlineConnect=0;fontColor=#232F3E;fillColor=#ED7100;strokeColor=#ffffff;dashed=0;verticalLabelPosition=bottom;verticalAlign=top;align=center;html=1;fontSize=12;fontStyle=0;aspect=fixed;shape=mxgraph.aws4.resourceIcon;resIcon=mxgraph.aws4.lambda;" vertex="1" parent="grp-subnet">
  <mxGeometry x="100" y="50" width="48" height="48" as="geometry" />
</mxCell>

MANDATORY: strokeColor=#ffffff for resourceIcon pattern. This makes the glyph white.

Dedicated shape (dark silhouette)

<mxCell id="res-lambda-fn" value="Lambda Function" style="sketch=0;outlineConnect=0;fontColor=#232F3E;gradientColor=none;fillColor=#ED7100;strokeColor=none;dashed=0;verticalLabelPosition=bottom;verticalAlign=top;align=center;html=1;fontSize=12;fontStyle=0;aspect=fixed;pointerEvents=1;shape=mxgraph.aws4.lambda_function;" vertex="1" parent="grp-subnet">
  <mxGeometry x="100" y="50" width="48" height="48" as="geometry" />
</mxCell>

Group container

<mxCell id="grp-vpc" value="VPC" style="sketch=0;outlineConnect=0;fontColor=#232F3E;fontStyle=0;container=1;collapsible=0;recursiveResize=0;shape=mxgraph.aws4.group;grIcon=mxgraph.aws4.group_vpc2;strokeColor=#8C4FFF;fillColor=none;verticalAlign=top;align=left;spacingLeft=30;fontColor=#AAB7B8;dashed=0;" vertex="1" parent="grp-region">
  <mxGeometry x="30" y="40" width="800" height="400" as="geometry" />
</mxCell>

Edge (arrow)

<mxCell id="edge-1" value="HTTPS" style="edgeStyle=orthogonalEdgeStyle;html=1;endArrow=block;elbow=vertical;startArrow=none;endFill=1;strokeColor=#545B64;rounded=0;fontSize=10;fontColor=#545B64;" edge="1" source="svc-cloudfront" target="svc-apigw" parent="1">
  <mxGeometry relative="1" as="geometry" />
</mxCell>

5. Output

Choose a descriptive kebab-case slug that best describes the diagram content (e.g., realtime-data-pipeline, event-driven-orders, multi-tier-web-app). Use this slug for both output files.

5a. Write the Draw.io file

• Write to docs/<slug>.drawio (e.g., docs/realtime-data-pipeline.drawio)

5b. Write the companion guide

• Write to docs/<slug>.md
• This Markdown file helps readers understand the diagram. Include:
  • Overview: 1-2 sentence summary of what the architecture does
  • Components: Table of each AWS service in the diagram, its role, and why it was chosen
  • Data flows: Step-by-step explanation of each flow (matching the step numbers in the diagram if using Non-Technical Audience Mode)
  • Key design decisions: Brief notes on architectural choices (e.g., why serverless, why this database, why this region setup)
  • Cost/scaling notes (optional): Anything helpful for planning — e.g., "Lambda scales automatically", "OpenSearch Serverless has a minimum baseline cost"
• Write the guide in the same language the user chose for the diagram
• Tell the user both file paths and suggest opening the .drawio in Draw.io to verify

Rules

1. Always look up icons in reference files before generating XML
2. Use strokeColor=#ffffff for all resourceIcon patterns (service-level icons)
3. Use strokeColor=none for all dedicated shapes (resource-level icons)
4. Match fillColor to category — never mix colors across categories
5. Ask the user for language (English or 日本語) — use consistently across diagram labels, titles, legend, and companion guide
6. No HTML in labels — plain text only
7. Max 15-20 icons per diagram for readability
8. Edge color: #545B64 (AWS default gray)
9. Font: 12px for icon labels, 10px for edge labels
10. Icon size: 48×48 for both service and resource icons
11. Single AWS Cloud group — use one AWS Cloud group spanning the full diagram, not multiple
12. Full-coverage background — add a light #F5F5F5 rounded rect behind everything (title, lanes, legend) so PNG export has a clean background instead of black

Non-Technical Audience Mode

When the diagram targets non-technical viewers (managers, stakeholders, end users):

Step-numbered edges

Replace technical labels (HTTPS, REST API, etc.) with circled step numbers:

• Flow A: ① ② ③ ④ (white circled)
• Flow B: ❶ ❷ ❸ ❹ (black circled)
• Use different circle styles per flow for visual distinction

Simplified labels

• Use plain Japanese descriptions instead of technical terms
• Examples: "チケット取得" not "REST API call", "AI学習用に変換" not "チャンク分割・埋め込み", "検索データベース" not "k-NNベクトルインデックス"
• Drop technical qualifiers: "OpenSearch" not "OpenSearch Serverless", "VPN接続" not "Site-to-Site VPN"

Lane layout with flow summaries

When a diagram has multiple flows (e.g., data processing + search), use swim lanes:

• Add a step-by-step summary in each lane header: e.g., "① チケット取得 → ② データ保存 → ③ AI変換 → ④ 索引化"
• Use a dashed vertical line to separate lanes instead of separate colored blocks
• Place the legend outside colored lanes for visibility

Background and legend

• One big #F5F5F5 rounded rect behind everything (title + lanes + legend)
• Legend text: fontColor=#232F3E (not gray) for readability on any export background
• Legend maps step numbers to short descriptions

Managed Services and VPC Endpoints Pattern

When a diagram includes AWS managed services (S3, Bedrock, OpenSearch, etc.) accessed from within a VPC:

Two-box layout

• VPC box (left): Contains user-deployed resources (EC2, Lambda, NAT Gateway, etc.)
• Managed Services box (right): A plain rounded-rect group containing AWS managed services that live outside the VPC (S3, Bedrock KB, OpenSearch, Bedrock Claude, etc.)
• VPC Endpoints icon: Placed on the boundary between the two boxes — visually sitting between VPC and Managed Services to communicate "this is the bridge"
• Both boxes sit inside the single AWS Cloud group

Managed Services group style

rounded=1;whiteSpace=wrap;fillColor=none;strokeColor=#879196;strokeWidth=1;dashed=1;dashPattern=4 4;fontColor=#232F3E;fontSize=12;fontStyle=1;verticalAlign=top;align=left;spacingLeft=10;spacingTop=8;container=1;collapsible=0;

Arrow routing

• Arrows go directly from source to target (e.g., Lambda → S3, EC2 → Bedrock KB) — do NOT route arrows through the VPC Endpoints icon
• The visual separation (two boxes + icon between them) already communicates that connections cross the VPC boundary via VPC Endpoints
• The companion guide explains the VPC Endpoint detail

When to use this pattern

• The architecture uses a VPC with VPC Endpoints for private connectivity
• Multiple managed services are accessed from within the VPC
• The audience benefits from seeing a clear boundary between "your infrastructure" and "AWS managed services"

Category Color Reference