この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
まいど、大阪の市田です。 先日、CloudFormationのドキュメントを眺めている時に、偶然ドキュメントの更新履歴から「IAMのService-Linked Roles作成がCloudFormationに対応した」というリリースを発見しました。
Release History - AWS CloudFormation
書式も非常にシンプルです。(下記はYAMLの場合です)
Type: "AWS::IAM::ServiceLinkedRole"
Properties:
AWSServiceName: String
CustomSuffix: String
Description: String詳細が記載されたドキュメントページは下記になります。
AWS::IAM::ServiceLinkedRole - AWS CloudFormation
今回新たにリリースされたのは「AWS::IAM::ServiceLinkedRole」というプロパティタイプですが、下記の通りドキュメント上だとまだメニューにリンクがありません。そのため、この機能の発見が遅くなってしまったのですが実際に利用できる状態になっていますので、ご紹介したいと思います。
（個別のドキュメントページは存在していたので、そのうちリンクにも表示されるようになると思います。）
Service-Linked Roleとは？
そもそも「Service-Linked Roleとは何ぞや」という話ですが、AWSの場合、あるサービスは別のサービスを利用していることがよくあります。例えば、EC2のAutoScalingではスケールアウト/インのトリガーにCloudWatchアラームを利用しています。
このように「そのサービスから他のAWSサービスを呼び出す」ためのIAMロールのことを「Service-Linked Role」、「サービスにリンクされたロール」と言います。先程の例だと「EC2のAutoScalingにリンクされたIAMロールは、CloudWatchアラームを操作できる権限を持っている」、と表現できます。
詳細については下記ドキュメントを参照してもらえればと思いますが、ザックリと理解いただけたかと思います。
サービスにリンクされたロールの使用 - AWS Identity and Access Management
使ってみた
全く大したことはないですが、せっかくなのでElastiCacheのロールで試してみます。 実際には、AWS CLIやマネジメントコンソールでElastiCacheを作成する時に自動的にこのロールは作成されるので、ElastiCache用にCloudFormationで作成することは無いと思います。
Resources:
ElastiCacheServiceLinkedRole:
Type: "AWS::IAM::ServiceLinkedRole"
Properties:
AWSServiceName: elasticache.amazonaws.com
Description: "This is a test."問題なく作成できました。
IAMのコンソールでも確認できました。
このように「Service-Linked Roles」をCloudFormationで作成すること自体はとても簡単です。また、この「Service-Linked Roles」は普段あまり意識することが無いため「何が嬉しいの？」という疑問も出てくると思います。
しかも、ElastiCacheの場合はCloudFormationを利用する時でも、上記のように明示的にAWS::IAM::ServiceLinkedRoleを使わなくてもAWS側で自動的に作成してくれます。
そうなると、ますますAWS::IAM::ServiceLinkedRoleが何のためにあるのか、ということが気になってきますよね。
そこで本エントリでは、「今回のアップデートの何がうれしいのか」という点に以後、焦点を当ててみようと思います。
CloudFormation対応でうれしい点
さて、「Service-Linked Role」が何なのか分かって実際の使い方も見ましたが、あらためて今回のアップデートの何がうれしいのでしょうか？
結論から言えば、「Service-Linked Role」を別作業として作成しなくてもよくなり、CloudFormationだけで対応できる幅が広がった、ということです。
結論はこれだけなんですが少し寂しいのでもう少し深掘りして、どういう時に使うのかという点をアップデートリリース以前の課題を踏まえてご紹介したいと思います。
アップデートリリース前の課題
この「Service-Linked Role」は、多くの場合でAWSサービスを作成する時に自動で作成されます。なので、ユーザが明示的にこのロールを作成することは、ほぼありません。 これはマネジメントコンソールやAWS CLI、CloudFormationなど、どの作成手段の場合でも「ほぼ同様」です。
「ほぼ同様」とはどういう意味かというと、一部のサービスでは特定の手段で作成するときに、明示的に「Service-Linked Role」を作成しないと自動で作成してくれない場合がある、ということです。
より具体的に言うと、「マネージメントコンソールやAWS CLI利用時は自動的に作成されるけど、CloudFormationでは自動的に作成されないケースがある。」という課題がありました。
課題解決するためのこれまでの方法
例として、「Amazon Elasticsearch Service」(以下Amazon ES)で話をしていきたいと思います。
詳細は別エントリで紹介しますが、マネジメントコンソールで「Amazon ES」をVPC上に作成する時は自動的に「Service-Linked Role」を作成してくれます。
しかし、「Amazon ES」を一度も作った事がない場合は「Amazon ES用のService-Linked Role」が存在しません。 その状況で、AWS CLIやCloudFormationで「Amazon ES」を作成すると「Service-Linked Role」は自動で作成されず、下記のようなエラーが出てしまいます。
An error occurred (ValidationException) when calling the CreateElasticsearchDomain operation: Before you can proceed, you must enable a service-linked role to give Amazon ES permissions to access your VPC.つまり、マネジメントコンソールを使わない場合は事前に「Service-Linked Role」を作成しておく必要があるというわけです。
明示的に「Service-Linked Role」を作成する場合は、AWS CLIやAPIを利用できます。AWS CLIならcreate-service-linked-roleコマンドで作成できるので、スクリプトに組み込んで実行するのも容易です。
コマンドの内容は下記の通りとても簡単なものです。（以下はAmazon Elasticsearch Serviceの場合です。念の為。）
$ aws iam create-service-linked-role --aws-service-name es.amazonaws.com`CloudFormationを使う場合
問題はCloudFormationで全部作りたい場合です。これまではCloudFormationで作成できなかったので、別途AWS CLIなどを使って別作業として作成する必要がありました。 職場ポリシーで自由にAWS CLIなどをPCにインストールできないとか、ITに詳しくない人が作業しなければいけないような場合だと、これではちょっと困りますよね。
しかし、強引に全部CloudFormationだけでやろうとすると、一例として下記のような構成のCloudFormationを事前に実行することになって、とても大げさな内容になってしまいます…
- IAMの操作権限を持った一時的なEC2インスタンスをAutoScalingで作成
- Userdataで
create-service-linked-roleのAWS CLIを実行 - 終わったらAutoScalingを利用してEC2インスタンスをTerminate
結局、何がうれしかったのか
さて、予想外に長いエントリになってしまいましたが、結論として今回のアップデートで上記のような問題が解決出来るようになったことが非常にうれしいと思っています。
まず、AWS CLIなどを使わなくてもマネジメントコンソールからCloudFormationを実行するだけでよくなりました。また、CloudFormationも上記のような大げさな事をしなくてもよくなり、非常に完結になりました。
これは嬉しいですよね。
最後に
地味なアップデートで恩恵を受けるユーザがどの程度いるか分からないですが、場合によってはうれしい内容なのではないかと思います。
この記事が皆様のCloudFormationライフのお役に立てれば幸いです。 以上になります。
4
