全てのリージョンにAWS Configを設定するときのポイント

この記事は1年以上前に書かれたものです。
内容が古い可能性がありますのでご注意ください。
こんにちわ。9月末にサーバーワークス技術3課にJOINしました、すぎたに@大阪オフィスです。
前職ではオンプレ系のインフラ構築、VPN網構築、PHPerとしてWEBアプリ開発、etc...など何でも屋的なことを18年もやっておりましたが、クラウドに特化したことがしたいと言うことで、サーバーワークスにお世話になることになり、もっかAWSガリガリ勉強中です。
早いもので入社直後2ヶ月間の東京での研修期間が終わり、大阪オフィスにきており、引き続きこちらでモクモクしています。

やってみた!AWS Config

さて、先日AWS Configを全リージョンに構築する際にちょっと引っかかりポイントがありましたので、そのご紹介をさせていただきます。
なお、こちらに弊社の多田も「AWS Configに関するIAMロールについて」という記事を書いておりますので、あわせてご覧下さい。
http://blog.serverworks.co.jp/tech/2016/05/13/awsconfig-iam-role/

もいちど・・・AWS Configとは・・・

AWS Configは、AWSリソースが時系列にどのような構成変化をしていったかをロギングするサービスで、サーバーワークスがお客様に提供するAWS環境については、開設されている全世界のリージョンへの実装を推奨しております。
例えば、簡単なところですと、「EC2でサーバーを作ったあとのEIP、インスタンス、サブネット」などの変更を追うことができ、その情報はS3に保存され場合によってはSNSで通知することができます。
2016年12月14日時点では、AWS Configでサポートされている主なAWSリソースは以下の様なものがあり、どのような値を追っかけられるかは、同じく以下にある「Supported AWS Resource Types」のURLからご確認ください。
  • ACM
  • CloudTrail
  • EBS
  • EC2
  • ELB
  • IAM
  • Redshift
  • RDS
  • S3
  • VPC
  • SSM
Supported AWS Resource Types(英文)
http://docs.aws.amazon.com/ja_jp/config/latest/developerguide/resource-config-reference.html#supported-resources

ということで全リージョンに設定!

早速、AWSで開設されている全世界のリージョンに設定していきましょう。
今回は仮のrole名(configRoleという名前)で設定していくものとします。
現時点では、13のリージョンが開設・・・ありゃりゃ、本日ロンドンリージョンが開設されていますね。
region Now Open – AWS London Region(英文)
https://aws.amazon.com/jp/blogs/aws/now-open-aws-london-region/
では、1つリージョンが増えましたので14のリージョンにAWS Configを設定していきましょう。
aws_config_console1 リージョンによっては、設定中にAWS Config Roleの設定画面が表示されますが、ここはskipします。
AWS Config Roleについてはこちらをご覧下さい。(英文)
http://docs.aws.amazon.com/ja_jp/config/latest/developerguide/evaluate-config.html

あれ?...10個目から設定できない?

ところが、10個目を設定するところで以下の様なエラーが出力されました。
aws_config_console%ef%bc%92 The maximum number of policies allowed for the role has been exceeded. Remove one or more policies and try again.
roleについているpolicyが上限の10個になってしまって、これ以上つけられない為、エラーとなったようです。
iam_management_console%ef%bc%91%ef%bc%90 これを回避する方法としては、以下の4つのいずれかをすると続きのリージョンの登録ができるようになります。
  • 指定したIAM roleで内容が重複している管理ポリシー(configRole_AWSConfigDeliveryPermissions_<リージョン名>) を最低1つ残して他をデタッチする。
  • 指定したIAM roleにアタッチされている管理ポリシーのうち、一部をインラインポリシーに移行し、移行した管理ポリシーをデタッチする。
  • 指定したIAM roleにアタッチされている管理ポリシーの内容を1つ、或いは複数の管理ポリシーにまとめて記述する。
  • 一部のリージョンでは先にIAM roleに指定したrole以外の名前のIAM roleを利用する。
今回私は一番初めの方法を採用したあと、他のリージョン登録をしていきました。roleの管理上、スッキリするとおもいますし、インラインポリシーを使うことや、別のIAM roleが増えるのもちょっと雑多になる感じがしました。とはいえ、いろんなケースがあると思いますので、他の方法があることも覚えておきます。

まとめ

ちょっと知らない間に裏でRoleのPolicyが増えてしまっててびっくりしてしまいましたが、ここを整理すると続きのリージョンも設定をしていくことができました。
リージョンの数に関しては今後も増えていくという話をチラホラききますので、注意していかないといけませんね。
では、また〜!

AWS運用自動化サービス「Cloud Automator」無料トライアルはこちらから

COMMENT ON FACEBOOK