翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# タグ付けの実装と実施
このセクションでは、手動、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 イベントへの読み取り専用アクセス権限を提供すると、開発者がリソースを順守できない場合のデバッグ作業を支援できます。