AWS

AWSのリソースタグについて注意するべき10のポイント

sho

はじめに

西藤です。

最近タグに関する記事を続けて書いていますが、今回もその話題です。

AWS ConfigとSecurity Hubを活用したタグ付け自動化の実践:複数の方法を比較
AWS ConfigとSecurity Hubを活用したタグ付け自動化の実践:複数の方法を比較
CloudFormation管理下のリソースに一括でタグをつける方法
CloudFormation管理下のリソースに一括でタグをつける方法

業務上、AWSのリソースタグに関した検討することが多く、注意すべきポイントが見えてきました。

今回は、ここでいったんこれまでに得られた知見をまとめてみて、AWSのサービスごとに参考資料となる記事にできればと思い書いてみます。

AWS Configにおける注意点

1. AWS Config Ruleの"required-tags"はすべてのリソースタイプに対応しているわけではない

組織としてAWS利用料の管理を行うために「必ず利用チームを区分できるタグがついていること」が求められる場合があります。
たとえば、

  • CostCenterBusinessUnitなどをつけて、コスト分配タグで発生した利用料をチームごとに分ける

などでしょうか。

そういった場合、AWS Config Ruleの"required-tags"ルールを使って「すべてのリソースにこのタグがついているか」をチェックし、必要なタグがついていないリソースを検出する体制が思い浮かぶことでしょう。

AWSリソースのタグ付けベストプラクティスにもその手法が紹介されています。


参考:Implementing and enforcing tagging - Best Practices for Tagging AWS Resources

しかし、ここで登場する"required-tags"はすべてのリソースタイプに対応しているわけではありません。

"required-tags"のドキュメントのページにある通り、対応しているリソースタイプは限られています。

参考:required-tags - AWS Config

AWS利用料の管理する上では大きなウエイトを占めることが多いであろう、EC2インスタンスやRDSインスタンス、S3バケットなどは対応していますが、対応していないリソースタイプについては別の方法でタグのチェックを行う必要があります。

2025年1月現在、対応しているリソースタイプは合計30種類となっており、そのため

  • AWS Config Ruleの"required-tags"を使ってもすべてのリソースで必要なタグがついているかのチェックはできない

ということに注意が必要です。

2. 修復アクション("AWS-SetRequiredTags")でタグをつけることができるリソースタイプは限られている

1.で述べたように、AWS Configの"required-tags"で検出できるリソースタイプは限られていますが、「その分だけでもいいから必要なタグを自動的につけるようにしたい」と思った時に検討されるのはAWS Configの修復アクション(remediation action)でしょう。

AWS Systems ManagerのAutomation Documentに「AWS-SetRequiredTags」というものがあります。

"required-tags"のAWS Config Ruleで非準拠を検出したときに、呼び出される修復アクションとしてこの「AWS-SetRequiredTags」を指定して、「検出」から「タグ付け」までを自動化できそうに思えます。すべてがマネージドに実現できてとても良さそうです。

フローとしては次の図のような具合でしょうか。

しかし、この組み合わせではタグ付けを行えるリソースタイプには限りがあります。

これは、AWS Config Ruleの"required-tags"で非準拠が検出されたのを起点に修復アクションを呼び出す際に引き渡される情報にはARNが含まれていないためです。(Resource IDが引き渡されるようになっている)

「AWS-SetRequiredTags」は引数としてARNを受け取る作りになっているため、"required-tags"起点で呼び出されてもタグ付けが行われません。

※このあたりは以前書いた記事に詳しく書いてありますので、こちらを参考にしてください。

以上を踏まえて、

  • "required-tags"を起点に"AWS-SetRequiredTags"を使ってタグ付けを行うことができるリソースタイプは限られている

ということに注意が必要です

AWS Security Hubにおける注意点

3. Security Hubの"Tagging Standard"はすべてのリソースタイプに対応しているわけではない

2024年の4月にAWS Security Hubにおいて、「AWSリソースのタグ付け標準」("Resource Tagging Standard")という標準がリリースされました。

参考:AWS Security Hub が AWS リソースのタグ付け標準を発表

この標準には、各AWSリソースにおいてタグキーがついているかをチェックするコントロールが含まれています。そして、パラメータを指定することで「指定のタグキーがついているか」の検査に使うことができます。

ただし、AWSのすべてのリソースタイプに対応しているわけではありません。

参考(Resource Tagging Standardが対応している検出項目):AWS Resource Tagging Standard - AWS Security Hub
(2025年1月現在、85種類)

そのためAWS Configと同様に

  • Security Hubの"Tagging Standard"を使ってもすべてのリソースで、必要なタグがついているかのチェックはできない

ということに注意が必要です

4. Security Hubの"Tagging Standard"はタグのValueを検査することができない

そして、さらに注意が必要なのは、Security Hubの"Tagging Standard"はタグのValueを検査することができないという点です。

ドキュメントには以下のように記載されています。

You can customize the requiredTagKeys parameter to specify specific tag keys that the controls check for. If specific tags aren't provided, the controls just check for the existence of at least one tag key.

AWS Resource Tagging Standard - AWS Security Hub

