AWS accounts are a critical object for structuring, securing, and managing your AWS cloud resources. While they are foundational for best practices cloud usage, they can be annoying and tedious to set up appropriately.
In this blog we’ll cover how you can make AWS account usage ubiquitous by providing an easy way to provision them, while ensuring that security, cost, organizational, and other standards that your company wants to follow are met. We’ll do so by starting with an existing Terraform module, turning it into a simple UI for developers to interact with, and adding guidance and guardrails around that UI experience.
Importance of AWS Accounts
AWS Accounts provide logical separation of concerns. With them you can:
- Isolate and secure your resources
- Isolating resources reduces the blast radius of potential breaches or malicious activity
- Secure different accounts with different IAM roles, permission sets, or policies
- Manage costs
- Separate billing reporting and tracking make cost optimization easier
- Compliance and governance
- Some industries are subject to strict regulation, requiring data governance practices such as isolation
- Scalability and management
- Organizing resources into accounts and separating access makes it easier as usage grows: your AWS organization won’t become a cesspool of mixed resources with no clear hierarchy
Companies use AWS accounts for a variety of use cases, from dev/staging/prod, to cost & budget tracking, to organizational or project-based separation.
AWS ControlTower Account Factory for Terraform
Module description
The AWS ControlTower Account Factory for Terraform (AFT) sets up an account factory for AWS, building a framework that allows users to provision new accounts seamlessly. Like with any Terraform module, it can be complicated and hard for a developer to implement…especially one who doesn’t often work with Terraform.
The AFT module creates many resources:
- CloudWatch logging queries
- Multiple IAM roles, policies, and policy attachments
- Lambdas with VPC configs for initiating accounts
…and requires 15 inputs that developers may need help, guidance, and a sensible path when deviating from defaults.
Adding a UI
To simplify our experience with Terraform and make it easier for developers to create AWS accounts that meet our standards, let’s import this module into Resourcely in order to automatically create a guided UI for this module.
Importing
Log in to Resourcely (create your free account here), click Create Blueprint, and then Import a module from external source.
Resourcely automatically detects inputs, assigns types, defaults, and more:
We’ll select the fields we care about, optionally select how to organize each variable on the next screen, and then we’ll have a Resourcely Blueprint built on top of this Terraform module. Immediately, a smart UI is created where users don’t need to interact with Terraform in order to take advantage of this module:
Guiding user inputs
Descriptions, defaults, and suggestions
Notice that our UI already has defaults and descriptions, automatically taken from the Terraform module’s variables.tf
. We can make changes to these easily in the variables frontmatter. Let’s take a variable and make improvements:
vcs_provider
variable frontmatter:
Resulting form input:
We can add a global value to this frontmatter to populate a dropdown box for developers to select from (instead of having to type in one of the valid inputs manually).
We create a Preset collection:
…and add it to our new vcs_provider
variable frontmatter, and change our description:
Here is what the form looks like for this variable now:
Policies
We can use Guardrails to better limit user inputs, and give them an easy way to request an exception to the rules we put in place. Let’s consider our logging expiration-related variables. Our Terraform module instructs a default of 365 days for log_archive_bucket_object_expiration_days
, which has been reflected in our variable frontmatter:
Let’s say we want to require logging to between 1 and 2 years for compliance or regulatory reasons. With the existing Terraform module, there would be no way to control that. With Resourcely Guardrails, it is easy.
From Foundry, navigate to Author a Guardrail and enter the following Guardrail:
If you start manually typing the above Guardrail you will notice Foundry’s autocomplete feature that make it easy to write new Guardrails.
Add metadata, save the Guardrail, and navigate back to the Author a Blueprint tab. On the developer form you can now see the Guardrail in action:
Embedding the Guardrail rules into the form allows users to know when they have deviated from a policy or rule before CI, so they aren’t wasting valuable cycles waiting for policies to evaluate and then making configuration changes.
This Guardrail will also be evaluated as part of our Terraform plan, and terraform apply will be blocked until the appropriate team can review and approve this exception.
Conclusion
We’ve walked through creating a Blueprint for setting up ControlTower Account Factory. We did this by quickly converting a Terraform module into a Resourcely Blueprint. With an Account Factory, you can encourage and simplify the use of AWS accounts: isolating your resources into logical groups, tracking costs and budgeting, and meeting compliance requirements.
The next step on your journey is to create a Blueprint for developers to use, that provisions accounts using the Account Factory that you just set up. You can do this yourself in Resourcely: sign up for free today, and import the account-provisioning
module using the same process that we used above.