# Direct Change mode in AMS Direct Change mode **Topics** + [ # Getting Started with Direct Change mode ](dcm-get-started.md) + [ # Security and compliance ](dcm-security-n-compliance.md) + [ # Change management in Direct Change mode ](dcm-change-mgmt.md) + [ # Creating stacks using Direct Change mode ](dcm-creating-stacks.md) + [ # Direct Change Mode use cases ](dcm-use-cases.md) AWS Managed Services (AMS) Direct Change mode (DCM) extends AMS Advanced change management by providing native AWS access to AMS Advanced Plus and Premium accounts to provision and update AWS resources. With DCM, you have the option to use native AWS API (console or CLI/SDK) or AMS Advanced change management requests for change (RFCs), and in either case the resources and changes to them are fully supported by AMS, including monitoring, patch, backup, incident response management. Resources provisioned through DCM are registered in the AMS service knowledge management system (SKMS), joined to the AMS managed Active Directory domain (when applicable), and run AMS management agents. Use existing tooling (for example, CloudFormation, AWS SDK, and CDK) to develop and deploy AMS-managed CloudFormation stacks. **Note** Direct Change mode does not remove AMS change management RFCs. You have full access to AMS RFCs with DCM. [![AWS Videos](http://img.youtube.com/vi/https://www.youtube.com/embed/Qu1aKIUPT28?si=KrOqr8pniwfh7Nob/0.jpg)](http://www.youtube.com/watch?v=https://www.youtube.com/embed/Qu1aKIUPT28?si=KrOqr8pniwfh7Nob) # Getting Started with Direct Change mode Begin by checking prerequisites and then submitting a request for change (RFC) in your eligible AMS Advanced account. 1. Confirm that the account that you want to use with DCM meets the requirements: + The account is AMS Advanced Plus or Premium. + The account doesn't have Service Catalog enabled. We currently don't support onboarding accounts to both DCM and Service Catalog at the same time. If you are already onboarded to Service Catalog but are interested in DCM, discuss your needs with your cloud service delivery manager (CSDM). If you decide to switch from Service Catalog to DCM, offboard Service Catalog, to do that, include the ask in the request for change below. For details about Service Catalog in AMS, see [AMS and Service Catalog](https://docs.aws.amazon.com/managedservices/latest/userguide/ams-service-catalog.html). 1. Submit a request for change (RFC) using the Management \$1 Managed account \$1 Direct Change mode \$1 Enable change type (ct-3rd4781c2nnhp). For an example walkthrough, see [Direct Change mode \$1 Enable](https://docs.aws.amazon.com/managedservices/latest/ctref/management-managed-direct-change-mode-enable.html). After the CT is processed, the predefined IAM roles, `AWSManagedServicesCloudFormationAdminRole` and `AWSManagedServicesUpdateRole` are provisioned in the specified account. 1. Assign the appropriate role to the users that require DCM access using your internal federation process. **Note** You can specify any number of SAMLIdentityProviders, AWS Services, and IAM Entities (Roles, Users etc) to assume the roles. You must provide at least one: `SAMLIdentityProviderARNs`, `IAMEntityARNs`, or `AWSServicePrincipals`. For more information, consult with your company's IAM department or with your AMS cloud architect (CA). ## Direct Change mode IAM roles and policies When Direct Change mode is enabled in an account, these new IAM entities are deployed: `AWSManagedServicesCloudFormationAdminRole`: This role grants access to the CloudFormation console, create and update CloudFormation stacks, view drift reports, and create and execute CloudFormation ChangeSets. Access to this role is managed through the your SAML provider. Managed policies that are deployed and attached to the role `AWSManagedServicesCloudFormationAdminRole` are: + AMS Advanced multi-account landing zone (MALZ) Application account + AWSManagedServices\$1CloudFormationAdminPolicy1 + AWSManagedServices\$1CloudFormationAdminPolicy2 + This policy represents the permissions granted to the `AWSManagedServicesCloudFormationAdminRole`. You and partners use this policy to grant access to an existing role in the account and allow that role to launch and update CloudFormation stacks in the account. This might require additional AMS service control policy (SCP) updates to allow other IAM entities to launch CloudFormation stacks. + AMS Advanced single-account landing zone (SALZ) account + AWSManagedServices\$1CloudFormationAdminPolicy1 + AWSManagedServices\$1CloudFormationAdminPolicy2 + cdk-legacy-mode-s3-access [in-line policy] + AWS ReadOnlyAccess policy `AWSManagedServicesUpdateRole`: This role grants restricted access to downstream AWS service APIs. The role is deployed with managed policies that provide mutating and non-mutating API operations, but in general restricts mutating operations (such as Create/Delete/PUT), against certain services such as IAM, KMS,GuardDuty, VPC, AMS infrastructure resources and configuration, and so forth. Access to this role is managed through the your SAML provider. Managed policies that are deployed and attached to the role `AWSManagedServicesUpdateRole` are: + AMS Advanced multi-account landing zone Application account + AWSManagedServicesUpdateBasePolicy  + AWSManagedServicesUpdateDenyPolicy  + AWSManagedServicesUpdateDenyProvisioningPolicy  + AWSManagedServicesUpdateEC2AndRDSPolicy  + AWSManagedServicesUpdateDenyActionsOnAMSInfraPolicy + AMS Advanced single-account landing zone account + AWSManagedServicesUpdateBasePolicy  + AWSManagedServicesUpdateDenyProvisioningPolicy  + AWSManagedServicesUpdateEC2AndRDSPolicy  + AWSManagedServicesUpdateDenyActionsOnAMSInfraPolicy1  + AWSManagedServicesUpdateDenyActionsOnAMSInfraPolicy2 Besides these, the managed policy `AWSManagedServicesUpdateRole` role also has the AWS managed policy `ViewOnlyAccess` attached to it. # Security and compliance Security and compliance is a shared responsibility between AMS Advanced and you, as our customer. AMS Advanced Direct Change mode does not change this shared responsibility. ## Security in Direct Change mode AMS Advanced offers additional value with a prescriptive landing zone, a change management system, and access management. When using Direct Change mode, this responsibility model does not change. However, you should be aware of additional risks. The Direct Change Mode "Update" role (see [Direct Change mode IAM roles and policies](dcm-get-started.md#dcm-gs-iam-roles-and-policies)) provides elevated permissions allowing the entity with access to it, to make changes to infrastructure resources of AMS-supported services within your account. With elevated permissions, varied risks exist depending on the resource, service, and actions, especially in situations where an incorrect change is made due to oversight, mistake, or lack of adherence to your internal process and control framework. As per AMS Technical Standards, the following risks have been identified and recommendations are made as follows. Detailed information about AMS Technical Standards is available through AWS Artifact. To access AWS Artifact, contact your CSDM for instructions or go to [Getting Started with AWS Artifact](http://aws.amazon.com/artifact/getting-started). **AMS-STD-001: Tagging** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/managedservices/latest/userguide/dcm-security-n-compliance.html) **AMS-STD-002: Identity and Access Management (IAM)** | Standards | Does it break | Risks | Recommendations | | --- | --- | --- | --- | | 4.7 Actions, which bypass the change management process (RFC), must not be permitted such as starting or stopping of an instance, creation of S3 buckets or RDS instances, and so forth. Developer mode accounts and Self-Service Provisioned mode services (SSPS) are exempted as long as actions are performed within the boundaries of the assigned role. | Yes. The purpose of self service actions allow you to perform actions bypassing the AMS RFC system. | The secure access model is a core technical facet of AMS and an IAM user for console or programmatic access circumvents this access control. The IAM users access is not monitored by AMS change management. Access is logged in CloudTrail only. | The IAM user should be time-bounded and granted permissions based on least-privilege and need-to-know. | **AMS-STD-003: Network Security** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/managedservices/latest/userguide/dcm-security-n-compliance.html) **AMS-STD-007: Logging** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/managedservices/latest/userguide/dcm-security-n-compliance.html) Work with your internal authorization and authentication team to control the permissions to the Direct Change mode roles accordingly. ## Compliance in Direct Change mode Direct Change mode is compatible with both production and non-production workloads. It's your responsibility to ensure adherence to any compliance standards (for example, PHI, HIPAA, PCI), and to ensure that the use of Direct Change mode complies with your internal control frameworks and standards. # Change management in Direct Change mode Change management is the process that AMS Advanced uses to implement requests for change. A request for change (RFC) is a request created by either you, or AMS Advanced through the AMS Advanced interface to make a change to your managed environment and includes an AMS Advanced change type (CT) ID for a particular operation. For more information, see [Change management](https://docs.aws.amazon.com/managedservices/latest/userguide/ex-what-is.html). **Note** Direct Change mode does not remove AMS change management RFCs, you still have full access to AMS RFCs with DCM. AMS Direct Change mode (DCM) extends AMS Advanced change management by providing native AWS access to AMS Advanced Plus and Premium accounts to provision and update AWS resources. Users who have been granted Direct Change mode permission through the IAM roles, can use native AWS API access to provision and make changes to resources in their AMS Advanced accounts. The users can still use AMS Advanced change management RFCs using the same IAM roles. In both cases the resources and changes to them are fully supported by AMS, including monitoring, patch, backup, incident response management. Users who do not have the appropriate role in these accounts must use the AMS Advanced change management RFC process to make changes. ## Change management use cases For security reasons, some changes in AMS Advanced can only be done through the change management request for change (RFC) process. The `AWSManagedServicesCloudFormationAdminRole` is restricted to actions taken through CloudFormation (CFN). For more about how to create stacks through DCM, see [Creating stacks using Direct Change mode](https://docs.aws.amazon.com/managedservices/latest/userguide/dcm-creating-stacks.html). The `AWSManagedServicesUpdateRole` is restricted for the following actions. For example walkthroughs for each change type, including the Management \$1 Managed account \$1 Direct Change mode \$1 Enable (ct-3rd4781c2nnhp) change type, see the "Additional Information" section for the relevant change type in the *AMS Advanced Change Type Reference* [Change Types by Classification](https://docs.aws.amazon.com/managedservices/latest/ctref/classifications.html) section. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/managedservices/latest/userguide/dcm-change-mgmt.html) # Creating stacks using Direct Change mode There are two requirements when launching stacks in CloudFormation using the `AWSManagedServicesCloudFormationAdminRole`, in order for the stack to be managed by AMS: + The template must contain an `AmsStackTransform`. + The stack name must start with the prefix `stack-` followed by a 17 character alphanumeric string. **Note** To successfully use the `AmsStackTransform`, you must acknowledge that your stack template contains the `CAPABILITY_AUTO_EXPAND` capability in order for CloudFormation (CFN) to create or update the stack. You do this by passing the `CAPABILITY_AUTO_EXPAND` as part of your create-stack request. CFN rejects the request if this capability is not acknowledged when the `AmsStackTransform` is included in the template. The CFN console ensures that you pass this capability if you have the transform in your template, but this can be missed when you are interacting with CFN via their APIs. You must pass this capability whenever you use the following CFN API calls: [CreateChangeSet](https://docs.aws.amazon.com/AWSCloudFormation/latest/APIReference/API_CreateChangeSet.html) [ CreateStack](https://docs.aws.amazon.com/AWSCloudFormation/latest/APIReference/API_CreateStack.html#API_CreateStack_RequestParameters) [UpdateStack](https://docs.aws.amazon.com/AWSCloudFormation/latest/APIReference/API_UpdateStack.html) When creating or updating a stack with DCM, the same validations and augmentations of CFN Ingest and Stack Update CTs are performed on the stack, for more information see [CloudFormation Ingest Guidelines, Best Practices, and Limitations](https://docs.aws.amazon.com/managedservices/latest/appguide/cfn-author-templates.html). The exception to this is that the AMS default security groups (SGs) will not be attached to any stand-alone EC2 instances or EC2 instances in Auto Scaling groups (ASGs). When you create your CloudFormation template, with stand-alone EC2 instances or ASGs, you can attach the default SGs. **Note** IAM roles can now be created and managed with the `AWSManagedServicesCloudFormationAdminRole`. The AMS default SGs have ingress and egress rules that allow the instances to launch successfully and to be accessed later through SSH or RDP by AMS operations and you. If the you find that the AMS default security groups are too permissive, you can create your own SGs with more restrictive rules and attach them to your instance, as long as it still allows you and AMS operations to access the instance during incidents. The AMS default security groups are the following: + SentinelDefaultSecurityGroupPrivateOnly: Can be accessed in the CFN template through this SSM parameter `/ams/${VpcId}/SentinelDefaultSecurityGroupPrivateOnly` + SentinelDefaultSecurityGroupPrivateOnlyEgressAll: Can be accessed in the CFN template through this SSM parameter `/ams/${VpcId}/SentinelDefaultSecurityGroupPrivateOnlyEgressAll` ## AMS Transform Add a `Transform` statement to your CloudFormation template. This adds a CloudFormation macro that validates and registers the stack with AMS at launch time. **JSON **Example ``` "Transform": {     "Name": "AmsStackTransform",     "Parameters": {       "StackId": {"Ref" : "AWS::StackId"}     }   } ``` **YAML **Example ``` Transform: Name: AmsStackTransform Parameters: StackId: !Ref 'AWS::StackId' ``` Also add the `Transform` statement when updating the template of an existing stack. **JSON **Example ``` {   "AWSTemplateFormatVersion": "2010-09-09",   "Description" : "Create an SNS Topic",    "Transform": { "Name": "AmsStackTransform", "Parameters": { "StackId": {"Ref" : "AWS::StackId"} } },   "Parameters": {     "TopicName": {       "Type": "String",       "Default": "HelloWorldTopic"     }   },   "Resources": {     "SnsTopic": {       "Type": "AWS::SNS::Topic",       "Properties": {         "TopicName": {"Ref": "TopicName"}       }     }   } } ``` **YAML **Example ``` AWSTemplateFormatVersion: '2010-09-09' Description: Create an SNS Topic Transform: Name: AmsStackTransform Parameters: StackId: !Ref 'AWS::StackId' Parameters: TopicName: Type: String Default: HelloWorldTopic Resources: SnsTopic: Type: AWS::SNS::Topic Properties: TopicName: !Ref TopicName ``` ## Stack name The stack name must start with the prefix `stack-` followed by a 17 character alphanumeric string. This is to maintain compatibility with other AMS systems that operate on AMS stack IDs.  The following are examples of ways to generate compatible stack IDs: Bash: ``` echo "stack-$(env LC_CTYPE=C tr -dc 'a-z0-9' < /dev/urandom | head -c 17)" ``` Python: ``` import string import random 'stack-' + ''.join(random.choices(string.ascii_lowercase + string.digits, k=17)) ``` Powershell: ``` "stack-" + ( -join ((0x30..0x39) + ( 0x61..0x7A) | Get-Random -Count 17 | % {[char]$_}) ) ``` # Direct Change Mode use cases The following are uses cases for Direct Change Mode: **Resource provision and management through CloudFormation** + Integrate existing CloudFormation-based tooling and processes. **Ongoing resource management and updates** + Small atomic changes with low risk. + Changes that would otherwise run through a manual or automated RFC. + Tooling that requires native AWS API access. + The DCM role can be utilized if you're in the migration stage. Migration teams leverage the permissions on the DCM to create or modify stacks. + DCM roles can be used in the CI/CD pipeline to build new AMIs, create Amazon ECS tasks, and so on.