"requiredTagKeys"を指定することで、特定のタグキーがついているかを確認できる。とあります。
つまり、

  • AWS Configの"required-tags"のように複数のタグのキーと値(Value)を検査するものではない

ということに注意が必要です。

ちなみに、"requiredTagKeys"を指定するとそのタグキーの有無を確認しますが、その指定がないデフォルトの場合は「少なくとも1つのタグキーがついているか」を確認するという仕様になっています。
「最低限何かしらのタグはついているべきなのに、何もついていないリソースを検出する」という目的に使うことができるということです。

5. Security Hubの"Tagging Standard"の"requiredTagKeys"は一括設定できない。

上記の通り"Tagging Standard"を使って、特定のタグキー(たとえばCostCenterBusinessUnit)がついているかを確認できます。

具体的には次の画面のようにパラメータを指定することで設定できます。

しかし、このパラメータは一括設定ができません。

2025年1月時点では、"Tagging Standard"が対応している85の各リソースタイプに対して、タグキーを個別に指定する必要があります。

また、もし仮にも"Tagging Standard"が対応するリソースタイプが増えたときには、その分だけ設定を追加する必要があります。

そのため"Tagging Standard"のコントロールすべてに一様にパラメータを設定する仕組みを定期的に実行するなどの工夫が必要になることでしょう。

  • "Tagging Standard"のパラメータを一様に設定する仕組みを構築する必要がある

ということに注意が必要です。

Tag Editorにおける注意点

6. Tag Editorはすべてのリソースタイプに対応しているわけではない

手動であれ、自動であれ必要なタグをリソースにつけた後、そのタグ付け状況を見るときにTag Editorを使うことが多いでしょう。

参考:What is Tag Editor_ - Tagging AWS Resources and Tag Editor

しかし、これもすべてのリソースタイプに対応しているわけではありません。

対応リソースは以下のドキュメントに記載されています。

参考:Resource types you can use with AWS Resource Groups and Tag Editor - AWS Resource Groups

かなり多く列挙されている様子がありますが、それはつまりは

  • Tag Editorは「すべてのリソースタイプに対応している」というわけではない

ということに注意が必要です。

2025年1月時点で800種類以上のリソースタイプがAWS Resource GroupsとTag Editorに対応しており、さらにその中でもTag Editorでのタグ付け(Tag Editor Tagging)に対応しているリソースタイプはさらに限られていて、160種類ほどとなっています。

(※本当は「案外少ないぞ!」ということを表現したかったのですが、下記の通りドキュメントの更新履歴を見ると2024年12月にTag Editorの対応リソースが405種類追加になっていて、結構数増えてますね。。。ニーズに合わせて利用できると良いと思います。)

ChangeDescriptionDate
Support for new resource types405 more resource types are now supported by Resource Groups and Tag Editor.December 6, 2024
Tag Editorの対応リソースが増えたことを示すドキュメント更新履歴
AWS Resource Groups document history - AWS Resource Groups

7. Tag Editorはクロスアカウントでの利用ができない

Tag Editorはアカウント内のリソースのみが対象です。

6.に記載の通り直近のアップデートのおかげもあり、800種類以上のリソースタイプのリソースをTag Editorを通じて確認できます。

ただし、リソースタイプの他、リージョンもまたいで確認することができるのですが、開いているAWSアカウント内のみでの確認ができます。

そのため複数のAWSアカウント内でのリソース状況をTag Editorを使って確認しようとするときには都度都度AWSアカウントを切り替えながら確認していく必要があります。

Resource Explorerにおける注意点

8. Resource Explorerはすべてのリソースタイプに対応しているわけではない

横断的にAWSリソースの情報を確認するための仕組みとして、Resource Explorerが使えます。

参考:Resource Search – AWS Resource Explorer – Amazon Web Services

ですが、これもやはりすべてのリソースタイプに対応しているわけではありません。2025年1月現在370リソースタイプに対応していますが、それでもすべてのリソースタイプに対応しているわけではありません。

他のタグ関連のサービスと同様に

  • Resource Explorerは「すべてのリソースタイプに対応している」というわけではない

ということに注意が必要です。

参考:Resource types you can search for with Resource Explorer - AWS Resource Explorer

AWS Organization Tag Policiesにおける注意点

9. Tag Policiesはタグ付けを強制する仕組みではない

  • AWS OrganizationのTag Policiesは「このタグをつけなさい」という強制的なタグ付けを行う仕組みではない

ということに注意が必要です。

「このタグをつける時にはこの記法にしなさい」というタグ入力時のフォーマットを定める仕組みです。

参考:Tag policies - AWS Organizations

そのため、タグ自体をつけずにリソース作成すればチェックに引っかかりません。

もしくはスペルミスなどがあった際にもポリシーによる制御が働きません。

たとえば

  • Key:CostCenter
  • Value:<8桁の数字>

のようなポリシーを定めたとしても、"CostCenter"の表記を間違えて" CostCenter"と頭にスペースを入れてしまった場合にはポリシーに引っかかりません。
必ずすべてのリソースにCostCenterのタグがつけられることを期待して、タグポリシーを設定してもその期待通りの統制は取れないわけです。

