翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
AMS モードとアプリケーションまたはワークロード
新しいアプリケーションアカウントをリクエストするか、既存のアプリケーションアカウントでアプリケーションをホストして、適切なモードを選択するときは、アプリケーションの運用要件とガバナンス要件を検討してください。各アプリケーションまたはワークロードに適した AMS モードの選択は、次の要因によって異なります。
環境が提供する SDLC ライフサイクル関数のタイプ (変更がモデレートされていないサンドボックス、頻繁に変更される UAT、最小限の変更と高度に規制された本番稼働など）
必要なガバナンスポリシー (OU レベルで SCPs を通じて実施）
運用モデル (運用責任を所有する場合、またはそれを AMS に外部委託する場合）
クラウドでの運用にかかる時間や運用コストなど、期待されるビジネス成果。
注記
AMS サービスごとのモードタイプの詳細については、「AMS のモードとアカウントのタイプ」を参照してください。
さまざまなモードの実際のユースケースについては、「AMS モードの実際のユースケース」を参照してください。
次の表は、アプリケーション所有者が最適な AMS モードを決定するための重要な考慮事項の概要を示しています。アプリケーション所有者は、特定のアプリケーションに適用されるモードを完全に理解するために、アプリケーション移行の前に評価フェーズを含める必要があります。例: クラウドネイティブサービスまたはサーバーレスアーキテクチャに基づくアプリケーションの場合、最適なオプションは、開発者モードで構築と反復を開始し、AMS Managed – SSP モードを使用して最終的な Infrastructure as Code をデプロイすることです。この場合、自動デプロイ用に作成された CloudFormation テンプレートが AMS によって定められた取り込みガイドラインを確実に満たすために、軽いリファクタリングが必要になる場合があります。さらに、IAM アクセス許可は、最小特権モデルに従っていることを確認するために、AMS Security によって承認される必要があります。
アプリケーションをホストするために選択された AMS モードは、希望するクラウド運用モデルに向けて構築するのに役立ちます。
注記
複数のクラウド運用モデルは、アプリケーションをホストするために選択されたさまざまな AMS モードに基づいて、単一の AMS Managed Landing Zone に存在できます。
| 決定の問題 | 標準 CM モード/OOD* | AWS Service Catalog | 直接変更モード | セルフサービスプロビジョニング | デベロッパーモード | カスタマーマネージド |
|---|---|---|---|---|---|---|
| 運用準備状況 | ||||||
| ログ記録、モニタリング、イベント管理 | すべてのマネージドインフラストラクチャを担当する AMS | セルフサービスプロビジョニングサービス (SSP) を担当するお客様 | AMS CM システムの外部で開発者 IAM ロールを使用してプロビジョニングされたリソースを担当するお客様 | お客様の責任 | ||
| 継続性管理 | お客様が選択したバックアッププランを実行する AMS 責任 | セルフサービスプロビジョニングサービス (SSP) を担当するお客様 | AMS CM システムの外部で開発者 IAM ロールを使用してプロビジョニングされたリソースを担当するお客様 | |||
| インスタンスレベルのアクセス管理 | オンプレミスドメインによる一方向 AD 信頼を通じて AMS 管理。マネージドインフラストラクチャが AMS ドメインに参加する必要がある | 該当しない | AMS CM システムの外部で開発者 IAM ロールを使用してプロビジョニングされたリソースを担当するお客様 | |||
| セキュリティ管理とアカウントレベルのアクセス管理 | すべてのマネージドアカウントの AMS 責任 | すべてのマネージドアカウントを担当する AMS | AMS CM システムの外部で開発者 IAM ロールを使用してプロビジョニングされたリソースを担当するお客様 | |||
| パッチ管理 | すべてのマネージドアカウントの AMS 責任 | セルフサービスプロビジョニングサービス (SSP) を担当するお客様 | AMS CM システムの外部で開発者 IAM ロールを使用してプロビジョニングされたリソースを担当するお客様 | |||
| 変更管理 | すべてのマネージドアカウントの AMS 責任 | セルフサービスプロビジョニングサービス (SSP) を担当するお客様 | AMS CM システムの外部で開発者 IAM ロールを使用してプロビジョニングされたリソースを担当するお客様 | |||
| プロビジョニング管理 | AMS で提供されるプロビジョニングオプションの規範的および標準化 | AMS 規範標準に従って AWS Service Catalog 用の AWS サービス API を直接使用する柔軟性 | AMS 規範標準に従って AWS サービス API を直接使用する柔軟性 | SSP サービスAPIs を直接使用する柔軟性 | プロビジョニングに AWS サービス API を直接使用する柔軟性 | |
| インシデント管理と監査 | すべてのマネージドアカウントの AMS 責任 | AMS 変更管理システムの外部で開発者 IAM ロールを使用してプロビジョニングされたリソースを担当するお客様 | ||||
| GuardRails と共有インフラストラクチャ (ネットワーク) とセキュリティフレームワーク | AMS Core アカウントを活用した規範的および標準化 | AMS Core アカウントを柔軟にカスタマイズ | ||||
| アプリケーションの準備状況 | ||||||
| アプリケーションのリファクタリング | ライトリファクタリングが必要 | ライトリファクタリングが必要 (AMS Standard CM を使用してプロビジョニングされている場合） | リファクタリングが不要 | |||
| AWS サービスのサポート | AMS でサポートされているものに限定 | 無制限 | ||||
| ビジネス上の考慮事項 | ||||||
| 運用準備時間 | 3～6 か月 | 6 か月 + 顧客のアプリケーションオペレーションのコンピテンシーに依存する | お客様のインフラストラクチャとアプリケーション運用のコンピテンシーに応じて 6～18 か月 | |||
| コスト | $$$$ | $$$ | $$ | $ | ||
| アプリケーション例 | 3 層スタックの Webserver、コンプライアンスと規制要件のアプリケーション | API Gateway を使用するウェブサーバー、ECS/EKS を活用したコンテナ化されたアプリケーション | Lambda、Glue、Athena などを使用する Data Lake アプリケーションでの反復/最適化 | サンドボックス、サードパーティーマネージドアプリケーションなどの分散型アカウント/アプリケーション | ||
*Operations On Demand (OOD) には、標準 CM モードを使用して、専用のリソースを通じて変更を管理するお客様向けのサービスがあります。詳細については、「Operations on Demand catalog of offerings」および「Cloud Service Delivery Manager (CSDM)」を参照してください。
注記
SSP モードとデベロッパーモードの料金比較では、同じ AWS サービスがプロビジョニングされていることを前提としています。
AMS モードとビジネス目標および IT 目標の比較
図に示すように、アプリケーション用に高度に制御され標準化されたガバナンスモデルをお探しの場合は、AMS 管理の標準変更モード、AWS Service Catalog モード、または直接変更モードが最適です。運用準備を必要とせずにアプリケーションのイノベーションに焦点を当てたカスタムガバナンスモデルが必要な場合は、カスタマーマネージドモードを選択します。カスタマーマネージドモードでは、インシデント管理、設定管理、プロビジョニング管理、セキュリティ管理、パッチ管理などの運用機能をサポートする人員、プロセス、ツールを確立する責任を負うため、アプリケーションの運用に時間がかかる場合があります。
