超訳・AWS Configベストプラクティス
AWS Management & Governance BlogでAWS Configのベストプラクティスが紹介されている。
読んでみたので、勝手に分類分け＆超訳してみました。
ひとまず、設定しとけの巻
- 1.Enable AWS Config in all accounts and Regions.
- 2.Record configuration changes to ALL resource types.
- 3.Record global resources (such as IAM resources) only in one Region.
すべてのアカウント＆リージョンで有効化するべし。
すべてのリソースタイプの構成変更を記録するべし。
ただし、グローバルリソースに関しては重複しちゃうから、お気に入りのリージョンだけで記録するべし。
はじめてのconfigで調べるとよく言われていることが書かれているよ。
構成履歴と構成スナップショットの保管の巻
- 4.Ensure that you have a secure Amazon S3 bucket to collect the configuration history and snapshot files.
- 11.Turn on periodic snapshots with a minimum frequency of once per day.
記録する構成履歴と構成スナップショットファイル保管用のS3は安全に運用するべし。
1日1回以上の頻度で定期的なスナップショットをオンにするべし。
マルチアカウントの巻
- 5.Specify an Amazon S3 bucket from another (central IT) account for centralized management of history files and snapshots.
- 6.Specify an Amazon Simple Notification Service (Amazon SNS) topic from another (central IT) account for centralized management of configuration and compliance notifications.
- 19.Use the data aggregation feature to aggregate resource configuration and compliance data into a central account.
- 20.Create an organizations-based aggregator to aggregate AWS Config data from your entire organization.
マルチアカウントで運用するときは集約するべし的なことが色々書かれている。
通知はさせておけの巻
CloudWatchEvents使って通知対応しているから設定するべし。
コンプラはしっかり設定しようの巻
- 8.Set the appropriate permissions for the IAM role assigned to AWS Config
- 9.If you prefer to create an IAM role for AWS Config yourself, use the AWS managed policy AWSConfigRole and attach it to the IAM role.
- 10.Ensure that the SNS topic permissions are restricted to only allow AWS Config to publish messages to it.
IAMRoleは適切なアクセス許可か確認するべし。
IAMRoleつくるときはAWS管理のAWSConfigRoleを活用するべし。
SNSトピックがconifgだけに制限されているか(適切に設定されているか)確認しよう。
変更発生後の確認方法の巻
- 12.Use the AWS CloudTrail Lookup API action to find the API events that occurred in the timeframe when the configuration change occurred.
構成変更が発生した場合はCloudTrailのlookup-eventsを活用して確認するべし。
カスタムルール作成についてのあれこれの巻
- 13.Create change-triggered custom rules for resource types supported in AWS Config.
- 14.Create periodic rules for resource types not supported in AWS Config.
- 15.Use the AWS Config Rule Development Kit (RDK) for authoring custom rules.
- 16.Use the AWS Config Rules repository, a community-based source of custom AWS Config rules.
- 17.Use Annotations.
サポートされているリソースは変更トリガーによる実行＆定期実行のカスタムルールが作れるよ。
サポートされていないリソースは定期実行のカスタムルールが作れれよ。
カスタムルール作るときはAWS Config Rule Development Kit（RDK）を使うべし。
AWS Config Rules RepositoryがGithubに公開されているから活用するべし。
カスタムルール作ったら、評価の基準はちゃんと書くべし。
AWS Config Rule Development Kit（RDK）は触ったことないから触ってみたい。
Conformance Packsは便利だから使っとけの巻
- 18.Use Conformance Packs.
Conformance Packsとは構成の評価ルール(Config Rule)と修復アクション(Remediation Configuration の集合をコードで定義・デプロイできる機能らしい。
知らなかった！これは便利そうなので是非使ってみたい。
終わり。let's config !
