【AWS解説 基本編 #6】AWS構成図の読み方 4つの代表パターンで整理
基本編の最後として、AWS構成図の読み方を整理します。
前回までの記事はこちらです。
AWSの構成図を初めて見ると、多くのサービスアイコンや矢印が並んでいるため、どこから見ればよいのか分からなくなることがあります。
左から順番に読めばよいのか
すべてのサービスを覚える必要があるのか
枠線や矢印にはどのような意味があるのか
この記事では、代表的な4つの構成パターンを例に、AWS構成図をどのように眺め、読み取ればよいのかを整理します。
各サービスの細かな設定手順や、本番環境向けの詳細設計までは扱いません。
構成図は「役割と流れ」で読む
AWSの構成図は、サービスアイコンを一つずつ暗記するよりも、システム内での役割と、通信やデータの流れを追う方が理解しやすくなります。
最初は、次の順番で見るのがおすすめです。
- 誰がシステムを利用するのか
- 矢印はどちらへ向いているのか
- リージョン、VPC、AZ、サブネットなどの枠はどう分かれているのか
- リクエストやデータの入口はどこか
- プログラムや処理はどこで実行されるか
- データはどこへ保存されるか
- 監視、通知、権限、暗号化などを何が支えているか
矢印を見る
構成図の矢印は、通信、リクエスト、データなどが移動する方向を示します。
多くのWebアプリケーション構成図は左から右へ流れますが、すべての図が同じ方向で描かれているとは限りません。
最初に矢印の向きを確認し、利用者やデータの発生元から順番にたどることが基本です。
また、矢印が双方向になっている場合は、リクエストを送るだけではなく、応答や制御命令が戻ることを表している場合があります。
枠線を見る
AWS構成図の枠線は、単なるデザインではありません。
次のような配置範囲を表していることがあります。
- AWSアカウント
- AWSリージョン
- VPC
- アベイラビリティゾーン
- サブネット
たとえば、1つのVPCの中に複数のAZが描かれていれば、複数AZを使った構成であることが分かります。
サブネットは1つのAZ内に配置されるため、構成図では、どのリソースがどのAZやサブネットに置かれているのかを確認することも重要です。
※VPCを使用しないケースもあります。
サービスを役割で分ける
基本編 #2で説明したとおり、AWSでは複数のサービスを組み合わせてシステムを構築します。
構成図は、その組み合わせを1枚の図にしたものです。
最初は各サービスを、次のような役割に分けると読みやすくなります。
| 役割 | 主な例 |
|---|---|
| 名前解決・入口 | Route 53、CloudFront、ALB、API Gateway |
| 処理 | EC2、Lambda、コンテナ |
| 待ち行列・イベント連携 | Amazon SQS、Amazon EventBridge |
| 保存 | S3、RDS、DynamoDB |
| 監視・通知 | CloudWatch、SNS |
| セキュリティ | IAM、AWS WAF、KMS、セキュリティグループ |
サービス名をすべて覚えていなくても、
このサービスは入口なのか
処理する場所なのか
保存する場所なのか
と考えることで、構成全体をつかみやすくなります。
なお、構成図に描かれている内容は、多くの場合は構成例の一つです。
同じ目的のシステムでも、要件、予算、運用体制、必要な可用性などによって、使用するサービスや配置は変わります。
パターン1：EC2を使ったWebアプリケーション
最初は、VPCの中にサーバーとデータベースを配置するWebアプリケーション構成です。
代表的な流れは、次のようになります。
利用者
↓
Application Load Balancer
↓
Amazon EC2
↓
Amazon RDS
利用者から送信されたリクエストをApplication Load Balancerが受け取り、EC2インスタンスへ振り分けます。
EC2上で動作するアプリケーションが、必要に応じてRDSへアクセスし、データを読み書きします。
どこを見るか
この構成では、最初に次の3点を確認します。
- リクエストの入口はどこか
- アプリケーションはどこで動いているか
- データはどこに保存されるか
この例では、それぞれ次のようになります。
- 入口：Application Load Balancer
- 処理：Amazon EC2
- 保存：Amazon RDS
その後で、VPC、AZ、サブネットの分け方を確認します。
たとえば、インターネットからアクセスされるALBをパブリックサブネットに配置し、EC2やRDSをプライベートなサブネットへ配置する構成があります。
Internet Gatewayは、ALBのようにアプリケーションのリクエストを振り分けるサービスではありません。
VPCとインターネットの間で通信できるようにするためのVPC側の構成要素として、VPCの外周に接続する形で描かれることがあります。
マルチAZを見る
EC2やRDSが複数のAZにまたがって描かれている場合は、1つのAZで障害が発生した場合にも、別のAZで処理を継続しやすくする設計であることが読み取れます。
ここは、基本編 #3で説明したリージョン、AZ、マルチAZの考え方が構成図に現れやすい部分です。
向いている用途のイメージ
EC2を使ったWebアプリケーション構成は、次のような場合に検討されます。
- サーバー上でアプリケーションを継続的に動かしたい
- OSやミドルウェアを細かく管理したい
- 既存のWebアプリケーションをAWSへ移行したい
- 特定のソフトウェアや実行環境が必要
- サーバーベースの構成に関する運用知識がある
EC2を使った構成が古い、または間違っているということではありません。
システムの要件に応じて、EC2を使う構成と、後述するサーバーレス構成を使い分けます。
パターン2：サーバーレスWebアプリケーション
次は、利用者がサーバーのOSや台数を直接管理する代わりに、マネージドサービスを組み合わせるサーバーレス構成です。
代表的な構成では、画面の配信とAPI処理が分かれます。
利用者
├─ CloudFront → S3
│ 静的ファイルの配信
│
└─ API Gateway → Lambda → DynamoDB
API処理とデータ保存
AWS公式のサーバーレスWebアプリケーション例でも、CloudFront、API Gateway、Lambda、DynamoDBなどを組み合わせる構成が紹介されています。
画面配信とAPI処理を分けて見る
サーバーレスWebアプリケーションでは、1本の直線として見るのではなく、画面配信とAPI処理を分けて見ると理解しやすくなります。
画面配信
S3に保存したHTML、CSS、JavaScript、画像などの静的ファイルを、CloudFront経由で利用者へ配信します。
API処理
画面から送信されたAPIリクエストをAPI Gatewayが受け付け、Lambdaを呼び出します。
Lambdaで処理した結果をDynamoDBなどへ保存し、API Gatewayを通じて利用者へ応答します。
周辺サービスの役割
構成図には、次のようなサービスが加わることがあります。
- Route 53：ドメイン名をCloudFrontなどの接続先へ案内する
- AWS WAF：不正なWebリクエストを検査・遮断する
- Amazon Cognito：ユーザー登録やログイン認証を行う
- CloudWatch：ログやメトリクスを確認する
- IAM：各サービスが実行できる操作を制御する
構成図を見るときは、これらをすべてリクエストの直線上へ並べるのではなく、それぞれがどの部分を支えているかを確認します。
サーバーレスでも運用は残る
サーバーレス構成では、EC2のOSパッチ適用やサーバー台数の管理などを減らせます。
一方で、次のような管理は引き続き必要です。
- IAM権限
- APIの設計
- Lambdaのコード
- ログと監視
- エラー処理
- データの公開範囲
- 呼び出し回数や実行時間に応じた料金
- Lambdaのコールドスタートなどの特性
サーバー管理が減っても、システム運用そのものがゼロになるわけではありません。
これは、基本編 #4で説明した責任共有モデルともつながります。
学習や個人開発での利用
サーバーレス構成は、小規模なWebアプリケーションや、学習・個人開発で小さく始める場合にも利用されます。
パターン3：データ分析基盤
データ分析基盤では、Webアプリケーションのように利用者のリクエストを追うのではなく、データがどこから発生し、どのように移動するかを追います。
代表的な流れは、次のようになります。
データ発生元
↓
Amazon Data Firehose
↓
Amazon S3
↓
AWS Glue
↓
Amazon Athena
↓
Amazon Quick Sight
Amazon Data Firehoseは、以前はAmazon Kinesis Data Firehoseという名称でした。現在は、ストリーミングデータをS3などの保存先へ配信するマネージドサービスとして提供されています。
Amazon Quick Sightは、Amazon Quickに含まれるBI・データ可視化機能です。
「データの旅」を追う
データ分析基盤では、次の順番で見ると分かりやすくなります。
- データはどこで発生するか
- どのサービスがデータを取り込むか
- データをどこに保存するか
- どこで整理・加工するか
- どのサービスで問い合わせるか
- 誰がどのように結果を見るか
この例では、各サービスの主な役割は次のとおりです。
| 役割 | サービス例 |
|---|---|
| 取り込み | Amazon Data Firehose |
| 保存 | Amazon S3 |
| 整理・加工・データカタログ | AWS Glue |
| SQLによる問い合わせ | Amazon Athena |
| 可視化 | Amazon Quick Sight |
横断的なサービスを見る
AWS KMSは、データ処理の途中にあるサービスというより、保存データの暗号化などを支える横断的な要素です。
IAMも同様に、誰がS3のデータを読み取れるか、Athenaで問い合わせできるかなどを制御します。
構成図では、KMSやIAMが矢印の直線上ではなく、複数のサービスと接続する形で描かれることがあります。
向いている用途のイメージ
データ分析基盤は、次のような用途で利用されます。
- アプリケーションログの集計
- Webアクセスログの分析
- 業務データの集計
- センサーデータの保存
- 可視化ダッシュボードの作成
- 大量データの調査や分析
パターン4：イベント駆動（非同期処理）
イベント駆動の構成では、リクエストを受け付けたあと、すぐにすべての処理を終わらせるのではなく、いったん待ち行列やイベントバスへ渡し、後続の処理を別途進めます。
代表的な流れは、次のようになります。
利用者 / アプリケーション
↓
Amazon API Gateway
↓ 受け付けて応答を返す
Amazon SQS
↓ 後から取り出す
AWS Lambda
├─ Amazon DynamoDB
└─ Amazon SNS
この構成では、API Gatewayがリクエストを受け付け、処理対象をSQSへ送ります。
利用者側には「受け付けた」という応答を先に返し、時間のかかる処理はLambdaがキューから取り出して実行します。
処理結果の保存はDynamoDB、完了や異常の知らせはSNS、といった役割分担がよく見られます。
同期の流れと非同期の流れを分けて見る
Webアプリケーションの構成図では、利用者のリクエストに対して、入口から処理、保存までを一続きに追うことが多くあります。
一方、イベント駆動では、次の2つの流れを分けて見ると理解しやすくなります。
- 受付の流れ：リクエストを受け取り、キューやイベントバスへ渡す
- 後続処理の流れ：キューから取り出して加工し、保存や通知を行う
構成図を見るときは、次の点を確認します。
- 何がイベントやメッセージの発生元か
- どこで受け付けているか
- どこで一時的に溜めているか（SQS、EventBridgeなど）
- どのサービスが後から処理するか
- 処理結果はどこへ保存するか
- 完了や失敗を誰へ通知するか
- 矢印は「すぐ応答する同期」か、「後で処理する非同期」か
SQSとLambdaの役割
Amazon SQSは、処理待ちのメッセージを一時的に保持する待ち行列です。
すぐに処理しきれない作業や、失敗しても後から再試行したい作業を置く場所として使われます。
AWS Lambdaは、キューに溜まったメッセージを取り出して処理します。
たとえば、次のような役割分担になります。
- API Gateway：リクエストの入口となり、受け付けを返す
- SQS：処理対象を一時保管し、後続へ渡す
- Lambda：本処理を実行する
- DynamoDB：処理結果や状態を保存する
- SNS：完了や異常を通知する
構成図によっては、SQSの代わりにAmazon EventBridgeが描かれることもあります。
EventBridgeは、複数のサービスやアプリケーションへイベントを振り分ける役割を持つことが多く、SQSとは使い方が異なります。最初は「同期で終わらせず、いったんイベントとして渡す」という共通点だけ押さえておけば十分です。
失敗時の見え方も確認する
イベント駆動の構成図では、通常の成功経路だけでなく、失敗時の経路が描かれることもあります。
- Dead Letter Queue（DLQ）：何度か失敗したメッセージを退避する
- CloudWatch：処理回数、エラー、待ち時間などを監視する
- IAM：どのサービスがキューを読み書きできるかを制御する
矢印が増えて見える場合でも、まずは「受付 → 待ち行列 → 本処理 → 保存/通知」の主経路を追ってから、失敗時や監視の線を見ると整理しやすくなります。
向いている用途のイメージ
イベント駆動構成は、次のような用途で利用されます。
- 画像やファイルの変換・取り込み
- 注文や申込みの受付後処理
- メールやチャットへの通知送信
- ほかのシステムへの非同期連携
- ピーク時に処理が集中しやすいバッチ的な作業
- すぐ応答しつつ、重い処理は後回しにしたいAPI
4つのパターンを比較する
4つの構成では、中心になるサービスだけでなく、図を読むときに追う対象も異なります。
| パターン | 中心になりやすい要素 | 読むときの手がかり |
|---|---|---|
| EC2を使ったWebアプリ | VPC、ALB、EC2、RDS | 利用者から入口、アプリ、DBへ追う |
| サーバーレスWebアプリ | CloudFront、S3、API Gateway、Lambda、DynamoDB | 画面配信とAPI処理の分岐を見る |
| データ分析基盤 | Data Firehose、S3、Glue、Athena、Quick Sight | データの発生、保存、加工、可視化を追う |
| イベント駆動 | API Gateway、SQS、Lambda、DynamoDB、SNS | 受付と後続処理を分け、非同期の矢印を追う |
どれか1つが常に正解というわけではありません。
同じWebアプリケーションでも、EC2を使う構成とサーバーレス構成では、次のような違いがあります。
- 運用する対象
- 責任を持つ範囲
- 性能の調整方法
- 障害対策
- 料金の発生方法
- 必要となる技術や知識
基本編 #5で説明したWell-Architectedフレームワークの6つの柱を使うと、それぞれの構成について、セキュリティ、信頼性、パフォーマンス、コストなどの観点から比較できます。
構成図を見るときの確認項目
新しいAWS構成図を見るときは、次の項目を順番に確認すると、全体像をつかみやすくなります。
利用者・データ発生元
- 誰がシステムを使うのか
- 人からのアクセスか、システム間通信か
- 外部サービスや別処理からのイベントか
矢印
- 通信やデータはどちらへ流れるか
- 一方向か、双方向か
- 同期処理か、非同期処理か
- 途中で分岐しているか
- 待ち行列やイベントバスを経由しているか
枠線
- どこまでがAWSクラウドか
- どのリージョンにあるか
- VPCの中か外か
- どのAZやサブネットにあるか
- 複数AZへ分散されているか
入口
- DNSはどこで解決されるか
- Webリクエストはどこで受け付けるか
- APIの入口はどこか
- イベントやメッセージはどこで受け取るか
処理
- プログラムはどこで動くか
- EC2、Lambda、コンテナのどれを使うか
- 複数の処理へ分岐するか
- 受付と本処理が分かれているか
保存
- データはどこへ保存されるか
- リレーショナルデータベースか
- NoSQLデータベースか
- オブジェクトストレージか
- 最新状態の保存か、長期保存か
- 処理待ちのメッセージをどこへ溜めているか
全体を支える要素
- 監視やログはどこにあるか
- 障害時にどのように通知するか
- IAM権限はどこで使われるか
- 暗号化には何を使うか
- 外部からの攻撃をどのように防ぐか
つまずきやすいポイント
アイコンを全部理解してから読もうとする
AWS構成図は地図のようなものです。
地図に描かれた道路をすべて暗記しなくても、出発点、目的地、主要な経路が分かれば、全体を理解できます。
AWS構成図でも、最初は次の4点を探せば十分です。
- 利用者
- 入口
- 処理
- 保存
その後で、分からないサービスを個別に調べます。
矢印を見ずにアイコンだけを見る
同じサービスが描かれていても、どのサービスと接続しているかによって役割が変わります。
アイコンの名前だけではなく、矢印がどこから来て、どこへ向かっているかを確認します。
枠線の意味を見落とす
リージョン、VPC、AZ、サブネットなどの枠線は、リソースの配置範囲を示します。
同じEC2やRDSでも、どのAZやサブネットに配置されているかによって、ネットワーク接続や可用性の意味が変わります。
図の構成をそのまま本番環境の正解だと思う
教材やブログに掲載される構成図は、説明のために一部が省略されていることがあります。
実際の本番環境では、次のような条件によって構成が変わります。
- 利用者数
- 扱うデータ
- 必要な可用性
- セキュリティ要件
- 予算
- 運用体制
- 復旧に許容できる時間
構成例は、完成した正解をコピーするためではなく、設計を考えるための参考として見ます。
サーバーレスなら運用がなくなると思う
サーバーレスでは、サーバーのOSや台数を直接管理する作業を減らせます。
しかし、次のような作業は残ります。
- 権限設定
- API設計
- アプリケーションコードの管理
- ログと監視
- 障害対応
- セキュリティ対策
- コスト管理
サーバー管理が減ることと、運用がなくなることは同じではありません。
まとめ
AWS構成図は、サービス名を並べただけの図ではありません。
利用者やデータの発生元から、入口、処理、保存へと続く流れと、それらを支える監視・通知・権限・暗号化などの要素を表しています。
構成図を見るときは、次の順番で確認すると理解しやすくなります。
- 利用者やデータ発生元を探す
- 矢印の方向を確認する
- リージョン、VPC、AZ、サブネットの枠を見る
- 入口となるサービスを探す
- 処理する場所を探す
- データの保存先を探す
- 監視、通知、権限などの周辺要素を見る
この記事では、次の4つのパターンを紹介しました。
- EC2を使ったWebアプリケーション
- サーバーレスWebアプリケーション
- データ分析基盤
- イベント駆動（非同期処理）
それぞれ中心になるサービスは異なりますが、役割と流れを追うという基本的な読み方は共通しています。
最初からすべてのAWSサービスを覚える必要はありません。
まずは、
このサービスは入口・処理・保存のどれに当たるのか
矢印はどこからどこへ向かっているのか
どのリージョン・VPC・AZ・サブネットに置かれているのか
を確認できれば、構成図の全体像をつかみやすくなります。
これで、AWS解説 基本編の全6回は終了です。
次の学習では、興味のあるAWSサービスを1つ選び、実際にAWSマネジメントコンソールで小さな構成を作ってみると理解が深まります。
また、構成図に登場したサービスについて、
- 何をするサービスなのか
- どのサービスと接続するのか
- 利用者側で何を設定するのか
- どのような料金が発生するのか
を1つずつ調べていくと、AWS構成を自分で考える力につながります。