翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
AMS のモードとアカウントのタイプ
AWS Managed Services (AMS) モードは、各モードの特定のガバナンスフレームワークの下で AMS サービスとやり取りする方法として定義できます。ランディングゾーンの違い、マルチアカウントランディングゾーンまたは MALZ とシングルアカウントランディングゾーンまたは SALZ が記録されます。
注記
アプリケーションのデプロイと適切な AMS モードの選択の詳細については、「AMS モードとアプリケーションまたはワークロード」を参照してください。
さまざまなモードの実際のユースケースについては、「AMS モードの実際のユースケース」を参照してください。
次の表は、AMS サービスあたりのモードの説明です。
| AMS 機能 | RFC モード (以前の標準 CM モード) / OOD* | 直接変更モード | AWS Service Catalog | セルフサービスプロビジョニング/デベロッパーモード | カスタマーマネージド |
|---|---|---|---|---|---|
| ランディングゾーンの設定 | MALZ と SALZ | MALZ と SALZ | MALZ と SALZ | ||
| 変更管理 | 変更スケジュール、手動変更のレビュー、変更レコード | IAM やセキュリティグループなどの高リスクの変更の RFC モードと同じ | なし | ||
| ログ記録、モニタリング、ガードレール、イベント管理 | はい (サポートされているリソース） | なし | |||
| 継続性管理 | はい (サポートされているリソース） | 該当なし/いいえ | なし | ||
| セキュリティ管理 | インスタンスレベルのセキュリティコントロールとアカウントレベルのコントロール | アカウントレベルのコントロール | AWS 組織レベルのコントロール | ||
| パッチ管理 | あり | 該当なし/いいえ | なし | ||
| インシデントと問題の管理 | AMS がサポートするリソースの応答と解決の SLA | 結果のリソースのレスポンス SLA | なし | ||
| レポート作成 | あり | なし | |||
| サービスリクエスト管理 | あり | サポートリクエストのみ | なし | ||
*Operations On Demand (OOD) には、RFC モードを使用して、専用のリソースを通じて変更を管理するためのサービスがあります。詳細については、「Operations on Demand catalog of offerings」および「Cloud Service Delivery Manager (CSDM)」を参照してください。
注記
AMS でのセルフサービスプロビジョニングモード と はどちらも、ネイティブ AWS サービスに根ざした複雑なアーキテクチャを持つアプリケーションに適しているように見えるAMS Advanced Developer モード場合があります。ワークロードを設計するときは、ビジネスコンテキストに基づいて、運用上の優秀性と俊敏性のトレードオフを行います。これは、アプリケーションの SSP モードまたはデベロッパーモードの選択を検討する良い方法です。選択は、アプリケーションの SDLC フェーズに基づいて変更される場合があります。例: アプリケーションが本番環境に対応している場合、このモードでは AMS ガードレールが厳しくなるため、SSP モードの方が適切なオプションである可能性があります。ガードレールは、IAM 更新の RFC ベースの変更管理やアプリケーション OU レベルでSCPs などの予防的コントロールの形式で適用されます。これらのビジネス上の意思決定がエンジニアリングの優先度を左右する可能性があります。ガバナンスと運用サポートを犠牲にして、「事前生産」フェーズでアプリケーション所有者の柔軟性を高めるように最適化できます。
MALZ アーキテクチャと関連する AMS モード
AMS マルチアカウントランディングゾーン (MALZ) では、デフォルトの組織単位 (OU)、カスタマーマネージド OU、マネージド OU、または開発 OU でアプリケーションアカウント (またはリソースアカウント) を自動的にプロビジョニングできます。これらの各 OUs で作成されたアプリケーションアカウントでプロビジョニングされるインフラストラクチャは、これらの基本 OUs によって提供される特定の AMS モードの対象となります。同じアプリケーションアカウントで 2 つ以上のモードの組み合わせを見つけるのが一般的です。例えば、RFC モードと SSP モードは、トリガー関数には API Gateway と Lambda、取り込みとオーケストレーションには EC2, S3、SQS で構成されるパイプラインアーキテクチャをホストする AMS マネージドアカウントに共存できます。この場合、SSP モードは Lambda と API Gateway に適用されます。
図 1 は、AMS の基本的な OUs を通じてさまざまなモードがどのように提供されるかを示しています。AMS で新しいアプリケーションアカウントをリクエストする場合は、アカウントの OU を選択する必要があります。
MALZ アーキテクチャと関連する AMS モード
.png)
AMS は、サービスコントロールポリシー (SCP) OUs を活用します。 SCPs これは、各 AMS モードを使用してガバナンスフレームワークを適用する方法として機能します。基礎 OUs に適用されるガバナンスとセキュリティガードレール (SCPsの形式) も、カスタム/子 OUs に自動的に適用されます。子 OUs に追加の SCPs をリクエストできます。アプリケーションアカウントはモードと同じではないことを理解することが重要です。モードは、アカウント内でプロビジョニングされたインフラストラクチャに適用され、AMS と顧客間の運用責任を定義します。
図 1: MALZ アーキテクチャと関連する AMS モード
注記
「制限OUs のカスタムポリシーをリクエストできることを意味します。ポリシーは、AMS の機能に干渉して運用上の優秀性を提供しないように、case-by-caseで AMS によって承認されます。AMS ガードレールの詳細なリストについては、 ユーザーガイドの「AMS ガードレール」を参照してください。