ただし、Service Control Policies(SCP)をうまく活用することで、タグ付けを強制するような手法も下記のように紹介されており、検討の余地はあります。
AWS内で使える機能をうまく組み合わせながらタグ付けの統制を行うことが求められるでしょう。

参考:Example SCPs for tagging resources - AWS Organizations

Resource Groups Tagging APIにおける注意点

10. Resource Groups Tagging APIはリージョンをまたいでタグを付けることができない

AWSの各リソースにタグ付けを行う際に効果的に使えるのがResource Groups Tagging APIです。

参考:TagResources - Resource Groups Tagging API

このAPIを有効活用することで従来必要だった

  • EC2インスタンスにタグをつけたい時には、ec2:CreateTagsコマンドを呼び出す
  • RDSインスタンスにタグをつけたい時には、rds:AddTagsToResourceコマンドを呼び出す
  • S3バケットにタグをつけたい時には、s3:PutBucketTaggingコマンドを呼び出す
  • リソースタイプXXXにタグをつけたい時には、XXXにタグをつけられるコマンドを呼び出す...

のようにタグ付けを行いたいリソースの種類に応じたAPIを呼び出す手間を省くことができます。

しかし、このAPIを使ってタグ付けを行う際にはリージョンをまたいでタグを付けることができません。

You can only tag resources that are located in the specified AWS Region for the AWS account.

https://docs.aws.amazon.com/resourcegroupstagging/latest/APIReference/API_TagResources.html

異なるリージョン内のリソースを対象にタグ付けを行おうとするとエラーになります。Lambda Functionを使った例で、図に表すと次のようになります。

そのため、

  • Lambda Functionが実行されるリージョンとタグ付け対象が存在するリージョンが一致している時のみResource Groups Tagging APIを使う
  • 異なるリージョンにもタグ付け対象となるリソースが存在していることが明らかな時には、そのリージョンでもタグ付けを行えるようにする

などの工夫が必要になります。

まとめ

以上、私がAWSでのタグ付け関連の業務を通じて直面していた注意点をまとめてみました。

最後にまとめると次のようになります

ポイント
  • AWS Config Ruleの"required-tags"はすべてのリソースタイプに対応しているわけではない
    • AWS Config Ruleの"required-tags"は30種類のリソースタイプのみ対応
    • 対応していないリソースタイプには別の仕組みが必要
  • 修復アクション("AWS-SetRequiredTags")でタグをつけることができるリソースタイプは限られている
    • AWS Config Ruleの"required-tags"でタグがついていないことを検出してもARNの情報が取れない
    • 修復アクション"AWS-SetRequiredTags"はARNの情報が必要なので自動タグ付けできるものが限られる
  • Security Hubの"Tagging Standard"はすべてのリソースタイプに対応しているわけではない
    • AWS Security Hubの「AWSリソースのタグ付け標準」("Resource Tagging Standard)は85種類のリソースタイプのみ対応
    • 対応していないリソースタイプには別の仕組みが必要
  • Security Hubの"Tagging Standard"はタグのValueを検査することができない
    • AWS Security Hubの「AWSリソースのタグ付け標準」("Resource Tagging Standard)はタグの「キー」の有無を検出する仕組み。値(Value)は検査できない
    • カスタムパラメータを指定しないときは「1つでもタグがついているか」を検査する仕組みになる
  • Security Hubの"Tagging Standard"の"requiredTagKeys"は一括設定できない
    • AWS Security Hubの「AWSリソースのタグ付け標準」("Resource Tagging Standard)の全コントロールに一斉に同じパラメータを指定できる仕組みがないので、仕組みを作る必要がある
  • Tag Editorはすべてのリソースタイプに対応しているわけではない
    • Tag Editorはすべてのリソースタイプに対応しているわけではない
    • ただし、直近で対応リソースタイプが大幅に(405種類)増えている
  • Tag Editorはクロスアカウントでの利用ができない
  • Tag Policyはタグ付けを強制する仕組みではない
    • Tag Policiesはリソース作成時にタグ付けを強制する仕組みではなく、タグをつける際の値(Value)の記法を制約する仕組み
    • タグをそもそもつけない場合はポリシーの制約を受けない
    • タグをつける際にタグキーにスペルミスがあれば、ポリシーの制約を受けない
    • Service Control Policiesを活用したタグ付けを強制する仕組みの例がAWSから紹介されている
  • Resource Groups Tagging APIはリージョンをまたいでタグを付けることができない
    • Resource Groups Tagging APIを使えば、タグをつけるためにリソースタイプごとのAPIを呼び出す必要がなくなり便利
    • ただし、APIを呼び出したリージョンと異なるリージョンのリソースにタグ付けを行おうとするとエラーになる

あくまで私の業務上の体験に基づいていたため、網羅できていないポイントもあるかとは思いますが、それでもタグ付け関連の業務をする上で障壁となるであろうポイントをピックアップすることができたかと思います。

今後もこういったポイントは増えてきましたら、またアップデート版を出せればと思います。今回の記事がタグ付け管理の業務をする方々の助けになれば幸いです。

参考資料

AUTHOR
sho
sho
記事URLをコピーしました