0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 3 years have passed since last update.

AWS Organizationsのタグポリシーを使ってみた

Last updated at Posted at 2021-01-18

タグポリシーとは

 タグポリシーをOU(組織単位)にアタッチすることで、タグの標準化を推進してくれます。
 タグポリシーの機能として
  キーの大文字小文字の統一
  バリューの制限
があり、非準拠のリソースを作成しないようにすることもできます。
 ただし、タグを強制できる機能ではありませんので、その点はしっかりと覚えておく必要があります。
 大文字小文字の統一では、作成するキーがname,Nameとばらけるのを防いでくれます。
 指定したキーを正しく入力さえしていれば、指定したバリューでしかリソースを作成できません。指定外のバリューを設定して作成すると、エラーが起きます。
 しかし、タグポリシーでキーをnameと指定し、実際に設定したものがnamedであれば、バリューの制限はできません。
 キーは一言一句一致していなければなりません。
 なお、以上の作成を防いでくれる機能は、デフォルトでは無効化されているので有効化する必要があります。

タグポリシーを使ってみる

01Organizationsポリシー.png

Organizationsのポリシータブからタグポリシーを選択。

02Organizationsタグポリシー有効化.png

タグポリシーはOU単位だけでなく、個々のアカウントにも適用できる。いいですね。
単なる有効化だけでは他のリソースに影響を及ぼすこともなさそうです。
有効化します。

03Organizationsタグポリシー有効化後.png

早速ポリシーを作成します。

04Organizationタグポリシー作成.png

設定項目の入力が終わりました。

いまいち分かりませんでしたが、中段のタグセクションでキーとバリューを入れてみました。
このタグは、アタッチ先のリソースに自動的に付与されるということでしょうか?アタッチした後に確認してみましょう。
→単にタグポリシーにタグを付与しているだけでした。リソースにタグを付与しているのと同じ意味です。

タグキー大文字コンプライアンスは小難しいことを書いていますが、指定した文字通りのキーでないと作成できないという意味だと思います。
例えば、project、PROJECTはダメで、ProjectのみOK。

タグ値コンプライアンスは分かりやすいですね。
Projectキーは、Private,Hands-on-*,ControlTowerしか値が付けられないという意味です。
ワイルドカードが使えるのはいいですね。ただしワイルドカードは一つの値につき一度だけしか使えません。

一番の注意点は、強制するリソースタイプでしょう。
今回はデフォルトのまま有効化しませんでした。
ドキュメントもタグポリシーの使用経験がないならデフォルトのままがいいと言っていますので、従いましょう。
ただし、非準拠操作を防止しないので非準拠タグが作成できそうですが、とりあえずこのまま進めてみましょう。

05Organizationsアタッチ.png

適当なアカウントにタグポリシーをアタッチします。

では、試しにタグポリシーをアタッチしたアカウントにサインインしてVPCをタグをつけずに作成してみます。
結果は、エラーも起きず普通に作成できました。

次に、タグキーにPROJECT、バリューにPublicとして作成してみます。
非準拠のタグですが、エラーも起きずそのとおりに作成されました。

AWS Resouce Groupsのタグポリシーを確認すると、非準拠として把握はされています。
しかし、非準拠操作を防止していないので、タグが作成されてしまったようです。

これではあまり意味がないので、タグポリシーの非準拠操作を防止してみます。
また、上述しましたが、タグポリシー自体につけたタグは、アタッチしたアカウントやOUでのリソース作成時に自動的に付与されるタグではなく、単にタグポリシーのタグという意味でした。
リソースにタグをつけるのと同様に、ポリシーにタグをつけているだけです。
ということでタグポリシーにつけたタグは削除しておきます。

タグポリシーにつけていたタグの削除と、非準拠操作防止を有効化しましたので、再度VPCを作成してみます。

06Organizationsエラー①.png

07Organizationsエラー②.png

タグポリシーに準拠していないタグを作成しようとしたら、エラーになって作成できませんでした。いいですね。

また、非準拠操作防止を有効化するに当たっての注意点として、ドキュメントに以下の記載がありました。

Understand interactions with some services – Some AWS services have container-like groupings of resources that automatically create resources for you, and tags can propagate from a resource in one service to another. For example, tags on Amazon EC2 Auto Scaling groups and Amazon EMR clusters can automatically propagate to the contained Amazon EC2 instances. You may have tag policies for Amazon EC2 that are more strict than for Auto Scaling groups or EMR clusters. If you enable enforcement, the tag policy prevents resources from being tagged and may block dynamic scaling and provisioning.

間違っているかもしれませんが、自分の言葉で要約してみます。
EC2オートスケーリンググループなどは、リソース(インスタンス)を自動的に作成します。
インスタンスのタグはオートスケーリングのタグが反映されますが、インスタンス自体がオートスケーリンググループより厳しいタグポリシーがあったとします。
その場合、インスタンスが自動で作成されなくなってしまうという大惨事が起きてしまう可能性があります。
例えば、オートスケーリングのタグキーNameの値はA,Bしか許されず、インスタンスのタグキーNameの値はAしか許されない場合などが、インスタンスの方が厳しいタグポリシーがある、ということになると思います。
オートスケーリングの値がBの場合、インスタンスの値もBになりますが、インスタンスがAの値しか許されていないので、作成できません。
このようなことが起きる可能性があるので、タグポリシーで非準拠操作を防止する際は、注意する必要があります。

終わりに

タグのルールが決まっている環境だと便利な機能だと思いました。
タグポリシーを複数作成している場合、上述のようにリソースが作成できないと言う予期せぬ出来事が起こりやすそうなので、便利ではありますが十分に配慮して使用した方がよさそうですね。

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?