Skip to content
Back to skills

Aws Drawio Diagram

ASecurity

AWS の構成図を draw.io の XML(.drawio)で描く。公式の AWS4 アイコンを使い、タイトルや凡例や番号バッジのような装飾を足さず、どのサービスがどこにあって何とつながっているかだけで読める図にする。AWS 構成図、アーキテクチャ図、インフラ構成図、ネットワーク構成図、VPC の図を描いてほしいとき、draw.io で AWS の図を作りたいとき、既存の構成図を直したいときは必ずこの Skill を使う。Use this whenever the user asks for an AWS architecture diagram, cloud infrastructure diagram, VPC diagram, or a draw.io file of AWS resources, even if they don't say "draw.io". Mermaid、PlantUML、Python の diagrams ライブラリなど、ほかの形式を指定されたときは使わない。Do not use it when the user explicitly ask...

  • 34 stars
  • 0 votes
  • 0 copies
  • 0 views
  • Added September 26, 2026
ai-agentspythongosqlaws

Works with

  • cli
  • mcp

Security analysis

A100/100

Pro scans all 4 files and shows the line behind each finding

Scanned September 26, 2026

npx -y skills add sagochiko/aws-drawio-diagram-skill --skill aws-drawio-diagram --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Aws Drawio Diagram?

Add the live security badge to your README. It updates with every re-scan.

