Reducing the Cost of Managing Multiple AWS Accounts Using AWS Control Tower

By Jonathan Pape, Sr. Cloud Systems Engineer at Logicworks
By Matthew Stockdale, Director of Professional Services at Logicworks

As larger and more complex workloads are deployed on Amazon Web Services (AWS), multi-account solutions are an increasingly common architectural blueprint.

These multi-account blueprints, often referred to as cloud “landing zones,” enable simple administrative boundaries along with a more confined blast radius. However, using multiple accounts also increases the complexity of security tooling, access control and authorization, and cross-account networking.

AWS Control Tower simplifies the process of setting up new multi-account environments with predefined security baseline templates. AWS Control Tower also enables self-service for new account provisioning with automated application of baselines and account standards.

At Logicworks, an AWS Partner Network (APN) Premier Consulting Partner and Managed Service Provider (MSP), we have built many AWS Control Tower deployments in a wide variety of industries.

In this post, we share our best practices for deploying AWS Control Tower services, having gleaned those best practices through real-world trial and error. We’ll show you how AWS Control Tower helps you automate the build-out of a multi-account architecture based on AWS best practices.

We will also share real-life stories of how companies are using AWS Control Tower to build and maintain large, complex AWS environments.

What is AWS Control Tower?

AWS Control Tower helps you set up and govern a new, secure, multi-account AWS environment. You can manage the service through the AWS Control Tower dashboard, which gives you continuous visibility into your AWS environment.

You can view the number of organizational units (OUs) and accounts provisioned and the number of guardrails enabled. You can also check the status of your OUs and accounts against those guardrails, and see a list of non-compliant resources.

In essence, the AWS Control Tower dashboard is an overlay interface to AWS foundational services and administration elements that collectively deliver a landing zone solution.

Figure 1 – AWS Control Tower services and administrative elements.

By combining the foundational services and administrative elements shown in Figure 1, AWS Control Tower provides:

Account provisioning via Account Factory.
Standardized account security baselines, called guardrails.
Centralized log storage for AWS CloudTrail or AWS Config services.
Centralized multi-account account authentication via AWS Single Sign-On (AWS SSO) with an integrated directory.
Auditor support and access capabilities.
Dashboard interface to view the status and notification events of AWS Control Tower-managed components and foundational services from the AWS Management Console.

Here is a brief summary of what each component does for our overall solution:

AWS Organizations — Provides multi-account management and structure, including centrally managed billing; control access, compliance, and security; and resource sharing across our AWS accounts.
Service Control Policies (SCPs) in AWS Organizations — Offers central control over the maximum available permissions for all member accounts; used in AWS Control Tower to implement preventative guardrails.
AWS Organizational Units (OUs) — We use it to group accounts together to administer as a single unit, effectively applying the preventive guardrails to multiple accounts.
AWS Config Rules — Allows us to define the desired configuration state for our AWS resources; used in AWS Control Tower to implement detective guardrails.
AWS CloudTrail — Enables us to log, continuously monitor, and retain account activity; in this case, multi-region API activity in each of our accounts.
Amazon Simple Storage Service (Amazon S3) — We use it as a bucket in the log archive account to provide a central archive location.
Amazon Simple Notification Service (Amazon SNS) — A messaging service we use to deliver security and events notifications.
AWS CloudFormation StackSets — Enables us to create, update, or delete stacks across our multiple accounts and regions with a single operation. We use them to apply baseline templates to our managed accounts.
AWS Service Catalog — Allows us to create and manage catalogs of IT services that are approved for use on AWS. It drives the Account Factory and enables you to provision other self-service application infrastructures.
AWS Single Sign-On (AWS SSO) — We use it in the Organizations Master Account to centrally manage access to all our AWS accounts. It also provides the multi-account authentication process and the AWS console sign-in URL.

AWS Control Tower can also work with functionality not yet exposed in the dashboard, but available in the direct configuration of the foundational services. For example, you can repoint AWS SSO to another identity provider directory, including Azure Active Directory or AWS Directory Service for Microsoft Active Directory (AWS Managed Microsoft AD).

This type of AWS SSO configuration works in an AWS Control Tower environment, but is not yet displayed in the dashboard itself.

You can also extend Control Tower with customizations.

Figure 2 shows the AWS Control Tower dashboard with a few accounts provisioned.

Figure 2 – AWS Control Tower dashboard.

How is AWS Control Tower Different from AWS Landing Zone?

