AWS Architecture BlogField Notes: Customizing the AWS Control Tower Account Factory with AWS Service Catalogby Remek Hetman | on 23 OCT 2020 | in Architecture, AWS Control Tower, AWS Lambda, AWS Service Catalog, Technical How-to | Permalink | Share Show Many AWS customers who are managing hundreds or thousands of accounts know how complex and time consuming this process can be. To reduce the burden and simplify the process of creating new accounts, last year AWS released a new service, AWS Control Tower. AWS Control Tower helps you automate the process of setting up a multi-account AWS environment (AWS Landing Zone) that is secure, well-architected, and ready to use. This Landing Zone is created following best practices established through AWS’ experience working with thousands of enterprises as they move to the cloud. This includes the configuration of AWS Organizations, centralized logging, federated access, mandatory guardrails, and networking. Those elements are a good starting point to cover the initial configuration of the new account. For some organizations, the next step is to baseline a newly vended account to align it with the company policies and compliance requirements. This means create or deploy necessary roles, policies, governance controls, security groups and so on. In this blog post, I describe a solution that helps achieve consistent governance and compliance requirements across accounts created by AWS Control Tower. The solution uses the AWS Service Catalog as the repository of products that will be deployed into the new accounts. Prerequisites and assumptions Before I get into how it works, let’s first review a few key AWS Service Catalog concepts:
You need an AWS Service Catalog portfolio with products that you plan to deploy to the accounts. The portfolio has to be created in the AWS Control Tower primary account. If you don’t have a portfolio, the starting point would be to review these resources:
Solution OverviewThis solution supports the following scenarios:
The architecture diagram in figure 1 shows the process of deploying products to the new account.
The architecture diagram in figure 2 shows process of updating product or deploying product to the existing account.
Deployment and configuration Before proceeding with the deployment, you must install Python3. Then, follow these steps:
AWS CloudFormation Template Parameters:
Configuration Files The configuration files have to be in the YAML format, you can use the following schemas for new or existing accounts: Configuration schema for new account: The configuration can apply to all new accounts or can be divided based on the organization unit associated with the new account. Also, you can mix deployments where some products are always deployed and some only to specific organization units. Example configuration file Configuration schema for existing accounts This configuration can be used to update provisioned products or deploy products into existing accounts. You can specify a target location either as account(s), organization unit(s) or both. If you specified an organization unit as a target, the product(s) will be updated/deployed to all accounts associated with organization unit. If the product doesn’t exist in the account, the Lambda function attempts to deploy it. You can manage this by setting the parameter ‘deployifnotexist’ to true. If omitted or set to false, Lambda won’t provision the product to an existing account. Example configuration file All products deployed by the AWS Service Catalog are provisioned under their own name that has to be unique across all provisioned products. In this example, products are provisioned under the following naming convention: <account id where product is provision>-<”provision_name” from configuration file> Example: 123456789-my-productIn the configuration file you can specify dependencies between products. Dependencies need to be provided as the list of provisioned product name not a product name. If provided, deployment of the product will be suspended until all dependencies successfully deployed. The Step Function is running in the loop with interval of 1 minute and checking if dependencies were deployed. In the event of an error in the dependency naming or configuration, the step function iterates only until it reaches the maximum iterations defined in the configuration file. If the maximum iterations are reached, the step function reports time out and interrupts the products’ deployment. Important: if you updating a product by adding a new AWS Region, you cannot specify the dependency or run updates in existing regions the same time. In this scenario you should break the update as follows:
You can find different examples of configuration files in GitHub. Note: The name of the configuration file and Amazon S3 location must match the values provided in the AWS CloudFormation template during solution deployment. AWS Lambda functions deployment considerations When deploying product is a Lambda function, you need to consider two requirements:
To accommodate both requirements, the approach is to create an Amazon S3 bucket under the AWS Control Tower primary account. There is one Amazon S3 bucket in each Region where the functions will be deployed. Each deployment bucket should have attached the following policy: { "Version": "2008-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "*" }, "Action": "s3:GetObject", "Resource": "arn:aws:s3:::<S3 bucket name>/*", "Condition": { "StringEquals": { "aws:PrincipalOrgID": "<AWS Organizations Id>" }, "StringLike": { "aws:PrincipalArn": [ "arn:aws:iam::*:role/AWSControlTowerExecution", "arn:aws:iam::*:role/< name of the Lambda IAM role – default: control-tower-account-factory-lambda-role>" ] } } } ] }This allows the deployment role to access Lambda’s source code from any account in your AWS Organizations. ConclusionIn this blog post, I’ve outlined a solution to help you drive consistent governance and compliance requirements across accounts vended though AWS Control Tower. This solution provides enterprises with mechanisms to manage all deployments from a centralized account. Also, this reduces the need for maintaining multiple separate CI/CD pipelines. Therefore you can simplify and reduce deployment time in a multi-account environment. This solution allows you keep provisioned products up to date by updating existing products or bringing old accounts to the same compliance level as the new accounts. Since this solution supports deployment to existing accounts and can be run without AWS Control Tower, it can be used for deployment of any AWS Service Catalog product either in single or multiple account environments. This solution then becomes an integral part of CI/CD pipeline. For more information, review the AWS Control Tower documentation and AWS Service Catalog documentation. Also, review the links listed in the “Prerequisites and assumptions” section of this post. Also, explore the AWS Solution presented in this video: Solving with AWS Solutions: Customizations for Control Tower. Field Notes provides hands-on technical guidance from AWS Solutions Architects, consultants, and technical account managers, based on their experiences in the field solving real-world business problems for customers.Remek HetmanRemek is a Senior Cloud Infrastructure Architect with Amazon Web Services Professional Services. He works with AWS financial enterprise customers providing technical guidance and assistance for Infrastructure, Security, DevOps, and Big Data to help them make the best use of AWS services. Outside of work, he enjoys spending time actively, and pursuing his passion – astronomy.
ResourcesAWS Architecture Center AWS Well-Architected AWS Architecture Monthly AWS Whitepapers AWS Training and Certification This Is My Architecture
FollowTwitter Facebook LinkedIn Twitch Email Updates |