【AWS】AWS Configとは？徹底解説！

1 AWS Configとは？
2 AWS Config Rulesとは？
3 料金
4 ユースケース
5 ハンズオン概要
6 利用手順

AWS Configとは？

AWS Configとは、AWSのマネージドサービスの一つで、システムの構成管理を容易にするツールです。AWSリソースの構成変更をロギングし、誰が、いつ、何をしたか自動で、継続的に記録し確認できます。ログの保持期間はデフォルトで7年となっており、30日~7年の間で設定が可能となります。

AWS Configを利用しない場合、構成管理は、システム構成図やパラメーターシートを利用し管理され、システムに修正が入ったら資料を更新するという対応を行う必要があります。このような運用だと、工数が掛かる上、いずれシステムと設計書の乖離が発生してしまう可能性もあります。AWS Configを利用する事で構成管理の効率や正確性を向上させる事が出来ます。

また、Config Rulesを設定する事で、ルールに反した変更をした際に自動的に通知(Amazon SNSとの連携)や修正アクションを実施する事が出来ます。これにより、誤操作や設定ミスによる設定変更を防ぎ、脆弱性を発生させない様にする事が出来ます。

AWS ConfigはS3バケットにリソースの設定履歴を保持する事が出来ます。

AWS Configは70程度のAWSサービスを対象としており、主要のサービスについては構成管理が可能と言えます。詳細については、AWS公式ページを参照下さい。

AWS Config Rulesとは？

AWS Config Rulesとは、AWSの各リソース/サービスに付与する設定で、リソース/サービスが準拠すべきルールです。定義されたルールに則っているかどうかを、リソースの新規作成、既存リソースに対する設定変更、定義した定期実行のタイミングで評価されます。

例えば、「S3バケットでパブリック読み取りアクセスを拒否する」というAWS Config Rulesを定義したとします。その場合、何等かのミスなどでS3がパブリック読み取りアクセスが許可に変更されたり、S3を作成する際にパブリック読み取りアクセスを許可する設定が施されると、ルール違反が検知され、通知や自動回復アクションが実行される事となります。

AWS Config RulesにはAWSによって事前定義されたマネージドルールとLambda関数を利用して自身で定義するカスタムルールの2種類が存在します。

また、個人が作成したルールが参照できるAWS Config Rules Repositoryというものも存在します。

マネージドルールは様々存在しますが、例を挙げると以下の様なルールが存在します。

EC2インスタンスで使用されているAMI(Amazon Machine Image)が指定したものか確認
リソースに指定したタグがあるか確認
EC2にアタッチされているEBSボリュームが暗号化されているか確認
EC2インスタンスがSSMで管理されている(マネージドインスタンスとなっている)か確認
VPCのフローログが有効になっているか確認
Amazon S3バケットでパブリック読み取りアクセスが拒否されているか確認
Amazon S3バケットでデフォルト暗号化が有効になっているか確認

また、AWS Configu Rulesに対して修正アクションも定義する事が可能です。

修正アクションとは、AWS Config Rulesに対する違反に対し修正を施すアクションです。

修正アクションを定義する事で、違反に対して自動で設定を修正する処理を走らせる事が可能です。

設定時のベストプラクティスは以下の様になります。

全てのアカウントとリージョンでAWS Configを有効化する
全てのリソースタイプについて設定変更を記録する
グローバルリソースは1リージョンで記録を有効にする

料金

AWS Configの料金は、AWS Configの構成と使用方法によって異なります。以下に、AWS Configの主な料金項目を示します。

AWS Config
- 1つの記録(リソースの新規追加/リソースの設定変更/設定した定期実行)あたり0.003USD
AWS Config Rules
- 実際に評価されたAWS Confiルール
  - 0~10万件：0.001USD/評価されたルール
  - 10万~40万：0.0008USD/評価されたルール

詳細な料金情報は、AWSの公式サイトを参照してください。

ユースケース

構成管理：AWS Configは、AWSリソースの構成変更履歴を保存するため、インフラストラクチャの構成変更管理に役立ちます。
セキュリティとコンプライアンスの管理： 構成変更に応じて修正アクションを定義し、自動的にリソースの設定を修正する事が出来るため、設定ミスなどによる脆弱性の発生を防ぎセキュリティとコンプライアンスを担保する事が出来ます。

ハンズオン概要

以下で実際にAWS Configを利用していきます。

今回は、AWS Configを利用して、Subscriberにメールを送信するという機能を作成します。

利用手順

※当ページでは2023年3月現在のSNSについて解説します。クラウドサービスは頻繁にアップデートが施されるため、仕様が異なる可能性があります。

Amazon SNSの作成

Configにて定義するConfig Rulesに則らないリソースが発見された場合に通知を連携する為に、Amazon SNSを作成します。”test-config-topic”という名前でトピックを作成します。