Prior to the release of AWS Control Tower, the AWS Landing Zone solution provided a similar blueprint for deploying a multi-account landing zone. AWS Landing Zone was only available via an approved APN Partner or a partner-led professional services engagement.

AWS Landing Zone delivered similar functionality to AWS Control Tower, but was delivered via AWS CodePipeline and had no interface in AWS console. However, most of the functionality delivered by AWS Landing Zone has been migrated into AWS Control Tower.

Capabilities that were formerly delivered as AWS Landing Zone “add-ons” are available in AWS Control Tower with the Customizations for Control Tower solution.

Some functionality found in AWS Landing Zone has been removed from the default AWS Control Tower deployment to reduce initial cost and complexity. For example, Amazon GuardDuty is no longer enabled in accounts by default, and AWS Control Tower no longer deploys a Shared Services account automatically.

AWS Control Tower now only deploys two managed AWS accounts into the core organizational unit: Log archive and Audit.

AWS Control Tower is currently the recommended AWS solution for all new multi-account landing zone deployments.

Best Practices for Setting up AWS Control Tower

At Logicworks, an AWS Security Competency Partner, we have built many AWS Control Tower deployments for companies in a wide variety of industries. We gleaned the following best practices through trial and error with AWS Control Tower services. We hope they help you answer common questions.

Best practices include:

Automating the creation of Amazon Virtual Private Clouds (Amazon VPCs).
Using AWS Transit Gateway.
Enabling self-service using AWS Service Catalog.
Using AWS Single Sign-On.
Reflecting internal organization structures and patters in AWS Control Tower.

Automate the Creation of Amazon VPCs

Account Factory creates an initial set of Amazon VPCs for the accounts to be managed by AWS Control Tower. You may be able to leverage those VPCs if you meet these conditions:

Software-as-a-Service (SaaS) provider that gives each of your tenants their own AWS account.
All your tenant accounts have the same infrastructure.
You don’t use any inter-account private network connectivity.

However, the vast majority of use cases require VPCs in each account to communicate with other VPCs in AWS Control Tower. For these use cases, we recommend configuring AWS Control Tower without a VPC.

You can also create Amazon VPCs outside Account Factory by using AWS Service Catalog. Simply create a standardized VPC deployment Service Catalog Portfolio and Service Catalog Product in the Master account. Then, share that Portfolio with the rest of the accounts for customized VPC creation.

The VPC Product can also contain adjunct resources for automated attachment to AWS Transit Gateway attachment, routing tables, standard Network Access Control List (network ACL) rules, Route 53 Resolver, and shared rules, among others.

This approach ensures your desired networking configuration is created the same way in every account. In turn, that significantly reduces the manual configuration effort to create new VPCs. It’s especially useful in use cases for which you frequently create customized VPCs.

Use AWS Transit Gateway

Managing point-to-point connectivity across many Amazon VPCs, without the ability to centrally manage the connectivity policies, can be operationally costly and cumbersome. For on-premises connectivity, you must attach your AWS Virtual Private Network (AWS VPN) to each individual Amazon VPC. This solution can be time consuming to build and hard to manage when the number of VPCs grows into the hundreds.

AWS Transit Gateway is a service that enables you to connect your Amazon VPCs and on-premises networks to a single gateway. It’s a complimentary service with AWS Control Tower’s multi-account architecture.

To connect VPCs in all the accounts in your AWS Control Tower, you only have to create and deploy a “centralized router” from the central gateway. From that point on, AWS Transit Gateway acts as a hub that controls how traffic is routed among all the connected networks, which act like spokes.

This hub-and-spoke model significantly simplifies management and reduces operational costs because each network only has to connect to AWS Transit Gateway and not to every other network. Any new VPC is simply connected to AWS Transit Gateway, and is then automatically available to every other network connected to the AWS Transit Gateway.

If you want to more narrowly define the routing between VPCs on AWS and your on-premises network, you can use AWS Transit Gateway to enable hybrid connectivity on AWS Control Tower. Simply attach provisioned dedicated network connections of AWS Direct Connect, AWS VPN, and site-to-site VPNs to AWS Transit Gateway.

Deployment Tip

To make AWS Transit Gateway available for all the VPCs in your AWS Control Tower solution, share the AWS Transit Gateway using the AWS Resource Access Manager (AWS RAM).

Once you share the AWS Transit Gateway to the AWS Control Tower accounts using their organization IDs, the VPCs in each account can view the AWS Transit Gateway. They can also submit AWS Transit Gateway attach requests to connect an Amazon VPC to the centralized AWS Transit Gateway using software defined networking.

