設定がいつ変わったかを記録から確かめる

手順に迷ったときや、用語の意味を確かめたいときに開きましょう。

※ リンク切れの場合は、ページタイトルで検索してください。

AWS Config を有効化する際に、記録対象のリソースタイプを選ぶ画面があります。今回どちらを選ぶかのイメージを示します。

以下の要件を満たし、セキュリティグループの設定変化を構成タイムラインで確認できる状態にしてください。

「Config を有効化する → 記録対象を絞る → 設定を変える → タイムラインで差分を見る」という順番で進みます。

1. マネジメントコンソールにサインインし、リージョンを東京に合わせる

   ブラウザで AWS マネジメントコンソールにサインインし、画面右上のリージョンが「アジアパシフィック（東京）ap-northeast-1」になっていることを確認します。

2. Config 用の S3 バケットを作成する

   S3 コンソールで「バケットを作成」し、世界で一意な名前を付けます（名前自由、例：config-記録用-自分の名前）。AWS Config の記録データ（構成項目）の配信先として使います。

3. AWS Config コンソールを開き、設定を進める

   画面上部の検索バーに Config と入力し、サジェストから選びます。初回であれば「今すぐ始める」から設定を進めます。記録対象の選択画面で、「特定のリソースタイプを記録」に切り替えます。

   AWS Config を設定 — 記録するリソースタイプの選択（イメージ）

   記録するリソースタイプ

   特定のリソースタイプを記録

   対象を絞って記録量とコストを抑える

   すべてのリソースを記録

   より本番に近いが記録量が増える

   ↳今回はセキュリティグループだけに絞ります

   絞り込むほどコストが読みやすい

   記録対象を絞ることで、記録される構成項目の件数が減り、コストの見通しが立てやすくなります。学習目的では、まず対象を絞って試すのがおすすめです。

4. 記録対象のリソースタイプを選び、配信先を指定する

   リソースタイプの一覧から「EC2: SecurityGroup」（セキュリティグループ）を選択します。配信先には、手順 2 で作成した S3 バケットを指定し、設定を完了します。

5. 確認用のセキュリティグループを 1 つ用意する

   既存のセキュリティグループを使ってもよいですし、新規に作成しても構いません。EC2 コンソールの「セキュリティグループ」から確認・作成できます。

6. そのセキュリティグループのインバウンドルールを 1 つ変更する

   対象のセキュリティグループの「インバウンドルール」タブから、ルールを 1 つ変更します（例：許可するポート番号を追加する、または許可元の範囲を変更する）。

   変更前に Config が動いていることが前提

   変更後の差分を見るには、変更する前の状態が既に記録されている必要があります。手順 3〜4 で Config を有効化してから、十分に間を置いてこの手順に進みましょう。

7. 構成タイムラインで変更前後の差分を確認する

   Config コンソールの「リソース」から対象のセキュリティグループを検索し、「構成タイムライン」を開きます。複数のタイムスタンプが並んでいるはずなので、変更前後を選んで差分を見比べます。

初学者がよく引っかかる箇所を先回りでまとめました。答えそのものは載せていませんが、「どこを見直せばよいか」の手がかりとして使ってください。

要件の再確認ではなく、画面のどこを見れば達成を確認できるかをまとめました。Config コンソールや S3 コンソールを開いて、次を順に確かめましょう。

• AWS Config の設定画面で、レコーダーのステータスが「有効」になっている。
• 記録対象のリソースタイプの一覧に、EC2 セキュリティグループが含まれている。
• 対象のセキュリティグループの構成タイムラインに、2 つ以上のタイムスタンプが並んでいる。
• タイムライン上で、手順で変更した箇所（インバウンドルール）の変化が確認できる。
• 配信先に指定した S3 バケットの中に、ファイルが作られている。

手を動かすことに加えて、次の問いに自分の言葉で答えられるようにしておくと、理解がより深まります。

1. CloudTrail と Config を組み合わせると、「誰が」「何を」変えたかをどう追跡できるでしょうか。
   ヒント

   CloudTrail には「誰が、いつ、どの API を呼んだか」という操作の記録があります。Config には「設定がどう変わったか」という状態の記録があります。同じ時刻帯のイベントを両方から探し出して突き合わせる、という流れを考えてみましょう。
2. 全リソースを記録しなかった場合、見えなくなる変更にはどんなものがあるでしょうか。それは許容できるリスクでしょうか。
   ヒント

   今回はセキュリティグループ以外の変更（例：IAM ロールの権限変更、別のネットワーク設定の変更など）は記録されません。何を監視したいかによって、絞り込みすぎることのリスクが変わってくる、という観点で考えてみましょう。
3. 本番環境で Config ルール（設定違反を自動検知する機能）を使うと、今回の「あとから確認する」運用とどう変わるでしょうか。
   ヒント

   今回の構成タイムラインは「過去を振り返って調べる」という事後的な使い方でした。Config ルールを使うと、設定が望ましい状態から外れた時点で自動的に検知できます。「事後の調査」と「事前の検知」の違いから考えてみましょう。

AWS Config は有効化したままにしておくと記録が続き、課金も続きます。確認が終わったら、次の順番で後片づけをしましょう。

1. AWS Config の記録を停止（無効化）する：Config コンソールの設定画面から、レコーダーを停止します。
2. 配信チャネル・レコーダーを削除する：設定が残っていると意図せず再開されることがあるため、不要であれば削除します。
3. S3 バケットを削除する：手順 2 で作成した、Config 用の配信先バケットを削除します。バケット内のオブジェクトを先に削除する必要がある場合があります。
4. 変更したセキュリティグループのルールを必要なら元に戻す：確認用に変更したインバウンドルールを、必要であれば元の設定に戻します。