Getting an Organization started on AWS Part 2: Multi-Account, Landing Zones & AWS Control Tower
Part 1: Introduction, AWS Accounts, IAM & AWS Organizations
Part 2: Multi-Account, Landing Zones & AWS Control Tower
Part 3: Domains, DNS & Route53
Part 4: Identity Center, Single-Sign-On & Directory Service
Part 5: WorkSpaces & WorkMail — workforce style users
Part 6: WordPress & Workloads
Theory: AWS Multi-Account, Landing Zones & AWS Control Tower
Welcome back! This is part 2 of the “Getting an Organization started on AWS — A practical guide to the boring bits that no one wants to do” course. Previously, we created our first AWS account and secured it.
In this part, we’ll be looking at the theory behind a well-architected AWS environment, and we shall lay the groundwork for a solid well-architected foundation. This will prove a great starting ground for whatever you need to do in AWS. This will cover multi-accounts, landing zones and the AWS Control tower product.
One account is plenty, and we could carry on and build all that we need in that one account. However, AWS accounts are natural hard boundaries between resources. Consider an account as a ‘resource container’. An AWS Account is the best unit of isolation between the groups of resources you create.
As you know, users live within an account. Because of this, if a user’s permissions were higher elevated than they should be, then they could do things they shouldn’t be able to do.
However, if the AWS Account itself is service restricted, then the user belonging to that account is limited in the damage they can do. Imagine if an account is just for running WordPress, if the account is restricted to just the services that are needed for that account, then the user cannot spin up expensive unrelated resources, or make any organizational or billing changes. Accounts created through AWS Control Tower can be created with guardrails, which prevent or detects any unusual activity.
Typically, it is considered bad practice to run workloads in the management account. Since some services have the functionality to work cross-accounts, because users can have cross-account roles, and because accounts are able to be restricted — it becomes an obvious decision for large or complex organizations to utilize multiple accounts.
Here is an example of a real-world looking organizational structure:
Any live or development/testing workloads such as custom applications or products would live in accounts under the ‘Workloads’ OU.
This is useful for many reasons — here is an example of how cross-account configuration can save you both technical complexity and financial cost.
In the above example, we have at least one account running multiple WordPress websites. If we were to have, say 5 accounts — all running WordPress on virtual machines, then each account would need its own VPC and network configuration. Later down the line if you want to monitor that, you’ll need to run network monitoring across all accounts.
Instead, we could have an account for shared network services, define a VPC in there with all the appropriate configuration and logging — and then expose those subnets to the WordPress accounts, which reduces networking costs (less infrastructure needs to be made) and allows for architectural simplicity.
We could also have an account for registering and managing domain names, child accounts can then manage their own subdomains against the domain managed by one account.
This is where a landing zone comes in. A landing zone is a well-architected, multi-account AWS environment that is scalable and secure. This is a starting point from which your organization can quickly launch and deploy workloads and applications with confidence in your security and infrastructure environment. Shared baselines that get reused by other accounts you create.
Multiple accounts provide the highest level of resource and security isolation. You should consider creating additional AWS accounts if you answer yes to any of the following questions:
· Does your business require administrative isolation between workloads?
· Does your business require limited visibility and discoverability of workloads?
· Does your business require isolation to minimize the blast radius?
· Does your business require strong isolation of recovery and/or auditing data?
AWS Control Tower offers a straightforward way to set up and govern an AWS multi-account environment, following prescriptive best practices.
Architecturally, this is how Control Tower looks. AWS Control Tower orchestrates the capabilities of several other AWS Services, including AWS Organizations, AWS Service Catalog, and AWS IAM Identity Center (successor to AWS Single Sign-On), to build a landing zone in less than an hour. Resources are set up and managed on your behalf.
The management account is only used to manage the organization.
There’s a foundational OU (Organizational Unit) which houses accounts fundamental to your landing zone.
This includes a security OU which houses an account that archives logs, and an account for monitoring logs and alerting for issues (could house custom monitoring software here).
You also get a custom OU which can house accounts you create through the account factory. Account factory uses AWS Service Catalog to create the account and bootstrap resources needed. These organization units come with guardrails, some mandatory and some you can configure yourself.
A guardrail is a high-level rule that provides governance against an OU. Through guardrails, Control Tower implements preventative and detective controls that monitor resources for compliance.
Preventive rules are implemented using Service Control Policies, which are restrictions applied to an OU which limit the AWS functionality that any account within the OU can use. Detective rules are implemented using AWS Config rules.
Custom OU’s can include a sandbox account (or a sandbox OU, which contains sandbox accounts). These are to be used by developers for experimentation and normally include a spending limit.
Other OU’s can be created for your actual workloads, the real value-add stuff that you’ll be building (in our example, WordPress sites). A “workloads” OU would house our live services, as well as internally mirror the software delivery lifecycle you intend to use. At a minimum, that would include a pre-production account (testing environment, UAT, Beta, whatever you call it…) where you can deploy changes for testing before you put the changes live to the world.
AWS Control Tower also manages AWS Identity Center (formally AWS SSO). This allows us to use a custom user directory to invite users to the organization, from here they can use a single sign-in portal to access whichever accounts the user, or the user’s group allows access to.
The user directory could live in the management account, but that doesn’t fit our architecture. Remember, the management account should just be used for managing the organization’s settings.
Since the directory is a shared service, it makes sense to have a Shared Services Organization Unit. Here, we can have an account for our directory. If we’re to use Route53 hosted zones for our DNS, then we can also create a Domains account within the Shared Services OU.
AWS Control Tower enables members of IT on your distributed teams to provision new AWS accounts quickly, using configurable account templates in Account Factory. Meanwhile, your central cloud administrators can monitor that all accounts are aligned with established, company-wide compliance policies.
In short, AWS Control Tower offers the easiest way to set up and govern a secure, compliant, multi-account AWS environment based on best practices established by working with thousands of enterprises.
AWS Control Tower has the following features:
· Landing zone — A landing zone is a well-architected, multi-account environment that’s based on security and compliance best practices. It is the enterprise-wide container that holds all your organizational units (OUs), accounts, users, and other resources that you want to be subject to compliance regulation. A landing zone can scale to fit the needs of an enterprise of any size.
· Guardrails — A guardrail is a high-level rule that provides ongoing governance for your overall AWS environment. It’s expressed in plain language. Two kinds of guardrails exist, preventive and detective. Three categories of guidance apply to the two kinds of guardrails: mandatory, strongly recommended, or elective.
· Account Factory — An Account Factory is a configurable account template that helps to standardize the provisioning of new accounts with pre-approved account configurations. AWS Control Tower offers a built-in Account Factory that helps automate the account provisioning workflow in your organization.
· Dashboard — The dashboard offers continuous oversight of your landing zone to your team of central cloud administrators. Use the dashboard to see provisioned accounts across your enterprise, guardrails enabled for policy enforcement, guardrails enabled for continuous detection of policy non-conformance, and non-compliant resources organized by accounts and OUs.
We’ll be using Control Tower to create an architecture like below:
I know that that’s a lot of theory and may seem a bit abstract right now. But we can jump into some walkthrough steps here, or you can check out the attached video. Hopefully, the following will clear all that up.
Walkthrough: AWS Multi-Account, Landing Zones & AWS Control Tower
- 1. Go to the AWS console home and click ‘Control Tower’, if not there — you can search it in the services bar at the top.
2. Should see an error like this. That’s because only the root user can administer this. Log out, and log back in as the root user.
3. Go back to Control Tower and click “Set up landing zone”.
4. You’re going to now want to specify the home region. In theory, this can be any of the regions in the dropdown, however, I like to set mine as N. Virginia — North Virginia has the most AWS features, and any certificated you may need to buy for CloudFront will have to be in N. Virginia, so I would recommend using US East (N. Virginia).
5. Now there are two other config details, whether Region Deny is enabled, and other regions for governance. Region Deny denies access to AWS services in any regions your control tower does not govern. You can then specify which regions you want to govern. I would recommend enabling Region Deny, if not — you can always enable it later (may take an hour or so to enable). Once you’ve specified the config you want, click “Next”.
6. Now you can define the OU name for your secured zone, as well as your additional OU. By default, these are “Security” and “Sandbox” respectively. I chose to name mine “Foundational” and “Workloads”. Specify the names then click “Next”.
7. Now you’ll need email addresses for the two accounts that are created in the Security/Foundational OU. Log archive and audit. Following the same practices as before, you can use a mail alias as I have. Provide these then click “Next”.
8. You can leave the other configurations as they are and click through. When you get to the end, your landing zone should begin construction. This may take some time. Feel free to pause here and come back when that is finished.
9. Now we can return to the control tower dashboard, and we can see what has been done
You’ll notice our environment now has three enrolled accounts. The management account, the Log Archive account, and the Audit account. These comprise the “Shared accounts”. We can also see that guardrails have been created, and we can see which ones are enabled or not, and out of those enabled — we can see which ones are enforced/clear.
You can create users in IAM Identity Center and then grant them permission sets to different AWS accounts, with an SSO portal to access the different accounts they’re a part of (you can also use Identity Center SSO to grant those users access to external SAML enabled apps, such as Slack or Office). More on Identity Center later.
Now we need to create some accounts through Control Towers ‘Account Factory’.
We’re going to be creating the directories account, which will store our user directory for WorkMail and WorkSpaces (mail and desktop solutions we’ll be providing to our users). If we wanted to use a self-managed Microsoft Active Directory solution to do this, we could also use this directory for Identity Center itself.
We’ll also be creating an account for our domain management (completely optional for this course).
We’ll be housing these in a “Shared Services” OU.
- Go to AWS Control Tower => Organization => Create resources => Create organizational unit
2. Once that has registered, go to AWS Control Tower => Account Factory. This will prompt you with a message that you cannot do this since you’re currently logged in as root.
3. We could log in with the administrator user we’ve created, but instead — let us create a user in Identity Center that we can use as the admin. This will make it easier when we’ll need to jump between accounts. Go to Aws Control Tower => Users and access. You’ll notice that when Control Tower was set up, you were emailed IAM Identity Center credentials.
4. Open the email and accept the invitation. Log in, and you should see something like this
5. You can now log in to the 3 shared accounts. When we create our other accounts, we can grant this user access to those. Click the management account, and then click the administrator access role log-in. This should now log you in as a federated user.
6. Go back to Control Tower. Go to Account Factory. Create Account. First, we’ll do the Domains account. Enter the email you’ll be using for the account (e.g. john+acmecorp-domains@mail.com). Use the same email for the Identity Center user email, this will create a user for the account in Identity Center. The OU will be “SharedServices”. Click Create account
7. 1. This will take some time to complete. When done, you can do the same for the directories account. Using this method, only one account creation request can be processed at a time.
For deeper technical details on AWS Control Tower, I recommend the following:
First, understand the following products used by Control Tower:
AWS Organizations: https://aws.amazon.com/organizations/
AWS Service Catalog: https://aws.amazon.com/servicecatalog/
AWS Identity Center: https://aws.amazon.com/iam/identity-center/
AWS Config: https://aws.amazon.com/config/
Then, for a clear overview of the history of AWS Control Tower, why we have it, and what landing zones are, see here: https://www.youtube.com/watch?v=zVJnenaD3U8
For a hands-on guide going through the behind-the-scenes of AWS Control Tower, please see here:
https://codeburst.io/aws-control-tower-by-example-part-1-d1b94df4c58c
The official documentation is here:
https://docs.aws.amazon.com/organizations/latest/userguide/services-that-can-integrate-CTower.html
https://docs.aws.amazon.com/controltower/?id=docs_gateway
And that should be everything for now for Control Tower! We now have our secured, well-designed environment to run our workloads and shared services. In part 3, we’ll be registering our domain name. This domain name is what we’ll use for our custom email addresses, as well as for our websites.
