There comes a moment in every administrator's life, when they see the ever-increasing burden of their users piling upon them, more and more accounts just keep joining the company, in ever quickening pace, how am I supposed to keep up with all this? The administrator screams to this guy as they create yet another developer account, trying desperately to wire up all the permissions as fast as possible.

The admin knows that these new database issues won't fix themselves, so they'll need to hurry, or how about the poor security auditor who is constantly having to look through production accounts to make sure that we're following best practices, do they already have an audit log in created for them or will they have to bother the overworked administrator from before? Adding yet another task to the ever-growing pile, and even then is the other supposed to check every production account by hand to see if their EBS volumes are actually encrypted? Why isn't there an automated way to check for all these things? The poor security person cries into their keyboard for the fourth time today.

And finally, when we have to keep track of all the log files from every security service that touches customer data, where does that all get stored? Are they on separate accounts for each of these production workloads? Do you aggregate everything into a locked vault somewhere? God save us from the crushing burden of all these text files.

Anyways, I think you get the point, there's an enormous amount of work to consider when you're administrating, securing or just simply creating an organization within AWS, there have also been a few ways over the years that AWS has recommended doing it, starting originally with just using IAM and hosting new users within your root accounts, creating policies, users and groups, and roles to divvy up permission, we were then given AWS organizations an extremely helpful service that allows us to administer large volumes of these accounts, organizations gave us ability to add accounts into groups and apply policies between them, these service control policies help to control and protect data and our users from portions of AWS, we didn't want them to have access to, they had the power to override local IAM permissions, regardless of what that particular account actually allowed internally with IAM.

Well, we have now moved on to the next stage of this progress, AWS has evolved something new and I'd like to grab a little bit of your time today, to discuss probably the simplest and most powerful way to date to create, govern and administer large numbers of user accounts within AWS, and that would be with AWS Control Tower. What is AWS Control Tower? AWS Control Tower is a service that offers a larger and more controlled method of creating, distributing, managing, and auditing multiple accounts.

Originally these tasks were relegated to multiple different services that each dealt with an individual piece of the puzzle, some tasks like auditing didn't even have a specific service to really help drive them forward, creating a large multi-account system from the ground up that deals with these scenarios might take an individual weeks to properly create, with AWS Control Tower we can manage all of these disparate services right within one area.

One of the first main topics we need to discuss for AWS Control Tower is the concept of landing zone What is a landing Zone? A landing zone is a multi-account architecture that follows the well-architected framework and is based around the ideas of security and compliance best practices. Your landing zone will be automatically created by AWS Control Tower and it is inherent part of the service, your landing zone is created from a series of best practice blueprints that help us setting up systems that deal with identity, federated access and overall account structure, these blueprints do the following on your behalf, they create a multi-cloud environment using AWS organizations, there are three organizational units that are provisioned here, the Root OU, this will be the parent OU that contains every other OU, within your landing zone, the core OU this OU contains the log archive and any audit member accounts, we generally refer to these accounts as the shared accounts and a custom OU, this OU another member OUs contain the actual working accounts that your users need to perform whatever duties they do within your AWS environment, for example your developer AWS accounts would sit within this OU.

The service also builds out two shared accounts, a log archive in the account which will be the place where all the logs will be sent between all accounts, it will store the logs of all API calls and resource configurations for every account within the landing zone and an audit account which has a restricted account that has been created to give your security and compliance team members read and write access to any account within your AWS landing zone.

From this account you'll have programmatic access to review all other accounts, by way of a role that grants use of Lambda functions only, this account does not allow you to log into other accounts manually, which is good. Control tower will also provide identity management with the use of AWS single sign-on, default directory, this directory will house all of the AWS SSO users, you can also use it to define the scope or permissions available for each of those users. It will also provide federated access to those accounts, using AWS SSO directly, control tower then hooks up centralized logging from AWS cloud trail, and into its config, which is stored securely within AWS three and the logging account.

Finally it enables cross account security auditing using AWS IAM an AWS SSO to allow the audit account to perform routine checks as it wishes. In the end AWS Control Tower will have all of that automatically set up for you that is incredible, the amount of time it might take you to create all that by hand would probably be measured in weeks if done by a single person. The service can even create pre-configured groups such as your admins, users, and auditors, you can of course create more designations that provide different levels of access based on your needs.

