The Ops Community ⚙️

David Krohn
David Krohn

Posted on • Originally published at globaldatanet.com

Account Factory - provision AWS Accounts

Best Practice for creating AWS Accounts

What is an Account Factory?

The Account Factory is a solution to manage account creation and bootstrapping in a scalable and efficient manner so that new accounts are created with a defined baseline and governance guardrails are in place. If you want to get your hands dirty with an Account Factory - you can take a look at this workshop.

Why should I use a Account Factory?

  1. ⚙️ Equivalent process for every account

  2. 💸 Save time and resources

  3. 🔐 Secure and well-architected accounts

  4. 📜 Documented process

  5. 🔌 Native integration to your ticket system like Jira - ServiceNow; this means that internal approval processes can be used to trigger the Account provisioning

  6. 🚀 Ready to use accounts in minutes

What solutions are outside for account provisioning?

If you use the Control Tower for your Landing Zone it's coming already with an Account Factory - there's also already existent solutions to customize the Account Factory to your needs. Even if you use the official landing zone solution there are some examples of Account vending machines on github.

What steps are part of an account factory?

  1. Creation of a new AWS Account - the first part of the Account Factory is to provision a new Account, the solution is using the organizations API for that. 💡 Activate IamUserAccessToBilling - othwerwise only the root user of the new account can access account billing information.
  1. Deploy the baseline template to new AWS Accounts - regardless of whether you want to provide resources via API / CDK, StackSets or CodePipeline, you need a role that you can assume in the new account, so we need an AccountBaseline that includes a role with trust for the management or automation account.
  1. Remove default VPC - A default VPC is suitable for getting started quickly - not for production workloads.
  1. Deploy security baseline and other customized ressources - this step includes eg.: the activation of GuardDuty, Config, CloudTrail - if you dont use the Organizational Trail, creation of own VPC, security notification service etc. You can use StackSets or CodePipeline for that. It would make sense to separate the configuration which stacks /resources you want to activate from the actual Account Factory. 💡 You can for example use SSM Parameter Store for that - You could also think of using different configs for services , which are deployed in to new accounts or not depending on the selection in the Account Factory.
  1. Optional:
    • Use support case API to activate enterprise Account in the new Account.
    • Activate root MFA automatically.
  1. Move new Account to desired organizional unit. According to best practices, it is recommend to structure your accounts in an organization and assign scps to organizational units. Since SCPs can cause problems when providing a new account, I recommend to move the new accounts at the end of the Account Factory to the corresponding unit.
  1. Send status mail or slack / teams message. In order to get a status overview of the new Account, you should think of collecting information while the Account Factory is running and send them as a message to the new Account owner or governance at scale team.

Account Factory Example Architecture

Top comments (0)