この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
はじめに
本記事では「AWS Configはとりあえず有効にする」事をおすすめしたいと思います。 設定はマネージドコンソールから行い、なるべくデフォルト値で行ってみます。
運用でよく発生するセキュリティグループの変更を例にAWS Configを使ってみます。 AWS Configをとりあえず有効にするだけで、
- ルールの割り当て変更を記録（=リレーションシップ変更の記録）
- ルールの変更を記録（=設定変更の記録）
といった恩恵を受けられます。 変更があった際のメール通知も簡単に行えます。
Get started
AWSマネージドコンソールからAWS Configを開きます。 Get startedを選択し、設定ウィザードを開始しましょう。
Step 1: Settings
Resource types to record
AWS Configで設定を記録するリソースを選択します。 IAMのようなリージョンに関係ないリソースについても記録するため、[Include global resources (e.g., AWS IAM resources)]にチェックを入れます。 特定のリソースのみ記録する事も出来ます。
Amazon S3 bucket
s3バケットを作成し、設定履歴と設定スナップショットを保存します。 デフォルト値のままで問題ないでしょう。
Amazon SNS topic
Amazon SNSを使って、設定の更新および以前の状態からの変更についての通知を行うことが出来ます。 デフォルト値のままにしておきます。
AWS Config role
AWS Configが設定情報を記録するために必要なIAM Roleを作成します。 デフォルト値のままで問題ないでしょう。
Step 2: AWS Config rules
AWS Config Rulesを使うと、社内ポリシーやガイドラインに沿った設定が行われているか評価する事ができます。 ウィザードには、AWSが管理するマネージドルールが表示されています。 「s3バケットのバージョニングが有効かチェックする」「CloudTrailが有効がチェックする」といったルールです。 今回はデフォルトのままチェックなしで進めます。
Step 3: Review
確認画面です。 行った設定は[Include global resources (e.g., AWS IAM resources)]にチェックを入れただけです。
コンフィグタイムラインの確認
しばらくすると画面が切り変わります。左メニューからResourcesを選択します。
リモートデスクトップ接続用のセキュリティグループを探します。リソースの種類とIDを入力しLook upを選択します。
セキュリティグループが見つかったら、時計マーク(=Config timeline)を選択します。
Config timelineを見ていきます。 「24th October 2016 3:14:17 PM」とあります。 これはAWS Configがセキュリティグループを見つけた時間です。 変更履歴がわかりやすいUIですね。
Configuration Detailsには、リソースタイプやIDが表示されます。 Relationshipsには、リソース同士の結びつきが表示されます。 セキュリティグループの場合、ENI ID、EC2インスタンスID、VPC IDが表示されます。 キャプチャはEC2に割り当てしていない時の表示です。
Changesには、変更履歴が表示されます。 過去7日間に限りますが、CloudTrailログも確認できます。
リレーションシップの変更
リレーションシップを変更してみます。 具体的には、先ほどのセキュリティグループをEC2に割り当てます。
コンフィグタイムラインに戻りましょう。 「1 Change」「1 Event」と表示されています。
「1 Change」の詳細です。 セキュリティグループがEC2のネットワークインタフェース(=ENI)に割り当てられた事がわかります。 アタッチされたENI IDも記録されていますね。
「1 Event」の詳細です。
abe.kokiユーザーが操作をした事がわかります。
操作した時刻October 24, 2016 at 5:37:16 PMもしっかり記録されていますね。
ルールの変更
セキュリティグループのルールに0.0.0.0/0の許可を追加します。
（リモートデスクトップの許可は拠点のIPアドレスなど、最小限に行いましょう）
タイムラインにしっかり記録されています。
設定の変更内容はFrom(変更前),To(変更後)を確認出来ます。
ToにipRangesに0.0.0.0/0が増えており、0.0.0.0/0のルールが追加された事がわかります。
イベント「AuthorizeSecurityGroupIngress」が記録されています。 APIリファレンスを確認すると、セキュリティグループに受信ルールが追加されたイベントである事がわかります。
通知
Amazon SNSを使った通知を試してみます。
SNS > Topicを見ると、config-topicがあります。AWS Configのウィザードで作成されたSNSトピックです。
ARNを選択します。
Create subscriptionsを選択し、通知に利用するメールアドレスを指定します。 Create subscriptionsを押下すると確認用のメールが送信されます。
メール中の[Confirm subscription]を選択し、有効化します。 以上で通知設定は完了です。
セキュリティグループのルールを変更すると、メールが送信されます。 件名は「[AWS Config:ap-northeast-1] AWS::EC2::SecurityGroup sg-xxxxxx Updated in Account XXXXXXXXXXX」でした。（IDをマスクしています。） 件名からでもセキュリティグループのアップデートがあった事がわかります。 メール中のURLを選択すると、AWS Configのタイムラインに接続されます。
対応サービス
2016/10/24現在、以下のサービスに対応しています。
- ACM
- CloudTrail
- EC2
- ELB v2
- IAM
- RDS
- S3
運用上、IAMユーザーの作成をウォッチしたいという事もあるかと思います。 IAMユーザーの新規作成についても、メール通知する事が出来ます。
イベントを確認すると、IAMユーザを作成したユーザや時刻を確認できます。
課金
AWS Configでは記録される設定項目の数に基づいて、1 回の前払い料金が発生します。 東京リージョンでは、記録される設定項目につき 0.003 USDです。(2016/10/24時点) 料金に関する最新の情報と詳細はこちらをご覧ください。
参考までに私のアカウントでは、$0.65ドルの前払いが発生しました。 セキュリティグループ、EC2インスタンス、IAMユーザーなどのリソースが多い場合、前払い料金は高くなります。 ほとんどのアカウントで高くても5ドル未満になると思います。 ただし、AutoScalingを頻繁に行うような環境では、EC2がローンチされる度に前払い料金が発生するので注意が必要です。 AWS Configで収集するサービスを絞ることで課金を止めるなど考慮します。
維持コストは、インスタンスやIAMユーザーの追加時の前払い料金とs3、SNSの利用料です。 s3、SNSは非常に安価に利用出来ます。 s3は東京リージョンで１ヶ月あたり約$0.0330/GBです。(2016/10/27時点) AWS Configで利用費が上がることは考えにくいです。 SNSは無料枠が大きいので、使い方によりますが課金が発生しないケースが多いと思います。 課金が発生しても数ドルと思われます。
SNSの料金に関する詳細はこちらをご覧ください。 s3の料金に関する詳細はこちらをご覧ください。
おわりに
AWS Configはほんのわずかな設定だけで、設定変更の記録と通知を行う事ができます。 セキュリティグループの割り当て変更とルール変更を行い、タイムラインからリソースの変更履歴を確認しました。 運用フェーズで変更が発生しやすいセキュリティグループとIAMユーザーの変更の記録や通知に十分に使える事がわかりました。 安価に使えるサービスなので、積極的に有効化していきましょう。
2
