はじめに
CloudFormationのスタックが CREATE_COMPLETE になっても、システムの確認が終わったわけではありません。
- ALBからアプリケーションへ通信できるか
- インターネットからRDSへ意図しない経路がないか
- S3バケットやIAMロールを外部から利用できないか
- テンプレートと実際の設定がずれていないか
- APIが実際に応答し、ログやアラームも機能するか
AWSにはこれらを確認できるサービスがありますが、それぞれ答えられる質問が違います。
この記事では、AWS構築後の確認を 設定分析、実動作、継続監視、障害試験 の4段階に分けて整理します。
先に結論
AWS構築後は、1つのサービスで「問題なし」と判定せず、次のように使い分けます。
| 確認したいこと | 最初に使うサービス |
|---|---|
| 2つのリソース間が通信可能な設定か | VPC Reachability Analyzer |
| 要件に反する意図しないネットワーク経路がないか | VPC Network Access Analyzer |
| 外部共有や未使用のIAM権限がないか | IAM Access Analyzer |
| CloudFormation管理外の設定変更がないか | CloudFormationドリフト検出 |
| リソースがルールに準拠しているか | AWS Config、AWS Security Hub CSPM |
| OS・プロセス・ヘルスチェックが実際に動くか | Systems Manager Run Command、CloudWatch Synthetics |
| API操作、ログ、メトリクス、通知の証跡が残るか | CloudTrail、CloudWatch |
| 脆弱性や意図しないネットワーク露出がないか | Amazon Inspector |
| 障害時に回復目標を満たせるか | AWS Resilience Hub、AWS Fault Injection Service |
Reachability AnalyzerとNetwork Access Analyzerは、AWSのリソース設定を分析するツールです。実際のパケット送信やアプリケーションの応答確認は別に必要です。
想定する構成
以下のようなWebシステムを構築したと想定します。
この構成では、少なくとも次の確認が必要です。
- InternetからALBの443番ポートに到達できる
- ALBからアプリケーションの待受ポートに到達できる
- アプリケーションからRDSの待受ポートに到達できる
- Internetやアプリケーション以外からRDSへの不要な経路がない
- S3バケットポリシーとIAMロールが最小権限に近い
- 実際にHTTPSリクエストを送ると、正常応答とログを確認できる
構築後の確認は4段階に分ける
判断の軸は次の4段階です。
| 段階 | 見るもの | 代表サービス |
|---|---|---|
| 設定分析 | 現在のAWS設定が意図した経路・権限・ルールか | Reachability Analyzer、Network Access Analyzer、IAM Access Analyzer、AWS Config |
| 実動作 | 実際にプロセスやAPIが動くか | Systems Manager Run Command、CloudWatch Synthetics |
| 継続監視 | 構築後も異常、脆弱性、設定変更を発見できるか | CloudWatch、CloudTrail、Security Hub CSPM、Amazon Inspector |
| 障害・回復 | 一部障害が発生しても回復目標を満たせるか | AWS Resilience Hub、AWS FIS |
Reachability AnalyzerとNetwork Access Analyzerの違い
2つの名前は似ていますが、質問の大きさが違います。
Reachability Analyzerは1本の通信経路を確かめる
VPC Reachability Analyzerは、送信元と送信先を指定し、AWSのリソース設定上で到達可能かを分析します。到達可能な場合はホップごとのパスを表示し、到達できない場合はセキュリティグループやルートなどの遮断要因を示します。
例えば、次のような確認に向いています。
- ALBのENIからEC2のENIへTCP 8080で到達できるか
- EC2のENIからRDSのENIへTCP 5432で到達できるか
- 到達できない場合、どの設定で止まっているか
AWS公式: What is Reachability Analyzer?
AWS CLIでは、パスを作成してから分析を開始します。
# 送信元ENIから送信先ENIへ、TCP 5432のパスを作成する。
aws ec2 create-network-insights-path \
--source eni-0123456789abcdef0 \
--destination eni-0abcdef1234567890 \
--protocol tcp \
--destination-port 5432
# 作成時に返ったNetworkInsightsPathIdを指定して分析する。
aws ec2 start-network-insights-analysis \
--network-insights-path-id nip-0123456789abcdef0
ENIはElastic Network Interfaceの略で、EC2やRDSなどがVPC内で通信するための仮想ネットワークインターフェースです。リソース種類によって指定できる送信元・送信先が異なるため、実行前にAWS公式の対応リソースを確認します。
Network Access Analyzerはネットワーク要件への違反を探す
VPC Network Access Analyzerは、「Internetからデータベースへ到達できる経路は許可しない」などの要件を Network Access Scope として定義し、要件に合わない可能性のあるパスをFindingとして検出します。
| ツール | 質問の例 |
|---|---|
| Reachability Analyzer | このEC2からこのRDSへ到達できるか |
| Network Access Analyzer | すべてのRDSに、許可していない送信元から到達できる経路がないか |
コンソールでは、VPCのNetwork Access Analyzerからスコープを作成し、分析実行後にFindingを確認します。最初はAWSが用意するスコープを参考にし、自社の許可要件に合わせて絞り込むと理解しやすくなります。
AWS公式: What is Network Access Analyzer?
Findingは「ただちに脆弱性がある」という意味ではありません。定義したスコープに合うパスなので、期待する要件と照合して判断します。
IAM Access Analyzerで外部共有と過剰権限を確認する
IAM Access Analyzerは、主に次の4つの用途で使えます。
| 機能 | 確認できること |
|---|---|
| External access analyzer | 信頼の境界として指定したAWSアカウントまたはOrganizationの外部へ共有されるリソース |
| Unused access analyzer | 使われていないIAMロール、アクセスキー、パスワード、サービスやアクションの権限 |
| Policy validation | IAMポリシーの文法、セキュリティ上の警告、改善提案 |
| Policy generation | CloudTrailに記録されたアクセス活動からポリシー候補を生成 |
AWS公式: Using AWS Identity and Access Management Access Analyzer
構築直後は、次の順で見ると整理しやすくなります。
- External access analyzerを作成する
- S3、KMS、SQS、Lambda、IAMロールの信頼ポリシーなどのFindingを確認する
- 意図した共有であれば理由と対象を記録する
- 新しいIAMポリシーはPolicy validationに通す
- 運用データが蓄積した後、Unused access analyzerやPolicy generationで絞り込む
ポリシー検証はAWS CLIからも実行できます。
# identity-policy.jsonをIDベースポリシーとして検証する。
aws accessanalyzer validate-policy \
--policy-document file://identity-policy.json \
--policy-type IDENTITY_POLICY
Findingが0件でも、アプリケーションに必要な権限が足りていることは証明できません。正常系と拒否されるべき異常系の両方を実行します。
IaCと実環境のずれを確認する
CloudFormationドリフト検出
ドリフトとは、CloudFormationテンプレートの期待値と実際のリソース設定のずれです。マネジメントコンソールで直接変更されたセキュリティグループなどを発見する手がかりになります。
# スタック全体のドリフト検出を開始する。
aws cloudformation detect-stack-drift \
--stack-name sample-production-stack
# 返されたIDで検出ステータスと結果を確認する。
aws cloudformation describe-stack-drift-detection-status \
--stack-drift-detection-id 00000000-0000-0000-0000-000000000000
CloudFormationは、テンプレートまたはパラメーターで 明示的に設定したプロパティ を中心にドリフト判定します。サービスのデフォルト値まで比較したい場合は、テンプレートに値を明示します。リソース種類によってドリフト検出の対応状況も異なります。
AWS公式: Detect unmanaged configuration changes with drift detection
AWS Config
AWS Configは、AWSリソースの構成、リソース同士の関係、過去の変更を記録し、Config Rulesで準拠状況を評価できます。
例えば、次のような確認に適しています。
- S3パブリックアクセスブロックが有効か
- EBSボリュームが暗号化されているか
- CloudTrailが有効か
- セキュリティグループの禁止ポートが公開されていないか
# Config Ruleごとの準拠状況を一覧表示する。
aws configservice describe-compliance-by-config-rule
AWS ConfigはアプリケーションへHTTPリクエストを送るテストツールではありません。「設定がルールに準拠しているか」を継続的に見るために使います。
AWS Security Hub CSPM
AWS Security Hub Cloud Security Posture Managementは、AWS環境のセキュリティ状態を集約し、セキュリティ標準やベストプラクティスに対する状態を確認するサービスです。
AWS Configが各リソースの構成履歴とルール評価を扱うのに対し、Security Hub CSPMはセキュリティ所見を集約して優先順位付けする入口として使えます。
AWS公式: Introduction to AWS Security Hub CSPM
実際のコマンドとHTTPで動作を確認する
Systems Manager Run Command
Systems Manager Run Commandを使うと、Systems Managerの管理対象になっているEC2などに、コンソールやAWS CLIからコマンドを実行できます。SSHの入口を新たに公開せず、プロセス、ローカルポート、ディスク容量などを確認できます。
# アプリの起動状態と、ローカルのヘルスチェックを確認する。
aws ssm send-command \
--instance-ids i-0123456789abcdef0 \
--document-name AWS-RunShellScript \
--parameters '{"commands":["systemctl is-active sample-app","curl -fsS http://localhost:8080/health"]}'
実行には、SSM Agent、IAMロール、Systems Managerのエンドポイントまたは外向き通信など、管理対象の条件を整える必要があります。出力に機密情報が混ざらないコマンドだけを使います。
AWS公式: AWS Systems Manager Run Command
CloudWatch Synthetics
CloudWatch Syntheticsは、Canaryと呼ばれるスクリプトをスケジュール実行し、WebページやAPIを定期的に確認します。利用者からのアクセスがない時間でも、応答コード、応答時間、ページの動作を継続確認できます。
Canaryの失敗をCloudWatch Alarmに接続し、SNSなどで通知すると、「監視対象と通知経路の両方が動くか」を確認できます。
CloudTrailとCloudWatchで証跡を確認する
CloudTrail
CloudTrailのEvent historyでは、各リージョンで過去90日間の管理イベントを検索できます。マネジメントコンソール、AWS CLI、SDK、APIで行われた操作の確認に使えます。
例えば、次の確認に役立ちます。
- セキュリティグループを誰が変更したか
- IAMポリシーの更新APIが成功したか
- EC2の停止・起動がスケジュールどおり実行されたか
# 特定リソース名に関連する管理イベントを最大20件確認する。
aws cloudtrail lookup-events \
--lookup-attributes AttributeKey=ResourceName,AttributeValue=i-0123456789abcdef0 \
--max-results 20
Event historyはリージョンごとの管理イベントが対象です。S3オブジェクトへのアクセスなどのデータイベントを長期保存・検索する場合は、TrailやCloudTrail Lakeの設計が別途必要です。
AWS公式: Working with CloudTrail event history
CloudWatch
CloudWatchでは、次の3点をセットで確認します。
- アプリケーションログが期待するLog Groupに出力される
- CPU使用率、ALBの5xx、RDS接続数などのメトリクスを取得できる
- しきい値を超えた場合にAlarmが状態変化し、通知先へ届く
アラームを作成しただけで完了にせず、検証環境で安全にしきい値を越え、通知が届くところまで確認します。
脆弱性と回復力を確認する
Amazon Inspector
Amazon Inspectorは、EC2、ECRのコンテナイメージ、Lambda関数を継続スキャンし、ソフトウェアの脆弱性や意図しないネットワーク露出に関するFindingを作成します。
InspectorのFindingが0件であっても、Webアプリケーションのロジックや認証、入力値検証までテストできたわけではありません。アプリケーションテストやコードレビューと組み合わせます。
AWS公式: What is Amazon Inspector?
AWS Resilience Hub
AWS Resilience Hubは、アプリケーションのレジリエンス目標を定義し、現在の構成がその目標を満たせるかを評価します。改善提案とテスの入口を一箇所で管理できます。
AWS公式: What is AWS Resilience Hub?
AWS Fault Injection Service
AWS Fault Injection Serviceは、EC2の停止、CPU負荷、ネットワーク影響などの障害イベントを実験として実行し、ワークロードがどう反応するかを確認するサービスです。
AWS FISは実際のリソースに障害操作を行います。対象タグ、IAM権限、停止条件、CloudWatch Alarm、実行時間、関係者の承認を決め、最初は本番と分離した検証環境で実行します。
AWS公式: What is AWS Fault Injection Service?
実務での確認順序
小〜中規模のWebシステムでは、次の順序が分かりやすいです。
- CloudFormationのスタックステータス、Outputs、ドリフトを確認する
- Reachability Analyzerで必要な通信経路を1本ずつ確認する
- Network Access Analyzerで禁止したい経路を横断確認する
- IAM Access Analyzerで外部共有とポリシー警告を確認する
- Run CommandやSyntheticsで実際のプロセス・HTTP応答を確認する
- CloudWatchでログ、メトリクス、アラーム、通知を確認する
- CloudTrailで構築・変更操作の証跡を確認する
- Config、Security Hub CSPM、Inspectorで継続的にFindingを管理する
- 重要システムはResilience Hubで評価し、承認済みのFIS実験で回復手順を確かめる
確認結果は「証跡」と「残リスク」を残す
実行したサービス名だけでなく、期待値と結果を残します。
確認日時: 2026-08-27 14:00 JST
AWSアカウント・リージョン: 社内の管理番号 / ap-northeast-1
確認したいこと: アプリENIからRDSへTCP 5432で到達できる
使用サービス: VPC Reachability Analyzer
期待結果: Reachable
実際の結果: Reachable
証跡: Network Insights Analysis IDと社内証跡保存先
追加確認: アプリから実際のDB接続テストを行う
残リスク: Reachability AnalyzerではDB認証情報とSQL実行を確認できない
公開記事や社外資料には、AWSアカウントID、実在するリソースID、内部URL、IPアドレス、Findingの詳細をそのまま載せません。
最小構成で始めるなら
すべてのサービスを同時に有効化する必要はありません。システムの規模とリスクで優先順位を決めます。
| システム | 最初の候補 |
|---|---|
| 個人学習・小規模検証 | Reachability Analyzer、IAM Access AnalyzerのPolicy validation、CloudWatch、CloudTrail Event history |
| インターネット公開のWebシステム | 上記に加えてNetwork Access Analyzer、Synthetics、Inspector、Security Hub CSPM |
| 複数アカウント・重要システム | AWS Config Aggregator、Security Hubのリージョン集約、Resilience Hub、承認済みのFIS実験 |
Network Access Analyzer、Reachability Analyzer、AWS Config、Security Hub CSPM、Synthetics、Inspector、Resilience Hub、FISなどは、実行回数、記録数、リソース数、評価時間などに応じて料金が発生する場合があります。有効化前に対象リージョンの公式料金ページと見積もりを確認します。
よくある間違い
Analyzerの結果だけで実動作OKと判定する
設定上到達できても、プロセス停止、TLS証明書、アプリケーション設定、DB認証、データ不整合は確認できません。実コマンドとHTTPテストを組み合わせます。
Findingが0件なら安全と考える
AnalyzerやSecurity Hubは、定義された範囲、ルール、対応リソースを評価します。対象外の設定やアプリケーションのロジックは別に確認します。
1つのリージョンだけ確認する
多くの分析、記録、セキュリティサービスはリージョンごとに有効化・確認が必要です。グローバルリソースと複数リージョン構成を含め、対象範囲を先に一覧化します。
有効化しただけで運用を終える
FindingやAlarmには、確認担当、期限、優先度、例外の理由、再評価日を決めます。通知先が誰にも見られていない状態では、検出機能があっても改善につながりません。
確認チェックリスト
- CloudFormationのスタックとドリフトを確認した
- 必要な通信経路のReachability Analyzerを実行した
- 禁止する通信経路をNetwork Access Scopeで確認した
- IAM Access AnalyzerのExternal access FindingとPolicy validationを確認した
- 正常系と異常系の実動作テストを実行した
- CloudWatch Logs、Metrics、Alarm、通知を確認した
- CloudTrailで構築・変更操作の証跡を確認した
- Config、Security Hub CSPM、InspectorのFindingを確認した
- リージョン、アカウント、対象外リソースの残リスクを記録した
- 実行ID、結果、確認日、判定者、次のアクションを証跡に残した
関連記事
- AWS VPC設計入門 CIDR・サブネット・ルートを最初に決める理由
- AWS Service CatalogとCloudFormationで標準テンプレートを配布する考え方
- CloudFormation後編｜本番更新が怖い人向け
参考・確認先
- VPC Reachability Analyzer
- VPC Network Access Analyzer
- IAM Access Analyzer
- CloudFormationドリフト検出
- AWS Config
- AWS Security Hub CSPM
- CloudTrail Event history
- CloudWatch Synthetics
- Amazon Inspector
- AWS Resilience Hub
- AWS Fault Injection Service
- AWS Systems Manager Run Command
- 仕様確認日: 2026-08-27
まとめ
- Reachability Analyzerは「この2点間が到達可能か」を確認する
- Network Access Analyzerは「要件に反する経路がないか」を横断的に確認する
- IAM Access Analyzerは外部共有、未使用権限、ポリシーの警告を確認する
- CloudFormationドリフト、AWS Config、Security Hub CSPMで設定のずれと準拠状況を見る
- 設定分析だけで終わせず、Run Command、Synthetics、CloudWatchで実際の動作も確かめる
- 重要システムでは、Inspector、Resilience Hub、承認済みのFIS実験まで検討する
おわりに
AWS構築後の確認は、「作成できた」で終わせず、必要な経路、禁止する経路、実際の応答、監視、回復を順番に確かめると抜け漏れを減らせます。
Wealthy Designでは、AWS・Azure・Google Cloudを利用したクラウド設計、構築、運用改善と、実務知識を学びに変える技術発信に取り組んでいます。