翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
AMS モードの実際のユースケース
これらを調べて、AMS モードの使用方法を判断します。
-
ユースケース 1 は、時間的制約のあるデータセンターの出口でコストを削減するためのビジネス上の課題です。データセンターの出口など、魅力的なビジネスイベントがある企業は、オンプレミスアプリケーションをクラウド上で再ホストすることに関心を持っています。オンプレミスインベントリのほとんどは、オペレーティングシステムのバージョンが混在する Windows サーバーと Linux サーバーで構成されます。そうすることで、お客様はクラウドへの移行によるコスト削減を活用し、アプリケーションの技術的およびセキュリティ上の体制を改善したいと考えています。お客様は迅速に移行したいと考えていますが、社内のクラウド運用の専門知識はまだ構築されていません。お客様はリファクタリングのバランスを見つける必要があります。リファクタリングが多すぎると、厳しいタイムラインに対してリスクが高くなります。ただし、OS バージョンの更新やデータベースの最適化などのリファクタリングにより、アプリケーションは次のレベルのパフォーマンスを達成できます。この例では、お客様は AMS マネージド RFC モードを選択して、ほとんどのアプリケーションをリホストできます。AMS はインフラストラクチャオペレーションを提供し、クラウドでの安全な運用に関するベストプラクティスについてお客様の運用チームをガイドします。
AMS 管理の AWS Service Catalog および AMS 管理の Direct Change モードは、同じビジネス成果と目標を達成しながら、お客様にさらなる柔軟性を提供します。さらに、お客様は AMS Operations On Demand (OOD) サービスを使用して、専用の AMS オペレーションエンジニアが変更リクエスト (RFCs) の実行に優先順位を付けることができます。
差別化されていないインフラストラクチャの運用タスク (パッチ適用、バックアップ、アカウント管理など) を AMS にオフロードしながら、お客様は引き続きアプリケーションの最適化とクラウド運用に関する社内チームの強化に集中できます。AMS は、コスト削減に関する月次レポートを顧客に提供し、リソースの最適化に関するレコメンデーションを行います。このユースケースでは、Windows 2003 や 2008 などのレガシー OS バージョンでホストされているend-of-lifeアプリケーションがリファクタリングしないことを決定した場合、それらを AMS に移行し、カスタマーマネージドモードを利用するアカウントでホストすることもできます。
ユースケース 2: 安全な AMS 境界内に Lambda、Glue、Athena を使用してデータレイクを構築する: 企業は、AMS の複数のアプリケーションのレポートニーズを満たすために Data Lake をセットアップしようとしています。お客様は、データセットの保存に S3 バケットを使用し、AWS Athena を使用して各レポートのデータセットに対してクエリを実行したいと考えています。S3 と AWS Athena は、別々の AMS マネージドアカウントにデプロイされます。S3 のアカウントには、データ取り込みパイプラインを構築するための Glue、Lambda、Step Functions などの他のサービスもあります。この場合、Glue、Lambda、Athena、Step Functions はセルフサービスプロビジョニング (SSP) サービスと見なされます。顧客は、アドホックツール/スクリプトサーバーとして機能する EC2 インスタンスをアカウントにデプロイしました。まず、AMS マネージドアカウントで SSP サービスを有効にするように AMS にリクエストします。AMS は、ロールが顧客のフェデレーションソリューションにオンボーディングされると、顧客が引き受けることができるサービスごとに IAM ロールをプロビジョニングします。管理を容易にするために、お客様は個別の IAM ロールのポリシーを 1 つのカスタムロールに結合することもできます。これにより、AWS のサービス間で作業するときにロールを切り替える必要がなくなります。アカウントでロールを有効にすると、顧客は要件に従ってサービスを設定できます。ただし、お客様は AMS 変更管理システムと協力して、ユースケースに応じて追加のアクセス許可をリクエストする必要があります。
たとえば、 Glue クローラにアクセスするには、 Glue によって追加のアクセス許可が必要です。Lambda のイベントソースを作成するには、追加のアクセス許可も必要です。お客様は AMS と協力して IAM ロールを更新し、Athena が S3 バケットをクエリするためのクロスアカウントアクセスを許可します。サービスロールまたはサービスにリンクされたロールの更新も、Lambda が Step Functions サービスを呼び出し、Glue がすべての S3 バケットを読み書きするための AMS 変更管理を通じて必要になります。AMS はお客様と協力して、最小特権のアクセスモデルに従い、リクエストされた IAM の変更が過度に許容されず、環境が不要なリスクにさらされないようにします。顧客のデータレイクチームは、顧客のアーキテクチャに固有のサービスに必要なすべての IAM アクセス許可の計画に時間を費やし、それらを有効にするために AMS をリクエストします。これは、すべての IAM 変更が手動で処理され、AMS セキュリティチームからレビューされるためです。これらのリクエストを処理する時間は、アプリケーションのデプロイスケジュールで考慮する必要があります。
SSP サービスはアカウントで運用されているため、お客様は AMS インシデント管理とサービスリクエストを通じてサポートをリクエストし、問題を報告できます。ただし、AMS は Lambda のパフォーマンスと同時実行メトリクス、または Glue のジョブメトリクスを積極的にモニタリングしません。SSP サービスで適切なログ記録とモニタリングが有効になっていることを確認するのはお客様の責任です。アカウントの EC2 インスタンスと S3 バケットは、AMS によって完全に管理されます。
ユースケース 3、AMS での CICD デプロイパイプラインの迅速かつ柔軟なセットアップ: お客様は、AMS 内のすべてのアプリケーションアカウントにコードパイプラインをデプロイするために Jenkins ベースの CICD パイプラインをセットアップしようとしています。お客様は、この CICD パイプラインを AMS 管理の直接変更モード (DCM) または AMS 管理のデベロッパーモードでホストするのが最も適している場合があります。これにより、EC2 で必要なカスタム設定で Jenkins サーバーを柔軟に設定し、アーティファクトリポジトリをホストする CloudFormation および S3 バケットにアクセスするための必要な IAM アクセス許可を付与できるためです。これは AMS 管理 RFC モードで実行することもできますが、カスタマーチームは、IAM ロール用に複数の手動 RFCs を作成して、AMS によって手動でレビューされる、承認された最小限のアクセス許可のセットで反復する必要があります。DCM を使用すると、AMS マネージド RFCs モードを使用するときに、IAM ロール用に複数の手動 RFC を作成して、AMS によって手動でレビューされる最小限の許可セットを反復処理する必要がなくなります。これには時間がかかり、AMS プロセスとツールを強化するために顧客側の教育も必要です。開発者モードを使用すると、ネイティブ AWS APIs」から始めることができます。このパイプラインをセットアップする最も迅速かつ柔軟な方法は、AMS Managed-Developer モードを使用することです。デベロッパーモードは、運用統合を犠牲にしながら、最も迅速かつ簡単な方法を提供します。一方、DCM は柔軟性が低くなりますが、RFC モードと同じレベルの運用サポートを提供します。
ユースケース 4、AMS 基盤内のカスタマイズされた運用モデル: 顧客は、期限駆動型のデータセンターの終了を検討しており、エンタープライズアプリケーションの 1 つは、アプリケーション運用やインフラストラクチャ運用を含むサードパーティーの MSP によって完全に管理されています。このアプリケーションを AMS で操作できるようにリファクタリングする時間がスケジュールにないと仮定すると、カスタマーマネージドモードが適切なオプションです。お客様は、AMS マネージドランディングゾーンの自動的かつ迅速なセットアップを活用できます。一元化されたネットワークアカウントを通じて、アカウントの供給と接続を制御する一元化されたアカウント管理を活用できます。また、AMS Payer アカウントを通じてすべてのカスタマーマネージドアカウントの料金を統合することで、請求を簡素化します。お客様は、AMS マネージドアカウントに使用される標準アクセス管理とは別に、MSP を使用してカスタムアクセス管理モデルを柔軟に設定できます。これにより、カスタマーマネージドモードを使用して、オンプレミス環境から退避するというビジネス要件を満たしながら、AMS マネージド環境をセットアップできます。この場合、お客様がクラウドに移行する Windows ベースのアプリケーションも持っていて、それらをカスタマーマネージドアカウントに移動することを選択した場合、お客様はクラウド運用モデルを作成する責任があります。これは、従来の IT プロセスを変革し、人材をトレーニングする顧客の能力によっては、複雑でコストが高く、時間がかかる場合があります。お客様は、このようなワークロードを「リフトアンドシフト」して AMS マネージドアカウントにし、インフラストラクチャオペレーションを AMS にオフロードすることで、時間とコストを削減できます。
注記
お客様は、RFC または SSP モードのガバナンスフレームワークとデベロッパーモードの間でアプリケーションアカウントを移動する必要があると感じることがあります。たとえば、お客様は最初のリフトアンドシフト移行の一環として AMS マネージドモードでアプリケーションをホストできますが、時間の経過とともにアプリケーションを書き換えてクラウドネイティブの AWS サービス用に最適化したいと考えています。本番稼働前のアカウントのモードを AMS マネージド RFC から AMS マネージド開発者モードに変更し、インフラストラクチャをプロビジョニングするための柔軟性と俊敏性を提供できます。ただし、「開発者ロール」を使用してインフラストラクチャのプロビジョニングが変更されると、同じインフラストラクチャを AMS マネージド RFC モードに戻すことはできません。これは、AMS が AMS 変更管理システムの外部でプロビジョニングされたインフラストラクチャのオペレーションを保証できないためです。お客様は、AMS マネージド RFC モードを提供する新しいアプリケーションアカウントを作成し、CloudFormation テンプレートまたは AMS マネージドアカウントに取り込まれたカスタム AMIs を使用して「最適化」インフラストラクチャ設定を再デプロイする必要がある場合があります。これは、本番稼働用設定をデプロイするためのクリーンな方法です。デプロイされると、アプリケーションは規範的な AMS ガバナンスと運用の下に置かれます。カスタマーマネージドモードと AMS マネージドモード間のモードの切り替えにも同じことが当てはまります。