AWS Trusted Advisorといえば、コスト最適化、パフォーマンス、セキュリティ、フォールトトレランス、サービスの制限という5つの分野でAWSについてのベストプラクティスを教えてくれる大変ありがたいサービスである。
AWSアカウントの設定に問題がある可能性があれば、黄色のアイコンで「Investigation Recommended（調査が推奨される）」と表示されるのだが、この中に無視できるアラートを見つけたのでまとめておく。
[Trusted Advisorのチェック内容について]
Trusted Advisorはコスト最適化やセキュリティなど5つの分野でのAWSベストプラクティスを提案してくれるが、その内容はAWSアカウントのサポートプランによって異なる。
日本語のページはないが、以下のページでTrusted Advisorが提供しているベストプラクティスの一覧を確認することができる*1。
これによれば、ベーシックサポートプランや、開発者プランでは以下のベストプラクティスについてチェックをうけることができる。
- セキュリティ：計6チェック
- Security groups - Specific ports unrestricted (セキュリティグループ - 開かれたポート)
- AWS IAM use (IAM の使用)
- Amazon S3 bucket permissions (Amazon S3バケット許可)
- Multi-factor authentication on root account (ルートアカウントのMFA)
- Amazon EBS public snapshots (Amazon EBS パブリックスナップショット)
- Amazon RDS public snapshots (Amazon RDS パブリックスナップショット)
- サービスの制限：計50チェック
ビジネスプランやエンタープライズプランであれば、上記以外にも多数存在するすべてのチェック項目を利用することができる。以下にチェック項目の例を挙げておく。
- コスト最適化
- Low utilization Amazon EC2 instances (使用率の低いAmazon EC2 Instances)
- Unassociated elastic IP addresses (関連付けられていない Elastic IP Address)
- Underutilized Amazon EBS volumes (利用頻度の低いAmazon EBSボリューム)
- ... など
- パフォーマンス
- High utilization Amazon EC2 instances (使用率の高いAmazon EC2インスタンス)
- Amazon CloudFront header forwarding and cache hit ratio (CloudFront ヘッダー転送とキャッシュヒット率)
- Large number of rules in an EC2 security group (EC2 セキュリティグループルールの増大)
- ... など
- セキュリティ
- Security groups - Unrestricted access (セキュリティグループ- 無制限アクセス)
- AWS Cloudtrail logging (AWS CloudTrail ロギング)
- AWS IAM password policy (IAM パスワードポリシー)
- ... など
- フォールトトレランス
- Amazon EC2 availability zone balance (Amazon EC2 アベイラビリティーゾーンのバランス)
- Amazon S3 bucket logging (Amazon S3 バケット ロギング)
- ELB cross-zone load balancing (ELB クロスゾーン負荷分散)
- ... など
[複数AWSアカウント利用時]
ベーシックサポートプランでも利用できるTrusted Advisorのチェック項目に「AWS IAM use (IAM の使用)」がある。
このチェック項目の前提として、AWSアカウントの作成時から存在するルートアカウントは強力な権限を持っているため、日常的な利用は推奨されていない。
一方で、複数AWSアカウントを利用する場合のIAMに関するベストプラクティスとしては、メインのAWSアカウントでのみIAMユーザーを作成し、それ以外のAWSアカウントではSwitch Roleという仕組みを利用することが推奨されている。
出典：AWS におけるマルチアカウント管理の手法とベストプラクティス
https://d0.awsstatic.com/events/jp/2017/summit/slide/D4T2-2.pdf
このベストプラクティスに従うと、ルートアカウントのみ存在し、IAMユーザーが存在しないAWSアカウントができあがる。しかし、Trusted Advisorではこうしたケースは想定されていないため、以下のようなアラートが表示されてしまう。
アラート基準
Yellow: このアカウントには IAM ユーザーが作成されていません。
Switch Roleで利用するAWSアカウントの場合は、複数AWSアカウント利用時のベストプラクティスとして、IAMユーザーを作成しないことが挙げられているので、このアラートは無視することができる*2。
[Auto Scaling Group Health Checkの問題点]
ビジネスプラン以上のサポートプランの場合、フォールトトレランス分野で「Auto scaling group health check (Auto Scaling Group ヘルスチェック)」というチェック項目を利用することができる。
ロードバランサーを利用している場合に、Auto Scalingグループのヘルスチェックが有効になっていないと、インスタンス障害発生時にインスタンスの切り替えがただしく機能しないことになる。
ところが、ロードバランサーの一種であるApplication Load Balancer (ALB)を利用していると、このチェックでアラートが表示される。アラートの基準は次のとおりである。
アラート基準
Yellow: Auto Scaling グループに関連付けられているロードバランサーがありますが、Elastic Load Balancing ヘルスチェックは有効化されていません。
Yellow: Auto Scaling グループに関連付けられているロードバランサーがありませんが、Elastic Load Balancing ヘルスチェックは有効化されています。
このドキュメントによれば、「1 つ以上のターゲットグループ (Application Load Balancer および Network Load Balancer)、1 つ以上のロードバランサー (クラシックロードバランサー)、またはその両方」をAuto Scalingグループに関連付けることができる。
今回アラートが表示された環境ではALBのみを利用していた。ALBもインスタンスのAuto Scalingを行うためには結局Auto Scalingグループを必要とするが、前述のとおりALB利用時にはターゲットグループがAuto Scalingグループに関連付けられ、ターゲットグループがELBヘルスチェックを実行する。
このため、ALBのみを利用しているAWSアカウントでは「Auto Scaling グループに関連付けられているロードバランサーがありませんが、Elastic Load Balancing ヘルスチェックは有効化されています。」という基準に合致してしまい、アラートが表示されることとなってしまう。
同様の事例として、「Load balancer optimization (Load Balancerの最適化)」というチェック項目も、クラシックロードバランサー (CLB)でのみ動作するらしい。この点についてはBlack Beltオンラインセミナーでも紹介されていた。
出典：20180711 AWS Black Belt Online Seminar AWS Trusted Advisor
[まとめ]
AWSさん、是非こちら改善をよろしくお願いいたしします。🙇♂️
*1:これらのチェックのうちいくつかは、なぜこれがベストプラクティスなのかについて、The Amazon Builders' Libraryなどで紹介されている。
*2:もちろん、Switch Roleで利用しないAWSアカウントであれば、全権限を持つルートユーザーで日常的な業務を行うのではなく、IAMユーザーを作成してそのユーザーを利用するべきである。
