Now let’s look at AWS Control Tower.
So it’s an easy way for you to set up and govern a secure and compliant multi-account AWS environments based on best practices. So out of it, you’re going to get your environment automated in just a few clicks.
You’re going to have ongoing policy management using guardrails and we see this in this lecture. We’re going to detect policy violations and remediate them automatically. And we can monitor compliance through an interactive dashboard.
So Control Tower is a way for you to really automate best practice multi-accounts and it runs on top of AWS organizations.
So it’s going to set up an organization for you and then organize these accounts and implement automatically the service control policies you need.
Account Factory
So out of it there is the account factory and since you automate account provisioning and deployments and it allows you to create pre-approved baseline and configuration options for all the accounts in your organization, such as, for example, configuring the default VPC, configuring the subnets, the regions and so on.
And to do so is going to use the underlying service called the AWS Service Catalog to provision these new accounts. So let’s have a look in where an account factor will be very helpful.
So we have an cloud computing environments and then we have a data center with an ADFS and an active directory. And now we are going to establish a VPN or direct connect connection between the cloud and the corporate data center.
And so therefore when we use Control Tower and a lending zone and we create accounts for account factory, then at the center of it is going to be IAM Identity Center. And we can set up in different ways.
But if you wanted to integrate with Microsoft Active Directory on your corporate data center then you would create an AWS managed Microsoft AD, which would be the source of notification for your IAM Identity Center.
And then you would create a two-way trust between active directory on your corporate data center and AWS.
From there, any accounts created through your landing zone and through account factory will be properly configured to leverage authentication through IAM ID Center and therefore use underlyingly the active directory you have in the cloud and the one you have also on your corporate data center.
Detect and Remediate Policy Violations
Now there’s another thing with Control Tower called guardrails. And this is used to detect and remediate policy violations. So it’s going to give you ongoing governance. And then you have two kinds of guardrails.
You have preventive guardrails or use SCPs.
And this is, for example, to have an action to disable or disallow the creation of access keys from the root user. That’s one way.
Or detective where you want to give all permissions to your accounts, but then you use config to detect, for example, whether or not MFA is enabled for the root user and so on. And config will be very helpful because it gives you compliance or non-compliance of resources.
And so here’s an example. We, for example, want to see which resources are untagged.
So we have a detective guardrail in Control Tower using config and it’s going to monitor for untagged resources in your member accounts as part of your organization is going to trigger if it’s noncompliance and SNS topic, which can notify an admin, maybe invoke Lambda function and that Lambda function itself can remediate to this and add tag where needed.
Guardrails Levels
So there are a few guardrail levels for Control Tower.
There is the mandatory guardrail, which is automatically enabled and enforced by AWS Control Tower. So for example, you want to disallow public read access to the log archive accounts and this is mandatory.
Strongly recommended, which is based on AWS practices. And for example, you wanna say you want to enable EBS volumes attached to EC2 instances.
And then you have elective guardrails, which is commonly used by enterprises. This is optional as well, for example, to disallow delete actions without MFA in S3 buckets.
Landing Zone
So now, let’s talk about landing zones in Control Tower.
So, landing zones are automatically provisioned, secure, and compliant multi-account environment based on AWS best practices.
Now, this concept may be quite obscure. So, a landing zone is a combination of many things.
We have an organization that is used to create and manage multi-account structure. We have Account Factory to easily create accounts and make them adhere to configs and policies.
We have OUs to group and categorize accounts based on the purpose. SCP to make sure you have fine-grained permissions and restrictions.
IAM Identity Center to make sure we have centralized user access to all the accounts and services. And Guardrails to make sure we have rules and policies in place to enforce security, compliance, and best practices. And Config to make sure we are assessing the resources’ compliance alongside the Guardrails. So, a landing zone is a concept to talk about the combination of all these things.
So, when we refer to a landing zone, we have the organization that is made up of the management accounts, different OUs, and within the security OU, we have, usually, a log and archive account and an audit account.
We have an Account Factory facility within Control Tower to create new accounts and make sure they’re properly configured. We have IAM Identity Center to make sure the users can log in into all the accounts securely using one login.
And then, we have Guardrails, so either preventive Guardrails by applying SCP at the organization’s level, or using detective Guardrails by using config and monitoring the compliance of everything across your organizations and accounts.
Account Factory Customization (AFC)
So now, let’s do a deep dive on Account Factory.
So we know that Account Factory allows us to create accounts from within the AWS Control Tower service but there is a way to customize these accounts and it’s called Account Factory Customization or AFC.
So, the idea is that you wanna customize the resources for the new and existing accounts created through Account Factory. And for this, we’ll use a blueprint.
So, you can use a custom blueprint, which is a CloudFormation template that will define all the resources and configurations that you wanna customize in the accounts. And this blueprint is defined in the form of a Service Catalog Product.
So, everything is stored in service catalog and it’s recommended to store this product in a Hub accounts for service catalog. So, that means that all your custom blueprints will be in that hub account and not in the management account. This is just a recommendation from AWS.
You can also use pre-defined blueprints created by partners of AWS, but there’s a caveat, only one blueprint either pre-defined or custom can be used to deploy to the accounts.
So, bottom line is the management accounts will be using the hub accounts and in service catalog, we’ll be creating the blueprints we need for deploying them to new accounts in Control Tower.
Then we’ll create a necessary IAM role which will be assumed by the management accounts.
And so whenever we create a new account from Control Tower, this blueprint will be deployed from Service Catalog as a CloudFormation template. But remember, there’s only the possibility to deploy one blueprint in an account, only one.
Account Factory
On top of it, whenever you create an account in Account Factory, there’s going to be a new event in EventBridge.
And so this would allow you, for example, to perform some kind of automation such as giving notifications through SNS or code through Lambda functions. On top of it, we can migrate accounts to Control Tower.
So here is your organizations and you have your management accounts and you want to include a new account in your organization.
So, you’re going to define an OU.
The target OU you want your account to be in is going to be the dev OU but first you’re going to move it into an unregistered OU. That is going to be a save zone.
Then you move the account into the organization. And so the account is now part of your organization and is part of your OU.
You’re going to create an IAM role which will allow Control Tower to manage this account.
So, it’s called the AWSControlTowerExecution role.
And then once there, we can deploy the config performance packs to this account to make sure that we have an account that is compliant with how we want it to work within our organization.
So, we evaluate the result of the conformance packs so all the rules and the compliance and the remediations in this new accounts.
And if we’re good, we can move this account into our dev OU and then set up Control tower successfully to have Control Tower manage this account as well.
Customizations for AWS Control Tower (CfCT)
So now let’s talk about a framework called Customizations for AWS Control Tower, or CfCT.
So it’s a GitOps-style customization framework created by AWS.
And I will show what this means in the next slide, but that means that you can commit code such as you can commit your CloudFormation templates and your SCPs and they will be automatically applied to all the accounts within account factory, the existing ones, as well as the new ones.
So the idea is that you want to manage some kind of deployment across all your accounts, such as you want all your control tower accounts to have the same SCPs in the same baseline confirmation templates.
Then you could use a CfCT framework to do this.
Now, it is very similar in feature to the account blueprint, but it is different because the account blueprint allows you to just send one CloudFormation template, whereas this allows you to do many CloudFormation templates, as well as service control policies.
And it’s all integrated within a pipeline.
So all the confirmation templates and your SCPs can be deployed either in Amazon S3 or CodeCommit. Then it will start a pipeline with CodeBuild, which is going to wrap this up and invoke a step function.
Now this step function is going to make sure that all the CloudFormation templates are deployed as part as text sets in CloudFormation and deployed to all the managed accounts, and for the service control policies, again, because they are managed via code, they can be deployed automatically in the organizations to all the managed accounts based on their OU.
Now, what happens if you have a new account?
Well, when you have a new account, we know that this actually generates an event in Control Tower and this event can be intercepted by EventBridge and so we can have some kind of automation out of it.
So the automation we can have is to send a message into an SQS FIFO queue so that we have a lender function handle these events one by one, and this lender function will take this event and invoke CodePipeline.
So CodePipeline, again, will build all the templates and all the SCPs for that account. And if you look again at my graph on the right hand side, it will apply all of these as well to your new account and we have full automation. So it’s a bit more work.
This is an architecture that is deployed as part of what AWS provides you as CfCT, but this gives you a full pipeline to manage all your cloud templates and your SCPs as code and have them deployed to all the accounts in your Control Tower, either new accounts or existing managed accounts.
AWS Config Integration
So now, let’s talk about how AWS Config is integrated with Control Tower.
So in Control Tower, you can implement Detective Guardrails and behind the scenes, these are config rules that are deployed to all your member accounts. So, whenever they are not compliant or compliant, all that configuration history and the compliance history is going to be sent into a log archive account.
And this is where we can see all the clients across all your accounts, and that’s why it’s called Detective Guardrails. So, this is going to be enabled for all the enabled regions in Control Tower, and then all the snapshots and history of your configuration will be delivered into essential accounts.
Now, to deploy config across all these accounts, we can use CloudFormation StackSets and we can also enable Config Aggregator, CloudTrail, and centralized logging.
AWS Config Conformance Packs
You can also deploy Conformance Packs across your Control Tower.
So, Conformance Packs allow you to create many rules and remediations for easy deployment at scale as part as a YAML template, and you can deploy them either in your organization or to individual accounts.
So, the process is that if a new account is created in Control Tower, then EventBridge will maybe send a message into an SQS FIFO queue, which will invoke a Lambda function.
And this Lambda function is going to add a deployment region or account to CloudFormation, which will enforce a StackSet and deploy all these Conformance Packs into new accounts such as in us-east-1, eu-west-2, and so on.
So, that’s it for the Config integration with Control Tower.
Account Factory for Terraform (AFT)
So now let’s discuss Control Tower Account Factory for Terraform or AFT.
So this allows you to deploy and customize accounts in Control Tower by using Terraform from your deployment pipeline. So the idea is that you’re going to create an account request Terraform file, and is going to trigger an AFT workflow.
We’ll show you this in the next slide for automated account provisioning. And there are some built-in feature options that are disabled by default but you need to know them at the exam.
So there is an option to enable CloudTrail data events. There is an option to enable the enterprise support plan and there is an option to delete the AWS default VPC in all the regions.
Now this Terraform module is maintained by AWS. And this works with the open source version of Terraform as well as the enterprise and the cloud version.
So let’s go into a bit more concrete thing.
So you’re going to push an account request file into CodeCommit, CodePipeline is then going to take care of sending it to CodeBuild and CodeBuild is going to analyze it and use Terraform to actually provision the account and the resources in control tower.
Now, what goes into this account request Terraform file?
Well, if you have a look at it there is a source saying, Hey what is the source of the module that is going to be deploying this Terraform file? Then we have the required parameters for your account such as what is the management account what is the log archive account what is the audit account, what is the management account the home region and the backend region.
And then we have these optional feature flags that are very important, as in do you want to delete the default DPC? Do you want to enable CloudTrail data events and do you want to enable enterprise support?
