Zenn
🐕

AWSのアーキテクチャ図を描くときに意識していること

2022/08/27に公開
AWS
#
構成図
#
アーキテクチャ図
tech

最初に

公式のガイドライン

AWSが配布しているツールキットの中に基本的なガイドラインが記載されています。
https://aws.amazon.com/jp/architecture/icons/

描き方に正解はない

こちらの記事のあるようにアーキテクチャ図に正解はなく、伝えたいことが適切に伝わるということが大切だと思います。
伝えたい内容や伝える相手によって重点や粒度を変えることを心がけています。
https://aws.amazon.com/jp/builders-flash/202204/way-to-draw-architecture/?awsf.filter-name=*all

描画ツール

diagrams.net（Draw.io）を使ってます。
https://www.diagrams.net/

意識していること

アイコンは最新バージョンを使用する

AWSのアイコンは定期にアップデートされるので最新のアイコンを使うようにします。

ちなみにdiagrams.netでEC2と調べると古いアイコンが先頭に出てきたので意識していないとこちらを使いがちかもです。

アイコンのバージョンを混ぜない

アイコンは最新バージョンを使用すると同じような内容ですが、複数バージョンのアイコンが混在しないようにします。以下の図ではELBだけ古いアイコンになっています。間違ってはいないのですがちょっと違和感のある図になります。

アカウント/リージョン/VPC/AZ/サブネットは省略しない

以下のような設計内容を明示的にするために基本的には描くようにしています。

  • ユーザやデータセンターなどの外部との境界
  • アカウント構成（1アカウント or マルチアカウント）
  • リージョン構成（使用するリージョン、単一リージョン or マルチリージョン）
  • AZ構成（シングルAZ or マルチAZ）

VPC、サブネットはNW構成を把握するために最低限必要なので必ず図示します。

サービス名も省略しない

アーキテクチャ図を作成者以外が見るときや作成者自身でも久しぶりに見るときに何のアイコンだっけとなるので書いておいた方が良いと思います。
EC2やECSのようなコンピューティングサービスは用途、RDS/Auroraはエンジンのタイプやインスタンスの種別（Writer/Reader/Stanby/Serverless）なども記載されていると分かりやすいです。

ALBのような複数サブネットに跨って構築されるサービスはサブネットの間に図示する

以下のような感じでサブネットに跨って構築しますよ感を出します。

サービスの配置は正確に

VPCの中に配置されるサービスなのか、リージョンごとに作成・管理されるサービスなのか、リージョンを跨って使用されるサービスなのかを意識して配置します。

  • 良くない例
    VPC内に構築するものでないCloudWatch AlarmとSNSがVPC内に配置されてしまっています。
    Amazon AuroraはVPC内に構築するものですがサブネット内に図示するとより正確です。

  • 良くない例を修正した例
    CloudWatch AlarmとSNSをVPC->リージョンに移動しました。
    Amazon Auroraはサブネット上に移動して構成が分かるようにしました。

VPC<->VPC外の通信経路が分かるようにする

VPCとVPC外（インターネット|AWSサービス|別VPC|PrivateLink|DC etc）のイン/アウトの通信がどのように行われるかというのは運用でも重要になってくるので、漏れなく図示します。
以下の図では書かれていませんがVPCエンドポイントは何のサービスのエンドポイントかまで記載されていると良いと思います。

通信やリクエストの流れを矢印で示す

アイコンを置いただけだと通信の流れやサービス間の連携が分かりづらいので矢印でそれらを示すようにします。

ユーザを描く

なくても問題ないのですが誰のためのシステムかということを示すためにと手間もかからないので描くことが多いです。

(基本的に)セキュリティグループとかEBSとかIAMは図示しない

使うサービスを全て図示しようすると、VPCやEC2に関連するものだけでもサブネット/セキュリティグループ/ルートテーブル/ネットワークACL/インスタンス/EBS/キーペア/EIP/IAMロールなどきりがなく、アーキテクチャ図も分かりづらくなります。またアーキテクチャ図の作成に時間がかかり、修正する際のコストも増えるので基本的にはそのアーキテクチャ図で伝える必要がないサービスは図示しません。

  • セキュリティグループ・EBS・IAMロールを図示した例
    これくらいだったらまだ見れるかもですがそれでも認知負荷が大きく、修正しづらい図になってしまっています。

EBSやセキュリティグループを図示するときの例

以下のような場合などはそれらを読み手に伝える必要性があるので、EBSやセキュリティグループ/ネットワークACL/ルートテーブルも図示するのが適切だと思います。

  • 10TBのEBSをEC2インスタンスにアタッチする
  • セキュリティグループ・ネットワークACL・ルートテーブルを使用して細かくトラフィックを制御する

全体図を1枚で描いて詳細はページを分ける

全てを1枚にまとめようとするのは限界があるので、diagrams.netのページを分ける機能を使用して全体図を最初に1枚用意、詳細は別ページで描くようにしています。このようにすることで全体像を把握しやすくしつつ、細かい内容まで正確に伝えることが出来ます。

Discussion