Well-Architected automation

The AWS Well-Architected Framework was initially developed as a whitepaper in 2012 to help architects moving applications to, or building natively on, AWS. The framework asks introspective questions that lead you to best practices and ensure that application teams are getting the most out of cloud native architectures.

In 2018, AWS released the first version of the Well-Architected Tool. This service from AWS helps walk application teams through assessment of their workloads against well-architected principals. The tool systematizes the way assessments are performed, and allows the application team building on AWS to gain insight from an expert system. The use of the tool is free; teams just define their workload and answer a set of questions regarding operational excellence, security, reliability, performance efficiency, and cost optimization.

This post looks at how to leverage the AWS Well-Architected tool for large organizations with hundreds (or thousands) of AWS accounts.

Turbot Guardrails has long promoted the benefits of multi-account isolation when it comes to enterprise use of AWS. In this model each application workload is deployed into separate AWS accounts with some common centrally managed infrastructure. This allows the application team to focus on building their application, and the centralized cloud operations and security teams to standardize critical security, compliance and data protection setup that should be consistent across the organization.

However, this poses two challenges for organizations looking to leverage the AWS Well-Architected Tool. First, the application teams have less knowledge of some key infrastructure for their accounts; if the cloud operations team is deploying their VPC configuration or their CloudTrail logging is centralized, it can make it difficult for the application team to answer many of the questions in the Well-Architected review. Secondly, very large enterprises have a scale issue. Namely, how do you conduct thorough reviews across hundreds of AWS accounts and ensure that the application teams are asking and answering the right questions.

Get it done with Turbot Guardrails

Turbot Guardrails automation can ensure that Well-Architected Framework questions are automatically answered, covering aspects of the application and infrastructure architecture that are centrally managed (e.g. Networking, Identity, etc). Automatically answering common questions helps reduce the amount of work required for a Well-Architected review, which removes excuses and decreases the time & effort application teams spend on their assessments.

Questions can be answered statically and dynamically.

1. Static answers can be used when a centralized deployment, tool, process, etc. covers the intent of the question on behalf of the application team. They can also cover the case of ‘Not Applicable’ when questions are not relevant to the workload.

2. Dynamic answers are based on conditional logic. Using Turbot Guardrails Calculated Policies, data from the Turbot Guardrails CMDB can be used to evaluate the appropriate answer to specific review questions based on resource or Turbot Guardrails configuration.

Turbot Guardrails has two Mods that work together for automating the Well-Architected Tool. The ‘aws-wellarchitected` Mod automates configuration of the Well-Architected Tool and associated Workloads, and the ‘aws-wellarchitected-framework’ Mod which has 340+ policies that allow your team to automate answers to the default ‘AWS Well-Architected Tool Framework Lens’.

Static Example:

In this example, our network is centrally managed, so the cloud operations team will configure Turbot Guardrails to automatically answer questions related to the organization’s network configuration. In the UI we can browse the framework questions and see potential answers:

To automate the answer to this question across all 300 of our AWS accounts, we only need to set two policies. First, let’s choose the Enforce non-overlapping private IP address ranges… answer:

Now that the appropriate answer is chosen for our workloads, we tell Turbot Guardrails to apply the answer via the parent policy:

These same controls can also be configured via the Turbot Guardrails Terraform Provider.

Dynamic example 1 - using CMDB resource metadata:

In this example, our KMS keys are classified with specific tags which identify they are centrally managed. If the keys are present in the account, you can use Turbot Guardrails Calculated Policies to lookup information from the CMDB to decide on the answer to specific questions. As an example in “SEC 08. How do you protect your data at rest?” One of the available answers is “Implement secure key management”.

Using a calculated policy Turbot Guardrails checks to see if a specifically tagged KMS key is present in the current account. If Turbot Guardrails finds the key it sets the answer to the Framework question to be ‘True’ if not found, the value is set to false.

Dynamic example 2 - using control states in Turbot Guardrails:

In this example, our organization has encryption at rest requirements for many AWS services. Instead of enumerating checks on all the required services, we will use the Encryption at Rest control category to evaluate if encryption at rest controls are applied effectively. Control categories aggregate related policies across services and across cloud platforms. You can use Turbot Guardrails Calculated Policies to look for evidence that Encryption at rest controls are in use to answer the question “SEC 08. How do you protect your data at rest?”.

This calculated policy will count the controls in ‘ok’ and ‘alarm’ state for a given scope. If Turbot Guardrails finds evidence that 1 or more controls are in place it sets the answer to the question to ‘True’ and if it finds no active controls it will set the value to ‘False’.

Once any static and or calculated policies are set, Turbot Guardrails will automatically discover all workloads configured in the Well-Architected Tool and apply the defined answers to the specified questions. These policies can be further grouped into Turbot Guardrails Smart Folders to apply to specific classes of AWS accounts (e.g. ‘Production’, ‘Development’, etc.).

Make it happen!

See for yourself how Turbot Guardrails can help you manage Workload Assessments at scale. As you are working towards setting these policies, an initial baseline to get started is available from the Turbot Development Kit (TDK). Additional calculated policy examples for dynamic answers (resource data and control states) are also available in the TDK in the calculated policies section. If you need any assistance, let us know in our Slack community #guardrails channel. If you are new to Turbot, connect with us to learn more!