If you want to deliver all traffic to the AWS Transit Gateway for centralized egress routing (default route 0.0.0.0/0), or route only on-premises-directed traffic to the AWS Transit Gateway, add local VPC route table routes.

Enable Self-Service with AWS Service Catalog

A common design goal is to enable developer teams and business unit owners to self-provision new environments, while ensuring mandatory security tooling is in place. AWS Control Tower supports self-service provisioning of new accounts with Account Factory. The process ensures automated deployment of security rules via AWS Control Tower guardrails.

Logicworks has frequently extended self-provisioning capabilities in landing zone projects. We have done so by leveraging AWS Service Catalog to allow users to deploy default infrastructures according to templates, such as default Amazon VPCs that automatically attach to AWS Transit Gateway.

You can create a selection of default application infrastructures in AWS Service Catalog and automatically share them with new accounts. This enables business unit owners of the new accounts to quickly launch approved infrastructure patterns that align with standards for security and logging in AWS Control Tower.

Use AWS Single Sign-On

If you work with multiple AWS accounts across several teams and business units, you need a centralized approach for access and authentication to your AWS resources. By default, AWS Control Tower includes AWS Single Sign-On as a mechanism for identity management, using a default directory.

You can access AWS SSO either through the AWS Console or through API functions you enter in the command line interface (CLI). With either form of access, you have two options for identity providers:

Option 1: Default SSO directory.
Option 2: External identity provider.

Option 1: Use the Default SSO Directory

In a standard AWS Control Tower deployment, you administer SSO users in the default SSO directory, which you set up during the initial deployment of AWS Control Tower. The standard deployment also sets up a default set of AWS SSO permission sets and user groups. You can view these permission sets and user groups in AWS Control Tower dashboard.

From there, you can also create users and add them to these groups directly via AWS SSO portal.

Figure 3 – AWS Control Tower users and access.

Option 2: Use an External Identity Provider

At Logicworks, we often get a requirement to integrate AWS SSO with a different identity provider. You can use an external provider because AWS SSO supports using Microsoft Active Directory or Azure Active Directory as the identity source.

You can use Microsoft Active Directory in the form of on-instance, on-premises, or AWS Managed Microsoft AD. Depending on the specifics of your active directory deployment, you may also need to deploy an AWS Directory Service Active Directory Connector to proxy the authentication requests between AWS SSO and Active Directory.

Once deployed, the Active Directory Connector simplifies logins and resource management. It also lets you enforce the same security policies on-premises and in the cloud. It also enables multi-factor authentication.

Reflect Internal Organization Structures and Patterns in AWS Control Tower

We have had individual business unit owners and development groups request individual AWS accounts for running “their own stuff.” These separate accounts simplify billing and access control for the leaders of these groups.

In fact, AWS Control Tower allows you to create these separate environments and maintain default security standards through guardrails. By using service control policies (SCPs), you can configure developer accounts with very open sandbox permissions, and configure production accounts with more restrictive permissions.

Additional AWS Control Tower Considerations

These are some additional considerations to keep in mind when you set up AWS Control Tower.

AWS Control Tower has no AWS API access.
Not all AWS regions support AWS Control Tower at this time (currently only five).
Currently, AWS Control Tower only deletes (purges) the default Amazon VPC from managed accounts in supported AWS regions.
AWS Control Tower currently only deploys Detective guardrails into managed accounts in supported AWS regions.
AWS Control Tower supports in-place upgrades to new AWS Control Tower versions, and prompts you to upgrade via the dashboard.
AWS Control Tower provides some drift detection and remediation for AWS Control Tower-managed configurations.

Managing AWS Control Tower Costs

The same basic principles for managing cloud costs on AWS apply to managing costs in AWS Control Tower. These include reducing unused resources and leveraging Spot and reserved instances of Amazon Elastic Compute Cloud (Amazon EC2).

However, AWS Control Tower provides additional capabilities and some enhanced options for cost control:

Consolidated billing.
Reserved Instances, savings plans, and service control policies.

Consolidated Billing

Through AWS Organizations, which provide central governance and management across AWS accounts, the billing data for all accounts is centralized into a consolidated billing report. This allows organization-wide visibility through AWS Cost Explorer and forecasting and alerting through AWS Budgets.

We recommend the following best practices and products to make the most of this reporting:

