Skip to main content
Latest Documentation
This is the latest documentation for the Cloud Posse Reference Architecture. To determine which version you're currently using, please see Version Identification.

FAQ

Frequently asked questions about managing AWS accounts with Cloud Posse's reference architecture.

Why not use Control Tower?

AWS Control Tower cannot be managed with Terraform. Depending on the Scope of Work, Cloud Posse is usually responsible for provisioning accounts with terraform which requires all the same access as Control Tower.

Why are there so many accounts?

Leveraging multiple AWS accounts within an AWS Organization is the only way to satisfy IAM level isolation. Each account has a very specific purpose, that all associated resources are isolated in that given account.

How can we set budgets?

Create budgets with the account-settings component. For more, see the account-settings component documentation

info

Budgets created for the root account apply to the AWS Organization as a whole

How do you add or remove Service Control Policies?

Service Control Policies are managed with the account component variable, service_control_policies_config_paths. For more, see the account component documentation

caution

This component manages the state of all AWS accounts, so apply with extreme caution!

How can you create an Account?

Follow the documentation for creating and setting up AWS Accounts

How do you delete an Account?

Follow the documentation for deleting AWS Accounts

How can you create a Tenant?

Follow the documentation for creating a new Organizational Unit

How do I use mixins and imports with Atmos?

As infrastructure grows, we end up with hundreds or thousands of settings for components and stack configurations. If we copy and paste these settings everywhere, it's error-prone and not DRY. What we really want to do is to define a sane set of defaults and override those defaults when we need them to change.

We accomplish this with Mixins. Mixins are imported into all stacks and each follow a set of rules. We use the mixins/region and mixins/account configurations to define common variables for all stacks. For example, mixins/region/us-east-1.yaml will define the variable region: us-east-1.

Note. Do not import components into the account or region mixins. These are imported multiple times to define common variables, so any component imports would be duplicated and cause an Atmos error such as this:

Executing command:
/usr/bin/atmos terraform deploy account-settings -s core-gbl-artifacts

Found duplicate config for the component 'account-settings' for the stack 'core-gbl-artifacts' in the files: orgs/cch/core/artifacts/global-region/baseline, orgs/cch/core/artifacts/global-region/monitoring, orgs/cch/core/artifacts/global-region/identity.
Check that all context variables in the stack name pattern '{tenant}-{environment}-{stage}' are correctly defined in the files and not duplicated.
Check that all imports are valid.

exit status 1

How do I access root credentials for member accounts?

With centralized root access enabled, you don't need to maintain individual root credentials for each member account. The management account can perform privileged root operations on any member account using the RootAccess permission set.

If you need per-account root credentials for compliance or recovery purposes, see Create Account Root Users.