トピックを作成したら、メール通知の送信先メールアドレスをサブスクリプションとして登録します。

作成方法の詳細については、【AWS】Amazon SNS(Simple Notification Service)とは？徹底解説！を参照下さい。

AWS Configの作成

トピックの作成

サインイン後検索バーに”Config”と入力し、”Config”を押下します。

“今すぐ始める”を押下します。

“一般設定”は以下の様に設定します。

記録するリソースタイプ：Configの記録対象となるリソースを設定します。今回は”Record all current and future resources supported in this region”を選択します。
- Record all current and future resources supported in this region：リージョン内の全てのリソースにConfigを適用したい場合に選択します。
- 特定のリソースタイプを記録する：リージョン内の特定のリソースに記録対象を絞りたい場合に選択します。
グローバルリソース(AWS IAMリソースなど)含める：グローバルリソースを含める場合チェックを入れます。Configはリージョンレベルのサービスですが、こちらを有効化すると、Configを作成したリージョン + グローバルリソースを記録の対象とします。
AWS Configロール：AWS Configが他サービスを呼び出すために必要なロールを設定します。今回は、”既存のAWS Configサービスにリンクされたロールを使用”を選択します。
- 既存のAWS Configサービスにリンクされたロールを使用：AWS Configによって事前に定義されたロールで、他のAWSサービスを呼び出すために必要な全てのアクセス許可が備わっております。
- アカウントからロールを選択：アカウントに自身で作成したロールを利用する場合に選択します。

“配信方法”については、以下のように設定します。

Amazon S3バケット：リソースの構成情報を送信するためのS3バケットを作成/選択します。今回は新規作成します。
S3バケット名：任意のS3バケット名を付与します。今回は”test-config-bucket-202304″と命名します。
Amazon SNSトピックへのストリーム設定の変更と通知：有効化すると、Configの記録対象リソースに変更が発生した際、SNSを経由して通知を行う事が出来ます。今回はConfig Rulesに反する時のみ通知を行いたいため、無効とします。

“ルール”では、どのリソースにどのようなConfig Ruleを付与するかを決定します。こちらは要件に応じて決定していきます。

Config作成後にもルールが追加可能なため、ここでは何も選択しません。

設定が正しいか確認し、”確認”を押下します。

作成すると、ダッシュボードが表示されます。

ダッシュボードではAWSのリソースを全て確認可能で、ダッシュボートより特定のサービスを選択すると、タイムラインごとに構成の詳細情報やを時系列毎に確認可能です。

設定タイムラインとは、どのユーザーによって何の変更が実施されたかを確認するためのツールです。

IAMロールの作成

Configが自動で修復アクションを実行するには、修復アクションが可能なIAMロールを作成し、自動修復アクションを定義する際に指定する必要があります。

“test-config-role”というユーザーに”AmazonSSMAutomationRole”というロールを直接アタッチし、IAMユーザーを作成します。

Config Rulesの定義

Config Rulesを定義し、EC2が”m7g.xlarge”のインスタンスタイプで作成される必要があるように設定します。

ルールタブより”ルールを追加”を押下します。

“AWSによって管理されるルールの追加”を選択した上で、”desired-instance-type”を選択します。

“Evaluation mode”にて”すべての変更”を選択します。

“パラメータ”の値にて、”m7g.xlarge”を入力します。

上記の設定が完了したら、”次へ”を押下し、確認画面にて”ルールを追加”を押下します。

ルールが作成されたら、作成したルールを選択し、”アクション”より、”修復の管理”を押下します。

“修復方法を選択”では、自動修復を選択します。

インターバル600秒で監視し、再試行まで5回の確認を行う設定をします。

“修復アクションの詳細”では、”AWS-PublishSNSNotification”を選択します。

“レート制限”及び”リソースIDパラメータ”はデフォルトとします。

“パラメータ”は以下の様に設定します。

TopicArn：先程作成したSNSトピックのARN(SNSのダッシュボードから確認可能)
Message：任意のメッセージを定義します。
AutomationAssumeRole：先程作成したIAMロール”test-config-role”のARN(IAMのダッシュボードから確認可能)を付与します。

変更履歴の確認

S3に連携される変更履歴の確認をしてみましょう。

S3を開き、”test-config-bucket-202304″配下を見ると、リソースの作成/変更の履歴がS3に保存されています。

EC2の作成

では、定義したConfig Rulesに反したEC2を作成した際に自動的にSNSを介して通知が連携されるかを確認します。

任意の名前を付与した上で、インスタンスタイプを”t2.micro”とし、他はデフォルトでEC2を作成します。

作成し、数分経過すると、Configのダッシュボードでは、非準拠ルールのリソースが確認されます。

関連記事

【AWS】EventBridgeとは？徹底解説！

AWS Configとは？

AWS Config Rulesとは？

料金

ユースケース

ハンズオン概要

利用手順