Additionally, if you have your own active directory service already going, you can plug that into AWS SSO and configure it to work directly with your system which again can be a cloud-based AD or when you're hosting on-premises, just make sure to use AD connector or the AD service. Safely managing your landings on resources, when you create your new landing zones using AWS Control Tower, there are large number of AWS resources that are created on your behalf, you need to be very careful about deleting or removing these pre-configured resources, if you were to destroy or tamper with these resources you can send control tower into an unknown state, AKA, it can break, so in very simple terms, do not modify or delete any of the AWS identity and access management roles that were created within the shared accounts, the auditing account and the archive account, otherwise bad things can happen.

Now, if you do so accidentally, it's not the of the world later on, we'll discuss how to fix these problems, additionally, it is very important that you do not disallow usage of any regions through service control policies or with AWS simple token service. Administration tips for setting up your landing zones. You should be setting up your landing zones in the region where you do most of your work, this region is known as your home region with that in mind make sure you deploy your new accounts from within that home region, if your architecture is multi-region again, keep it simple, put your landing zone and whichever region is the primary region, do not move the audit bucket or other buckets that were created when you launched control tower from your home region, this can cause issues down the line, and when you first launch your landing zones, AWS STS end points need to be activated in the management account in all regions supported AWS Control Tower if not, it might fail midway through the creation process.

Guardrails, even if AWS Control Tower only deployed the landing zones for us with all of its associated accounts and features, I would be happy, however, that is not all that AWS Control Tower helps deploy on your behalf, In addition to everything we've just covered, Control tower also deploys guardrails, guardrails is an appropriately named service that helps to keep all of your users accounts and everything under AWS is control tower and compliance with basic security regulations, overall, a guardrail is a fairly high-level security rule that provides continual oversight, they implement preventative or detective based policies that can help you govern your accounts, users, groups, and resources, the best part about these guardrails is that they're written and meant to be understood in plain English.

Unlike other types of control policies be it service control policies, or IAM user policies, guardrails are very straightforward to understand, here are three simple examples, enable encryption at rest for log archive, enable access logging for log archive, disallow changes to CloudWatch logs, log group, just by reading these titles of the guardrails you already have a great understanding of what they're supposed to do.

Now, of course, these are all built on top of existing AWS infrastructure and do have an associate SEP lying underneath them, but all of that is managed by AWS and they will keep that site up-to-date for you, here's an example of what these look like in their normal form. Guardrails are applied to an entire organizational unit just like normal SCPS and therefore are also added to each account underneath that organizational unit, so that means that any accounts you add within your landing zone will be effective by the guardrails that you have in place, in general, guardrail's there to help express your policy intentions.

Three types of guardrails, when using AWS was control tower we have three types of guardrails that we need to know about, first we have the mandatory set of guardrails, these are automatically added to your landing zone accounts upon creation and can not be disabled, in total there are 22 mandatory guardrails and you can check here for a full list of them and what they do. In general, though the mandatory guardrails are there to deal with basic security concerns, dealing with these shared accounts, to summarize them quickly, they help with enforcing logging, allowing the right services and all regions to facilitate logging, encrypting logs, stopping people from turning off your logs and stopping people from changing anything that AWS Control Tower set up.

Overall the mandatory guard rails don't do anything super controlling and are defensive in nature. Second, we have a series of strongly recommended guardrails, they are designed to enforce some of the most common best practices for well-architected and multi-account environments, these guard rails are not mandatory and can be enabled and disabled as you please, these optional guardrails are not enabled initially, allowing you to choose what level of security and scrutiny you want for your environment.

Here are a few examples of the strongly recommended guardrails, disallowing creation of access keys for the root user, disallowing public access to Amazon RDS database instances, disallowing public right access to Amazon S3 buckets, there are a total of 13 strongly recommended guardrails in general they try to lock down, read, write, and control access to accounts and services that are commonly compromised.

