口頭説明だけでは漏れが出やすく、後任者が実環境を見ても何がどこにあるのか把握できないケースは、よくある引き継ぎのつまずきです。
この記事では、AWSアーキテクチャ図の書き方を基礎から解説し、draw.ioを使った引き継ぎ向けの図面作成手順とNotionを活用した保守メモの構造化まで説明します。想定環境はAWS東京リージョンでマルチAZを使った標準的なWebシステムです。
この記事のポイント
・AWSアーキテクチャ図はVPC境界→サブネット→リソースの順に描くと整理しやすい
・draw.ioで公式AWSアイコンを使うと構成要素の役割が視覚的に伝わる
・aws ec2 describe-vpcsコマンドで実態を随時確認して図と突き合わせる
・Notionのデータベースビューで構成要素・変更履歴・メンテ手順を一元管理できる
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
なぜAWSアーキテクチャ図が運用引き継ぎに欠かせないのか
AWSの構成は、コンソールや CLIで確認しようとすると情報が分散しています。VPCの設定はひとつのコンソール画面、EC2インスタンスは別、セキュリティグループはまた別のタブというように、全体像を一目で見られる場所がありません。アーキテクチャ図はこの問題を解決するためのものです。構成要素と通信フローを1枚の図にまとめることで、後任者が「このサービスはどのサブネットにいるのか」「どのセキュリティグループを通過するのか」を瞬時に把握できるようになります。
特に引き継ぎを想定した図面には以下の3点が含まれている必要があります。
・ネットワーク境界：VPC、パブリック/プライベートサブネット、インターネットゲートウェイの位置関係
・サービスの役割：EC2、RDS、ALB、Lambda等の配置と役割
・通信フロー：インターネットから各サービスへの通信経路とセキュリティグループのルール
AWSアーキテクチャ図の書き方：基本要素と記法
1. 公式AWSアイコンライブラリの使い方
AWSはdraw.io（diagrams.net）向けの公式アイコンライブラリを無償で提供しています。このライブラリを使うと、EC2・RDS・S3・ALBなど各サービスのアイコンをそのまま使えます。サービス名のラベルを付けるだけで構成要素の種別が直感的に伝わるため、引き継ぎ相手がAWSの基礎知識を持っていれば説明の手間が大幅に減ります。draw.ioで公式アイコンを使う際は、画面左の「検索」ボックスにサービス名を入力するか、「AWS」ライブラリを有効化して一覧から選びます。アイコンに直接ラベル（例：「Web Server (ap-northeast-1a)」）を付けると、どのAZに配置しているかまで一目でわかります。
2. VPCとサブネットの境界を正確に描く
アーキテクチャ図の骨格になるのがVPCとサブネットの境界です。描き方の基本は以下の順番です。・外側の四角：VPC全体を囲む枠（CIDRブロックをラベルに記載）
・内側の四角（パブリック）：インターネットゲートウェイに接続できるサブネット
・内側の四角（プライベート）：直接インターネットに出られないサブネット
・AZごとに列を分ける：ap-northeast-1aとap-northeast-1cを横に並べてマルチAZ構成を明示
この構造で書くと、可用性ゾーンごとの冗長構成が視覚的に伝わります。後任者がどのAZにどのリソースがあるかを一目で確認でき、障害時の影響範囲の判断にも役立ちます。
3. セキュリティグループとトラフィックフローの表現
セキュリティグループは、リソースを囲む破線の枠として描くのが一般的な書き方です。枠のラベルに「sg-web（80/443 inbound from internet）」のように名前と主要ルールを簡潔に書くと、後任者がインバウンドルールを確認しなくても通信可否の概要が把握できます。トラフィックフローは矢印で表します。インターネット→ALB→EC2→RDSの順に実線の矢印を引き、矢印にポート番号（例：「443」「3306」）を添えると、通信経路が明確になります。セキュリティグループのルールが複雑な場合は、図の外側に補足テーブルを置いて詳細を記載するとスッキリします。
draw.ioで引き継ぎ用アーキテクチャ図を作成する手順
1. AWSアイコンセットの追加と初期設定
draw.ioを開いたら、まずAWSアイコンライブラリを追加します。・画面左下の「＋」→「Shape Library」を開く
・「AWS」のチェックボックスをオンにする
・左パネルに「AWS19」等のカテゴリが追加されたことを確認する
次に新規ファイルを作成し、ファイル名に「システム名_arch_YYYYMMDD.drawio」のように日付を入れます。こうすると変更のたびに版管理ができ、後任者が「最新の構成図はどれか」を迷わずに済みます。
Linuxサーバーを直接AWSで運用している方は、AWS（Amazon Linux）の実務入門と組み合わせると、図の内容とコマンド操作の両方を体系的に習得できます。
2. 階層を意識した構成要素の配置
図を描く順序は「外側から内側へ」が鉄則です。・まずVPCの外枠を描く：CIDRブロック（例：10.0.0.0/16）をラベルに記載
・AZの列を作る：VPC内を縦2列（または横2列）に分けてAZを割り当てる
・パブリックサブネットを描く：各AZ列の上段に配置（例：10.0.1.0/24, 10.0.2.0/24）
・プライベートサブネットを描く：下段に配置（例：10.0.101.0/24, 10.0.102.0/24）
・各サービスアイコンを配置：ALBはパブリックに、EC2・RDSはプライベートに置く
AWSの構成はこのパターンで8割の一般的なWebシステムをカバーできます。
3. 引き継ぎ相手が読みやすい注釈と凡例の付け方
構成図に以下の要素を追加すると引き継ぎの質が上がります。・凡例（Legend）：図の右下に「パブリックサブネット＝青、プライベート＝緑」等の色の意味を記載
・各リソースのラベル：インスタンスID・プライベートIPアドレスを記載（IPは定期更新が必要）
・更新日：図の左上または右上に「最終更新：YYYY-MM-DD」を必ず記載
特に更新日は重要です。古い図を最新の構成と思い込んで作業する後任者がいると、オペレーションミスの原因になります。
AWS CLIで現在の構成を確認しながら図を正確に保つ
アーキテクチャ図の最大のリスクは「実態との乖離」です。構成変更のたびに図を更新する運用ルールが徹底されないと、数ヶ月で図と実環境が食い違います。この問題を防ぐため、定期的にAWS CLIで実際のリソース情報を確認し、図と突き合わせる習慣をつけます。VPCとサブネットの情報を一覧で取得するには以下のコマンドを使います。
# VPC一覧を確認する aws ec2 describe-vpcs --query 'Vpcs[*].[VpcId,CidrBlock,Tags[?Key==].Value|[0]]' --output table # 出力例（環境により異なります） # --------------------------------------------------------- # | DescribeVpcs | # +-----------------+----------------+--------------------+ # | vpc-0abc12345 | 10.0.0.0/16 | production-vpc | # +-----------------+----------------+--------------------+
# サブネット一覧をVPC IDで絞り込む aws ec2 describe-subnets --filters "Name=vpc-id,Values=vpc-0abc12345" --query 'Subnets[*].[SubnetId,CidrBlock,AvailabilityZone,Tags[?Key==].Value|[0]]' --output table # 出力例（環境により異なります） # ----------------------------------------------------------------------- # | DescribeSubnets | # +------------------+-----------------+------------------+-------------+ # | subnet-001pub | 10.0.1.0/24 | ap-northeast-1a | public-1a | # | subnet-002pub | 10.0.2.0/24 | ap-northeast-1c | public-1c | # | subnet-101prv | 10.0.101.0/24 | ap-northeast-1a | private-1a | # | subnet-102prv | 10.0.102.0/24 | ap-northeast-1c | private-1c | # +------------------+-----------------+------------------+-------------+
# セキュリティグループのインバウンドルールを確認する aws ec2 describe-security-groups --filters "Name=vpc-id,Values=vpc-0abc12345" --query 'SecurityGroups[*].[GroupId,GroupName,IpPermissions[*].[FromPort,ToPort,IpRanges[*].CidrIp]]' --output json # ※出力はJSONになる。ポート番号とCIDRを確認して図のラベルと照合する
Notionで保守メモを構造化する手順
draw.ioのアーキテクチャ図は構成の全体像を伝えるためのものですが、「このサーバーのメンテナンス手順はどうするのか」「過去にどんな変更をしたのか」という情報は図だけでは伝えられません。Notionを使うとこの補完的な情報を構造化して管理できます。1. アーキテクチャ図ページの基本構成
Notionでの推奨ページ構成は以下のとおりです。・インフラ概要ページ（トップ）：draw.ioの図を埋め込み＋VPC CIDRやリージョン等の基本情報
・コンポーネントDB：リソースごとのデータベース（後述）
・変更履歴ページ：日付・変更内容・実施者・影響範囲の記録
・障害対応手順ページ：症状別のトラブルシュート手順
draw.ioの.drawioファイルはNotionにアップロードして添付ファイルとして管理できます。ただしNotion内でのプレビュー表示は2024年時点で非対応のため、PDFエクスポートを別途添付しておくと後任者が図を素早く参照できます。
2. データベースビューで構成要素を管理する
コンポーネントDBをNotionのテーブルビューで作ると、各リソースの情報を一元管理できます。推奨カラムは以下のとおりです。・Name：リソース名またはタグ名
・Type：EC2 / RDS / ALB / Lambda等
・ID：インスタンスIDやARN
・Private IP：プライベートIPアドレス
・AZ：配置しているAvailability Zone
・Role：Webサーバー / DBサーバー / バッチ等の役割
・メンテ手順：関連ページへのリレーション
テーブルビューとボードビューを切り替えると、役割別・AZ別の俯瞰が簡単にできます。引き継ぎ時に後任者がフィルタリングして必要な情報だけ見られるため、大規模な構成でも迷いません。
3. 変更履歴とメンテナンス手順を紐付ける
変更履歴は独立したデータベースで管理し、コンポーネントDBとリレーションで繋ぐのが効果的です。変更履歴DBの推奨カラムは以下です。・日付：変更実施日
・対象コンポーネント：コンポーネントDBへのリレーション
・変更内容：何を変えたか（1行で）
・理由：なぜ変更したか
・実施者：誰が変更したか
・影響範囲：どのサービスに影響が出たか
変更理由を記録する習慣が特に重要です。「なぜこうなっているのか」がわからない構成は、後任者が誤って変更したり、変更を躊躇して技術的負債を積み上げる原因になります。
よくある失敗パターンと対処法
| 失敗パターン | 原因 | 対処法 |
|---|---|---|
| 図と実環境がずれている | 構成変更時に図を更新していない | 変更手順書に「図の更新」をステップとして明記する |
| セキュリティグループIDだけ書いてある | sg-xxxxxxxx形式では役割が伝わらない | タグ名と主要ルールをラベルに記載する |
| AZ区分が不明確 | 全サービスが1列にまとめて描かれている | AZごとに列を分け、列ヘッダに「ap-northeast-1a」等を記載 |
| Notionのページが増えすぎて迷子になる | ページ階層の設計が最初からない | インフラ概要→コンポーネントDB→変更履歴の3階層を最初に決める |
| 図のファイルがどれが最新か不明 | 日付入りファイル名のルールがない | 「システム名_arch_YYYYMMDD.drawio」のネーミングルールを統一する |
本記事のまとめ
AWSアーキテクチャ図の書き方と運用引き継ぎ資料の作成手順をまとめます。| やること | ポイント |
|---|---|
| アーキテクチャ図の基本構成 | VPC外枠→AZの列→サブネット→リソースの順に描く |
| draw.ioの設定 | 公式AWSアイコンライブラリを有効化してサービス名ラベルを付ける |
| AWS CLIでの確認 | aws ec2 describe-vpcs / describe-subnets で実態と図を定期照合 |
| Notionの構成 | インフラ概要・コンポーネントDB・変更履歴の3階層で管理 |
| 変更時のルール | 変更手順に「図の更新」「Notionへの記録」をセットで組み込む |
AWSをLinuxとセットで体系的に学べる無料マニュアルを用意しています。
＞＞ AWS（Amazon Linux）無料マニュアルを受け取る
3,100名以上が実践した「型」を無料で公開中
プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。
姓・名・メールの3つだけ／30秒／解除は3秒 ／ 詳細はこちら
- 前のページへ：AWSマイクロサービスアーキテクチャをVPCサブネットで分離設計する｜ECS構成の実践例
- この記事の属するカテゴリ：AWS(Amazon Linux)へ戻る
無料メルマガで学習を続ける
Linuxの実践スキルをメールで毎週お届け。
登録は30秒、解除もいつでも可。
登録無料・いつでも解除できます