翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# タグ付けのユースケース
**Topics**
+ [コスト配分と財務管理のタグ](tags-for-cost-allocation-and-financial-management.md)
+ [運用とサポート用のタグ](tags-for-operations-and-support.md)
+ [データセキュリティ、リスク管理、アクセス制御用のタグ](tags-for-data-security-risk-management-and-access-control.md)
# コスト配分と財務管理のタグ
組織が最初に取り組むタグ付けのユースケースの 1 つは、コストと使用量の可視化と管理です。これには通常、次のようないくつかの理由があります。
+ **一般に、このシナリオは誰もが理解していることであり、要件は明らかです。**たとえば、財務チームのニーズは、複数のサービス、機能、アカウント、またはチームにまたがるワークロードとインフラストラクチャの総コストを確認することです。このようなコストの可視化を実現する 1 つの方法として、リソースに一貫したタグ付けをします。
+ **タグとその値は明確に定義されています。**通常、コスト配分メカニズムは、コストセンター、事業単位、チーム、または組織機能ごとの追跡など、組織の財務システムに既にあるメカニズムです。
+ **迅速で実証可能な投資収益率。**例えば、適切なサイズに設定されたリソース、自動スケーリングされたリソース、スケジュール設定されたリソースなど、リソースに一貫したタグが付けられていると、コスト最適化の傾向を経時的に追跡できます。
でコストが発生する方法を理解すること AWS で、情報に基づいた財務上の意思決定を行うことができます。リソース、ワークロード、チーム、または組織レベルでコストが発生した場所がわかれば、達成したビジネス成果と比較して、該当するレベルでもたらされる価値をより深く理解できます。
エンジニアリングチームには、リソースの財務管理の経験がない場合もあります。財務管理の専門知識を持ち、 AWS 財務 AWS 管理の基本についてエンジニアリングチームと開発チームをトレーニングし、財務とエンジニアリングの関係を構築して FinOps の文化を育むことができる人材をアタッチすると、ビジネスにとって測定可能な成果を達成し、チームがコストを念頭に置いて構築することを促すことができます。優れた財務慣行の確立については、Well-Architected フレームワークの「[コスト最適化の柱」](https://docs.aws.amazon.com/wellarchitected/latest/cost-optimization-pillar/welcome.html)で詳しく説明していますが、このホワイトペーパーではいくつかの基本原則に触れます。
# コスト配分タグ
コスト配分とは、発生したコストを、定められたプロセスを経て、そのコストの利用者または受益者に割り当て、あるいは配分することです。このホワイトペーパーでは、コスト配分を*ショーバック*と*チャージバック*の 2 種類に分けています。
*ショーバック*ツールとメカニズムは、コスト意識の向上に便利です。*チャージバック*はコスト回収に役立ち、コスト意識の向上に便利です。*ショーバック*とは、ビジネスユニット、アプリケーション、ユーザー、コストセンターなど、特定のエンティティが負担する料金の表示、計算、レポートに関する概念です。例:「インフラストラクチャエンジニアリングチームは先月 AWS を X ドル使用しました」。*チャージバック*とは、財務システムや仕訳伝票などの組織の内部会計プロセスを通じて、発生した費用をそれらの事業体に実際に請求することです。例：「X USD はインフラストラクチャエンジニアリングチームの AWS 予算から差し引かれました」。いずれの場合も、リソースに適切にタグを付けると、エンティティへのコスト配分に便利です。唯一の違いは、誰かが支払いを求められるかどうかです。
組織の財務ガバナンスでは、アプリケーション、ビジネスユニット、コストセンター、チームレベルで発生するコストの透明性の高い会計処理が求められる場合があります。[コスト配分タグ](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/cost-alloc-tags.html)でサポートされているコスト属性を実行すると、適切にタグ付けされたリソースに対してエンティティが発生させたコストを正確に関連付けるために必要なデータが得られます。
+ **説明責任** - コストは必ずリソース使用量の責任者に配分してください。支出のレビューや報告の責任を負うことができるのは 1 つのサービス拠点またはグループです。
+ **財務の透明性** - 経営陣向けの効果的なダッシュボードと有意義なコスト分析の作成によって、IT 部門に対する資金配分を明確に把握できます。
+ **情報に基づいた IT 投資** - 目的は、プロジェクト、アプリケーション、または事業分野に基づいて ROI を追跡し、チームがより良いビジネス上の意思決定を行うことです。例えば、収益を生み出すアプリケーションにより多くの資金を割り当てるといったことが可能です。
以上のことから、コスト配分タグは次の事項の把握に便利です。
+ 支出の所有者と最適化の責任者は誰か？
+ 支出の原因になっているワークロード、アプリケーション、または製品は何か? どの環境またはステージか?
+ 最も急速に増加しているのはどの支出分野か?
+ 過去の傾向に基づいて AWS 予算からいくらの支出を差し引くことができますか?
+ 特定のワークロード、アプリケーション、または製品におけるコスト最適化の取り組みにはどのような影響があったか?
コスト配分のためのリソースタグをアクティブ化すると、支出の説明責任の透明性を高める AWS 使用状況の可視性を提供するために使用できる、組織内の測定プラクティスの定義に役立ちます。それによって、コストと使用状況の可視性が適切なレベルで細分化され、コスト配分レポートや KPI 追跡を通じてクラウドの利用行動に影響を与えることもできます。
# コスト配分戦略の構築
## コスト配分モデルの定義と実装
デプロイ先のリソースのアカウントとコスト構造を作成します AWS。 AWS 支出によるコスト、それらのコストがどのように発生したか、それらのコストを誰が、何を発生したかの関係を確立します。一般的なコスト構造は AWS Organizations AWS アカウント、基幹業務やワークロードなど、組織内の環境とエンティティに基づいています。したがって、個々のワークロードのコストをその対象となる事業部門に積み上げるなど、コストはさまざまな方法や詳細レベルで調べることができます。
想定した結果に合致するコスト構造を選択するときは、*実装のしやすさ*と*望ましい精度*を対比しながらコスト配分メカニズムを評価してください。これには、説明責任、ツールの利用可能性、文化の変化に関する考慮事項が関係する場合があります。 AWS 顧客が通常開始する 3 つの一般的なコスト配分モデルは次のとおりです。
+ **アカウントベース** — このモデルは、最小限の労力で、ショーバックとチャージバックに高い精度を提供し、アカウント構造が定義されている組織に適しています ([複数アカウントを使用した AWS 環境の整理](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/organizing-your-aws-environment.html)に関するホワイトペーパーの推奨事項に準拠しています）。これにより、アカウント毎のコストが明確に可視化されます。コストの可視化と配分については[AWS Cost Explorer](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/ce-what-is.html)、[Cost and Usage Reports](https://docs.aws.amazon.com/cur/latest/userguide/what-is-cur.html) だけでなく、[AWS Budgets](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/budgets-managing-costs.html) でコストの監視と追跡を行うことができます。これらのツールは、フィルタリングとグループ化のオプションを提供します AWS アカウント。コスト配分の観点からは、このモデルが個々のリソースの正確なタグ付けに依存する必要はありません。
+ **ビジネスユニットまたはチームベース** — 企業内のチーム、ビジネスユニット、または組織にコストを配分できます。このモデルの操作にはそこそこの手間が必要とされますが、ショーバックやチャージバックの精度も高く、さまざまなチーム、アプリケーション、ワークロードタイプに分離された明確なアカウント構造 (通常は AWS Organizationsを使用) を持つ組織に適しています。これにより、チームやアプリケーション全体でコストを明確に把握でき、さらなる利点として、1 回の AWS アカウント以内に[AWS サービスクォータ](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html)に達するリスクが軽減されます。例えば、各チームに 5 つのアカウント (`prod`、`staging`、`test`、`dev`、`sandbox`) があっても、2 つのチームやアプリケーションが同じアカウントを共有することはないでしょう。このような構造では、[AWS Cost Categories](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/manage-cost-categories.html) にはアカウントやその他のタグ（「メタタギング」）をカテゴリにグループ化する機能（「メタタギング」があり、前の例で説明したツールで追跡できます。ではアカウントと組織単位 (OUs) のタグ付け AWS Organizations が許可されますが、これらのタグはコスト配分と請求レポートには適用できません (つまり、OU AWS Cost Explorer でコストをグループ化またはフィルタリングすることはできません）。 AWS この目的には Cost Categories を使用する必要があります。
+ **タグベース** - このモデルは前の 2 つに比べて手間がかかりますが、要件や最終目標に応じてショーバックやチャージバックの精度も高くなります。[「複数アカウントを使用した AWS 環境の整理](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/organizing-your-aws-environment.html)」ホワイトペーパーで説明されているプラクティスを採用することを強くお勧めしますが、現実的には、お客様は移行に時間がかかる混合アカウント構造と複雑なアカウント構造を持つことがよくあります。このシナリオでは、厳密で効果的なタグ付け戦略を実装し、次に Billing and Cost Management コンソールで[関連するタグをコスト配分用にアクティブ化](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/activating-tags.html)します ( では AWS Organizations、タグは Management Payer アカウントからのみコスト配分のためにアクティブ化できます）。コスト配分でタグを有効にすると、前の方法で説明したコストの可視化と配分のためのツールをショーバックやチャージバックに使用できます。コスト配分タグはさかのぼることはなく、コスト配分が有効化された後にのみ、請求レポートやコストトラッキングツールに表示されるので注意してください。
要約すると、ビジネスユニット別にコストを追跡する必要がある場合は、[AWS Cost Categories](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/manage-cost-categories.html) を使用して、それに応じて AWS Organization 内のリンクされたアカウントをグループ化し、請求レポートでこのグループ化を表示できます。本番環境と非本番環境で別々のアカウントを作成すると、[AWS Cost Explorer](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/ce-what-is.html)などのツールで環境に関連するコストのフィルタリングや、[Budgets](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/budgets-managing-costs.html) を利用して、それらのコストの追跡もできます。AWS 最後に、個々のワークロードやアプリケーション別など、より詳細なコスト追跡が必要なユースケースでは、それらのアカウント内のリソースに適切なタグを付け、管理アカウントで[コスト配分用のタグキーを有効](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/activating-tags.html)にすれば、請求レポートツールでそのコストをタグキーでフィルタリングできます。
## コストレポートとモニタリングプロセスの確立
まず、社内の利害関係者にとって重要なコストのタイプ (たとえば、日次支出、アカウント別コスト、X 単位コスト、償却コストなど) の特定から始めます。これにより、確定した AWS 請求書を待つよりも、予期しない支出や異常な支出に関連する予算上のリスクを軽減できます。タグにはこうしたレポートシナリオを可能にする属性があります。レポートから得られた情報は、財政予算における異常な想定外の支出による影響軽減のための対策に役立ちます。想定外のコスト増が発生した場合は、提供した価値が予想よりも急増したかどうかを判定して、必要な対策が必要かどうか、またどのような対策が必要かの判断が重要です。
コスト配分に役立てるためのタグ付け戦略を策定する際は、以下の要素を念頭に置いてください。
+ **AWS Organizations** - 複数のアカウント内でのコスト配分は、アカウント、アカウントグループ、またはそれらのアカウントのリソース用に作成したタグのグループごとに実行できます。の個々のアカウントに存在するリソース用に作成されたタグ AWS Organizations は、管理アカウントからのコスト配分にのみ使用できます。
+ **AWS アカウント** - 1 つの 内のコスト配分は、サービスやリージョンなどの追加のディメンションで実行 AWS アカウント できます。アカウント内のリソースにさらにタグを付け、そのようなリソースタグのグループと連携することができます。
+ **コスト配分タグ** - 必要に応じて、ユーザーが作成したタグと AWS が生成したタグの両方を有効化してコスト配分を行うことができます。請求コンソール ( の管理アカウントの AWS Organizations) でコスト配分のタグを有効にすると、ショーバックとチャージバックに役立ちます。
+ **Cost Categories** - AWS Cost Categoriesでは、 AWS 組織内のアカウントのグループ化とタグのグループ化 (メタタグ付け) が可能です。これにより、 AWS 予算やコストと使用状況レポートなどのツールを使用して AWS Cost Explorer、これらのカテゴリに関連する AWS コストをさらに分析できます。
## 企業内の事業部門、チーム、または組織のショーバックとチャージバックを行います。
コスト構造とコスト配分タグに裏付けられたコスト配分プロセスを使用してコストを特定します。タグは、直接費用を支払う責任はないものの、その費用を発生させた責任があるチームにショーバックを提供するために使用できます。このアプローチで、チームの支出への貢献度と、そのコストがどのように発生しているかを把握できます。コストに直接の責任があるチームにチャージバックを実施して、消費したリソースの費用を回収し、それらのコストとその発生状況を把握することができます。
## KPI の効率性または値の測定と循環
ここでは、クラウド財務管理への投資の影響を測定するために、単位コストや KPI の指標について理解していただきます。この演習では、テクノロジーとビジネスの利害関係者の間で共通の言語を構築し、絶対的な総支出のみに焦点を当てたストーリーではなく、効率に基づいたストーリーをお話しします。その他の情報については、「[ユニットメトリックがビジネス機能間の調整にどのように役立つか](https://aws.amazon.com/blogs/aws-cloud-financial-management/unit-metrics-help-create-alignment-between-business-functions/)」を説明したこのブログをチェックしてください。
## 割り当てられない支出の配分
組織の会計方法によっては、請求の種類が異なれば処理も異なる場合があります。タグ付けできないリソースやコストカテゴリを把握してください。使用するサービスと使用予定のサービスに応じて、このような割り当て不可能な支出をどのように処理し、評価するかについてのメカニズムについて理解していただきます。例えば、[AWS Resource Groups とタグエディタ](https://docs.aws.amazon.com/ARG/latest/userguide/supported-resources.html)がサポートしているリソースのリストについては、* と『AWS Resource Groups タグユーザーガイド*』を参照してください。
タグ付けできないコストカテゴリの一般的な例としては、リザーブドインスタンス (RI) や Savings Plans (SP) などのコミットメントベースの割引にかかる手数料があります。サブスクリプション料金や未使用の SP や RI 料金は、請求レポートツールに表示される前にタグ付けすることはできませんが、表示後であれば、RI と SP の割引が AWS Organizations でアカウント、リソース、およびそれらのタグにどのように適用されるかを追跡できます。たとえば、償却コスト、関連するタグキーで消費するグループ、ユースケースに関連するフィルターを適用 AWS Cost Explorer できます。 AWS コストと使用状況レポート (CUR) では、RI と SP の割引の対象になる使用量に対応する行を除外し (詳細は [CUR ドキュメント](https://docs.aws.amazon.com/cur/latest/userguide/use-cases.html)の「ユースケース」セクションを参照)、自分だけに関連する列を選択することができます。コスト配分対象として有効になった各タグキーは、[月次コスト配分レポート](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/configurecostallocreport.html)など、他の従来の請求レポートに表示される場合と同様に、CUR レポートの最後に個別の列に表示されます。その他の参考資料としては、[AWS Well-Architected Labs](https://www.wellarchitectedlabs.com/cost/300_labs/300_cur_queries/) で CUR データからコストと使用状況を把握する例を確認してください。
## 報告
ショーバックとチャージバックを支援するために使用できる AWS ツールに加えて、タグ付けされたリソースのコストをモニタリングし、タグ付け戦略の有効性を測定するのに役立つ、他の AWS 作成済みおよびサードパーティーのソリューションもいくつかあります。それぞれの組織の要件と最終目的によっては、カスタマイズされたソリューションの構築に時間とリソースを投資するか、[AWS クラウド Management Tools Competency Partners](https://aws.amazon.com/products/management-tools/partner-solutions/?partner-solutions-cards.sort-by=item.additionalFields.partnerNameLower&partner-solutions-cards.sort-order=asc&awsf.partner-solutions-filter-partner-type=%2Aall&awsf.Filter%20Name%3A%20partner-solutions-filter-partner-use-case=%2Aall&awsf.partner-solutions-filter-partner-location=%2Aall) が提供するツールを購入するかを選択できます。ビジネスに関連する制御されたパラメータを使用して独自の*信頼できる*唯一のソースのコスト配分ツールを作成する場合、 AWS コストと使用状況レポート (CUR) は最も詳細なコストと使用状況データを提供し、カスタマイズされた最適化ダッシュボードの作成を可能にします。これにより、アカウント、サービス、コストカテゴリ、コスト配分タグ、その他の複数のディメンションによるフィルタリングとグループ化が可能になります。これらのツールの 1 つとして使用できる AWS によって開発された CUR ベースのソリューションについては、 AWS Well-Architected Labs のウェブサイトで [Cloud Intelligence Dashboards](https://www.wellarchitectedlabs.com/cost/200_labs/200_cloud_intelligence/) を確認してください。
# 運用とサポート用のタグ
AWS 環境には、運用要件が異なる複数のアカウント、リソース、ワークロードがあります。タグを使用すると、運用チームによるサービス管理の強化をサポートするコンテキストやガイダンスが得られます。タグは、管理対象リソースの運用ガバナンスの透明性の向上にも使用できます。
運用タグの一貫した定義の作成を促がす主な作業には、次のようなものがあります。
+ **自動インフラストラクチャーアクティビティ中にリソースをフィルタリングする。**例えば、リソースをデプロイ、更新、削除する場合などです。もう 1 つは、コストの最適化と時間外使用量の削減を目的としたリソースのスケーリングです。実際の例については、[AWS インスタンススケジューラ](https://aws.amazon.com/solutions/implementations/instance-scheduler/)のソリューションを参照してください。
+ **孤立したリソースや廃止予定のリソースを特定する。**定義された有効期間を過ぎたリソースや、内部メカニズムによって隔離のフラグが立てられたリソースには、サポート担当者が調査できるように、適切なタグを付ける必要があります。廃止予定のリソースは、分離、アーカイブ、削除の前にタグ付けする必要があります。
+ **リソースグループのサポート要件。**一般に、リソースにはさまざまなサポート要件があり、それらはチーム間の交渉や、アプリケーションの重要度の一部として設定することができます。運用モデルに関する詳細なガイダンスは、[オペレーショナルエクセレンスの柱](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/operating-model.html)に掲載されています。
+ **インシデント管理プロセスを強化する。**インシデント管理プロセスの透明性を高めるタグをリソースにタグ付けると、サポートチームやエンジニア、重大インシデント管理 (MIM) チームによるイベント管理の効果化が図れます。
+ **バックアップ。**タグは、リソースのバックアップが必要な頻度、バックアップコピーの保存先、バックアップの復元先の特定にも使用できます。[バックアップと復旧のアプローチに関する規範的なガイダンス AWS](https://docs.aws.amazon.com/prescriptive-guidance/latest/backup-recovery/welcome.html)。
+ **パッチ適用。**で実行されているミュータブルインスタンスへのパッチ適用 AWS は、包括的なパッチ適用戦略とゼロデイ脆弱性のパッチ適用の両方において重要です。より広範なパッチ戦略に関するより詳細なガイダンスについては、『[規範的ガイダンス](https://docs.aws.amazon.com/prescriptive-guidance/latest/patch-management-hybrid-cloud/welcome.html)』を参照してください。ゼロデイ脆弱性のパッチについては、この[ブログ](https://aws.amazon.com/blogs/mt/avoid-zero-day-vulnerabilities-same-day-security-patching-aws-systems-manager/)で説明しています。
+ **運用上の可観測性**。運用 KPI 戦略をリソースタグに変換しておくと、運用チームは目標が達成されているかどうかをより正確に追跡してビジネス要件を強化できます。KPI 戦略の策定は独立したトピックですが、そこでは定常的に運営されている事業や、変化の影響と成果をどこで測定すべきかに焦点が当てられる傾向があります。[KPI ダッシュボード](https://wellarchitectedlabs.com/cost/200_labs/200_cloud_intelligence/cost-usage-report-dashboards/dashboards/2c_kpi_dashboard/) (AWS Well-Architected ラボ) とオペレーション KPI ワークショップ ([AWS エンタープライズサポートのプロアクティブサービス](https://aws.amazon.com/premiumsupport/technology-and-programs/proactive-services/)) はどちらも、安定した状態でパフォーマンスを測定します。 AWS エンタープライズ戦略ブログ記事[「変換の成功の測定](https://aws.amazon.com/blogs/enterprise-strategy/measuring-the-success-of-your-transformation/)」では、IT のモダナイゼーションやオンプレミスから への移行など、変換プログラムの KPI 測定について説明します AWS。
# 自動インフラストラクチャーアクティビティ
タグは、インフラストラクチャーを管理する際のさまざまな自動化アクティビティに使用できます。たとえば、[AWS Systems Manager](https://docs.aws.amazon.com/systems-manager/index.html) を使用すると、作成した定義済みのキーと値のペアで指定したリソースの自動化やランブックを管理できます。管理ノードには、タグのセットを定義してオペレーティングシステムや環境毎のノードの追跡やターゲット化ができます。その後、グループ内のすべてのノードに対する更新スクリプトの実行や、それらのノード状態の確認ができます。[Systems Manager リソース](https://docs.aws.amazon.com/systems-manager/latest/userguide/taggable-resources.html)にタグを付けて、自動化されたアクティビティの絞り込みや、追跡もできます。
環境リソースの開始と停止のライフサイクルの自動化は、どの組織にとっても大幅なコスト削減につながります。[AWS上のインスタンススケジューラーは](https://aws.amazon.com/solutions/implementations/instance-scheduler/)、Amazon EC2 インスタンスと Amazon RDS インスタンスが不要なときに起動、停止できるソリューションの一例です。例えば、週末に実行する必要のない Amazon EC2 や Amazon RDS インスタンスを利用している開発者環境では、それらのインスタンスのシャットダウンによるコスト削減の可能性は活かされていません。チームとその環境のニーズを分析し、これらのリソースに適切にタグを付けて管理を自動化すれば、効果的に予算を活用できます。
*Amazon EC2 インスタンスのインスタンススケジューラーが使用するスケジュールタグの例:*
```
{
"Tags": [
{
"Key": "Schedule",
"ResourceId": "i-1234567890abcdef8",
"ResourceType": "instance",
"Value": "mon-9am-fri-5pm"
}
]
}
```
# ワークロードのライフサイクル
**裏付けとなる運用データの正確性を確認します。**ワークロードのライフサイクルに関連するタグを定期的に見直し、そのレビューに適切な利害関係者が関わっていることを確認してください。
*表 7 — ワークロードライフサイクルの一環としての運用タグの見直し*
| ユースケース | タグキー | 根拠 | 値の例 |
| --- | --- | --- | --- |
| アカウント所有者 | example-inc:account-owner:owner | アカウントの所有者とそれに含まれるリソース。 | ops-center, dev-ops, app-team |
| アカウントオーナーのレビュー | example-inc:account-owner:review | アカウント所有権の詳細内容が最新で正しいことを確認する。 | <タグ付けライブラリ内で定義されている日付が正しいフォーマットであることを確認する> |
| データ所有者 | example-inc:data-owner:owner | アカウントにあるデータのデータ所有者。 | bi-team, logistics, security |
| データ所有者レビュー | example-inc:data-owner:review | データ所有権の詳細が最新で正確であることを確認する。 | <タグ付けライブラリ内で定義されている日付が正しいフォーマットであることを確認する> |
## 停止 OU に移行する前に、停止アカウントにタグを割り当てる
[「Organizing Your AWS Environment Using Multiple Accounts](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/organizing-your-aws-environment.html)」ホワイトペーパーで説明されているように、アカウントを停止して停止された OU に移行する前に、アカウントのライフサイクルの内部トレースと監査に役立つタグをアカウントに追加する必要があります。例えば、組織の ITSM チケットシステム上の相対 URL やチケット参照には、一時停止中のアプリケーションの監査記録が表示されます。
*表 8 - ワークロードのライフサイクルが新たな段階に入った際の運用タグの追加*
| ユースケース | タグキー | 根拠 | 値の例 |
| --- | --- | --- | --- |
| アカウント所有者 | example-inc:account-owner:owner | アカウントの所有者とそれに含まれるリソース。 | ops-center, dev-ops, app-team |
| データ所有者 | example-inc:data-owner:owner | アカウントにあるデータのデータ所有者。 | bi-team, logistics, security |
| 停止日 | example-inc:suspension:date | アカウントが停止された日付 | <タグ付けライブラリ内で定義された正しいフォーマットの停止日> |
| 一時停止の承認 | example-inc:suspension:approval | アカウント停止の承認へのリンク | workload/deprecation |
# インシデント管理
タグは、インシデントの記録から、優先順位付け、調査、コミュニケーション、解決、終了に至るまで、インシデント管理のあらゆる段階で重要な役割を果たします。
タグには、インシデントを記録すべき場所、インシデントについて知らせるべきチーム、定義済みのエスカレーション優先度を詳細に記述できます。タグは暗号化されないので、タグにどのような情報を保存するかをよく考えてください。また、組織、チーム、報告部門では責任の所在が移り変わるので、情報をより効果的に管理できる安全なポータルへのリンクを保存することを検討してください。これらのタグは排他的である必要はありません。例えば、アプリケーション ID で、IT サービス管理ポータルのエスカレーションパスを検索できます。運用上の定義では、このタグが複数の目的で使用されていることを明確にしてください。
インシデントマネージャーや運用担当者がインシデントやイベントに対応して目標を絞り込むのに役立つように、運用要件タグも詳細に記述できます。
[ランブック](https://wa.aws.amazon.com/wellarchitected/2020-07-02T19-33-23/wat.concept.runbook.en.html)や[プレイブック](https://wa.aws.amazon.com/wellarchitected/2020-07-02T19-33-23/wat.concept.playbook.en.html)の (ナレッジシステムのベース URL への) 相対リンクをタグとして含めると、対応チームが対応するプロセス、手順、文書を特定しやすくなります。
*表 9 - 運用タグをインシデント管理の情報伝達に使用する*
| ユースケース | タグキー | 根拠 | 値の例 |
| --- | --- | --- | --- |
| インシデント管理 | example-inc:incident-management:escalationlog | サポートチームがインシデントを記録するために使用しているシステム | jira, servicenow, zendesk |
| インシデント管理 | example-inc:incident-management:escalationpath | エスカレーションの経路 | ops-center, dev-ops, app-team |
| コスト配分とインシデント管理 | example-inc:cost-allocation:CostCenter | コストセンターごとにコストを監視します。これは、コストセンターをインシデント記録のアプリケーションコードとして使用するデュアルユースタグの例です。 | 123-\$1 |
| バックアップスケジュール | example-inc:backup:schedule | リソースのバックアップスケジュール | Daily |
| プレイブック/インシデント管理 | example-inc:incident-management:playbook | 文書化されたプレイブック | webapp/incident/playbook |
# パッチ適用
組織で、 AWS Systems Manager Patch Manager と AWS Lambdaを使用すれば、可変コンピューティング環境へのパッチ適用戦略を自動化し、可変インスタンスをそのアプリケーション環境の定義済みパッチベースライに一致させることができます。これらの環境内の可変インスタンスのタグ付け戦略は、そのインスタンスを**パッチグループ**と**メンテナンスウィンドウ**に割り当てれば管理できます。Dev → Test → Prod の分割については、以下の例を参照してください。 [可変インスタンスのパッチ管理](https://docs.aws.amazon.com/prescriptive-guidance/latest/patch-management-hybrid-cloud/welcome.html)については、 AWS の規範的なガイダンスが用意されています。
*表 10 - 環境によって異なる運用タグ*
| 開発 | ステージング | 本番稼働 |
| --- | --- | --- |
| {
"Tags": [
{
"Key": "Maintenance Window",
"ResourceId": "i-012345678ab9ab111",
"ResourceType": "instance",
"Value": "cron(30 23 ? * TUE#1 *)"
},
{
"Key": "Name",
"ResourceId": "i-012345678ab9ab222",
"ResourceType": "instance",
"Value": "WEBAPP"
},
{
"Key": "Patch Group",
"ResourceId": "i-012345678ab9ab333",
"ResourceType": "instance",
"Value": "WEBAPP-DEV-AL2"
}
]
}
| {
"Tags": [
{
"Key": "Maintenance Window",
"ResourceId": "i-012345678ab9ab444",
"ResourceType": "instance",
"Value": "cron(30 23 ? * TUE#2 *)"
},
{
"Key": "Name",
"ResourceId": "i-012345678ab9ab555",
"ResourceType": "instance",
"Value": "WEBAPP"
},
{
"Key": "Patch Group",
"ResourceId": "i-012345678ab9ab666",
"ResourceType": "instance",
"Value": "WEBAPP-TEST-AL2"
}
]
}
| {
"Tags": [
{
"Key": "Maintenance Window",
"ResourceId": "i-012345678ab9ab777",
"ResourceType": "instance",
"Value": "cron(30 23 ? * TUE#3 *)"
},
{
"Key": "Name",
"ResourceId": "i-012345678ab9ab888",
"ResourceType": "instance",
"Value": "WEBAPP"
},
{
"Key": "Patch Group",
"ResourceId": "i-012345678ab9ab999",
"ResourceType": "instance",
"Value": "WEBAPP-PROD-AL2"
}
]
}
|
ゼロデイ脆弱性は、パッチ戦略を補完するタグの定義によっても管理できます。詳細なガイダンスについては、[AWS 「Systems Manager を使用した当日のセキュリティパッチ適用によるゼロデイ脆弱性の回避](https://aws.amazon.com/blogs/mt/avoid-zero-day-vulnerabilities-same-day-security-patching-aws-systems-manager/)」を参照してください。
# 運用上のオブザーバビリティ
環境パフォーマンスに対して実行可能な見通しを立て、問題の検出と調査に役立てるには、オブザーバビリティが必要です。また、重要業績評価指標 (KPI) や稼働時間などのサービスレベル目標 (SLO) を定義して測定できるという副次的な目的もあります。ほとんどの組織にとっては、インシデント発生時の平均検出時間 (MTTD) とインシデントからの平均回復時間 (MTTR) が重要な運用 KPI です。
オブザーバビリティでは、データが収集されてから関連するタグが収集されるため、コンテキストが重要です。対象になるサービス、アプリケーション、またはアプリケーション層に関係なく、その特定のデータセットを絞り込んで分析できます。CloudWatch Alarms へのオンボーディングをタグで自動化できるため、特定のメトリクスのしきい値を超えた場合に適切なチームがアラートを受け取ることができます。例えば、タグキー `example-inc:ops:alarm-tag` とその値が CloudWatch アラームの作成を示している可能性があります。これを示すソリューションについては、「[Amazon EC2 インスタ―スに対する Amazon CloudWatch アラームの作成と維持のためにタグを使用する](https://aws.amazon.com/blogs/mt/use-tags-to-create-and-maintain-amazon-cloudwatch-alarms-for-amazon-ec2-instances-part-1/)」を参照してください。
設定したアラームの数が多すぎると、オペレーターが個々のアラームを手動で重要度を判定して優先順位付けをしている間に、大量のアラームや通知でオペレーターに負担がかかり、全体的な効果を低下して、アラートストームが発生しやすくなります。アラームの追加コンテキストはタグの形で提供でき、Amazon EventBridge 内でルールを定義できるため、ダウンストリームの依存関係ではなくアップストリームの問題に的を絞ることができます。
DevOps と並行して運用が果たす役割は見過ごされがちですが、多くの組織では、中央運用チームが依然として通常の営業時間外に重要な初対応を行っています。(このモデルの詳細については、「[オペレーショナルエクセレンスのホワイトペーパー](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/separated-aeo-ieo-with-cent-gov-and-partner.html)」を参照してください。) ワークロードを所有する DevOps チームとは異なり、通常、それらには同じ知識の深さがないため、タグがダッシュボードやアラート内に提供するコンテキストは、問題の正しいランブックにタグを誘導したり、自動ランブックを開始したりできます (ブログ記事[「Automating Amazon CloudWatch Alarms with AWS Systems Manager](https://aws.amazon.com/blogs/mt/automating-amazon-cloudwatch-alarms-with-aws-systems-manager/)」を参照）。
# データセキュリティ、リスク管理、アクセス制御用のタグ
データの保存と処理の適切な取り扱いについて、組織にはさまざまなニーズや責任があります。データ分類は、アクセス制御、データ保持、データ分析、コンプライアンスなど、いくつかのユースケースでは、重要な前提条件です。
# データセキュリティとリスク管理
AWS 環境内では、コンプライアンス要件とセキュリティ要件が異なるアカウントが存在する可能性があります。例えば、開発者用サンドボックスと、支払い処理などの規制の厳しいワークロード用の本番環境をホストするアカウントがあるとします。それらを異なるアカウントに分離して、[個別のセキュリティ制御を適用し](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/benefits-of-using-multiple-aws-accounts.html#apply-distinct-security-controls-by-environment)、[機密データへのアクセスを制限すれば](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/benefits-of-using-multiple-aws-accounts.html#constrain-access-to-sensitive-data)、規制対象のワークロードの監査範囲を狭めることができます。
すべてのワークロードに同じ標準を採用することは、問題の発生につながるおそれがあります。多くの制御機能が環境全体に等しく適用されていますが、特定の制御機能の枠組みを満たす必要のないアカウントや、個人を特定できるデータが存在しないアカウント (開発者用サンドボックスやワークロード開発アカウントなど) には、その存在が過剰な制御や無関係な制御もあります。そのような状況は、一般に、優先順位を付けて何もしないでクローズしなければならないセキュリティ上の誤検出につながるため、本来の調査すべき発見に費やされる労力が無駄に奪われます。
*表 11 — データセキュリティタグとリスク管理タグの例*
| ユースケース | タグキー | 根拠 | 値の例 |
| --- | --- | --- | --- |
| インシデント管理 | example-inc:incident- management:escalationlog | サポートチームがインシデントを記録するために使用しているシステム | jira, servicenow, zendesk |
| インシデント管理 | example-inc:incident- management:escalationpath | エスカレーションの経路 | ops-center, dev-ops, app-team |
| データ分類 | example-inc:data:classification | コンプライアンスとガバナンスのためのデータの分類 | Public, Private, Confidential, Restricted |
| コンプライアンス | example-inc:compliance:framework | ワークロードが対象となるコンプライアンスフレームワークを特定します。 | PCI-DSS, HIPAA |
AWS 環境全体で異なるコントロールを手動で管理すると、時間がかかり、エラーが発生しやすくなります。次のステップでは、適切なセキュリティ制御の導入を自動化し、そのアカウントの分類に基づいてリソースの検査を設定します。アカウントとその中のリソースにタグを適用すると、制御の導入を自動化し、ワークロードに合わせて適切に設定できます。
**例: **
ワークロードには、値 `Private` のタグ `example-inc:data:classification` が付いた Amazon S3 バケットが含まれます。セキュリティツールの自動化は`s3-bucket-public-read-prohibited`、Amazon S3 バケットのブロックパブリックアクセス設定、バケットポリシー、バケットアクセスコントロールリスト (ACL) をチェックし、バケットの設定がデータ分類に適していることを確認する AWS Config ルール をデプロイします。バケットの内容が分類と一致していることを確認するために、[Amazon Macie は個人識別情報 (PII) をチェックするように設定できます](https://aws.amazon.com/about-aws/whats-new/2021/05/amazon-macie-supports-criteria-based-bucket-selection-sensitive-data-discovery-jobs/)。ブログ「[Amazon Macie を使用して S3 バケットデータ分類を検証する](https://aws.amazon.com/blogs/architecture/using-amazon-macie-to-validate-s3-bucket-data-classification/)」では、このパターンについて詳しく説明しています。
保険や医療などの特定の規制環境では、必須のデータ保持ポリシーが適用される場合があります。タグを使用したデータ保持と Amazon S3 ライフサイクルポリシーを組み合わせると、オブジェクトを別のストレージ階層で調べるための効果的で簡単な方法が得られます。Amazon S3 ライフサイクルルールで、必須の保持期間の終了後にデータを削除するオブジェクトを期限切れにすることもできます。このプロセスの詳細なガイドについては、「[Amazon S3 ライフサイクルでオブジェクトタグを使用してデータライフサイクルを簡素化する](https://aws.amazon.com/blogs/storage/simplify-your-data-lifecycle-by-using-object-tags-with-amazon-s3-lifecycle/)」を参照してください。
さらに、セキュリティ上の検出結果の優先順位付けや対処を行う際に、調査担当者にはタグでリスクの見極めに役立つ重要なコンテキストが得られ、適切なチームを関わらせて調査結果や軽減に役立てることができます。
# ID 管理とアクセス制御用のタグ
を使用して AWS 環境全体のアクセスコントロールを管理する場合 AWS IAM アイデンティティセンター、タグはスケーリングのためにいくつかのパターンを有効にすることができます。適用できる委任パターンはいくつかあり、中にはタグ付けに基づくものもあります。それぞれの説明と、それらを参照するためのリンクを用意しました。
# 個々のリソースの ABAC
IAM Identity Center のユーザーと IAM ロールは、属性ベースのアクセス制御 (ABAC) をサポートし、タグに基づいて操作とリソースへのアクセスを定義します。ABAC で、権限ポリシーを更新する必要性が減り、社内ディレクトリで従業員属性からベースアクセスを行うのに便利です。すでにマルチアカウント戦略を採用している場合は、ロールベースのアクセス制御 (RBAC) に加えて ABAC を使用すれば、同じアカウントで業務を行う複数のチームに、さまざまなリソースに対するきめ細かいアクセス権限を与えることができます。例えば、IAM Identity Center のユーザーまたは IAM ロールには、特定の Amazon EC2 インスタンスへのアクセス権限を制限する条件を含めることができます。そうしない場合、それらのインスタンスにアクセスするためには各ポリシーに明示的に記載する必要があります。
ABAC 認可モデルはオペレーションやリソースへのアクセス権限をタグに依存するため、想定外のアクセスを防ぐためのガードレールを設けることが重要です。SCP では、特定の条件下でのみタグの変更を許可して、組織全体のタグを保護するために使用できます。実装方法についてはブログ「[Seecuring resource tags used for authorization using a service control policy in AWS Organizations](https://aws.amazon.com/blogs/security/securing-resource-tags-used-for-authorization-using-service-control-policy-in-aws-organizations/)」と「[Permissions boundaries for IAM entities](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html)」を参照してください。
運用期間の長い Amazon EC2 インスタンスで古くからの運用方法をサポートしている場合、このアプローチを利用できます。ブログ「[Configure IAM Identity Center ABAC for Amazon EC2 instances and Systems Manager Session Manager](https://aws.amazon.com/blogs/security/configure-aws-sso-abac-for-ec2-instances-and-systems-manager-session-manager/)」では、この形式の属性ベースのアクセス制御についてさらに詳しく説明しています。前述のように、すべてのリソースタイプがタグ付けをサポートしているわけではなく、サポートしているリソースタイプの中には、すべてのリソースタイプがタグポリシーを使用した強制をサポートしているわけではないため、この戦略を AWS アカウントに実装する前に、これを評価することをお勧めします。
ABAC をサポートするためにサービスについては、「[IAM と動作するAWS サービス](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html)」を参照してください。