Feel free to look here for more information about them. Finally, we have the elective guardrails, they continue to help lock down your accounts and can help keep track of the most commonly restricted actions with an enterprise environments, these guardrails are also not enabled by default, there are only five elective guardrails at this moment, so I'll just name them quickly, disallow cross-region replication for Amazon S3 buckets, disallow delete actions on Amazon S3 buckets without MFA, disallow access to IAM users without MFA, disallow console access to IAM users without MFA and disallow Amazon S3 buckets that are not version enabled.

As you can see, they're fairly common and highly recommended additions to the security of any architecture, just to finish up about guardrails, it's important to reiterate that when you turn on these guardrails, they can and will create resources within your AWS account do not modify or delete these resources, otherwise it can set false flags for your guard rails. Provisioning counts for your users, we have spent a lot of time so far looking how control tower helps you set up a robust, secure and easy to audit environment through the use of shared accounts and guardrails, this next topic I wanna cover will explain how to actually add users accounts into the system in the safest and most scalable way possible.

AWS Control Tower has three methods for creating new member accounts, you can add new accounts directly through the enrolled accounts feature which lives directly inside AWS Control Tower, you can create new accounts through the account factory which is included as a part of AWS service catalog, finally, you can create new accounts from your management account using Lambda code and the appropriate IAM roles, I'm not a real fan of this option as it's not streamlined to my liking, but it does exist and allows you to create an ad accounts programmatically.

Let's take a moment to look at each of these scenarios to see what is gained or lost in each of these circumstances. Enrolling new accounts, the account enrollment feature of AWS Control Tower provides probably the most straightforward way for your administrators to add new accounts into an organization, these new accounts will be governed by control tower and any guardrails you may have set up.

One caveat for enrolling new accounts is that your landing zone must not be in a state of drift. Drift is where some of the assets within your landing zone have fallen out of compliance and must be updated, this can happen accidentally over time or might have occurred on purpose, to fix a time sensitive issue either way, once you have brought everything back into alignment you can create an account using this method.

To actually create an account, it's fairly simple, navigate to the account factory page of AWS Control Tower, select enroll account, fill in the appropriate information under the create account section, this will include fields like account email, account name SSO username, and organizational unit, and finally click enroll account, the actual account creation might take up to several minutes to complete, if you do not have this option available make sure you are signed into an IAM user that has access to the AWS service catalog end user full access policy, if you're still having issues make sure you're not signed in as root.

Account factory, account factory allows your cloud administrators and your SSO end users to create new accounts within your control tower landing zone AWS refers to this method of account creation as the advanced account provisioning method, they recommend that you use the enrollment feature from earlier.

Account factory creates new accounts so the use of another service called ADSL service catalog, AWS service catalog is an organizational tool developed with the purpose of making provisioning and creation of IT tacks easier for both the end user as well as your IT admins, these stacks can include almost everything under the AWS sun such as easy to instances, databases, software and all the underlying infrastructure to create multi-tiered applications and architectures, service catalog allows your end users to select the content that they need from a list of pre-approved services that your IT or admin teams set up ahead of time, this helps to bring down those barriers of entry for content creation, as well as helping to keep best practices and system security a key component of any development.

Background information aside, to actually go about creating a new account within account factory, we have a few steps to follow, sign into your SSO user portal and from applications select AWS account and from your selection of accounts choose the management account, an AWS service catalog and user access, click on management console, make sure you're in the correct region, this should be your AWS Control Tower main region search for and choose service catalog, click on the products list, select AWS Control Tower account factory, and then the launch button, now fill out the appropriate user information here, choose next until you get to the review section, now this is very important, do not define tag options and do not enable notifications, this will cause the account provisioning to fail. Review and launch, do not create a resource plan, this will also cause the account provisioning to fail, after that you're all done.

This method will also take several minutes to complete. Using Lambda, is also possible to do all the above in an automated way, using Lambda, you can have your function create and provision account for you, you must do this for the management account that runs your control tower however, some notes, if you are automating control tower functions like account creation, your identity that is performing the work must have the AWS policy, AWS service catalog, and user full access, as well as the following permission.

This direction is fairly complex and might require a bit of back and fiddling to get working for your specific requirements that aside however, if you do really want to know how to get automatic account creation working just by uploading a CSV file then into an S3 bucket, please check out this blog link by AWS.

