📘
AWS公式MCPを使って勉強(設計)するぞ
AWS の更新情報をそれなりには追っているつもりでも、今必要なかったり関心がなかったりといったサービスについては全然わからないところです。自分だとアプリ領域ではないエンタープライズ向けサービスはどうにも「AWS 認定試験で出てくるやつ」くらいの認識だったりします。
仕事上学ぶ必要ができたので、7 月に公開された AWS Knowledge MCP Server などを使って勉強してみます。
概要
AWS Knoledge MCP Server は AWS が公開した AWS のナレッジを取得できる MCP サーバで、現在はベータ版です。既に AWS Documentation MCP Server というものがあるのですが、
公式ドキュメントだけでなくブログ記事、新着情報、Well-Architected のベストプラクティスなど
も検索してくれるとのこと。読み込んでいるソースは こちら に記載されています。
なお、リモート MCP ということもあり、レートリミットがあると触れられています。
The Knowledge MCP server does not require authentication but is subject to rate limits.
ツール
2025/08/01 時点で以下のツールがあります。
- search_documentation: Search across all AWS documentation
- read_documentation: Retrieve and convert AWS documentation pages to markdown
- recommend: Get content recommendations for AWS documentation pages
Ref: https://github.com/awslabs/mcp/tree/main/src/aws-knowledge-mcp-server#tools
設定方法
Streamable HTTP として提供されているため、クライアントが対応していれば以下のように指定するだけ。自分は Claude Code を普段使っているので、このままで問題なく使えました。
{
"mcpServers": {
"aws-knowledge-mcp-server": {
"url": "https://knowledge-mcp.global.api.aws"
}
}
}
非対応の場合は、mcp-remote(node) や mcp-proxy(python) などを使う必要があります。詳しくは公式のドキュメントを参照のこと。
Ref: https://github.com/awslabs/mcp/tree/main/src/aws-knowledge-mcp-server#prerequisites
やってみた
組織レベルのネットワーク設計が全然わからんので、
「TransitGateway を使ったハブ＆スポーク型ネットワークをベストプラクティスに沿って設計して」
と MCP の設定をした Claude Code 君に聞いてみます。
⏺ AWS Transit Gatewayを使用したハブ＆スポーク型ネットワークのベストプラクティスに沿った構成を設計します。
⏺ Update Todos
⎿ ☐ AWS Transit Gatewayのベストプラクティスを調査
☐ ハブ＆スポーク型ネットワークアーキテクチャの設計
☐ アーキテクチャ図の作成
☐ 設計ドキュメントの作成
⏺ aws-knowledge - aws___search_documentation (MCP)(search_phrase: "AWS Transit Gateway hub and spoke network architecture
best practices", limit: 10)
⎿ {
"response": {
"payload": {
… +104 lines (ctrl+r to expand)
⏺ aws-knowledge - aws___read_documentation (MCP)(url: "https://docs.aws.amazon.com/wellarchitected/2025-02-25/framework/re
l_planning_network_topology_prefer_hub_and_spoke.html")
⎿ {
"response": {
"payload": {
… +74 lines (ctrl+r to expand)
⏺ aws-knowledge - aws___read_documentation (MCP)(url: "https://docs.aws.amazon.com/vpc/latest/tgw/tgw-best-design-practice
s.html")
⎿ {
"response": {
"payload": {
… +31 lines (ctrl+r to expand)
⏺ Update Todos
⎿ ☒ AWS Transit Gatewayのベストプラクティスを調査
☐ ハブ＆スポーク型ネットワークアーキテクチャの設計
☐ アーキテクチャ図の作成
☐ 設計ドキュメントの作成
ベストプラクティスを調べたらしい。
⏺ Update Todos
⎿ ☒ AWS Transit Gateway のベストプラクティスを調査
☒ ハブ＆スポーク型ネットワークアーキテクチャの設計
☐ アーキテクチャ図の作成
☐ 設計ドキュメントの作成
設計が終わると、AWS Diagram MCP Server も設定していたため、ネットワーク図を書き始めました。
⏺ aws-diagram - get_diagram_examples (MCP)(diagram_type: "aws")
⎿ {
"examples": {
"aws_basic": "with Diagram(\"Web Service Architecture\", show=False):\n ELB(\"lb\") >> EC2(\"web\") >> RDS(\"us
… +24 lines (ctrl+r to expand)
⏺ aws-diagram - list_icons (MCP)(provider_filter: "aws", service_filter: "network")
⎿ {
"providers": {
"aws": {
… +59 lines (ctrl+r to expand)
⏺ aws-diagram - list_icons (MCP)(provider_filter: "aws", service_filter: "compute")
⎿ {
"providers": {
"aws": {
… +57 lines (ctrl+r to expand)
⏺ aws-diagram - list_icons (MCP)(provider_filter: "aws", service_filter: "general")
⎿ {
"providers": {
"aws": {
… +34 lines (ctrl+r to expand)
⏺ aws-diagram - list_icons (MCP)(provider_filter: "aws", service_filter: "security")
⎿ {
"providers": {
"aws": {
… +60 lines (ctrl+r to expand)
⏺ aws-diagram - generate_diagram (MCP)(code: "with Diagram(\"AWS Transit Gateway Hub & Spoke Architecture\", show=False,
direction=\"TB\"):\n # On-premises\n onprem =
TraditionalServer(\"On-premises\\nData Center\")\n cgw =
VPCCustomerGateway(\"Customer\\nGateway\")\n \n # Transit Gateway\n tgw =
TransitGateway(\"Transit Gateway\\n(Hub)\")\n \n # Network Services VPC
(Shared Services)\n with Cluster(\"Network Services VPC\\n10.0.0.0/16\"):\n
fw = GenericFirewall(\"Network\\nFirewall\")\n nat = NATGateway(\"NAT
Gateway\")\n with Cluster(\"Public Subnet\\n10.0.1.0/24\"):\n igw
= InternetGateway(\"Internet\\nGateway\")\n \n # Production VPC\n with
Cluster(\"Production VPC\\n10.1.0.0/16\"):\n with Cluster(\"Private Subnet
A\\n10.1.10.0/24\"):\n prod_app = [EC2(\"App Server 1\"),\n
EC2(\"App Server 2\")]\n with Cluster(\"Private Subnet
B\\n10.1.20.0/24\"):\n prod_db = RDS(\"Production\\nDatabase\")\n
prod_rt = RouteTable(\"Route Table\")\n \n # Development VPC\n with
Cluster(\"Development VPC\\n10.2.0.0/16\"):\n with Cluster(\"Private
Subnet\\n10.2.10.0/24\"):\n dev_app = EC2(\"Dev Server\")\n
dev_db = RDS(\"Dev Database\")\n dev_rt = RouteTable(\"Route Table\")\n \n
# Test VPC\n with Cluster(\"Test VPC\\n10.3.0.0/16\"):\n with
Cluster(\"Private Subnet\\n10.3.10.0/24\"):\n test_app = EC2(\"Test
Server\")\n test_db = RDS(\"Test Database\")\n test_rt =
RouteTable(\"Route Table\")\n \n # Security/Monitoring VPC\n with
Cluster(\"Security VPC\\n10.4.0.0/16\"):\n with Cluster(\"Private
Subnet\\n10.4.10.0/24\"):\n security = [Inspector(\"Inspector\"),\n
Guardduty(\"GuardDuty\"),\n
SecurityHub(\"Security Hub\")]\n \n # Internet\n internet =
InternetAlt2(\"Internet\")\n \n # Connections\n onprem >> cgw >>
Edge(label=\"Site-to-Site VPN\", style=\"dashed\") >> tgw\n \n # Transit
Gateway Attachments\n tgw >> Edge(label=\"TGW Attachment\", color=\"darkgreen\")
>> fw\n tgw >> Edge(label=\"TGW Attachment\", color=\"darkgreen\") >> prod_rt\n
tgw >> Edge(label=\"TGW Attachment\", color=\"darkgreen\") >> dev_rt\n tgw >>
Edge(label=\"TGW Attachment\", color=\"darkgreen\") >> test_rt\n tgw >>
Edge(label=\"TGW Attachment\", color=\"darkgreen\") >> security\n \n #
Internet connectivity through Network Services VPC\n fw >> nat >> igw >>
internet\n \n # Internal routing\n prod_rt >> prod_app >> prod_db\n
dev_rt >> dev_app\n dev_app >> dev_db\n test_rt >> test_app\n test_app >>
test_db", filename: "transit-gateway-hub-spoke.png", workspace_dir:
"/Users/hsakakibara/programs/awsailab")
⎿ {
"status": "success",
"path": "/Users/hsakakibara/programs/awsailab/generated-diagrams/transit-gateway-hub-spoke.png.png",
… +3 lines (ctrl+r to expand)
⏺ Update Todos
⎿ ☒ AWS Transit Gatewayのベストプラクティスを調査
☒ ハブ＆スポーク型ネットワークアーキテクチャの設計
☒ アーキテクチャ図の作成
☐ 設計ドキュメントの作成
そして最後に設計ドキュメントとしてまとめます。
⏺ Write(transit-gateway-design.md)
⎿ Wrote 151 lines to transit-gateway-design.md
# AWS Transit Gateway ハブ＆スポーク型ネットワーク設計
## 概要
AWS Transit Gatewayを使用したハブ＆スポーク型ネットワークアーキテクチャの設計です。この設計はAWS
Well-Architectedフレームワークのベストプラクティスに準拠しています。
## アーキテクチャ図
## 設計の特徴
… +141 lines (ctrl+r to expand)
⏺ Update Todos
⎿ ☒ AWS Transit Gatewayのベストプラクティスを調査
☒ ハブ＆スポーク型ネットワークアーキテクチャの設計
☒ アーキテクチャ図の作成
☒ 設計ドキュメントの作成
生成された設計ドキュメントとアーキテクチャ図は 末尾に付記。以下にピックアップしますと、
## 概要
AWS Transit Gateway、Direct Connect、および Inspection VPC を使用したエンタープライズグレードのハブ＆スポーク型ネットワークアーキテクチャの設計です。この設計は AWS Well-Architected フレームワークのベストプラクティスに準拠し、すべてのトラフィックを Network Firewall で検査する高セキュリティ構成を採用しています。
ネットワーク図。
設計上のポイント。
## 設計の特徴
### 1. ネットワーク構成
- **Transit Gateway（ハブ）**: すべての VPC とオンプレミス接続の中央ハブ
- **Inspection VPC**: すべてのトラフィックを検査する Network Firewall を集約配置
- **Egress VPC**: インターネット向けトラフィックの出口を集約
- **ワークロード別 VPC**: Production、Development、Test 環境を分離
- **Security VPC**: セキュリティ監視ツールを集約
### 2. IP アドレス設計
Inspection VPC: 10.0.0.0/16
Egress VPC: 10.10.0.0/16
Production VPC: 10.1.0.0/16
Development VPC: 10.2.0.0/16
Test VPC: 10.3.0.0/16
Security VPC: 10.4.0.0/16
ベストプラクティスについて。
## ベストプラクティスの実装
### 1. Transit Gateway 設計
- **専用サブネット**: 各 VPC に Transit Gateway 接続用の小さなサブネット（/28）を作成
- **ルートテーブル管理**: 必要な通信のみを許可するルート設計
- **高可用性**: Transit Gateway は設計上高可用性を提供
実装手順。
## 実装手順
### 1. 準備
- [ ] ネットワーク設計の確認（CIDR 範囲の重複がないことを確認）
- [ ] Network Services アカウントの作成（存在しない場合）
### 2. Transit Gateway の作成
# Transit Gateway の作成
aws ec2 create-transit-gateway \
--description "Central Hub Transit Gateway" \
--options=AmazonSideAsn=64512,DefaultRouteTableAssociation=disable,DefaultRouteTablePropagation=disable
運用上の考慮点。
## 運用上の考慮事項
### 1. スケーラビリティ
- Transit Gateway は最大 5,000 個の VPC 接続をサポート
- 帯域幅は最大 50 Gbps（バースト時 100 Gbps）
### 2. コスト最適化
- アタッチメントごとに時間単位で課金
- データ処理料金（GB 単位）
- 不要なアタッチメントは削除
勉強中なのでちゃんとした精度はわかりません。嘘をついている危惧は持ちつつも、しかし今回の記事のテーマとしているように少なくともこの情報をもとにしてベストプラクティスのポイントを理解しようとしたり、実際に試してみることはできそうです。
AWS 公式の Workshop もむろん良いのですが、もっと具体的に必要そうな要件をリストアップしつつ、セルフカスタマイズの Workshop みたいなものを作ってみるのは良さそうです。また、AWS Diagram MCP Server を併用することで、文章だけだと直感的にわかりづらい部分もわかりやすくなっていると思います。
AWS Diagram MCP Server についてはこちら。
まとめ
明らかにレートリミットとは別に接続が不安定な時がありそう？でしたが、まあいまはベータ版ですし、みな試しているのでしょう。正式リリースが楽しみです。
参考
生成結果
AWS Transit Gateway ハブ＆スポーク型ネットワーク設計
概要
AWS Transit Gateway、Direct Connect、および Inspection VPC を使用したエンタープライズグレードのハブ＆スポーク型ネットワークアーキテクチャの設計です。この設計は AWS Well-Architected フレームワークのベストプラクティスに準拠し、すべてのトラフィックを Network Firewall で検査する高セキュリティ構成を採用しています。
アーキテクチャ図
設計の特徴
1. ネットワーク構成
- Transit Gateway（ハブ）: すべての VPC とオンプレミス接続の中央ハブ
- Inspection VPC: すべてのトラフィックを検査する Network Firewall を集約配置
- Egress VPC: インターネット向けトラフィックの出口を集約
- ワークロード別 VPC: Production、Development、Test 環境を分離
- Security VPC: セキュリティ監視ツールを集約
2. IP アドレス設計
Inspection VPC: 10.0.0.0/16
Egress VPC: 10.10.0.0/16
Production VPC: 10.1.0.0/16
Development VPC: 10.2.0.0/16
Test VPC: 10.3.0.0/16
Security VPC: 10.4.0.0/16
3. セキュリティ設計
- 全トラフィック検査: Inspection VPC の Network Firewall ですべての通信を検査
- ネットワークセグメンテーション: 環境ごとに VPC を分離
- マルチ AZ 冗長性: Network Firewall エンドポイントを AZ 毎に配置
- 監視とコンプライアンス: Security VPC で集中監視
ベストプラクティスの実装
1. Transit Gateway 設計
- 専用サブネット: 各 VPC に Transit Gateway 接続用の小さなサブネット（/28）を作成
- ルートテーブル管理: 必要な通信のみを許可するルート設計
- 高可用性: Transit Gateway は設計上高可用性を提供
2. ネットワーク ACL
- Transit Gateway サブネット用に 1 つのネットワーク ACL を作成
- インバウンド/アウトバウンド両方向でオープンに設定
- ワークロードサブネットで適切な ACL を適用
3. ルーティング設計
- ルート伝播: Direct Connect ゲートウェイと BGP Site-to-Site VPN 接続で有効化
- 分離ポリシー: 相互依存のないワークロード間のルートは省略
- 集中管理: Network Services アカウントでハブを管理
4. 接続性
- オンプレミス接続: Site-to-Site VPN（本番環境では Direct Connect を推奨）
- インターネット接続: Network Services VPC 経由で集中管理
- VPC 間通信: Transit Gateway 経由で必要な通信のみを許可
実装手順
1. 準備
- ネットワーク設計の確認（CIDR 範囲の重複がないことを確認）
- Network Services アカウントの作成（存在しない場合）
2. Transit Gateway の作成
# Transit Gatewayの作成
aws ec2 create-transit-gateway \
--description "Central Hub Transit Gateway" \
--options=AmazonSideAsn=64512,DefaultRouteTableAssociation=disable,DefaultRouteTablePropagation=disable
3. VPC の作成と接続
# 各VPCでTransit Gateway接続用サブネットを作成
aws ec2 create-subnet \
--vpc-id vpc-xxxxx \
--cidr-block 10.x.255.0/28 \
--tag-specifications 'ResourceType=subnet,Tags=[{Key=Name,Value=TGW-Subnet}]'
# Transit Gateway Attachmentの作成
aws ec2 create-transit-gateway-vpc-attachment \
--transit-gateway-id tgw-xxxxx \
--vpc-id vpc-xxxxx \
--subnet-ids subnet-xxxxx
4. ルートテーブルの設定
# Transit Gatewayルートテーブルの作成
aws ec2 create-transit-gateway-route-table \
--transit-gateway-id tgw-xxxxx \
--tag-specifications 'ResourceType=transit-gateway-route-table,Tags=[{Key=Name,Value=Main-Route-Table}]'
# ルートの追加
aws ec2 create-transit-gateway-route \
--destination-cidr-block 10.1.0.0/16 \
--transit-gateway-route-table-id tgw-rtb-xxxxx \
--transit-gateway-attachment-id tgw-attach-xxxxx
5. セキュリティグループの設定
- Transit Gateway ENI 用のセキュリティグループを作成
- 必要なトラフィックのみを許可
6. 監視の設定
# CloudWatchメトリクスの有効化
aws ec2 modify-transit-gateway \
--transit-gateway-id tgw-xxxxx \
--options AmazonSideAsn=64512,EnableDnsSupport=enable,EnableMulticast=disable
# VPC Flow Logsの有効化
aws ec2 create-flow-logs \
--resource-type VPC \
--resource-ids vpc-xxxxx \
--traffic-type ALL \
--log-destination-type cloud-watch-logs
運用上の考慮事項
1. スケーラビリティ
- Transit Gateway は最大 5,000 個の VPC 接続をサポート
- 帯域幅は最大 50 Gbps（バースト時 100 Gbps）
2. コスト最適化
- アタッチメントごとに時間単位で課金
- データ処理料金（GB 単位）
- 不要なアタッチメントは削除
3. 災害復旧
- 各リージョンに 1 つの Transit Gateway を配置
- リージョン間ピアリングで冗長性を確保
4. トラブルシューティング
- Transit Gateway Network Manager で可視化
- VPC Reachability Analyzer で接続性を検証
- CloudWatch Logs でトラフィックを分析
セキュリティのベストプラクティス
1. 最小権限の原則
- IAM ポリシーで必要最小限の権限のみを付与
- ネットワークレベルでもトラフィックを制限
2. 暗号化
- VPN 接続は IPsec で暗号化
- Direct Connect は専用線（必要に応じて VPN over Direct Connect）
3. 監査とコンプライアンス
- AWS CloudTrail ですべての変更を記録
- AWS Config で設定の準拠性を監視
- Security Hub で統合的なセキュリティ監視
まとめ
この設計により、スケーラブルで安全なハブ＆スポーク型ネットワークを実現できます。Transit Gateway を中心としたアーキテクチャにより、ネットワーク管理の簡素化と運用効率の向上が期待できます。
Discussion