【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構成を自分で考える力につながります。