Amazon Web Services ブログ
SAP on AWSにおけるタグ付けの推奨
SAP on AWSを稼働しているお客様から、SAPワークロードにおけるタグ付けの戦略に再利用可能な傾向があるかどうか、たびたびお問い合わせをいただきます。タグは、お客様が定義するキーとオプションの値で構成される単純なラベルです。タグを使用すると、お客様はメタデータをクラウドリソースに割り当てることができ、既存のリソースの管理、検索、フィルタリングが容易になります。
この記事では、タグ付けの利点の概要を示し、AWS上にSAPワークロードを展開しているお客様とパートナーのために推奨事項を紹介します。おすすめのタグは、多くの案件対応で培った経験に基づいています。お客様はこれらのタグをすべて直接的に使用することも、自分のニーズに合わせて変更することもできます。
タグ付けの利点
- お客様は、ストレージボリュームのスナップショット、OSのパッチ適用、AWS System Manager Automationといった運用や展開の自動化アクティビティにタグを使用します。SAPのお客様は、SAPサーバーの起動/停止の自動化、cronジョブの実行、監視/アラート機能にタグを使用することもできます
- パートナーは、ソリューションの展開にAWSタグを使用します。高可用性クラスター、バックアップ、監視ソリューションは、多くの場合、それらの操作をAWSリソースタグに依存しています
- AWS請求レポートは、タグの使用をサポートしています。お客様は、個々のアカウント、リソース、事業単位、SAP環境に基づいてAWSリソースの料金を識別するのに役立つコスト配分タグを作成できます
- AWS Identity and Access Management (IAM)ポリシーはタグベースの条件をサポートしているため、お客様は特定のタグとその値に基づいてアクセス許可を制限できます。IAMユーザーまたはロールのアクセス許可には、タグに基づいて、開発、テスト、本稼働環境、あるいはAmazon Virtual Private Cloud (Amazon VPC)ネットワークへのアクセスを制限する条件を含めることができます
- 高度なセキュリティリスク管理業務を必要とするリソースを識別するために、タグを割り当てることができます。例えば、機密データを処理するアプリケーションをホストするAmazon Elastic Compute Cloud (Amazon EC2)インスタンスです。これにより、自動化されたコンプライアンスチェックを有効にして、適切なアクセス制御が行われていること、パッチコンプライアンスが最新であることを確認できます
タグ付けの考慮事項
- タグはいつでも適用可能: リソースの作成後にタグを作成および適用できます。ただし、リソースが作成されてからタグが適用されるまでは情報は取得されません
- タグは遡及不可: コスト配分レポートは、タグが有効化された時点からのみ利用可能です。10月にコスト配分を有効にした場合、9月からの情報は表示されません
- タグはその時点での静的スナップショット: レポートの実行後にタグに加えられた変更は、以前のレポートには反映されません
- タグはコスト配分のために明示: 新しいタグを作成した後、それをコスト配分タグとして要求する/有効化する/追加する必要があります。そうでない場合、詳細請求レポート (DBR)やAWS Cost Explorerに表示されません
タグ付けの戦略
- 命名規則の定義: タグでは大文字と小文字が区別されるため、AWSリソースの標準を定義します。例えば、タグのキー名は、手動で作成するため、アッパーキャメルケース (またはパスカルケース、複合語の語頭を大文字にする記法)を使用するのが良いです。キャメルケースは、MiscMetadataやSupportEndpointsのように各単語を大文字で開始し、単語/略語を組み合わせます
- 区切り文字の標準化: タグの値の一部として区切り文字を使用しないでください。これは、大文字と小文字を区別するタグを使えば問題なく機能します
- 連結/複合タグ付けの使用: タグのキーを複数の値で結合します (Owner = JohnDoe | johndoe@company.com | 8005551234)。複合タグを標準化するために、パスカルケースを使用しましょう
タグ付けの提案
注: “<customer name>:” プレフィックスを使用して、会社定義のタグとAWSが定義するタグ、お客様が使用するサードパーティツールで必要なタグを明確に区別できます。
タグの名前 | <customer name>:name |
目的 | リソース名の識別。SAPサーバーのホスト名にすることができます |
値 | 文字列 例: aws2sql01 |
コスト配分タグ? | はい |
タグの名前 | <customer name>:sap-product |
目的 | SAPリソースに対して稼働しているSAP製品を識別 |
値 | 文字列 例: ecc, bw, po, solman, content-server |
コスト配分タグ? | はい |
タグの名前 | <customer name>:sid |
目的 | SAPシステムのSIDを識別 |
値 | 文字列 |
コスト配分タグ? | いいえ |
タグの名前 | <customer name>:landscape-type |
目的 | SAPランドスケープタイプのサポートやプロジェクトを識別 |
値 | 文字列 例: n, n+1, n+2 |
コスト配分タグ? | いいえ |
タグの名前 | <customer name>:ha-node |
目的 | HAクラスターノードを識別 |
値 | 文字列 例: primary, secondary, disaster recovery (DR) |
コスト配分タグ? | いいえ |
タグの名前 | <customer name>:backup |
目的 | サーバーのバックアップポリシーを識別 |
値 | 文字列 例: daily-full, daily-incremental, weekly-full |
コスト配分タグ? | いいえ |
タグの名前 | <customer name>:environment-type |
目的 | リソースが本稼働環境または非実稼働環境の一部であるかどうかを識別 |
値 | 文字列 例: lab, development, staging, production |
コスト配分タグ? | いいえ |
タグの名前 | <customer name>:created-by |
目的 | リソースを作成したAWSアカウントID、IAMユーザー名、IAMロールを追跡 |
値 | 文字列 例: account-id, user name, role session name |
コスト配分タグ? | はい |
タグの名前 | <customer name>:application |
目的 | リソースのアプリケーション名を識別 |
値 | 文字列 例: sap |
コスト配分タグ? | はい |
タグの名前 | <customer name>:app-tier |
目的 | 階層キーは、関連するAWSリソースの機能階層を指定するために使用。このキーは、AWSの支出を分解して、各インフラストラクチャのサブコンポーネントが全体的なコストにどのように寄与するかを理解する別の方法を提供します。バックアップと災害復旧の要件を決定するためにも使用されます。また、AWS Tirosなどのツールを使用した脅威のモデリングにも役立ちます |
値 | 文字列 例: Web, app, data, network, other |
コスト配分タグ? | いいえ |
タグの名前 | <customer name>:cost-center |
目的 | リソースに対して請求される部門のコストセンターを識別 |
値 | コストセンターコードの数値 |
コスト配分タグ? | はい |
追加のタグ付けの選択肢
お客様は、AWSリソースごとにpoweroff-time、poweron-time、business-stream、resource-owner-email、support-team-emailなどのタグを検討することもできます。
以下のスクリーンショットは、設定したいくつかのタグの例を示しています。ここでのabcは会社名です。
結論
タグ付けの戦略は、お客様のニーズに応じてお客様ごとに異なります。私たちのSAPプロフェッショナルサービスの経験では、お客様が構築する際に規則の出発点を提供することが有用であることが分かっています。タグ付けの最も重要な部分は、組織で何が機能するかを定義し、明確で正確なままにすることです。SAPワークロードのタグ付けの戦略を準備する際に、タグの制限も確認してください。
何かコメントや質問があればお気軽にお問い合わせください。私たちはお客様のフィードバックを大切にしています。
翻訳はPartner SA 河原が担当しました。原文はこちらです。