While it may be possible to allocate gross costs to budget owners or business units at the account level, we still recommend you implement an organization-wide tagging standard. Then, measure compliance through AWS Config (specifically, the “required-tags” AWS Config Managed Rule). Make these tags part of your AWS Service Catalog products. Consider automatically terminating non-compliant resources in non-production accounts.
.
In addition to traditional informative or Cost Allocation tags, consider more creative use of tag keys such as “expiration” or “deleteafter” to make sure that resources are reviewed periodically. You only want to keep what is still justified. Consider automating the reaping of expired resources or Service Catalog products in non-production accounts.
.
Implement AWS Cost and Usage Reports, and import the data into native AWS Services such as Amazon Athena, Amazon Redshift, or Amazon QuickSight. These will give you more advanced query capabilities. You can also use a third-party cost optimization or cloud management platform.

AWS Reserved Instances, Savings Plans, and Service Control Policies

AWS provides more options than ever to reduce costs through spending commitments via Amazon EC2 Reserved Instances and Savings Plans for AWS compute services. Using AWS Organizations, AWS Control Tower helps manage commitments in aggregate:

By default, Savings Plan and Reserved Instance commitments apply first to the account they are purchased in. However, underutilized commitments can apply to other accounts in the Organization. Consider leveraging SCPs to whitelist regions, instance types, or families in order to better use Savings Plan or Reserved Instances across accounts. Don’t disable Savings Plan or Reserved Instance sharing unless necessary.
.
Take advantage of lifecycle metadata (for instance, “expiration” or “deleteafter” tags) when planning your Savings Plans or Reserved Instance purchasing. You can purchase multiple Savings Plans, so don’t feel obligated to make one large commitment to support all your workloads.
.
Savings Plans are a simple way to reduce your spending, but remember that unlike Reserved Instances, they can’t be sold. There is also opportunity for volume discounts. Consider centralizing the cost commitment function across your organization. Also provide advice and guidance to your application owners or business units to make sure they select the cost saving strategy that most benefits the Organization as a whole.
.
Perform regular cost reviews and pay attention to long-term trends in commitment utilization and coverage. Some individual or ephemeral workloads, such as development environments or sandboxes, may not make sense for Service Plans or Reserved Instances. It may be worth committing to a percentage of these workloads in aggregate.
- For example, the hourly spend across all development accounts may vary from $50 to $100 an hour. If that spend rate is consistent for many months, consider a savings plan commitment of 50-80 percent of minimum sustained usage, or $25 to $40 an hour.
  .
Tag your Reserved Instance and Savings Plan purchases. Tie each back to a specific business justification and make sure it still applies when it comes time to consider renewal.

Launching AWS Control Tower in the Real World

Over the past year, Logicworks has launched nearly a dozen multi-account solutions for a wide variety of customers. AWS Control Tower is a perfect toolset for any company that must segregate business units or SaaS tenants, while maintaining central billing and security baselines.

The companies we’ve worked with have been pleased with the result: a secure, well-organized account structure that can expand with their company.

These are just three of the multi-account projects we’ve worked on in the last 12 months:

Financial investment management firm used a landing zone to provide dedicated accounts for each portfolio manager or team, with automated baselines and security tooling by default.
Franchise-based service delivery organization used a landing zone to provide accounts for every business unit and application development lifecycle.
Billing management SaaS provider used a landing zone to deploy dedicated accounts per end tenant for clear infrastructure segmentation by customer. This also allows them to maintain different security and compliance requirements for each customer, if necessary.

Conclusion

AWS Control Tower doesn’t just simplify the process of building out multi-account architectures, it also gives you a dashboard and other tools for long-term manageability.

We believe this is the reason AWS Control Tower is becoming more popular. Companies understand the pain of managing disparate cloud environments. The elegant way in which AWS Control Tower handles complex matters like authentication and provisioning set it apart from other cloud platforms.

If you’re planning to launch an AWS Control Tower-based environment, we encourage you to seek out expert help. Leveraging an approved AWS Control Tower partner like Logicworks can dramatically accelerate the training, design, and build process. It also ensures a secure, cost efficient solution.

If you’re interested in learning more about AWS Control Tower, explore the getting started documentation. To learn more about Logicworks, please visit our website.

The content and opinions in this blog are those of the third party author and AWS is not responsible for the content or accuracy of this post.

.

.

Logicworks – APN Partner Spotlight

Logicworks is an APN Premier Consulting Partner. They provide expertise in complex infrastructure for industries with high security and compliance requirements, including finance, healthcare, and retail.

Contact Logicworks | Practice Overview

*Already worked with Logicworks? Rate this Partner

*To review an APN Partner, you must be an AWS customer that has worked with them directly on a project.

AWS Partner Network (APN) Blog