手動管理のリソース Infrastructure as code (IaC) 管理リソース CI/CD パイプラインの管理リソース強制

タグ付けの実装と実施

このセクションでは、手動、Infrastructure as Code (IaC)、継続的インテグレーション/継続的デリバリー (CI/CD) といったリソース管理戦略に使用できるツールを紹介します。これらのアプローチの重要な側面は、デプロイ頻度がますます高まっていることです。

手動管理のリソース

これらは通常、導入の基盤段階または移行段階に分類されるワークロードです。多くの場合、これらは、従来の書面による手順を使用して構築された単純な主に静的なワークロードであるか、オンプレミス環境 AWS Application Migration Service からなどのツールを使用して として移行されたワークロードです。Migration Hub や Application Migration Service などの移行ツールは、移行プロセスの一部としてタグを適用できます。ただし、元の移行中にタグが適用されなかった場合、またはそれ以降タグ付けスキーマが変更された場合、タグエディタ ( の機能 AWS Management Console) を使用すると、さまざまな検索条件を使用してリソースを検索し、タグを一括で追加、変更、または削除できます。検索条件には、特定のタグや値の有無にかかわらず、リソースを含めることができます。Resource AWS Tagging API を使用すると、これらの関数をプログラムで実行できます。

これらのワークロードを最新化すると、Auto Scaling グループなどのリソースタイプが導入されます。これらのリソースタイプにより、柔軟性が高まり、レジリエンスが向上します。自動スケーリンググループはユーザーに代わって Amazon EC2 インスタンスを管理しますが、場合によっては、EC2 インスタンスに手動で作成したリソースで一貫したタグを付ける必要性が生ずる場合があります。Amazon EC2 起動テンプレートでは、自動スケーリングが作成するインスタンスに適用するタグを指定することができます。

ワークロードのリソースを手動で管理するときは、リソースのタグ付けを自動化すると便利です。さまざまなソリューションが利用できます。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 を設定する必要があります。また、Auto Scaling グループで EC2 起動テンプレートを使用している場合は、その定義でタグを定義できます。Auto Scaling グループまたは AWS コンテナサービスで EC2 起動テンプレートを使用することをお勧めします。これらのサービスは、Amazon EC2 インスタンスに一貫したタグ付けを行うのに役立ち、耐障害性を向上させ、コンピューティングコストを最適化する複数のインスタンスタイプと購入オプションにわたる自動スケーリングもサポートしています。

AWS CloudFormation フックを使用すると、開発者はアプリケーションの主要な側面を組織の標準と整合させることができます。フックは警告を出す設定や、デプロイを妨げたる設定が可能です。この機能は、Auto Scaling グループが、起動するすべての Amazon EC2 インスタンスに顧客定義タグを適用するように設定されているかどうか、またはすべての Amazon S3 バケットが必要な暗号化設定で作成されていることを確認するなど、テンプレート内の主要な設定要素を確認するのに最適です。どちらの場合も、このコンプライアンスの評価は、デプロイ前の AWS CloudFormation フックを使用してデプロイプロセスの前のにプッシュされます。

AWS CloudFormation は、テンプレートからプロビジョニングされたリソース (ドリフト検出をサポートするリソースを参照) が変更され、リソースが予想されるテンプレート設定と一致しなくなったことを検出する機能を提供します。これをドリフトと呼びます。IaC で管理されているリソースに自動化でタグを適用すると、タグを変更することになり、ドリフトが生じます。IaC を使用する場合、現在、IaC テンプレートの一部としてタグ付け要件を管理し、 AWS CloudFormation フックを実装し、オートメーションで使用できる Guard AWS CloudFormation ルールセットを発行することをお勧めします。

CI/CD パイプラインの管理リソース

ワークロードの成熟度が高まるにつれて、継続的インテグレーションや継続的デプロイ (CI/CD) などの手法が採用される可能性が高くなります。これらの手法では、テストの自動化が進み、小さな変更を頻繁にデプロイしやすくなるため、デプロイリスクの軽減に役立ちます。デプロイによって生じる予期しない動作を検出するオブザーバビリティ戦略があれば、ユーザーへの影響を最小限に抑えながらデプロイを自動的にロールバックできます。1 日に何十回もデプロイする段階になると、さかのぼってタグを適用することはもはや現実的ではなくなります。すべてをコードまたは構成として表現し、バージョン管理し、可能な場合は本番環境にデプロイする前にテストと評価を行う必要があります。複合開発運用（DevOps）モデルでは、多くのプラクティスでは運用上の配慮事項がコードとして扱われ、導入ライフサイクルの早い段階で検証されます。

理想的には、プロセスの早い段階でこれらのチェックをプッシュし ( AWS CloudFormation フックで表示）、開発者のマシンを離れる前に AWS CloudFormation テンプレートがポリシーを満たしていることを確信できるようにします。

AWS CloudFormation Guard 2.0 は、CloudFormation で定義できるすべてのものに対して予防的コンプライアンスルールを記述する手段を提供します。テンプレートは開発環境のルールに照らして検証されます。この機能にはさまざまな用途があることは明らかですが、このホワイトペーパーでは、AWS::AutoScaling::AutoScalingGroupTagProperty が常に使用される例をいくつか見ていきます。

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']
        <<Tag must have a permitted value
          Tag must have PropagateAtLaunch set to 'true'>>
    }
}

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-/
        <<Tag must have a permitted value
          Tag must have PropagateAtLaunch set to 'true'>>
    }
}

このコード例では、タイプ 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）、組織内のすべてのリンクされたアカウントのタグポリシーコンプライアンスを表示できます。

タグポリシーそのもの中では、特定のリソースタイプへの強制機能を有効にできます。以下のポリシー例では、ec2:instance タイプと ec2:volume タイプのすべてのリソースにポリシーの遵守を義務付ける強制機能を追加しました。タグポリシーでリソースを評価するにはそのリソースにタグが必要であるなど、いくつかの制限が知られています。リストについては、「タグポリシーの強制をサポートするリソース」を参照してください。

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」を参照）。タグ付けの場合は、required_tags ルールを使用して特定のキーを持つタグがないリソースの識別に使用できます (「required_tags がサポートするリソースタイプ」を参照してください)。前の例から、すべての 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 です。


{
  "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 イベントへの読み取り専用アクセス権限を提供すると、開発者がリソースを順守できない場合のデバッグ作業を支援できます。

ブラウザで JavaScript が無効になっているか、使用できません。

AWS ドキュメントを使用するには、JavaScript を有効にする必要があります。手順については、使用するブラウザのヘルプページを参照してください。

ドキュメントの表記規則

AWS Organizations – タグポリシー

タグ付けの有効性の評価と改善の推進