翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# タグ付け戦略の構築
運用における多くのプラクティスと同様に、タグ付け戦略の実装は反復と改善のプロセスです**。当面の優先事項から小さく始めて、必要に応じてタグ付けスキーマを拡張します。
![\[タグ付け戦略の反復と改善のサイクルを表した図\]](http://docs.aws.amazon.com/ja_jp/whitepapers/latest/tagging-best-practices/images/tagging-strategy-cycle.png)
このプロセスを通じて、責任の所在が説明責任と進歩の鍵になります。タグはさまざまな目的に使用できるため、全体的なタグ付け戦略を組織内の各責任分野に分けることができます。タグ付けにより、リソースの特性に依存するアクティビティにプログラム的にアプローチできます。タグ付けによってメリットが得られる利害関係者の範囲は、組織の規模と運用方法によって異なります。大規模な組織では、タグ付け戦略の構築と実施に関わるチームの責任を明確に定義することでメリットが得られます。タグ付けのニーズの識別 (ユースケースの定義) を担当するステークホルダーもいれば、タグ付け戦略の維持、実装、改善を担当するステークホルダーもいます。
オーナーシップを割り当てることで、戦略の個々の側面が実施しやすくなります。必要に応じて、このオーナーシップをポリシーとして定式化し、責任マトリックス (RACI: 実行責任者、説明責任者、相談先、報告先) に文書化することも、責任分担モデルとして文書化することもできます。小規模な組織では、要件の定義から実装、適用まで、チームがタグ付け戦略において複数の役割を果たすことがあります。
# ニーズとユースケースの定義
まずは、メタデータを利用したいという根本的なニーズを持つ利害関係者に働きかけることから戦略の構築を始めましょう。これらのチームは、レポート、自動化、データ分類などのアクティビティをサポートするためにリソースにタグを付ける必要のあるメタデータを定義します。リソースをどのように整理し、どのポリシーにマッピングする必要があるかを概説します。これらの利害関係者が組織内で果たすことができる役割と機能の例には次のようなものがあります。
+ **財務部門**や**事業部門**は、投資の価値をコストと照らし合わせて把握し、非効率な状況に対処する際に取るべきアクションの優先順位を決めます。コストと生み出される価値**を理解すると、うまくいっていない事業部門や製品提供を見極めることができます。その結果、サポートの継続、代替案の採用（SaaSオファリングやマネージドサービスの使用など）、または不採算のビジネスオファリングの廃止について、根拠のある決定を下すことができます。
+ **ガバナンス**と**コンプライアンス**では、データの分類（公開、機密、極秘など）、特定のワークロードが特定の標準や規制に対する監査の対象となるかどうか、および権限、ポリシー、監視などの適切な制御と監視を適用するためのサービスの重要性（サービスまたはアプリケーションがビジネスに不可欠なかどうか）を理解する必要があります。
+ **運用部門**と**開発部門**は、ワークロードのライフサイクル、サポート対象製品の実装段階、リリース段階 (開発、テスト、本番など) の管理、および関連するサポートの優先順位付けと利害関係者の管理要件を理解する必要があります。バックアップ、パッチ適用、オブザーバビリティ、非推奨などの義務も定義し、理解する必要があります。
+ **情報セキュリティ (InfoSec)**と**セキュリティオペレーション (SecOps)**は、適用すべき統制と推奨する統制の概要をまとめます。通常、InfoSec は統制の実装を定義し、それらの統制の管理は一般的に SecOps が担当します。
ユースケース、優先順位、組織の規模、運用方法によっては、財務 (調達を含む)、情報セキュリティ、クラウド支援、クラウド運用など、組織内のさまざまなチームの代表者が必要になる場合があります。また、パッチ適用、バックアップと復元、監視、ジョブスケジューリング、ディザスタリカバリなどの機能については、アプリケーションオーナーやプロセスオーナーの代表者も必要です。これらの担当者は、タグ付け戦略の定義、実装、効果の評価に関わります。その場合、利害関係者やそのユースケースから[https://www.youtube.com/watch?v=aFdpBqmDpzM](https://www.youtube.com/watch?v=aFdpBqmDpzM)、部門横断的なワークショップを実施する必要があります。ワークショップでは、各自の視点やニーズを共有して、全体的な戦略を推し進めます。参加者の例とさまざまなユースケースへの関わり方については、このホワイトペーパーの後半で説明します。
また、利害関係者は必須タグのキーを定義して検証します。オプションタグの範囲を推奨することもできます。例えば、財務チームでは、社内のコストセンター、事業単位、あるいはその両方にリソースを関連付ける必要があるかもしれません。そのため `CostCenter` や `BusinessUnit` などの特定のタグキーを必須にする必要があるかもしれません。個々の開発チームが、`EnvironmentName` や `OptIn`、`OptOut` などの追加のタグを自動化目的で使用することを決定する場合があります。
主要利害関係者は、タグ付け戦略のアプローチについて合意し、次のようなコンプライアンスやガバナンス関連の質問に対する回答を文書化する必要があります。
+ 取り組む必要があるユースケースは何か？
+ リソースのタグ付け (実装) の責任者は誰か？
+ タグはどのように適用され、どのような方法や自動化が使用されるのか (事前対応的か事後対応的か)？
+ タグ付けの効果と目標はどのように測定されるのか？
+ タグ付け戦略はどのくらいの頻度で見直すべきか？
+ 誰が改善を推し進めるのか？ 改善はどのように行われるのか？
Cloud Enablement、Cloud Business Office、Cloud Platform Engineering などのビジネス部門が、進捗状況を測定し、障害を取り除き、重複する作業を減らすことで、タグ付け戦略の構築プロセスのファシリテーターの役割を果たし、タグ付け戦略の採用を促進し、適用の一貫性を確保することができます。
# タグ付けスキーマの定義と公開
必須タグとオプションタグの両方について、 AWS リソースのタグ付けに一貫したアプローチを採用します。包括的なタグ付けスキーマは、この一貫性を実現するのに役立ちます。始めるにあたって次の例を参照してお役立てください。
+ 必須のタグキーについて合意する
+ 使用できる値とタグ命名規則 (大文字または小文字、ダッシュまたはアンダースコア、階層など) を定義する
+ 値が個人を特定できる情報 (PII) を構成しないことを確認する
+ 新しいタグキーを定義して作成できる担当者を決める
+ 新しい必須タグ値を追加する方法とオプションタグを管理する方法について合意する
以下の[タグ付けカテゴリ](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html)の表を見てください。この表は、タグ付けスキーマに含める内容のベースラインとして使用できます。さらに、タグキーに使用する規則と、それぞれで使用できる値を決定する必要があります。タグ付けスキーマは、使用環境に合わせてそれらを定義する文書です。
*表 6 — 最終的なタグ付けスキーマの例*
| ユースケース | タグキー | 根拠 | 使用できる値 (リストまたは値プレフィックス/サフィックス) | コスト配分に使用 | リソースタイプ | スコープ | 必須 |
| --- | --- | --- | --- | --- | --- | --- | --- |
| コスト配分 | example-inc:cost-allocation:ApplicationId | 事業部門ごとの発生コストと生成価値を対比して追跡する | DataLakeX, RetailSiteX | はい | すべて | すべて | 必須 |
| コスト配分 | example-inc:cost-allocation:BusinessUnitId | ビジネスユニットごとにコストを監視する | Architecture, DevOps, Finance | はい | すべて | すべて | 必須 |
| コスト配分 | example-inc:cost-allocation:CostCenter | コストセンターごとにコストを監視する | 123-\$1 | はい | すべて | すべて | 必須 |
| コスト配分 | example-inc:cost-allocation:Owner | このワークロードに責任があるのはどの予算担当か | Marketing, RetailSupport | はい | すべて | すべて | 必須 |
| アクセスコントロール | example-inc:access-control:LayerId | 役割に基づいてリソースへのアクセスを許可するサブコンポーネント/レイヤーを特定する | DB\$1Layer, Web\$1Layer, App\$1Layer | いいえ | すべて | すべて | オプションです。 |
| Automation | example-inc:automation:EnvironmentId | テスト環境と開発環境 (別名ソフトウェア開発ライフサイクル (SDLC) ステージ) のスケジューリングを実装する | Prod, Dev, Test, Sandbox | いいえ | EC2、RDS、EBS | すべて | 必須 |
| DevOps | example-inc:operations:Owner | リソースの作成とメンテナンスを担当するのはどのチーム/グループか | Squad01 | いいえ | すべて | すべて | 必須 |
| ディザスタリカバリ | example-inc:disaster-recovery:rpo | リソースに対する目標復旧時点 (RPO) を定義する | 6h, 24h | いいえ | S3、EBS | Prod | 必須 |
| データ分類 | example-inc:data:classification | コンプライアンスとガバナンスのためにデータを分類する | Public, Private, Confidential, Restricted | いいえ | S3、EBS | すべて | 必須 |
| コンプライアンス | example-inc:compliance:framework | ワークロードが適用されるコンプライアンスフレームワークを特定する | PCI-DSS, HIPAA | いいえ | すべて | Prod | 必須 |
タグ付けスキーマを定義したら、そのスキーマを関連するすべての利害関係者がアクセスして簡単に参照して、更新を追跡できようにバージョン管理されたリポジトリで管理します。このアプローチで効率が向上し、アジリティが高まります。
# AWS Organizations – タグポリシー
のポリシー AWS Organizations を使用すると、組織内の に追加 AWS アカウント タイプのガバナンスを適用できます。[https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_tag-policies.html](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_tag-policies.html)は、タグ付けスキーマを JSON 形式で表現して、プラットフォームが AWS 環境内でスキーマをレポートし、オプションで適用できるようにする方法です。タグポリシーでは、特定のリソースタイプのタグキーに使用できる値を定義します。このポリシーは、値のリストでも、プレフィックスにワイルドカード文字 (`*`) が続く形式でもかまいません。単純なプレフィックス方式は、個別値のリストほど厳密ではありませんが、メンテナンスは少なくて済みます。
以下の例は、タグ付けポリシーを定義して特定のキーに許容される値を検証する方法を示したものです。わかりやすい表形式のスキーマの定義に基づいて、この情報を 1 つ以上のタグポリシーに転記できます。所有権の委任をサポートするために個別のポリシーを使用することもでき、また特定のシナリオにのみ適用されるポリシーもあります。
## ExampleInc-CostAllocation.json
次に、コスト配分タグのレポートを行うタグポリシーの例を示します。
```
{
"tags": {
"example-inc:cost-allocation:ApplicationId": {
"tag_key": {
"@@assign": "example-inc:cost-allocation:ApplicationId"
},
"tag_value": {
"@@assign": [
"DataLakeX",
"RetailSiteX"
]
}
},
"example-inc:cost-allocation:BusinessUnitId": {
"tag_key": {
"@@assign": "example-inc:cost-allocation:BusinessUnitId"
},
"tag_value": {
"@@assign": [
"Architecture",
"DevOps",
"FinanceDataLakeX"
]
}
},
"example-inc:cost-allocation:CostCenter": {
"tag_key": {
"@@assign": "example-inc:cost-allocation:CostCenter"
},
"tag_value": {
"@@assign": [
"123-*"
]
}
}
}
}
```
## ExampleInc-DisasterRecovery.json
次に、ディザスタリカバリのレポートを行うタグポリシーの例を示します。
```
{
"tags": {
"example-inc:disaster-recovery:rpo": {
"tag_key": {
"@@assign": "example-inc:disaster-recovery:rpo"
},
"tag_value": {
"@@assign": [
"6h",
"24h"
]
}
}
}
}
```
この例では、`ExampleInc-CostAllocation` タグポリシーは `Workloads` OU にアタッチされているため、その `Prod` と子 OU `Test` の両方のすべてのアカウントに適用されます。同様に、`ExampleInc-DisasterRecovery` タグポリシーは `Prod` OU にアタッチされているため、この OU の下位のアカウントにのみ適用されます。『[複数のアカウントによる環境の整理](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/organizing-your-aws-environment.html)』ホワイトペーパーでは、推奨される OU 構造について詳しく説明しています。
![\[OU 構造へのタグポリシーのアタッチと有効なポリシーを示す図\]](http://docs.aws.amazon.com/ja_jp/whitepapers/latest/tagging-best-practices/images/adding-tagging-to-policies-in-ou-structure.png)
図の `marketing-prod` アカウントを見ると、両方のタグポリシーがこのアカウントに適用されるため、*効果的なポリシー*を考えました。それは、1 つのアカウントに適用される所定のタイプのポリシーのコンボリューションです。リソースを主に手動で管理している場合は、コンソールの [Resource Groups & Tag Editor: タグポリシー](https://console.aws.amazon.com/resource-groups/tag-policies) にアクセスして有効なポリシーを確認できます。Infrastructure as Code (IaC) またはスクリプトでリソースを管理している場合は、[https://docs.aws.amazon.com/organizations/latest/APIReference/API_DescribeEffectivePolicy.html](https://docs.aws.amazon.com/organizations/latest/APIReference/API_DescribeEffectivePolicy.html) API 呼び出しを使用できます。
# タグ付けの実装と実施
このセクションでは、手動、Infrastructure as Code (IaC)、継続的インテグレーション/継続的デリバリー (CI/CD) といったリソース管理戦略に使用できるツールを紹介します。これらのアプローチの重要な側面は、デプロイ頻度がますます高まっていることです。
## 手動管理のリソース
これらは通常、[導入の基盤段階または移行段階に分類されるワークロードです](https://docs.aws.amazon.com/prescriptive-guidance/latest/migration-program-implementation/reviewing-frameworks.html)。多くの場合、これらは、従来の書面による手順を使用して構築された単純な主に静的なワークロードであるか、オンプレミス環境 AWS Application Migration Service から などのツールを使用して *として*移行されたワークロードです。Migration Hub や Application Migration Service などの移行ツールは、移行プロセスの一部としてタグを適用できます。ただし、元の移行中にタグが適用されなかった場合、またはそれ以降タグ付けスキーマが変更された場合、[タグエディタ](https://docs.aws.amazon.com/ARG/latest/userguide/tag-editor.html) ( の機能 AWS マネジメントコンソール) を使用すると、さまざまな検索条件を使用してリソースを検索し、タグを一括で追加、変更、または削除できます。検索条件には、特定のタグや値の有無にかかわらず、リソースを含めることができます。 AWS Resource Tagging API を使用すると、これらの関数をプログラムで実行できます。
これらのワークロードを最新化すると、Auto Scaling グループなどのリソースタイプが導入されます。これらのリソースタイプにより、柔軟性が高まり、レジリエンスが向上します。自動スケーリンググループはユーザーに代わって Amazon EC2 インスタンスを管理しますが、場合によっては、EC2 インスタンスに手動で作成したリソースで一貫したタグを付ける必要性が生ずる場合があります。[https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-launch-templates.html](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-launch-templates.html)では、自動スケーリングが作成するインスタンスに適用するタグを指定することができます。
ワークロードのリソースを手動で管理するときは、リソースのタグ付けを自動化すると便利です。さまざまなソリューションが利用できます。1 つのアプローチは を使用することです。これにより AWS Config ルール、Lambda 関数を確認して開始`required_tags`し、適用できます。 AWS Config ルール 詳細については、このホワイトペーパーの後半で説明します。
## Infrastructure as code (IaC) 管理リソース
AWS CloudFormation は、 AWS 環境内のすべてのインフラストラクチャリソースをプロビジョニングするための共通言語を提供します。CloudFormation テンプレートは、 AWS リソースを自動的に作成する JSON ファイルまたは YAML ファイルです。CloudFormation テンプレートを使用して AWS リソースを作成する場合、CloudFormation Resource Tags プロパティを使用して、作成時にサポートされているリソースタイプにタグを適用できます。IaC でタグとリソースを管理すると、一貫性が保たれます。
リソースが によって作成されると AWS CloudFormation、サービスは AWS CloudFormation テンプレートによって作成されたリソースに AWS 定義されたタグのセットを自動的に適用します。次のようなものがあります。
```
aws:cloudformation:stack-name
aws:cloudformation:stack-id
aws:cloudformation:logical-id
```
AWS CloudFormation スタックに基づいてリソースグループを簡単に定義できます。これらの AWS 定義済みタグは、スタックで作成されたリソースに継承されます。ただし、Auto Scaling グループ内の Amazon EC2 インスタンスの場合、 AWS CloudFormation テンプレートの Auto Scaling グループの定義で [`AWS::AutoScaling::AutoScalingGroup` TagProperty](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-as-tags.html) を設定する必要があります。また、Auto Scaling グループで [EC2 起動テンプレート](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-ec2-launchtemplate.html) を使用している場合は、その定義でタグを定義できます。Auto Scaling グループまたは AWS コンテナサービスで [EC2 起動テンプレート](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-ec2-launchtemplate.html)を使用することをお勧めします。これらのサービスは、Amazon EC2 インスタンスに一貫したタグ付けを行うのに役立ち、耐障害性を向上させ、コンピューティングコストを最適化する[複数のインスタンスタイプと購入オプションにわたる自動スケーリング](https://aws.amazon.com/blogs/aws/new-ec2-auto-scaling-groups-with-multiple-instance-types-purchase-options/) もサポートしています。
[AWS CloudFormation フック](https://aws.amazon.com/blogs/mt/proactively-keep-resources-secure-and-compliant-with-aws-cloudformation-hooks/)を使用すると、開発者はアプリケーションの主要な側面を組織の標準と整合させることができます。フックは*警告*を出す設定や、*デプロイを妨げたる*設定が可能です。この機能は、起動するすべての Amazon EC2 インスタンスにカスタマー定義タグを適用するように Auto Scaling グループが設定されているかどうか、またはすべての Amazon S3 バケットが必要な暗号化設定で作成されていることを確認するなど、テンプレートの主要な設定要素を確認するのに最適です。どちらの場合も、このコンプライアンスの評価は、デプロイ前の AWS CloudFormation フックを使用してデプロイプロセスの前の にプッシュされます。
AWS CloudFormation は、テンプレートからプロビジョニングされたリソース ([ドリフト検出をサポートするリソースを参照](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/resource-import-supported-resources.html)) が変更され、リソースが予想されるテンプレート設定と一致しなくなったことを検出する機能を提供します。これを*ドリフト*と呼びます。IaC で管理されているリソースに自動化でタグを適用すると、タグを変更することになり、ドリフトが生じます。IaC を使用する場合、現在、IaC テンプレートの一部としてタグ付け要件を管理し、 AWS CloudFormation フックを実装し、オートメーションで使用できる Guard AWS CloudFormation ルールセットを発行することをお勧めします。
## CI/CD パイプラインの管理リソース
ワークロードの成熟度が高まるにつれて、継続的インテグレーションや継続的デプロイ (CI/CD) などの手法が採用される可能性が高くなります。これらの手法では、テストの自動化が進み、小さな変更を頻繁にデプロイしやすくなるため、デプロイリスクの軽減に役立ちます。デプロイによって生じる予期しない動作を検出するオブザーバビリティ戦略があれば、ユーザーへの影響を最小限に抑えながらデプロイを自動的にロールバックできます。1 日に何十回もデプロイする段階になると、さかのぼってタグを適用することはもはや現実的ではなくなります。すべてをコードまたは構成として表現し、バージョン管理し、可能な場合は本番環境にデプロイする前にテストと評価を行う必要があります。複合[開発運用（DevOps）モデル](https://aws.amazon.com/devops/what-is-devops/)では、多くのプラクティスでは運用上の配慮事項がコードとして扱われ、導入ライフサイクルの早い段階で検証されます。
理想的には、プロセスの早い段階で ( AWS CloudFormation フックで示されているように) これらのチェックをプッシュし、開発者のマシンを離れる前に AWS CloudFormation テンプレートがポリシーを満たしていることを確信できるようにします。
[AWS CloudFormation Guard 2.0](https://aws.amazon.com/blogs/mt/introducing-aws-cloudformation-guard-2-0/) は、CloudFormation で定義できるすべてのものに対して予防的コンプライアンスルールを記述する手段を提供します。テンプレートは開発環境のルールに照らして検証されます。この機能にはさまざまな用途があることは明らかですが、このホワイトペーパーでは、[`AWS::AutoScaling::AutoScalingGroup`TagProperty](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-as-tags.html) が常に使用される例をいくつか見ていきます。
CloudFormation ガードルールの例を次に示します。
```
let all_asgs = Resources.*[ Type == 'AWS::AutoScaling::AutoScalingGroup' ]
rule tags_asg_automation_EnvironmentId when %all_asgs !empty {
let required_tags = %all_asgs.Properties.Tags.*[
Key == 'example-inc:automation:EnvironmentId' ]
%required_tags[*] {
PropagateAtLaunch == 'true'
Value IN ['Prod', 'Dev', 'Test', 'Sandbox']
<>
}
}
rule tags_asg_costAllocation_CostCenter when %all_asgs !empty {
let required_tags = %all_asgs.Properties.Tags.*[
Key == 'example-inc:cost-allocation:CostCenter' ]
%required_tags[*] {
PropagateAtLaunch == 'true'
Value == /^123-/
<>
}
}
```
このコード例では、タイプ `AutoScalingGroup` のすべてのリソースについてテンプレートをフィルタリングし、2 つのルールを設定しています。
+ **`tags_asg_automation_EnvironmentId`** -このキーを持つタグが存在し、使用できる値リスト内の値があり、`PropagateAtLaunch` が次 `true` に設定されていることを確認します。
+ **`tags_asg_costAllocation_CostCenter`** -このキーを持つタグが存在し、定義したプレフィックス値で始まる値を持ち、`PropagateAtLaunch` が `true` に設定されていることを確認します
## 強制
前述のように、**Resource Groups & Tag Editor** では、組織の OU に適用されるタグポリシーで定義されたタグ付け要件をリソースが満たしていない場所を識別することができます。組織のメンバーアカウント内から **Resource Groups & Tag Editor** コンソールツールにアクセスすると、そのアカウントに適用されるポリシーと、アカウント内でタグポリシーの要件を満たしていないリソースが表示されます。管理アカウントからアクセスする場合 (および**タグポリシー**で のサービスで*アクセスが有効になってい*る場合 AWS Organizations)、[組織内のすべてのリンクされたアカウントのタグポリシーコンプライアンス](https://docs.aws.amazon.com/ARG/latest/userguide/tag-policies-orgs-evaluating-org-wide-compliance.html)を表示できます。
タグポリシーそのもの中では、特定のリソースタイプへの強制機能を有効にできます。以下のポリシー例では、`ec2:instance` タイプと `ec2:volume` タイプのすべてのリソースにポリシーの遵守を義務付ける強制機能を追加しました。タグポリシーでリソースを評価するにはそのリソースにタグが必要であるなど、いくつかの制限が知られています。リストについては、「[タグポリシーの強制をサポートするリソース](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_supported-resources-enforcement.html)」を参照してください。
### ExampleInc-Cost-Allocation.json
次に、コスト配分タグのレポートを行うタグポリシーと強制するタグポリシーの両方またはいずれかの例を示します。
```
{
"tags": {
"example-inc:cost-allocation:ApplicationId": {
"tag_key": {
"@@assign": "example-inc:cost-allocation:ApplicationId"
},
"tag_value": {
"@@assign": [
"DataLakeX",
"RetailSiteX"
]
},
"enforced_for": {
"@@assign": [
"ec2:instance",
"ec2:volume"
]
}
},
"example-inc:cost-allocation:BusinessUnitId": {
"tag_key": {
"@@assign": "example-inc:cost-allocation:BusinessUnitId"
},
"tag_value": {
"@@assign": [
"Architecture",
"DevOps",
"FinanceDataLakeX"
]
},
"enforced_for": {
"@@assign": [
"ec2:instance",
"ec2:volume"
]
}
},
"example-inc:cost-allocation:CostCenter": {
"tag_key": {
"@@assign": "example-inc:cost-allocation:CostCenter"
},
"tag_value": {
"@@assign": [
"123-*"
]
},
"enforced_for": {
"@@assign": [
"ec2:instance",
"ec2:volume"
]
}
}
}
}
```
**AWS Config (`required_tag`)**
AWS Config は、 AWS リソースの設定を評価、監査、評価できるサービスです ( [でサポートされているリソースタイプ AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/resource-config-reference.html)を参照）。タグ付けの場合は、`required_tags` ルールを使用して特定のキーを持つタグがないリソースの識別に使用できます (「[required\$1tags がサポートするリソースタイプ](https://docs.aws.amazon.com/config/latest/developerguide/required-tags.html)」を参照してください)。前の例から、すべての Amazon EC2 インスタンスにキーが存在するかどうかをテストできます。キーが存在しない場合、インスタンスは非準拠として登録されます。この AWS CloudFormation テンプレートでは、テーブル、Amazon S3 バケット、Amazon EC2 インスタンス、Amazon EBS ボリュームで記述されている必須キーの存在をテストする AWS Config ルールについて説明します。
```
Resources:
MandatoryTags:
Type: AWS::Config::ConfigRule
Properties:
ConfigRuleName: ExampleIncMandatoryTags
Description: These tags should be in place
InputParameters:
tag1Key: example-inc:cost-allocation:ApplicationId
tag2Key: example-inc:cost-allocation:BusinessUnitId
tag3Key: example-inc:cost-allocation:CostCenter
tag4Key: example-inc:automation:EnvironmentId
Scope:
ComplianceResourceTypes:
- "AWS::S3::Bucket"
- "AWS::EC2::Instance"
- "AWS::EC2::Volume"
Source:
Owner: AWS
SourceIdentifier: REQUIRED_TAGS
```
リソースを手動で管理している環境では、 AWS Lambda 関数を介した自動修復を使用して、欠落しているタグキーをリソースに自動的に追加するように AWS Config ルールを強化できます。これは静的なワークロードではうまく機能しますが、IaC やデプロイパイプラインを介してリソースを管理し始めると、次第に効果が低下します。
**AWS Organizations – サービスコントロールポリシー (SCPs**は、組織内のアクセス許可を管理するために使用できる組織ポリシーの一種です。SCP では、組織または組織単位 (OU) のすべてのアカウントで使用可能な最大権限を一元的に制御できます。SCP は、組織の一部であるアカウントが管理するユーザーとロールのみに反映されます。リソースには直接反映されませんが、アクションにタグを付ける権限を含め、ユーザーとロールの権限が制限されます。タグ付けに関しては、SCP はどのようなタグポリシーを提供できるかという機能に加えて、さらにきめ細かいタグ適用を行うことができます。
次の例では、`example-inc:cost-allocation:CostCenter` タグが存在しない `ec2:RunInstances` リクエストはポリシーによって拒否されます。
以下は拒否 SCP です。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "DenyRunInstanceWithNoCostCenterTag",
"Effect": "Deny",
"Action": "ec2:RunInstances",
"Resource": [
"arn:aws:ec2:*:*:instance/*"
],
"Condition": {
"Null": {
"aws:RequestTag/example-inc:cost-allocation:CostCenter": "true"
}
}
}
]
}
```
------
設計上、連結アカウントに適用される有効なサービスコントロールポリシーを取得することは不可能です。SCP でタグ付けを強制する場合、開発者が自分のアカウントに適用されているポリシーにリソースを適合させられるように、開発者がドキュメントを入手できる環境を整える必要があります。アカウント内の CloudTrail イベントへの読み取り専用アクセス権限を提供すると、開発者がリソースを順守できない場合のデバッグ作業を支援できます。
# タグ付けの有効性の評価と改善の推進
タグ付け戦略を実装したら、対象となるユースケースに対してその効果を評価することが重要です。効果の尺度はユースケースによって異なります。例えば、次のようになります。
+ **コスト属性**-[AWS Cost Explorer](https://aws.amazon.com/aws-cost-management/aws-cost-explorer/) または [AWS コストと使用状況レポート](https://aws.amazon.com/aws-cost-management/aws-cost-and-usage-reporting/)などのツールを使用すると、支出に基づいてリソースのタグ付け範囲を評価できます。例えば、主に、特定のタグキーを監視して、*タグ付けされたリソースとタグ付けされていないリソース*で、料金が発生しているリソースの割合を追跡できます。
+ **自動化** - 予想したした結果が得られたかどうかを確認したい場合もあります。例えば、本番環境以外の Amazon EC2 インスタンスが営業時間外に停止されているかどうかを確認するには、インスタンスの起動時間と停止時間を監査します。
管理アカウント内の[Resource Groups & Tag Editor](https://docs.aws.amazon.com/ARG/latest/userguide/resource-groups.html) には、組織内のすべての連結アカウントのタグポリシーコンプライアンスを分析する追加機能があります。
タグ付けの有効性を測定した結果に基づいて、ユースケース定義、タグ付けスキーマの実装や強制などのステップで改善や変更が必要かどうかを確認します。必要な変更を加え、望ましい効果が得られるまでこのサイクルを繰り返します。コスト属性を使った例では、改善率を確認できます。
リソースに実際にタグを付ける必要があるのは開発者と運用者なので、彼らに所有権を与えることが重要です。これは、チームが AWS 導入の過程で通常引き受ける唯一の追加責任ではありません。アプリケーションの開発と運用のセキュリティとコストに対する責任の増加も重要です。組織では、新しいプラクティス採用の動機付けの手段として目標やターゲットが使用されることが多いので、ここでも同じことが言えます。