Unmanaging a member account, there might come a time after you've created an AWS account that need to release it from direct purview of AWS Control Tower, although this might be an infrequent issue, it's fairly easy to accomplish, releasing an account or unmanaging it, as it officially called, can be done through AWS service catalog, simply log into a SSO user, that is part of the AWS account factory group, from there you can open service catalog, select provision products list, choose the name of the account that you wish to release, choose terminate, this doesn't mean destroy, it just means removed from the organizational unit and your landing zone, thanks Amazon for making that clear and just give it a few minutes and the account will be unregistered, just to be clear however, this does not remove the users access to the account, it just unregistered it from control towers oversight, if you wish to clear SSO access to that account, you'll need to change the settings and AWS SSO by changing the user email for that account.

Resolving and detecting drift within AWS Control Tower. When you create your initial setup within AWS Control Tower your landing zones, accounts, and all other organizations will be in compliance with your rules and guardrails that have been set up, as you work with and keep adding new accounts, identities and all the other good stuff to your AWS Control Tower system, you will, at some point experienced drift, some of the drift will be accidental, of course but other drifts might've been created on purpose to fix those time-sensitive issues.

AWS control tower is able to detect these abnormalities and lets you know how far from center your setup has officially drifted. Continually resolving drift is the best way to stay up-to-date and in compliance with both your internal corporate policies as well as with any governmental regulations you must comply with, you will receive your drift detection notifications automatically through Amazon SNS, these are aggregated within the audit account that was created in your landing zone.

Remember account admins should subscribe to these SNS drift notifications, even though the drift detection is automatic, you must resolve the problems manually through the console most of the time, luckily most of these drift issues can be repaired by literally pressing a button on the settings page through repair button to be specific, most drift can be taken care of at your leisure, but there are a few examples we call major drift that should be dealt with as soon as possible.

If you delete the organizational unit, originally named core you'll not be able to perform any additional operations until you prepare it, if any of the IAM roles that check for drift are missing or inaccessible, you will see an error requiring you to repair the landing zone, these roles are the AWS Control Tower admin, AWS was control tower CloudTrail role and the AWS Control Tower stack set role. And finally, if you delete the OU originally named custom, your landing zone will be in a state of major drift but you will still be able to use control tower, only one non-core OU is required for control tower to operate, but you should still fix this.

Edge case guidance for organizations and AWS Control Tower. There's practices that you should be aware of when working with AWS Control Tower, I have already spoken about a few of these as we've gone through the course, but I'll restate the important ones for extra dramatic flare, do not update any service control policies through AWS organizations that are being managed by AWS Control Tower, if you do, it can throw off the detection systems within guardrails and leave it in an unknown state, this might require you to re-enable those guardrails in order to fix them.

AWS recommends that you instead create a new service control policy and attach those to the organizational units, instead of editing old ones, you should also be careful moving outside accounts into AWS Control Tower doing so will cause drift to occur that must be repaired, to fix this type of drift, simply update the account within the account factory, you can find a full breakdown of that process over here.

Nested OUs are not accessible from AWS Control Tower, the service only deals with top level OUs. And finally, if you rename an account or OU that was created by a control tower, you must repair your landing zone to see the new name displayed in control tower, and again, you just hit the press the button.

Comparisons, one final note I want to touch upon as we come to the end of this lecture is the comparison between ADFS control tower and AWS Security Hub, both of these services deal quite extensively with managing your environment and keeping your services secure, the main distinction that AWS has mentioned between the services is that AWS Control Tower is the primary destination for cloud administrators, helping you set up a secure and well-architected environment that sets your company off on the right path, AWS Security Hub is the primary destination for your security and compliance professionals, it allows you to see a comprehensive and timely analysis of your environments and gives you the option to take actions, based on these findings, these two services also sit on different sides of the security spectrum, AWS Control Tower has a more preventative approach, it tries to stop bad things before they happen through the use of guardrails and limiting your users while AWS security Hub exhibits a more detective-based approach providing reports and an analysis of your security posture allowing you to make decisions and root out possible vulnerabilities.