Security grade badge for Aws Drawio Diagram
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/sagochiko-aws-drawio-diagram/badge)](https://www.skillsdirectory.com/skills/sagochiko-aws-drawio-diagram)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
name: aws-drawio-diagram
description: AWS の構成図を draw.io の XML(.drawio)で描く。公式の AWS4 アイコンを使い、タイトルや凡例や番号バッジのような装飾を足さず、どのサービスがどこにあって何とつながっているかだけで読める図にする。AWS 構成図、アーキテクチャ図、インフラ構成図、ネットワーク構成図、VPC の図を描いてほしいとき、draw.io で AWS の図を作りたいとき、既存の構成図を直したいときは必ずこの Skill を使う。Use this whenever the user asks for an AWS architecture diagram, cloud infrastructure diagram, VPC diagram, or a draw.io file of AWS resources, even if they don't say "draw.io". Mermaid、PlantUML、Python の diagrams ライブラリなど、ほかの形式を指定されたときは使わない。Do not use it when the user explicitly asks for Mermaid, PlantUML, or the Python diagrams library.
---

# AWS 構成図を draw.io で描く

## この図が目指すもの

見た人が、どのサービスがどのネットワークの境界の中にあり、リクエストやデータがどこからどこへ流れるかを、図だけで追えること。

構成が読めることを優先し、見栄えのための要素は足さない。タイトル、番号付きのバッジ、凡例のような装飾は、情報を増やす一方で図を読みにくくする。アイコンを色付きの枠で囲むと、公式アイコンをそのまま置いた図に見えなくなる。

## 進め方

1. 構成を把握する。登場するサービス、置き場所(VPC の内か外か、どのサブネットか)、つながりを書き出す
2. 配置を決める。下の「配置」の決まりに沿って、枠の入れ子と各アイコンの座標を先に決める
3. XML を分けて書く。枠、アイコン、線の順に、何回かに分けてファイルへ足していく
4. draw.io の CLI で PNG に書き出し、自分の目で確かめる
5. 書いたもの、描かなかったもの、迷ったところを伝える

3 で分けるのは、1回の応答で XML を丸ごと書くと出力の上限に当たって落ちることがあるため。

座標を計算するスクリプトなどの作業用のファイルは、`/tmp` ではなく出力先と同じディレクトリに置く。消さずに残し、最後の説明でどのファイルを残したかを伝える。`/tmp` に置くと、同時に動いている別の作業のファイルと名前がぶつかることがある。

座標は自分で決める。draw.io CLI の `--layout`(自動配置)は使わない。枠の入れ子や上下の位置に意味がある図なので、自動配置で動かされると崩れる。

## draw.io の CLI

PNG への書き出しには draw.io desktop の CLI を使う。まず `which drawio` で PATH にあるかを見る。無ければ `references/cli.md` の OS ごとの場所を探す。画面の無い Linux や WSL2 での呼び方もそこにある。

書き出しはこう叩く。`-e` で PNG の中に図の XML を埋め込むので、PNG を draw.io で開けば編集できる。

```sh
drawio -x -f png -e -b 10 -o diagram.drawio.png diagram.drawio
```

書き出す前に `python3 -c "import sys, xml.dom.minidom; xml.dom.minidom.parse(sys.argv[1])" diagram.drawio` で XML が壊れていないかを確かめる。壊れた XML でも CLI はエラーを出さず、何も描かれていない小さな PNG を作るので、PNG ができたことは成功の証拠にならない。CLI が `sandbox_extension_issue_file failed` のような警告を出しても、図が描かれていれば問題ない。書き出した画像で、線がラベルの文字に重なっていないか、アイコンが枠からはみ出していないか、アイコンの絵が出ているかを見る。直したら書き出し直す。

CLI が見つからなければ書き出しは飛ばす。そのときは上の検査で XML が壊れていないことだけ確かめ、目で確かめていないことを最後に伝える。

## 依頼に無いもの

依頼どおりに動かすと必ず要るものは、依頼に書かれていなくても描く。NAT Gateway や外向きの ALB を置く VPC の Internet Gateway が代表で、描かないと、動かない構成の図になる。足したものは最後の説明で伝える。

要るかどうかが構成の選び方で変わるもの(VPC エンドポイント、踏み台のサーバーなど)は足さない。描いていないことを最後の説明で伝える。

## 配置

利用者は図の上端に置く。リクエストが上から下へ流れる向きにそろえると、入れ子の深さと縦の位置が対応して読みやすい。

枠は外から AWS Cloud、リージョン、VPC、アベイラビリティゾーン、サブネットの順に入れ子にする。

VPC の外で動くものは、グローバルなサービスかリージョンのサービスかで置き場所を分ける。CloudFront、Route 53、CloudFront に付ける WAF、Lambda@Edge、IAM のようなグローバルなサービスは、AWS Cloud の枠の中、リージョンの枠の外に置く。S3、CloudWatch、Cognito、Lambda、DynamoDB、ECR のようなリージョンのサービスは、リージョンの枠の中、VPC の枠の外に置く。リージョンの枠の外に S3 を置くと、どのリージョンのバケットか読めなくなる。どちらか迷うサービスは、作るときにリージョンを選ぶかどうかで決める。

アベイラビリティゾーンは横に並べ、各ゾーンの中はパブリックサブネットを上、プライベートサブネットを下に置く。インターネットに近いものほど上に来るので、リクエストの流れと向きがそろう。

各ゾーンでは、リクエストの本流になるアイコン(ECS や EC2、データベースなど)を縦一列にそろえ、その列をサブネットの横幅の中央に置く。アイコンの x 座標は、サブネットの幅の半分からアイコンの幅の半分を引いた値にする。ALB と NLB はこの列に入れず、下の「よく出るサービスの描き方」のとおり AZ の境目に1つ置く。NAT Gateway のように本流から外れるものは、パブリックサブネットの中で ALB と反対側(AZ の外側寄り)に置く。本流を片側に寄せると、反対側が何も無い区画として残り、どれが主役か分かりにくくなる。

アベイラビリティゾーンは `ap-northeast-1a` のように正式名称で書く。「AZ A」「ゾーン1」のような略記にすると、どのリージョンの構成かが図から読めなくなる。リージョンの指定がなければ、会話の言語から妥当なものを選ぶ。日本語なら東京(`ap-northeast-1`)が自然で、枠の名前に「東京リージョン」のように地名を添えてよい。指定が無くて選んだときは、どのリージョンにしたかを最後に伝える。

アイコンは 60x60 にする。間隔はラベルと線のラベルが収まる最小限にとどめ、広げすぎない。図が広がると、記事や画面に載せたとき全体が縮み、アイコンも文字も小さく見える。目安は、同じ行に並ぶアイコンの中心どうしが横 140 前後、同じ列が縦 160 前後。あいだに線のラベルが入るときだけ縦 210 程度まで広げる。ラベルの付いた横向きの線でつなぐアイコンどうしは、ラベルの幅に左右 20 ずつ足した分だけあいだを空ける。`fontSize=12` の日本語なら1文字およそ 12 で、「ログ・メトリクス」なら中心どうしを 200 前後にする。枠の内側の余白は 20 から 30 にする。

VPC の外に置くリージョンのサービス(S3、CloudWatch、Cognito など)は、VPC の右に縦一列に並べる。それぞれの高さは、つながる相手の高さに合わせる。S3 なら、VPC の中から読み書きするサービス(ECS など)があればその高さ、CloudFront から配信するだけならリージョンの枠の上端近くにする。CloudFront はリージョンの枠の外にあるので、同じ高さには置けない。CloudWatch はログを送るサービスの高さにする。置く側をそろえると、回ごとに位置が変わらない。VPC から離しすぎず、VPC の枠との間は 60 から 80 にする。VPC の無い構成では、本流の列の右に並べる。書き出した PNG で、枠の中やサービスのあいだに何も無い区画が目立てば、座標を詰めて書き出し直す。

## アイコン

AWS 公式の AWS4 アイコンを使う。四角や丸、文字だけの箱で代用しない。

アイコンはサービス単位にそろえる(`shape=mxgraph.aws4.resourceIcon;resIcon=mxgraph.aws4.<名前>`)。ALB と NLB も Elastic Load Balancing のサービスアイコンで描き、種類はラベル(「Application Load Balancer」「Network Load Balancer」)で書く。ECS のタスク、S3 のバケット、Lambda の関数のようなリソースアイコンも使わず、そのサービスのアイコンにする。サービスごとに粒度を変えると、同じ依頼でも ALB を四角で描く回と丸で描く回に割れ、同じものが別の種類に見える。サービス単位にそろえるのが一番単純で、回ごとに割れにくい。

リソースアイコン(`shape=mxgraph.aws4.<名前>`)は、NAT Gateway、Internet Gateway、VPC エンドポイント、Site-to-Site VPN の接続、カスタマーゲートウェイ、Transit Gateway のアタッチメントのように、独立したサービスアイコンを持たない部品にだけ使う。

細かすぎるアイコンは使わない。EC2 のインスタンスの種類別(`c5_instance` など)や、DB のエンジン別(`aurora_mysql_instance` など)のアイコンは、違いが絵ではほとんど伝わらない。違いはラベルに書く。

NAT Gateway と Internet Gateway は、専用のリソースアイコン(`nat_gateway`、`internet_gateway`)で描く。サービス単位にそろえようとして VPC のアイコンに丸めると、何の機器か分からなくなる。Transit Gateway は本体のリソースアイコンが無いので、サービスアイコン(`transit_gateway`)で描く。

利用者、インターネット、社内データセンター、カスタマーゲートウェイ、モバイル端末、IoT 機器のような AWS の外のものも、汎用のアイコンで描く。文字だけの箱にしない。

使う名前は `references/styles.md` の表から選ぶ。表に無いものは draw.io の名前を推測することになるが、draw.io の名前は略称が多く(EKS は `eks`)、サービス名をそのまま小文字にしても当たらないことがある。名前が違うとアイコンの絵が出ず、色の四角だけになるので、書き出した PNG で必ず確かめる。CLI が無くて書き出せないときは確かめようがないので、表に無いサービスに推測した名前を使ったら、そのことを最後に伝える。

アイコンをそのまま置く。色付きの枠で囲んだり、枠に「Compute」「データベース」のような役割名を載せたりしない。

枠、アイコン、線のスタイル文字列とカテゴリの色は `references/styles.md` にある。

## ラベル

ラベルは常にアイコンの下に置く。スタイルの `verticalLabelPosition=bottom` を書き換えず、線を避けるためにラベルを上や横へ動かさない。線がラベルにかかりそうなときは、ラベルではなく線のほうを「線」の節のやり方で直す。サービス名は英語の正式名称のまま(`Amazon CloudFront`、`Application Load Balancer`)にし、それ以外は会話の言語に合わせる。

枠の名前も同じにする。「AWS Cloud」「VPC」はそのまま書き、リージョン、アベイラビリティゾーン、サブネットは会話の言語で書く。日本語なら「東京リージョン(ap-northeast-1)」「パブリックサブネット」「プライベートサブネット」。枠だけ英語にすると、1枚の図の中で言語が混ざる。最後に伝える説明も会話の言語で書く。

要素の理解に要る短い補足は、ラベルの2行目に添えてよい。「Writer」「Reader」、「us-east-1 で発行」のように、図だけでは分からない役割や制約か、依頼に書かれた区別(「内部向け」など)を書く。図から読めることは書かない。CloudFront の後ろにある ALB に「インターネット向け」と添えても、何も足さない。長い説明文にはしない。

線にもラベルを付ける。「HTTPS」「動的リクエスト」「静的ファイル」「読み書き」「レプリケーション」「ログ・メトリクス」のように、何が流れるかを書く。線のラベルがないと、どの線が何の通信か読めない。ラベルは線の `value` に書き、線とは別の文字として置かない。別に置くと、線を動かしたときにラベルだけ取り残される。

文字の背景は透明にする。線のラベルは何も書かないと白い箱の上に出て、色の付いた枠の上で浮き、下の枠線も隠す。透明にしただけだと線が文字の真ん中を横切るので、`references/styles.md` の線のスタイルにある `labelBackgroundColor=none;verticalAlign=bottom;align=left;spacingLeft=6` をそのまま使う。縦向きの線では、文字が線の右に出る。横向きの線(始点と終点がほぼ同じ高さにある線)は、`align=left;spacingLeft=6` を `align=center` に置き換え、文字を線の上の真ん中に出す。左寄せのままだと、文字が線の中点から右へ伸びて、右隣のアイコンに乗る。アイコンや枠のラベルにも背景色を付けない。

## 線

線は `edgeStyle=orthogonalEdgeStyle` で直角に曲げる。

曲がり角は丸めない。線のスタイルには必ず `rounded=0` を書く。draw.io の一般的な例は直角の線に `rounded=1` を勧めているが、構成図では角が丸いと線の向きが変わる位置がぼやけ、手描き風の柔らかい見た目になる。

線はアイコンの辺の中央から出し、辺の中央へ入れる。`exitX`、`exitY`、`entryX`、`entryY` で接続点を指定する。角や辺の端から出ると、どのアイコンにつながっているか追いにくい。

アイコンの下の辺はラベルに隠れているので、下の辺の中央から出す線と、下の辺の中央へ入れる線は、ラベルの下から出し、ラベルの下で止める。`exitY=1` のまま `exitDy` で接続点を下へずらし、`exitPerimeter=0` を足す。入れる側は `entryDy` と `entryPerimeter=0`。ずらす量はラベルが1行なら 24、2行なら 38、3行なら 52。`exitPerimeter=0` や `entryPerimeter=0` を書かないと接続点がずれず、線がラベルを突き抜けてアイコンの下の辺まで届く。

```text
exitX=0.5;exitY=1;exitDy=38;exitPerimeter=0
entryX=0.5;entryY=1;entryDy=24;entryPerimeter=0
```

アイコンやラベルの文字の上に線を通さない。線どうしを同じ経路で並行させて重ねない。重なると1本に見えて、何本つながっているか分からなくなる。線どうしの交差はかまわない。交差を無理に避けると遠回りの経路になり、かえって読みにくい。

同じ役割のアイコンが複数ある構成(各 AZ の ECS から Aurora の Writer と Reader へ、など)では、つながる組み合わせをすべて線で描く。AZ をまたぐ線が交差してもかまわない。最後の説明で「同じ AZ の中の線だけにまとめ、ラベルに『両 AZ から』と添える形にもできる」と伝え、見やすさを優先したい人が選べるようにする。

線が多く集まるアイコンでは、ここまでの決まりを全部は守れないことがある。そのときは次の順に優先する。

1. 省かない。依頼にあるつながりは描く。まとめて1本にしたときは、線のラベルでそう断る
2. 線どうしを重ねない
3. 辺の中央から出す。1つの辺に2本以上つなぐときは、次の位置に振り分ける。2本なら 0.25 と 0.75、3本なら 0.25、0.5、0.75。中央の 0.5 を残してもう片方だけずらすと、どちらの線が主か分かりにくい

本流と補助の流れで線を描き分ける。リクエストの本流は実線、ログ、メトリクス、レプリケーション、関連付けは破線にし、色も変える。意味は線のラベルで伝わるので、凡例は置かない。

矢印の向きは、呼び出しやデータが流れる向きにする。CloudFront が呼び出す Lambda@Edge は、CloudFront から Lambda@Edge へ向ける。WAF や ACM のように、流れが無く設定として付けるだけのものは、付ける側から付けられる側(CloudFront)へ向ける。

## 図の外に置かないもの

タイトル、サブタイトル、凡例、番号付きのバッジ、図の横に並べる説明パネルは置かない。図の情報は、枠、アイコン、ラベル、線とそのラベルで伝える。

## よく出るサービスの描き方

AWS WAF は、利用者と CloudFront の間の経路に挟まない。CloudFront の横に置き、「Web ACL を適用」のような破線で CloudFront に関連付ける。WAF は CloudFront に付ける Web ACL で、トラフィックが通過する別の機器ではない。

AWS Certificate Manager は CloudFront の横に置き、破線で関連付ける。CloudFront に付ける証明書は us-east-1 で発行する必要があるので、図のリージョンの枠の外に置き、ラベルにそう添える。

ALB と NLB は1つだけ描く。複数の AZ のサブネットにまたがる1つのリソースなので、AZ ごとに描くと2つあるように読める。AWS の公式の図や記事でも、ロードバランサーは1つ、その先のターゲットは AZ ごとに描くのが普通。

AZ が2つなら、ALB を左右の AZ の境目、パブリックサブネットの高さに置く。アイコンの中心の x 座標を2つの AZ の境目に合わせ、両方のパブリックサブネットの枠に少しかかるようにする。こうすると、ALB がパブリックサブネットに置かれていることも図から読める。ALB の親(`parent`)はサブネットではなく VPC にし、XML ではサブネットと AZ の枠より後に書いて前面に出す。ALB から各 AZ のターゲット(ECS など)へ線を引く。下の辺から2本出すので、辺の 0.25 と 0.75 から、ラベルの下までずらして出す。Internet Gateway を描くときは、ALB と同じ x 座標にそろえて真上に置く。

AZ が3つ以上なら、境目が1つに決まらないので、ALB を AZ の枠の上の段(VPC の中)に1つ置き、各 AZ のターゲットへ線を引く。このときは「ALB と反対側」が決まらないので、NAT Gateway はどの AZ でも本流の列の右に置く。

CloudWatch には、ログやメトリクスを送るサービスから線を引く。ログやメトリクスは補助の流れなので、「線」の節の「つながりをすべて描く」の例外として、代表の1本にまとめてよい。まとめたときは、線のラベルに「ALB / ECS / Aurora」のように送り元を書くか、「両 AZ から同様」と断る。黙って省かない。

ECS のサービスを Fargate で動かす構成は、AWS Fargate のアイコン(`fargate`)1つで描き、ラベルを「Amazon ECS(Fargate)」のようにする。ECS のアイコンは置かない。両方を並べると各サブネットにアイコンが2つずつ並び、図が横に広がるわりに、読み手に伝わることは増えない。

Aurora は Writer と Reader をそれぞれのアベイラビリティゾーンに置き、Writer から Reader へ「レプリケーション」の破線を引く。

## XML の決まりごと

`.drawio` は mxGraphModel の XML そのもの。圧縮や base64 にしない。

```xml
<mxGraphModel adaptiveColors="auto">
  <root>
    <mxCell id="0" />
    <mxCell id="1" parent="0" />
  </root>
</mxGraphModel>
```

`id="0"` と `id="1"` は必ず置く。ほかの要素は `id="1"` か、入れ子の枠を親にする。子の座標は親の左上からの相対座標になる。`adaptiveColors="auto"` はダークモードで色を自動で反転させるためのもので、`background` は付けない。

セルの id は `vpc`、`alb`、`ecs-1a`、`edge-ecs-1a-to-writer` のように中身が分かる名前にし、重複させない。線の `source` と `target` は、実在するセルの id を指す。

線のセルは自己終了タグにせず、必ず `<mxGeometry relative="1" as="geometry" />` を子に持たせる。無いと線が描かれない。

```xml
<mxCell id="edge-alb-to-ecs-1a" value="動的リクエスト" style="..." edge="1" parent="vpc" source="alb" target="ecs-1a">
  <mxGeometry relative="1" as="geometry" />
</mxCell>
```

XML のコメント(`<!-- -->`)は書かない。中に `--` が入ると読み込めなくなるうえ、図には何も足さない。

属性値の中の `&`、`<`、`>`、`"` は `&amp;`、`&lt;`、`&gt;`、`&quot;` にする。ラベルの改行は `&#xa;` を使う。`\n` はそのまま文字として出てしまう。スタイルには `html=1` を入れる。

## 既存の図を直す

既存の .drawio を直すよう頼まれたら、描き直さずにそのファイルを直す。手順は `references/edit.md` にある。

## 出力

保存先の指定があればそこに書く。なければ、リポジトリに既存の図の置き場があればそこに、無ければ作業ディレクトリに書く。ファイル名は中身が分かるケバブケースにする(`cloudfront-alb-ecs-aurora.drawio` など)。

渡すのは `.drawio`。確かめるために書き出した PNG は、`cloudfront-alb-ecs-aurora.drawio.png` のように二重の拡張子で隣に置く。

書き終えたら、次のことを伝える。上の節で「最後に伝える」としたものは、ここでまとめて書く。

- ファイルの場所と、描いたサービス
- PNG に書き出して目で確かめたかどうか
- 依頼に無いが足したものと、描かなかったもの
- まとめて省いた線と、別の描き方もできること
- 指定が無くて選んだリージョンと、推測したアイコン名
- 残した作業用のファイル
- 判断に迷ったところ

## ライセンス

この Skill は jgraph/drawio-mcp の drawio スキルと、awslabs/agent-plugins の aws-architecture-diagram スキルを元に変更したもの(Apache License 2.0)。元にした作品と変えたところは、配布元のリポジトリの NOTICE にある。

Files in this skill

  • SKILL.md23.1 KB
  • references/cli.md1.1 KB
  • references/edit.md1.4 KB
  • references/styles.md8 KB

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…