AWS Managed Services (AMS) modes can be defined as the ways of interacting with the AMS service under the specific governance framework for each mode. The landing zone differences, multi-account landing zone or MALZ and single-account landing zone or SALZ are noted.
Note
For details about application deployment and choosing the right AMS mode, see AMS modes and applications or workloads.
For real-world use cases of the different modes, see Real world use cases for AMS modes
The following table provides descriptions of the modes per AMS service.
| AMS feature | RFC mode (formerly Standard CM mode) / OOD* | Direct Change mode | AWS Service Catalog | Self-service provisioning / Developer mode | Customer Managed |
|---|---|---|---|---|---|
| Landing Zone Configuration | MALZ and SALZ | MALZ and SALZ | MALZ and SALZ | ||
| Change Management | Change scheduling, review of manual changes, and change record | Same as RFC mode for high-risk changes like IAM or security groups | None | ||
| Logging, Monitoring, Guardrails, and Event Management | Yes (supported resources) | No | |||
| Continuity management | Yes (supported resources) | Not applicable / No | No | ||
| Security management | Instance level security controls and account level controls | Account level controls | AWS Org level controls | ||
| Patch management | Yes | Not applicable / No | No | ||
| Incident and problem management | Response and resolution SLA for AMS supported resources | Response SLA for resulting resources | No | ||
| Reporting | Yes | No | |||
| Service request management | Yes | Support requests only | No | ||
*Operations On Demand (OOD) has an offering for customers using the RFC mode to manage their changes through dedicated resourcing. For more details, see the Operations on Demand catalog of offerings and talk to your cloud service delivery manager (CSDM).
Note
Self-Service Provisioning mode in AMS and AMS Advanced Developer mode may both appear to be a suitable fit for an application that has complex architecture rooted in native AWS Services. When architecting workloads, you make trade-offs between operational excellence and agility, based on your business context. This is a good way to think about selecting SSP mode or Developer mode for your application. The selection may also change based on the SDLC phase of the application. For example: When the application is production-ready, then SSP mode maybe a more appropriate option due to stricter AMS guardrails in this mode. The guardrails are enforced in the form of preventative controls like RFC-based change control for IAM updates and SCPs at the application OU level. These business decisions can drive your engineering priorities. You might optimize to increase flexibility for application owners in "pre-prod" phase at the expense of governance and operational support.
MALZ architecture and associated AMS modes
AMS multi-account landing zone (MALZ) gives you the option to automatically provision application accounts (or resource accounts) under the default Organizational Units (OU): Customer Managed OU, Managed OU, or Development OU. The infrastructure provisioned in the application accounts created under each of these OUs is subject to the specific AMS mode offered by those foundational OUs. It is common to find a mix of two or more modes in the same application account. For example: RFC mode and SSP mode can coexist in an AMS managed account that hosts pipeline architecture consisting of API Gateway and Lambda for trigger functions, and EC2, S3, and SQS for ingestion and orchestration. In this case, SSP mode would apply to Lambda and API Gateway.
Figure 1 presents how different modes are offered through the foundational OUs in AMS. When requesting a new application account in AMS, you must select the OU for the account.
MALZ architecture and associated AMS modes
.png)
AMS leverages the foundational OUs based on AWS best practices as a way to logically manage accounts using Service Control Policies (SCPs). This serves as a way to enforce the governance framework with each AMS mode. Any governance and security guardrails (in the form of SCPs) applied to the foundational OUs also get applied to the custom/child OUs automatically. Additional SCPs can be requested for the child OUs. It is important to understand that application accounts are not the same as modes. Modes are applied to the infrastructure provisioned within the accounts and define the operational responsibilities between AMS and customers.
Figure 1: MALZ architecture and associated AMS modes
Note
"Restrictive" implies that you can request custom policies for these OUs, they are approved by AMS on a case-by-case basis to ensure they don’t interfere in AMS's capabilities to provide operational excellence. For a detailed list of AMS guardrails see AMS Guardrails in the user guide.
