AWS構成図は「サービスを並べる絵」ではなく、読み手に意思決定や運用判断を促すドキュメントです。本記事では、伝わる構成図を描くための原則と、現場でよく使われるツールの選び方を整理します。
目次
構成図を描く前に決める3つのこと
いきなりツールを開く前に、次の3点をはっきりさせてください。これが曖昧なまま描くと、「何のための図か分からない」資料が量産されます。
- 目的：提案・設計レビュー・運用引き継ぎ・障害対応のどれか
- 読み手：意思決定者・開発者・運用者・顧客のどれに向けるか
- 粒度：サービス単位なのか、リソース単位（サブネット・SGまで）なのか
例えば営業資料であればサービスアイコン中心の俯瞰図で十分ですが、運用引き継ぎではAZ・サブネット・セキュリティグループまで描き込まないと現場が困ります。
レイヤーで切ると見やすくなる
構成図は左から右、または上から下に「ユーザー → エッジ → アプリケーション → データ → 監視」のレイヤーで配置すると、視線の流れと処理の流れが一致して読みやすくなります。
- ユーザー / クライアント
- エッジ層（Route 53, CloudFront, WAF, Shield）
- アプリケーション層（ALB, ECS/EKS, Lambda, EC2）
- データ層（RDS, DynamoDB, S3, ElastiCache）
- 運用・監視層（CloudWatch, X-Ray, SNS, Systems Manager）
公式アイコンを使う
AWSは公式のアーキテクチャアイコンセットを無償配布しています。色・形状の意味が決まっているので、独自アイコンよりも誤読が減ります。
- サービスカテゴリごとに枠の色が決まっている（コンピュート＝橙、ストレージ＝緑など）
- 正方形＝サービス本体、丸＝リソース、白抜き＝特殊用途
- 毎年デザインが更新されるため、社内テンプレートも年1回はリフレッシュする
ツール選びの指針
用途に合わせて選びます。万能ツールは存在せず、目的によって最適解が変わります。
- draw.io（diagrams.net）：無料・公式アイコン同梱・GitHub保存可。提案～運用まで一番無難
- Cloudcraft：3D表現が映える。経営層向けプレゼンに強い
- Excalidraw：手書き風で「議論用ホワイトボード」に最適
- Mermaid / d2 / PlantUML：コードで図を書く。Pull Requestでレビューできる
- Lucidchart / Miro：複数人同時編集が必要な現場向け
コードで構成図を管理する選択肢
変更が頻繁なシステムでは、構成図そのものをコード管理してCIで自動生成するのが効果的です。Mermaidの例を示します。
flowchart LR
User((User)) --> CF[CloudFront]
CF --> S3[(S3 Static)]
CF --> APIGW[API Gateway]
APIGW --> Lambda[Lambda]
Lambda --> DDB[(DynamoDB)]このようにテキストで管理しておけば、Pull Requestで「アーキ変更」をレビューできます。
やってはいけないアンチパターン
- 矢印の意味が混ざる：データフローと依存関係を同じ矢印で描くと読み手が混乱します。線種を分けるか、図自体を分割しましょう
- VPCの境界線がない：パブリック/プライベートサブネットの境界は必須情報です
- 1枚に全てを詰め込む：俯瞰図と詳細図は別ページに分割します
- 更新日と作者がない：図の信頼性は「いつ・誰が」で決まります
まとめ
構成図は「美しさ」よりも「目的への適合」が重要です。レイヤーで整理し、公式アイコンを使い、必要なら複数枚に分け、更新日を入れる。これだけで現場で使われる図になります。次回はこの図に対応する「定番アーキテクチャ」を解説します。
