# MALZ network architecture
## About multi-account landing zone network architecture
Before you start the onboarding process to AWS Managed Services (AMS) Multi-account landing zone (MALZ), it is important to understand the baseline architecture, or landing zone, that AMS creates on your behalf, its components, and functions.
AMS multi-account landing zone is a multi-account architecture, pre-configured with the infrastructure to facilitate authentication, security, networking, and logging.
**Note**
For estimates of costs, see [AMS multi-account landing zone environment basic components](https://docs.aws.amazon.com/managedservices/latest/userguide/ams-sd.html#basic-components-malz).
**Topics**
+ [Service region](#service-region)
+ [Organizational units](#malz-ous)
+ [Service control policies and AWS Organization](#malz-scps)
The following diagram outlines at a high level the account structure and how infrastructure is segregated into each of the accounts:
![\[AWS account structure diagram showing management, shared services, network, security, and log archive accounts.\]](http://docs.aws.amazon.com/managedservices/latest/userguide/images/MALZ-high-level-Nov2022.png)
### Service region
All resources within an AMS multi-account landing zone are deployed within a single AWS Region of your choice, due to current cross region limitation with Active Directory and Transit Gateway.
### Organizational units
A typical AMS multi-account landing zone consists of four top-level organizational units (OUs):
+ The core Organizational unit (OU) (used to group accounts together to administer as a single unit)
+ The applications OU
+ The customer-managed OU
+ The accelerate OU
AMS-managed multi-account landing zone also enables you to create custom OUs for grouping and organizing AWS Accounts and to associate custom SCPs with them; for examples on doing this, see [ Management account \$1 Create Custom OUs](https://docs.aws.amazon.com/managedservices/latest/ctref/deployment-managed-management-account-create-custom-ous.html) and [ Management account \$1 Create Custom SCP (managed automation)](https://docs.aws.amazon.com/managedservices/latest/ctref/deployment-managed-management-account-create-custom-scp-review-required.html), respectively. AMS provides four existing OUs under which new OUs and accounts can be requested: accelerate, applications > managed, applications > development, and customer-managed.
+ accelerate OU:
This is a top-level OU in AMS multi-account landing zone (MALZ). Accounts under this OU are provisioned by AMS with an RFC (Deployment \$1 Managed landing zone \$1 Management account \$1 Create Accelerate account, change type ID: ct-2p93tyd5angmi). In these accelerate application accounts, you can benefit from accelerate operational services such as monitoring and alerting, incident management, security management, and backup management. For more details, see [AMS Accelerate accounts](https://docs.aws.amazon.com/managedservices/latest/userguide/malz-accelerate-account.html).
+ applications > managed OU:
In this sub organizational unit of the Application OU, accounts are fully managed by AMS including all operational tasks. The operational tasks include service request management, incident management, security management, continuity management, patch management, cost optimization, monitoring and event management. These tasks are carried out for your infrastructure's management. Multiple child OUs can be created as needed, until a maximum limit of nested OUs is reached for AWS organizations. For details, see [Quotas for AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_reference_limits.html).
+ applications > development OU:
Under this sub-OU of the application OU in AMS-managed landing zone, accounts are [Developer mode](https://docs.aws.amazon.com/managedservices/latest/userguide/developer-mode-section.html) accounts that provide you with elevated permissions to provision and update AWS resources outside of the AMS change management process. This OU also supports the creation of new children OU as needed.
+ customer-managed OU:
This is a top-level OU in AMS multi-account landing zone. Accounts under this OU are provisioned by AMS with an RFC. In these accounts, the operations of workloads and AWS resources are your responsibility. This OU also supports the creation of new children OU as needed.
As a best practice, we recommend that accounts under these OUs and custom-requested sub-OUs be grouped based on their functionalities and policies.
### Service control policies and AWS Organization
AWS provides service control policies (SCPs) for permissions management in an AWS Organization. SCPs are used to define additional guardrails for what actions users can perform in which OUs. By default, AMS provides a set of SCPs deployed in management accounts which provide protections at different default OU levels. For SCP restrictions, please contact your CSDM.
You can also create custom SCPs and attach them to specific OUs. They can be requested from your Management account using change type ct-33ste5yc7hprs. AMS then reviews the custom SCPs requested before applying them to the target OUs. For examples, see [ Management account \$1 Create Custom OUs](https://docs.aws.amazon.com/managedservices/latest/ctref/deployment-managed-management-account-create-custom-ous.html) and [ Management account \$1 Create Custom SCP (managed automation)](https://docs.aws.amazon.com/managedservices/latest/ctref/deployment-managed-management-account-create-custom-scp-review-required.html).
# Choosing single MALZ or multiple MALZs
The following table provides some high level considerations on deciding between a single multi-account landing zone (MALZ) vs multiple multi-account landing zones (for example, two multi-account landing zones - Prod and non-Prod). In general, the choice depends upon individual needs, legal requirements, and operating practices.
**Single multi-account landing zone vs. multiple multi-account landing zones**
| Entity | Single AMS landing zone | Multiple (two or more) landing zones |
| --- | --- | --- |
| Base cost | Lower, optimized at approximately \$13,000 per month. | Higher, an additional cost of approximately \$13,000 per environment. |
| Billing | Single bill, due to single Billing/ Management account. | Separate bill for each multi-account landing zone. Currently AWS Org does not support multi-Management accounts with a single bill. |
| Portability of existing reserved instances (RIs) | Low. AWS RIs are currently not convertible across multiple billing accounts. You would repurpose existing RIs for multi-account landing zone. | Lower. You would repurpose and distribute RIs across all multi-account landing zone. |
| Product tiering discounts | High. See [ Volume discounts.](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/useconsolidatedbilling-discounts.html) | Low. See [ Volume discounts.](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/useconsolidatedbilling-discounts.html) |
| Initial setup overhead (on project/migration timelines) | Low. Active Directory, networking and single sign-on (SSO) integrations once only. | High. You would perform Active Directory, network integration, and SSO integrations for every landing zone. This could cause potential delays to any migration project. |
| Common services configurability | Low efforts. You configure common/shared services like DNS, backup, monitoring, logging etc. | High efforts. Additional planning is required to address where the common infrastructure or services will be sitting. Traffic traversing across multiple transit gateways (TGWs) in each landing zone, could lead to extra cost. |
| Scalability | Medium. AMS has a current practical limit of 150 accounts per multi-account landing zone. Multiple teams or vendors running applications in same account could have access to stacks owned by different teams. This limitation can be mitigated by controlling access to application-specific stacks at the ServiceNow layer (by integrating the AMS ServiceNow Connector application and making use of tags). Ask AMS technical delivery managers (TDMs) or cloud architects (CAs) how to implement this. | High. Ability to leverage multiple multi-account landing zone to distribute the accounts while achieving an account or application level of segregation. Managing large numbers of accounts could lead to operational or cost overhead. |
| Operational Risk | (Depends) Low. Operational integration and readiness once only. Less chance of process drifts. | (Depends) Low. Multiple integration and operational activities. Drift in multiple landing zones over the period could lead to operational risks. |
| Multi AWS Region | Single AWS Region. AMS multi-account landing zone is restricted to a single AWS Region. To span multiple AWS Regions, use multiple multi-account landing zone. | Multi AWS Region. With multiple multi-account landing zones, you can have each MALZ deployed in one region and interconnect them using transit gateway (TGW) peering. |
| Account migration or portability | Yes. Moving accounts from one OU to another within the same AWS Organization is possible. | No. AMS doesn't support migration of an account across landing zones; that is, across AWS Organizations. Workloads can reach across landing zones with transit gateway (TGW) or VPC peering. |
| Change management | Medium. Making destructive changes to common components like TGW, Active Directory (AD), or outbound (egress) can impact all workloads in a multi-account landing zone. However, changes to AMS-managed components are tested internally and are pushed in rolling updates. | Low. Making destructive changes to common components like TGW, AD, or outbound (egress) can impact only the workloads in that specific multi-account landing zone. |
| Data and access controls | (Depends) Low control if you’d like to connect to different on-premise ADs and networks for Prod vs Non-Prod workloads. SAML federation, TGW domains, and security groups (SGs) can help implement required controls too. | (Depends) High control if you’d like to connect to different on-premise ADs and networks for Prod vs Non-Prod workloads. Use separate landing zones for strict compliance requirements. |
| Compliance and Security | (Depends) Low if there are strict compliance needs to completely segregate material vs non-material workloads. AMS standard preventative and detective controls in place. | (Depends) High as multiple multi-account landing zone could help achieve strict compliance requirements by completely segregating material vs non-material workloads. AMS standard preventative and detective controls in place. |
**Recommendation**: Without strict Compliance or multi-Region need, starting with single AMS multi-account landing zone would strike a good balance among cost, security, operational excellence, and migration complexity. You can always setup additional landing zone, if any account or business constraints are encountered.
# Single multi-account landing zone vs. Multiple multi-account landing zone FAQs
Some commonly asked questions when choosing to set up a single multi-account landing zone or multiple multi-account landing zones:
**Q1**: Can I start with a single multi-account landing zone and move to multiple multi-account landing zone, if any account limits or business constraints are encountered?
**A**: Yes. You can choose to set up another multi-account landing zone at any given time:
+ A new billing payer account will be required to be setup (currently AWS doesn’t support multi-payer accounts in a single AWS org).
+ Multi-Account Landing Zone base build takes up to 2 weeks lead time once the multi-account landing zone questionnaire is filled out.
+ Every multi-account landing zone means an addition of \$13K USD / month running cost.
+ N/W, AD, DNS, and SSO integration will be required to establish for new MALZ.
+ Any Reserved Instances (RIs), Cost Saving plans will be needed to be setup for the new multi-account landing zone (RIs are not transferrable).
+ AMS multi-account landing zone doesn't support migration of an account across multi-account landing zone accounts; for example, across AWS Orgs. However, to move applications from one account to another is possible using standard migration methods.
**Q2**: What is AMS approach to MALZ updates/changes to underlying/shared infrastructure and quantify the risk to customers? Provide details on what assurances are wrapped into the process. How do Customers get comfortable that MALZ updates/changes will not impact customers? Is there any measures Customer need to take to prevent disruption?
**A**: AMS follows a strict change methodology using internal tools that enables us to define, review, schedule and execute changes to customers' environments.
The process to release updates enforces code reviews, integration testing, deployment in gamma and beta environments, and additional baking time and testing in beta and gamma environments before releasing to customers environments. All releases include rollback procedures and are closely monitored by the releases team and the team who created and requested the change. The scope of the releases are confined to stacks owned and provisioned by AMS. On average, we execute at least one release per week.
In addition:
+ AMS SLA are applicable. As per AMS service description any incident raised post shared infra maintenance activity would adhere to entitled SLA for resolution or credits.
+ No special preventive measures are required by Customers to prevent disruption to common infrastructure. Customers have Read-Only permissions at AWS Org or Core OU accounts, so customers can’t make any destructive changes to the MALZ core env. All customer’s requests to Core infrastructure requires AMS review and approval.
+ Customers can test certain Org level changes like SCPs/Roles at individual non-prod account levels before propagating changes at App OU level. It is on the AMS roadmap to allow multiple APP OUs (Q2 2020), which would further alleviate risk in making some of the ORG level changes. MALZ team has already released separate OU for “Build Mode” accounts, to ensure clear segregation of customer ownership and separate controls.
+ Most of these are changes that allow AMS to operate the workload in effective and efficient manner and does not necessarily impact customers workload. Where AMS believes a shared infra change can have an impact to customers’ workload they are then aligned with customers’ change window.
**High level recommendation**, start with multiple multi-account landing zones if:
+ If it helps you achieve any specific compliance.
+ If you need to use Multi-Region.
+ If you have different on-prem ADs and Networks for Prod/Material vs Non-Prod/Non-Material workloads, to clearly segregate b/w the workloads.
# Multi-Account Landing Zone accounts
**Topics**
+ [Management account](management-account.md)
+ [Networking account](networking-account.md)
+ [Shared Services account](shared-services-account.md)
+ [Log Archive account](logging-account.md)
+ [Security account](security-account.md)
+ [Application account types](application-account.md)
+ [AMS Tools account (migrating workloads)](tools-account.md)
# Management account
The management account is your initial AWS account when you begin onboarding with AMS. It utilizes AWS Organizations as a management account (also known as the payer account that pays the charges of all the member accounts), which gives the account the ability to create and financially manage member accounts. It contains the AWS landing zone (ALZ) framework, account configuration stack sets, AWS Organization service control policies (SCPs), etc.
For more information on using a management account, see [Best practices for the management account](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_best-practices_mgmt-acct.html).
The following diagram provides a high-level overview of the resources contained in the management account.
![\[Management account overview showing AMS Customer Region and various AWS services and features.\]](http://docs.aws.amazon.com/managedservices/latest/userguide/images/management-account.png)
## Resources in the management account
Other than the above standard services, no additional AWS resources are created in the management account during onboarding. The following inputs are required during onboarding to AMS:
+ *Management account ID*: AWS Account ID that is created initially by you.
+ *Core Accounts emails*: Provide the emails to be associated with each of the core accounts: Networking, Shared Services, Logging, and Security account.
+ *Service Region*: Provide the AWS region to which all resources of your AMS landing zone will be deployed.
# Networking account
The Networking account serves as the central hub for network routing between AMS multi-account landing zone accounts, your on-premises network, and egress traffic out to the Internet. In addition, this account contains public DMZ bastions that are the entry point for AMS engineers to access hosts in the AMS environment. For details, see the following high-level diagram of the networking account below.
![\[Network architecture diagram showing Egress VPC, DMZ VPC, and connections to on-premises and internet.\]](http://docs.aws.amazon.com/managedservices/latest/userguide/images/malzNetworkAccount.png)
# Networking account architecture
The following diagram depicts the AMS multi-account landing zone environment, showcasing network traffic flows across account, and is an example of a highly-available setup.
![\[AWS network architecture diagram showing multiple accounts, VPCs, and connectivity components.\]](http://docs.aws.amazon.com/managedservices/latest/userguide/images/AMS_MALZ_NET_FLOW-2.png)
![\[Diagram showing network traffic flow between AWS accounts, VPCs, and internet gateways.\]](http://docs.aws.amazon.com/managedservices/latest/userguide/images/AMS_MALZ_NET_FLOW_LEGEND.png)
AMS configures all aspects of networking for you based on our standard templates and your selected options provided during onboarding. A standard AWS network design is applied to your AWS account, and a VPC is created for you and connected to AMS by either VPN or Direct Connect. For more information about Direct Connect, see [AWS Direct Connect](https://aws.amazon.com/directconnect/). Standard VPCs include the DMZ, shared services, and an application subnet. During the onboarding process, additional VPCs might be requested and created to match your needs (for example, customer divisions, partners). After onboarding, you are provided with a network diagram: an environment document that explains how your network has been set up.
**Note**
For information about default service limits and constraints for all active services, see the [AWS Service Limits](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html) documentation.
Our network design is built around the Amazon ["Principle of Least Privilege"](https://en.wikipedia.org/wiki/Principle_of_least_privilege). In order to accomplish this, we route all traffic, ingress and egress, through a DMZ, except traffic coming from a trusted network. The only trusted network is the one configured between your on-premises environment and the VPC through the use of a VPN and/or an AWS Direct Connect (DX). Access is granted through the use of bastion instances, thereby preventing direct access to any production resources. All of your applications and resources reside inside private subnets that are reachable through public load balancers. Public egress traffic flows through the NAT Gateways in the egress VPC (in the Networking account) to the Internet Gateway and then to the Internet. Alternatively, the traffic can flow over your VPN or Direct Connect to your on-premises environment.
# Private network connectivity to AMS Multi-account landing zone environment
AWS offers private connectivity via either virtual private network (VPN) connectivity, or dedicated lines with AWS Direct Connect. Private connectivity in your multi-account environment, is set up using one of the methods described next:
+ Centralized Edge connectivity using Transit Gateway
+ Connecting Direct Connect (DX) and/or VPN to account virtual private clouds (VPCs)
# Centralized edge connectivity using transit gateway
AWS Transit Gateway is a service that enables you to connect your VPCs and your on-premises networks to a single gateway. Transit gateway (TGW) can be used to consolidate your existing edge connectivity and route it through a single ingress/egress point. Transit gateway is created in the networking account of your AMS multi-account environment. For more details about transit gateway, see [AWS Transit Gateway](https://aws.amazon.com/transit-gateway/).
AWS Direct Connect (DX) gateway is used to connect your DX connection over a transit virtual interface to the VPCs or VPNs that are attached to your transit gateway. You associate a Direct Connect gateway with the transit gateway. Then, create a transit virtual interface for your AWS Direct Connect connection to the Direct Connect gateway. For information on DX virtual interfaces, see [ AWS Direct Connect Virtual Interfaces](https://docs.aws.amazon.com/directconnect/latest/UserGuide/WorkingWithVirtualInterfaces.html).
This configuration offers the following benefits. You can:
+ Manage a single connection for multiple VPCs or VPNs that are in the same AWS Region.
+ Advertise prefixes from on-premises to AWS, and from AWS to on-premises.
**Note**
For information about using a DX with AWS services, see the Resiliency Toolkit section [Classic](https://docs.aws.amazon.com/directconnect/latest/UserGuide/getstarted.html). For more information, see [Transit Gateway associations](https://docs.aws.amazon.com/directconnect/latest/UserGuide/direct-connect-transit-gateways.html).
![\[AWS Transit Gateway network diagram showing connections to VPCs and Direct Connect.\]](http://docs.aws.amazon.com/managedservices/latest/userguide/images/malz-cent-edge.png)
To increase the resiliency of your connectivity, we recommend that you attach at least two transit virtual interfaces from different AWS Direct Connect locations to the Direct Connect gateway. For more information, see the [AWS Direct Connect resiliency recommendation](https://aws.amazon.com/directconnect/resiliency-recommendation/).
# Connecting DX or VPN to account VPCs
With this option, the VPCs in your AMS multi-account landing zone environments are directly connected to Direct Connect or VPN. The traffic directly flows from the VPCs to Direct Connect or VPN without traversing through the transit gateway.
# Resources in the networking account
As shown in the networking account diagram, the following components are created in the account and require your input.
The Networking account contains two VPCs: **Egress VPC** and **DMZ VPC** also known as the **Perimeter** VPC.
# AWS Network Manager
AWS Network Manager is a service that enables you to visualize your transit gateway (TGW) networks at no additional cost to AMS. It provides centralized network monitoring on both AWS resources and on on-premises networks, a single global view of their private network in a topology diagram and in a geographical map, and utilization metrics, such as bytes in/out, packets in/out, packets dropped, and alerts for changes in the topology, routing, and up/down connection status. For information, see [AWS Network Manager](https://aws.amazon.com/transit-gateway/network-manager/).
Use one of the following roles to access this resource:
+ AWSManagedServicesCaseRole
+ AWSManagedServicesReadOnlyRole
+ AWSManagedServicesChangeManagementRole
# Egress VPC
The Egress VPC is primarily used for egress traffic to the Internet and is composed of public/private subnets in up to three availability zones (AZs). Network address translation (NAT) gateways are provisioned in the public subnets, and transit gateway (TGW) VPC attachments are created in the private subnets. Egress, or outbound, internet traffic from all networks enter through the private subnet via TGW, where it is then routed to a NAT via VPC route tables.
For your VPCs that contain public-facing applications in a public subnet, traffic originating from the internet is contained within that VPC. Return traffic is not routed to the TGW or Egress VPC, but routed back through the internet gateway (IGW) in the VPC.
**Note**
Networking VPC CIDR range: When you create a VPC, you must specify a range of IPv4 addresses for the VPC in the form of a Classless Inter-Domain Routing (CIDR) block; for example, 10.0.16.0/24. This is the primary CIDR block for your VPC.
The AMS multi-account landing zone team recommends the range of 24 (with more IP address) to provide some buffer in case other resources/appliances, are deployed in the future.
# Perimeter (DMZ) VPC
The Perimeter, or DMZ, VPC contains the necessary resources for AMS Operations engineers to access AMS networks. It contains public subnets across 2-3 AZs, with SSH Bastions hosts in an Auto Scaling group (ASG) for AMS Operations engineers to log into or tunnel through. The security groups attached to the DMZ bastions contain port 22 inbound rules from **Amazon Corp Networks**.
*DMZ VPC CIDR range:* When you create a VPC, you must specify a range of IPv4 addresses for the VPC in the form of a Classless Inter-Domain Routing (CIDR) block; for example, 10.0.16.0/24. This is the primary CIDR block for your VPC.
**Note**
The AMS team recommends the range of 24 (with more IP address) to provide some buffer in case other resources, such as a firewall, are deployed in the future.
# AWS Transit Gateway
AWS Transit Gateway (TGW) is a service that enables you to connect your Amazon Virtual Private Clouds (VPCs) and your on-premises networks to a single gateway. Transit gateway is the networking backbone that handles the routing between AMS account networks and external networks. For information about Transit Gateway, see [AWS Transit Gateway](https://aws.amazon.com/transit-gateway/).
Provide the following input to create this resource:
+ *Transit Gateway ASN number*\$1: Provide the private Autonomous System Number (ASN) for your transit gateway. This should be the ASN for the AWS side of a Border Gateway Protocol (BGP) session. The range is 64512 to 65534 for 16-bit ASNs.
# Shared Services account
The Shared Services account serves as the central hub for most AMS data plane services. The account contains infrastructure and resources required for access management (AD), end-point security management (Trend Micro), and it contains the customer bastions (SSH/RDP). A high-level overview of the resources contained within Shared Services Account is shown in the following graphic.
![\[Diagram of Shared Services Account architecture with VPC, subnets, and various AWS services.\]](http://docs.aws.amazon.com/managedservices/latest/userguide/images/malzSharedServicesAccount2.png)
The Shared Services VPC is composed of the AD subnet, the EPS subnet, and the customer bastions subnet in the three availability zones (AZs). The resources created in the Shared Services VPC are listed below and require your input.
+ *Shared Services VPC CIDR range:* When you create a VPC, you must specify a range of IPv4 addresses for the VPC in the form of a Classless Inter-Domain Routing (CIDR) block; for example, 10.0.1.0/24. This is the primary CIDR block for your VPC.
**Note**
The AMS team recommends the range of /23.
+ *Active Directory Details*: Microsoft Active Directory (AD) is utilized for user/resource management, authentication/authorization, and DNS, across all of your AMS multi-account landing zone accounts. AMS AD is also configured with a one-way trust to your Active Directory for trust-based authentication. The following input is required to create the AD:
+ Domain Fully Qualified Domain Name (FQDN): The fully qualified domain name for the AWS Managed Microsoft AD directory. The domain should not be an existing domain or child domain of an existing domain in your network.
+ Domain NetBIOS Name: If you don't specify a NetBIOS name, AMS defaults the name to the first part of your directory DNS. For example, corp for the directory DNS corp.example.com.
+ *Trend Micro – endpoint protection security (EPS)*: Trend Micro endpoint protection (EPS) is the primary component within AMS for operating system security. The system is comprised of Deep Security Manager (DSM), EC2 instances, relay EC2 instances, and an agent present within all data plane and customer EC2 instances.
You must assume the `EPSMarketplaceSubscriptionRole` in the Shared Services account, and subscribe to either the Trend Micro Deep Security (BYOL) AMI, or the Trend Micro Deep Security (Marketplace).
The following default inputs are required to create EPS (if you want to change from the defaults):
+ Relay Instance Type: Default Value - m5.large
+ DSM Instance Type: Default Value - m5.xlarge
+ DB Instance Size: Default Value - 200 GB
+ RDS Instance Type: Default Value - db.m5.large
+ *Customer bastions*: You are provided with SSH or RDP bastions (or both) in the Shared Services Account, to access other hosts in your AMS environment. In order to access the AMS network as a user (SSH/RDP), you must use "customer" Bastions as the entry point. The network path originates from the on-premise network, goes through DX/VPN to the transit gateway (TGW), and then is routed to the Shared Services VPC. Once you are able to access the bastion, you can jump to other hosts in the AMS environment, provided that the access request has been granted.
+ The following inputs are required for SSH bastions.
+ SSH Bastion Desired Instance Capacity: Default Value - 2.
+ SSH Bastion Maximum Instances: Default Value - 4.
+ SSH Bastion Minimum Instances: Default Value -2.
+ SSH Bastion Instance Type: Default Value - m5.large (can be changed to save costs; for example a t3.medium).
+ SSH Bastion Ingress CIDRs: IP address ranges from which users in your network access SSH Bastions.
+ The following inputs are required for Windows RDP bastions.
+ RDP Bastion Instance Type: Default Value - t3.medium.
+ RDP Bastion Desired Minimum Sessions: Default Value - 2.
+ RDP Maximum Sessions: Default Value -10.
+ RDP Bastion Configuration Type: You can choose one of the below configuration
+ SecureStandard = A user receives one bastion and only one user can connect to the bastion.
+ SecureHA = A user receives two bastions in two different AZ's to connect to and only one user can connect to the bastion.
+ SharedStandard = A user receives one bastion to connect to and two users can connect to the same bastion at once.
+ SharedHA = A user receives two bastions in two different AZ's to connect to and two users can connect to the same bastion at once.
+ Customer RDP Ingress CIDRs: IP address ranges from which users in your network will access RDP Bastions.
# Updates to shared services: Multi-Account Landing Zone
AMS applies data plane releases to managed accounts on a monthly basis, without prior notice.
AMS uses the core OU to provide shared services such as access, networking, EPS, log storage, alert aggregation in your Multi-Account Landing Zone. AMS is responsible for addressing vulnerabilities, patching, and deployments of these shared services. AMS regularly updates the resources used for providing these shared services so that users have access to latest features, and security updates. The updates typically happen on a monthly basis. Resources that are part of these updates are:
+ Accounts that are part of the core OU.
The management account, shared services account, network account, security account, and log archive account have resources for RDP and SSH bastions, proxies, management hosts, and endpoint security (EPS), that are typically updated every month. AMS uses immutable EC2 deployments as part of the shared services infrastructure.
+ New AMS AMIs incorporating the latest updates.
**Note**
AMS operators utilize an internal alarm suppression change type (CT) when executing data plane changes and the RFC for that CT appears in your RFC list. This is because, as the data plane release is deployed, various infrastructure may be shut down, rebooted, taken offline, or there may be CPU spikes or other effects of the deployment that trigger alarms that, during the data plane deployment, are extraneous. Once the deployment is complete, all infrastructure is verified to be running properly and alarms are re-enabled.
# Log Archive account
The Log Archive account serves as the central hub for archiving logs across your AMS multi-account landing zone environment. There is an S3 bucket in the account that contains copies of AWS CloudTrail and AWS Config log files from each of the AMS multi-account landing zone environment accounts. You could use this account for your Centralised Logging solution with AWS Firehose, or Splunk, and so forth. AMS access to this account is limited to a few users; restricted to auditors and security teams for compliance and forensic investigations related to account activity.
![\[Log Archive Account diagram showing Aggregated CloudTrail Logs and Aggregated Config Logs icons.\]](http://docs.aws.amazon.com/managedservices/latest/userguide/images/malzLogAccount.png)
# Security account
The Security account is the central hub for housing security related operations and the main point for funneling notifications and alerts to the AMS control plane services. In addition, the Security account houses the Amazon Guard Duty management account and the AWS Config aggregator.
![\[Security Account diagram showing GuardDuty Master, Simple Notification System, and Config Aggregator.\]](http://docs.aws.amazon.com/managedservices/latest/userguide/images/malzSecurityAccount.png)
# Application account types
Application accounts are AWS accounts within the AMS-managed landing zone architecture that you use to host your workloads. AMS offers three types of Application accounts:
+ [AMS-managed application accounts](application-account-ams-managed.md)
+ [AMS Accelerate accounts](malz-accelerate-account.md)
+ [Customer Managed application accounts](application-account-cust-man.md)
Application accounts are grouped in different OUs in AWS Organizations depending on the Application account type:
+ Root OU:
1. Applications OU
+ Managed OU: AMS-managed accounts
+ Development OU: AMS-managed accounts with Developer mode enabled
1. Accelerate OU: AMS Accelerate Application accounts
1. Customer-managed OU: Customer-managed Application accounts
Application accounts are provisioned through an RFC submitted from the Management account:
+ Create Application Account With VPC [ct-1zdasmc2ewzrs](https://docs.aws.amazon.com/managedservices/latest/ctref/deployment-managed-management-account-create-application-account-with-vpc.html)
+ Create Accelerate Account [ct-2p93tyd5angmi](https://docs.aws.amazon.com/managedservices/latest/ctref/deployment-managed-management-account-create-accelerate-account.html)
+ Create Customer-Managed Application Account [ct-3pwbixz27n3tn](https://docs.aws.amazon.com/managedservices/latest/ctref/deployment-managed-management-account-create-customer-managed-application-account.html)
# AMS-managed application accounts
Application accounts that are fully managed by AMS are referred to as AMS-managed application accounts, where some or all operational tasks, like service request management, incident management, security management, continuity management (backup), patch management, cost-optimization, or monitoring and event management of infrastructure, are performed by AMS.
The amount of tasks performed by AMS depends on the Change Management mode that you select. AMS-managed accounts support different modes for change management:
+ [RFC mode](rfc-mode.md)
+ [Direct Change mode in AMS](direct-change-mode-section.md)
+ [AMS and AWS Service Catalog](ams-service-catalog-section.md)
+ [AMS Advanced Developer mode](developer-mode-section.md)
+ [Self-Service Provisioning mode in AMS](self-service-provisioning-section.md)
For more information about change management and different modes, see [Change management modes](using-change-management.md).
There are some AWS services that you can use in your AMS-managed account without AMS management. The list of these AWS services and how to add them into your AMS account are described in the [Self-service provisioning](https://docs.aws.amazon.com/managedservices/latest/userguide/self-service-provisioning-section.html) section.
# AMS Accelerate accounts
AMS Accelerate is the AMS operations plan that can operate AWS infrastructure supporting workloads. You can benefit from AMS Accelerate operational services such as monitoring and alerting, incident management, security management, and backup management, without going through a new migration, experiencing downtime, or changing how you use AWS. AMS Accelerate also offers an optional patch add-on for EC2 based workloads that require regular patching.
With AMS Accelerate you have the freedom to use, configure, and deploy all AWS services natively, or with your preferred tools. You will use your preferred access and change mechanisms while AMS consistently applies proven practices that help scale your team, optimize costs, increase security and efficiency, and improve resiliency.
**Note**
AMS Accelerate accounts in AMS Advanced do not have AMS change management (RFCs) or the AMS Advanced console. Instead, they have the AMS Accelerate console and functionality.
Accelerate accounts can only be provisioned from your AMS multi-account landing zone Management account. Accelerate offers different operational capabilities. To learn more see the [Accelerate service description](https://docs.aws.amazon.com/managedservices/latest/accelerate-guide/acc-sd.html).
+ You will continue to enjoy some of the features from the multi-account landing zone (MALZ) core accounts such as centralized logging, single billing, Config Aggregator in the security account and SCPs.
+ AMS Accelerate does not provide some AMS Advanced services like EPS, Access management, Change management and provisioning. We recommend you follow the next steps to gain access and configure the transit gateway (TGW).
For more details about Accelerate, see [What is Accelerate](https://docs.aws.amazon.com/managedservices/latest/accelerate-guide/what-is-acc.html).
## Creating your Accelerate account
To create an Accelerate account, follow the steps outlined here [ Create an Accelerate account](https://docs.aws.amazon.com/managedservices/latest/ctref/deployment-managed-management-account-create-accelerate-account.html#deployment-managed-management-account-create-accelerate-account-info).
## Accessing your Accelerate account
After you provision an Accelerate account in your multi-account landing zone (MALZ) account, a role with [Administrative access](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html#jf_administrator) permissions, `AccelerateDefaultAdminRole`, is in the account for you to assume.
To access the new Accelerate account:
1. Log into the IAM console for the management account with the `CustomerDefaultAssumeRole` role.
1. In the IAM console, on the navigation bar, choose your username.
1. Choose **Switch Role**. If this is the first time choosing this option, a page appears with more information. After reading it, choose **Switch Role**. If you clear your browser cookies, this page can appear again.
1. On the **Switch Role** page, type the Accelerate account ID and the name of the role to assume: `AccelerateDefaultAdminRole`.
Now that you have access, you can create new IAM Roles to continue to access your environment. If you would like to leverage SAML Federation for your Accelerate account, see [Enabling SAML 2.0 federated users to access the AWS Management Console](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_enable-console-saml.html).
## Connecting your Accelerate account with Transit Gateway
AMS does not manage the network setup of an Accelerate account. You have the option of managing your own network using AWS APIs (see [Networking Solutions](https://aws.amazon.com/solutionspace/networking/)) or connecting to the MALZ network managed by AMS, using the existing Transit Gateway (TGW) deployed in AMS MALZ.
**Note**
You can only have a VPC attached to the TGW if the Accelerate account is in the same AWS Region. For more information see [Transit gateways](https://docs.aws.amazon.com/vpc/latest/tgw/tgw-transit-gateways.html).
To add your Accelerate account to Transit Gateway, request a new route using the [ Deployment \$1 Managed landing zone \$1 Networking account \$1 Add static route](https://docs.aws.amazon.com/managedservices/latest/ctref/deployment-managed-networking-account-add-static-route.html) (ct-3r2ckznmt0a59) change type, include this information:
+ **Blackhole**: True to indicate that the route's target isn't available. Do this when the traffic for the static route is to be dropped by the Transit Gateway. False to route the traffic to the specified TGW attachment ID. Default value is false.
+ **DestinationCidrBlock**: The IPV4 CIDR range used for destination matches. Routing decisions are based on the most specific match. Example: 10.0.2.0/24.
+ **TransitGatewayAttachmentId**: The TGW Attachment ID that will serve as the route table target. If **Blackhole** is false, this parameter is required, otherwise leave this parameter blank. Example: tgw-attach-04eb40d1e14ec7272.
+ **TransitGatewayRouteTableId**: The ID of the TGW route table. Example: tgw-rtb-06ddc751c0c0c881c.
Create routes in the TGW route tables to connect to this VPC:
1. By default this VPC will not be able to communicate with any of the other VPCs in your MALZ network.
1. Decide with your solutions architect what VPCs you want this Accelerate VPC to communicate with.
1. Submit a [ Deployment \$1 Managed landing zone \$1 Networking account \$1 Add static route](https://docs.aws.amazon.com/managedservices/latest/ctref/deployment-managed-networking-account-add-static-route.html) (ct-3r2ckznmt0a59) change type, include this information:
+ **Blackhole**: True to indicate that the route's target isn't available. Do this when the traffic for the static route is to be dropped by the Transit Gateway. False to route the traffic to the specified TGW attachment ID. Default value is false.
+ **DestinationCidrBlock**: The IPV4 CIDR range used for destination matches. Routing decisions are based on the most specific match. Example: 10.0.2.0/24.
+ **TransitGatewayAttachmentId**: The TGW Attachment ID that will serve as the route table target. If **Blackhole** is false, this parameter is required, otherwise leave this parameter blank. Example: tgw-attach-04eb40d1e14ec7272.
+ **TransitGatewayRouteTableId**: The ID of the TGW route table. Example: tgw-rtb-06ddc751c0c0c881c.
**Connecting a new Accelerate account VPC to the AMS Multi-Account Landing Zone network (creating a TGW VPC attachment)**:
1. In your multi-account landing zone Networking account, open the [Amazon VPC console](https://console.aws.amazon.com/vpc/).
1. On the navigation pane, choose **Transit Gateways**. Record the TGW ID of the transit gateway you see.
1. In your Accelerate account, open the [Amazon VPC console](https://console.aws.amazon.com/vpc/).
1. In the navigation pane, choose **Transit Gateway Attachments** > **Create Transit Gateway Attachment**. Make these choices:
+ For the **Transit Gateway ID**, choose the transit gateway ID you recorded in Step 2.
+ For **Attachment type**, choose **VPC**.
+ Under **VPC Attachment**, optionally type a name for **Attachment name tag**.
+ Choose whether to enable **DNS Support** and **IPv6 Support**.
+ For **VPC ID**, choose the VPC to attach to the transit gateway. This VPC must have at least one subnet associated with it.
+ For **Subnet IDs**, select one subnet for each Availability Zone to be used by the transit gateway to route traffic. You must select at least one subnet. You can select only one subnet per Availability Zone.
1. Choose **Create attachment**. Record the ID of the newly created TGW Attachment.
**Associating the TGW attachment to a route table**:
1. Decide which TGW route table you want to associate the VPC with. We recommend creating a new application route table for Accelerate account VPCs using Deployment \$1 Managed landing zone \$1 Networking account \$1 Create transit gateway route table (ct-3dscwaeyi6cup) change type.
1. Submit a [ Management \$1 Managed landing zone \$1 Networking account \$1 Associate TGW attachment](https://docs.aws.amazon.com/managedservices/latest/ctref/management-managed-networking-account-associate-tgw-attachment.html) (ct-3nmhh0qr338q6) RFC on the Networking account to associate the VPC or TGW attachment to the route table you select.
**Create routes in the TGW route tables to connect to this VPC**:
1. By default, this VPC will not be able to communicate with any of the other VPCs in your multi-account landing zone network.
1. Decide with your solutions architect what VPCs you want this Accelerate account VPC to communicate with.
1. Submit a [ Deployment \$1 Managed landing zone \$1 Networking account \$1 Add static route](https://docs.aws.amazon.com/managedservices/latest/ctref/deployment-managed-networking-account-add-static-route.html) (ct-3r2ckznmt0a59) RFC against the networking account to create the TGW routes you need.
**Configuring your VPC Route tables to point at the AMS multi-account landing zone transit gateway**:
1. Decide with your solutions architect what traffic you want to send to the AMS Multi-Account Landing Zone transit gateway.
1. Submit a [ Deployment \$1 Managed landing zone \$1 Networking account \$1 Add static route](https://docs.aws.amazon.com/managedservices/latest/ctref/deployment-managed-networking-account-add-static-route.html) (ct-3r2ckznmt0a59) RFC against the networking account to create the TGW routes you need.
# Customer Managed application accounts
You can create accounts that AMS doesn't manage in the standard way. Those accounts are called Customer Managed accounts and they give you full control to self-operate the infrastructure within the accounts while enjoying the benefits of the centralized architecture managed by AMS.
Customer Managed accounts do not have access to the AMS console or any of the services we provide (patch, backup, and so on).
Customer Managed accounts can only be provisioned from your AMS multi-account landing zone management account.
Different AMS modes work with Application accounts differently; to learn more about the modes, see [AWS Managed Services modes](https://docs.aws.amazon.com/managedservices/latest/onboardingguide/ams-modes.html).
To create your Customer Managed application account, see [ Management account \$1 Create Customer-Managed Application Account](https://docs.aws.amazon.com/managedservices/latest/ctref/deployment-managed-management-account-create-customer-managed-application-account.html).
To delete a Customer Managed application account, use [ Management account \$1 Offboard Application Account](https://docs.aws.amazon.com/managedservices/latest/ctref/management-managed-management-account-offboard-application-account.html). (The [ Confirm Offboarding](https://docs.aws.amazon.com/managedservices/latest/ctref/management-managed-application-account-confirm-offboarding.html) CT does not apply to Customer Managed application accounts.)
# Accessing your Customer Managed account
After you provision a Customer Managed account (CMA) in multi-account landing zone, (MALZ) an Admin role, `CustomerDefaultAdminRole`, is in the account for you to assume, through SAML federation, to configure the account.
To access the CMA:
1. Log into the IAM console for the management account with the **CustomerDefaultAssumeRole** role.
1. In the IAM console, on the navigation bar, choose your username.
1. Choose **Switch Role**. If this is the first time choosing this option, a page appears with more information. After reading it, choose **Switch Role**. If you clear your browser cookies, this page can appear again.
1. On the **Switch Role** page, type the Customer Managed account ID and the name of the role to assume: **CustomerDefaultAdminRole**.
Now that you have access, you can create new IAM Roles to continue to access your environment. If you would like to leverage SAML Federation for your CMA Account, see [ Enabling SAML 2.0 federated users to access the AWS Management Console](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_enable-console-saml.html).
# Connecting your CMA with Transit Gateway
AMS does not manage the network setup of Customer Managed accounts (CMAs). You have the option of managing your own network using AWS APIs (see [Networking Solutions](https://aws.amazon.com/solutionspace/networking/)) or connecting to the multi-account landing zone network managed by AMS, using the existing Transit Gateway (TGW) deployed in AMS MALZ.
**Note**
You can only have a VPC attached to the TGW if the CMA is in the same AWS Region. For more information see [ Transit gateways](https://docs.aws.amazon.com/vpc/latest/tgw/tgw-transit-gateways.html).
To add your CMA to Transit Gateway, request a new route with the [ Networking account \$1 Add static route (ct-3r2ckznmt0a59)](https://docs.aws.amazon.com/managedservices/latest/ctref/deployment-managed-networking-account-add-static-route.html) change type and include this information:
+ **Blackhole**: True to indicate that the route's target isn't available. Do this when the traffic for the static route is to be dropped by the Transit Gateway. False to route the traffic to the specified TGW attachment ID. Default value is false.
+ **DestinationCidrBlock**: The IPV4 CIDR range used for destination matches. Routing decisions are based on the most specific match. Example: `10.0.2.0/24`.
+ **TransitGatewayAttachmentId**: The TGW Attachment ID that will serve as route table target. If **Blackhole** is false, this parameter is required, otherwise leave this parameter blank. Example: `tgw-attach-04eb40d1e14ec7272`.
+ **TransitGatewayRouteTableId**: The ID of the TGW route table. Example: `tgw-rtb-06ddc751c0c0c881c`.
**Connecting a new customer-managed VPC to the AMS Multi-Account Landing Zone network (creating a TGW VPC attachment)**:
1. In your multi-account landing zone Networking account, open the [Amazon VPC console](https://console.aws.amazon.com/vpc/).
1. In the navigation pane, choose **Transit Gateways**. Record the TGW ID of the transit gateway you see.
1. In your Customer Managed account, open the [Amazon VPC console](https://console.aws.amazon.com/vpc/).
1. In the navigation pane, choose **Transit Gateway Attachments** > **Create Transit Gateway Attachment**. Make these choices:
1. For the **Transit Gateway ID**, choose the transit gateway ID you recorded in Step 2.
1. For **Attachment type**, choose **VPC**.
1. Under **VPC Attachment**, optionally type a name for **Attachment name tag**.
1. Choose whether to enable **DNS Support** and **IPv6 Support**.
1. For **VPC ID**, choose the VPC to attach to the transit gateway. This VPC must have at least one subnet associated with it.
1. For **Subnet IDs**, select one subnet for each Availability Zone to be used by the transit gateway to route traffic. You must select at least one subnet. You can select only one subnet per Availability Zone.
1. Choose **Create attachment**. Record the ID of the newly created TGW Attachment.
**Associating the TGW attachment to a route table**:
Decide which TGW route table you want to associate the VPC with. We recommend creating a new application route table for Customer Managed VPCs by submitting a Deployment \$1 Managed landing zone \$1 Networking account \$1 Create transit gateway route table (ct-3dscwaeyi6cup) RFC. To associate the VPC or TGW attachment to the route table you select, submit a Deployment \$1 Managed landing zone \$1 Networking account \$1 Associate TGW attachment (ct-3nmhh0qr338q6) RFC on the Networking account.
**Create routes in the TGW route tables to connect to this VPC**:
1. By default, this VPC will not be able to communicate with any of the other VPCs in your Multi-Account Landing Zone network.
1. Decide with your solutions architect what VPCs you want this customer-managed VPC to communicate with. Submit a Deployment \$1 Managed landing zone \$1 Networking account \$1 Add static route (ct-3r2ckznmt0a59) RFC against the networking account to create the TGW routes you need.
**Note**
This CT (ct-3r2ckznmt0a59) does not allow adding static routes to core route table EgressRouteDomain; if your CMA needs to allow egress traffic, submit a Management \$1 Other \$1 Other (MOO) RFC with ct-0xdawir96cy7k.
**Configuring your VPC Route tables to point at the AMS Multi-Account Landing Zone transit gateway**:
Decide with your solutions architect what traffic you want to send to the AMS Multi-Account Landing Zone transit gateway. Update your VPC route tables to send traffic to TGW attachment created earlier
# Getting operational help with your Customer Managed accounts
AMS can help you operate the workloads you deployed in your Customer Managed accounts by on-boarding the account into AMS Accelerate. With AMS Accelerate you can benefit from operational services such as monitoring and alerting, incident management, security management, and backup management, without going through a new migration, experiencing downtime, or changing how you use AWS. AMS Accelerate also offers an optional patch add-on for EC2-based workloads that require regular patching. With AMS Accelerate you continue using, configuring, and deploying all AWS services natively, or with your preferred tools; as you do with AMS Advanced Customer Managed accounts. You use your preferred access and change mechanisms while AMS applies proven practices that help scale your team, optimize costs, increase security and efficiency, and improve resiliency. To learn more see the [Accelerate service description](https://docs.aws.amazon.com/managedservices/latest/accelerate-guide/acc-sd.html).
To onboard your Customer Managed account into Accelerate, contact your CSDM and follow the steps from [Getting Started with AMS Accelerate](https://docs.aws.amazon.com/managedservices/latest/accelerate-guide/getting-started-acc.html).
**Note**
AMS Accelerate accounts in AMS Advanced do not have AMS change management (requests for change or RFCs) or the AMS Advanced console. Instead, they have the AMS Accelerate console and functionality.
# AMS Tools account (migrating workloads)
Your Multi-Account Landing Zone tools account (with VPC) helps accelerate migration efforts, increases your security position, reduces cost and complexity, and standardizes your usage pattern.
A tools account provides the following:
+ A well-defined boundary for access to replication instances for system integrators outside of your production workloads.
+ Enables you to create an isolated chamber to check a workload for malware, or unknown network routes, before placing it into an account with other workloads.
+ As a defined account setup, it provides faster time to onboard and get set up for migrating workloads.
+ Isolated network routes to secure traffic from on-premise -> CloudEndure -> Tools account -> AMS ingested image. Once an image has been ingested, you can share the image to the destination account via an AMS Management \$1 Advanced stack components \$1 AMI \$1 Share (ct-1eiczxw8ihc18) RFC.
High level architecture diagram:
![\[AWS account structure with Management, Shared Services, Network, Security, and Log Archive accounts.\]](http://docs.aws.amazon.com/managedservices/latest/userguide/images/high-level-diagram_v1.png)
Use the Deployment \$1 Managed landing zone \$1 Management account \$1 Create tools account (with VPC) change type (ct-2j7q1hgf26x5c), to quickly deploy a tools account and instantiate a Workload Ingestion process within a Multi-Account Landing Zone environment. See [Management account, Tools account: Creating (with VPC)](https://docs.aws.amazon.com/managedservices/latest/ctref/ex-malz-master-acct-create-tools-acct-col.html).
**Note**
We recommend having two availability zones (AZs), since this is a migration hub.
By default, AMS creates the following two security groups (SGs) in every account. Confirm that these two SGs are present. If they are not present, please open a new service request with the AMS team to request them.
SentinelDefaultSecurityGroupPrivateOnlyEgressAll
InitialGarden-SentinelDefaultSecurityGroupPrivateOnly
Ensure that CloudEndure replication instances are created in the private subnet where there are routes back to on-premise. You can confirm that by ensuring that the route tables for the private subnet has a default route back to TGW. However, performing a CloudEndure machine cut over should go into the "isolated" private subnet where there is no route back to on-premise, only Internet outbound traffic is allowed. It is critical to ensure cutover occurs in the isolated subnet to avoid potential issues to the on-premise resources.
Prerequisites:
1. Either **Plus** or **Premium** support level.
1. The application account IDs for the KMS key where the AMIs are deployed.
1. The tools account, created as described previously.
# AWS Application Migration Service (AWS MGN)
[AWS Application Migration Service](https://aws.amazon.com/application-migration-service/) (AWS MGN) can be used in your MALZ Tools account through the `AWSManagedServicesMigrationRole` IAM role that is created automatically during Tools account provisioning. You can use AWS MGN to migrate applications and databases that run on supported versions of Windows and Linux [operating systems](https://docs.aws.amazon.com/mgn/latest/ug/Supported-Operating-Systems.html).
For the most up-to-date information on AWS Region support, see [the AWS Regional Services List](https://aws.amazon.com/about-aws/global-infrastructure/regional-product-services/).
If your preferred AWS Region is not currently supported by AWS MGN, or the operating system on which your applications run is not currently supported by AWS MGN, consider using the [CloudEndure Migration](https://console.cloudendure.com/#/register/register) in your Tools account instead.
**Requesting AWS MGN Initialization**
AWS MGN must be [initialized](https://docs.aws.amazon.com/mgn/latest/ug/mandatory-setup.html) by AMS before first use. To request this for a new Tools account, submit a Management \$1 Other \$1 Other RFC from the Tools account with these details:
```
RFC Subject=Please initialize AWS MGN in this account
RFC Comment=Please click 'Get started' on the MGN welcome page here:
[ https://console.aws.amazon.com/mgn/home?region=*MALZ\$1PRIMARY\$1REGION*\$1/welcome](https://console.aws.amazon.com/mgn/home?region=AP-SOUTHEAST-2#/welcome) using all default values
to 'Create template' and complete the initialization process.
```
Once AMS successfully completes the RFC and initializes AWS MGN in your Tools account, you can use `AWSManagedServicesMigrationRole` to edit the default template for your requirements.
![\[AWS MGN, Setup application migration service.\]](http://docs.aws.amazon.com/managedservices/latest/userguide/images/aws_mgn_firstrun.png)
# Enable access to the new AMS Tools account
Once the tools account is created, AMS provides you with an account ID. Your next step is to configure access to the new account. Follow these steps.
1. Update the appropriate Active Directory groups to the appropriate account IDs.
New AMS-created accounts are provisioned with the ReadOnly role policy as well as a role to allow users to file RFCs.
The Tools account also has an additional IAM role and user available:
+ IAM role: `AWSManagedServicesMigrationRole`
+ IAM user: `customer_cloud_endure_user`
1. Request policies and roles to allow service integration team members to set up the next level of tools.
Navigate to the AMS console and file the following RFCs:
1. Create KMS key. Use either [Create KMS Key (auto)](https://docs.aws.amazon.com/managedservices/latest/ctref/ex-kms-key-create-auto-col.html) or [Create KMS Key (managed automation)](https://docs.aws.amazon.com/managedservices/latest/ctref/ex-kms-key-create-rr-col.html).
As you use KMS to encrypt ingested resources, using a single KMS key that is shared with the rest of the Multi-Account Landing Zone application accounts, provides security for ingested images where they can be decrypted in the destination account.
1. Share the KMS key.
Use the Management \$1 Advanced stack components \$1 KMS key \$1 Share (managed automation) change type (ct-05yb337abq3x5) to request that the new KMS key be shared with your application accounts where ingested AMIs will reside.
Example graphic of a final account setup:
![\[AWS architecture diagram showing Migration VPC, IAM, and Permissions with various components and connections.\]](http://docs.aws.amazon.com/managedservices/latest/userguide/images/WIGS_Account_ExpandedV1.png)
# Example AMS pre-approved IAM CloudEndure policy
To see an AMS pre-approved IAM CloudEndure policy: Unpack the [WIGS Cloud Endure Landing Zone Example](samples/wigs-ce-lz-examples.zip) file and open the `customer_cloud_endure_policy.json`.
# Testing AMS Tools account connectivity and end-to-end setup
1. Start with configuring CloudEndure and installing the CloudEndure agent on a server that will replicate to AMS.
1. Create a project in CloudEndure.
1. Enter the AWS credentials shared when you performed the prerequisites, though secrets manager.
1. In **Replication settings**:
1. Select both AMS "Sentinel" security groups (Private Only and EgressAll) for the **Choose the Security Groups to apply to the Replication Servers** option.
1. Define cutover options for the machines (instances). For information, see [Step 5. Cut over](https://docs.aws.amazon.com/prescriptive-guidance/latest/migration-factory-cloudendure/step5.html)
1. **Subnet**: Private subnet.
1. **Security Group**:
1. Select both AMS "Sentinel" security groups (Private Only and EgressAll).
1. Cutover instances have to communicate to the AMS-managed Active Directory (MAD) and to AWS public endpoints:
1. **Elastic IP**: None
1. **Public IP**: no
1. **IAM role**: customer-mc-ec2-instance-profile
1. Set tags as per your internal tagging convention.
1. Install the CloudEndure agent on the machine and look for the replication instance to come up in your AMS account in the EC2 console.
The AMS ingestion process:
![\[Flowchart showing AMS ingestion process steps from customer instance to application deployment.\]](http://docs.aws.amazon.com/managedservices/latest/userguide/images/Ingestion_Process_v1.png)
# AMS Tools account hygiene
You'll want to clean up after you are done in the account have shared the AMI and no longer have a need for the replicated instances:
+ Post instance WIGs ingestion:
+ Cutover instance: At a minimum, stop or terminate this instance, after the work has been completed, via the AWS console
+ Pre-Ingestion AMI backups: Remove once the instance has been ingested and the on-premise instance terminated
+ AMS-ingested instances: Turn off the stack or terminate once the AMI has been shared
+ AMS-ingested AMIs: Delete once sharing with the destination account is completed
+ End of migration clean up: Document the resources deployed through Developer mode to ensure clean-up happens on regular basis, for example:
+ Security groups
+ Resources created via Cloud-formation
+ Network ACK
+ Subnet
+ VPC
+ Route Table
+ Roles
+ Users and accounts
# Migration at scale - Migration Factory
See [Introducing AWS CloudEndure Migration Factory Solution](https://aws.amazon.com/about-aws/whats-new/2020/06/introducing-aws-cloudendure-migration-factory-solution/).