Here’s a couple interesting fun facts in the form of numbers from yesterday (11/27), 6.46 and 0. Going to and from the various sessions, I walked 6.46 miles yesterday and I had 0 desserts. 0 desserts! I had a dessert Sunday night, a good one called “The cookie jar”. The cookie jar was a big, warm, and moist chocolate chip cookie served in a skillet, topped with vanilla ice cream and chocolate and caramel sauces. It was just as good as the waitress claimed it to be, but the problem was I ate the whole thing when I knew at the halfway point I should stop. When I got done, I could barely walk. I ate too much over the thanksgiving break and think the cookie jar was simply the last straw, throwing my body into some form of shock from way to much dessert in too short a time frame. Thus, yesterday I could barely fathom eating any kind of dessert, especially one involving chocolate chip cookies….I hope this is a temporary condition.
Back to the notes.
The Architecting Security and Governance Across a Multi-Account Strategy session was strange I had to go to the overflow room because I didn’t reserve the session originally but when told to put on the “blue” headphones to listen in, the speaker was not talking about a multi-account strategy but going through a 12-step procedure on how to setup the ideal cloud migration team? Whatever, I’m here so I might as well take notes but then 23 minutes into the 12-step process for creating a cloud migration team, the presentation stopped and we we’re then switched to the Architecting Security and Governance Across a Multi-Account Strategy session….so I missed the first 20+ minutes of this session.
I think what I’ll do is start out with the ideal multi-account approach and offer notes on the purpose of each desired account.
What became clear over the course of what we were able to hear is that your organization could end up deploying thousands of AWS accounts. Especially in the “Developer Accounts” box on the lower left. Though I missed the introductions, I’m pretty confident that one of the speakers worked for Capital One and he stated that they had over 12,000 Developer Sandbox accounts to give each developer their own autonomous “innovation space” on which developers can experiment while also having full administrative permissions to that environment.
A brief overview of the account types:
- AWS Organizations Master
- This account would have no access to the corporate on-prem datacenter and ideally would have as minimal resources as possible. Primary function is consolidated billing and the creation of service control policies.
- Enterprise Accounts – Logging
- Use this account to created a versioned, restricted, and MFA delete protected S3 bucket that would house all CloudTrail and other security logs. This S3 bucket serves as your “single source of truth”.
- Enterprise Account – Security
- This is the account in which any security and auditing tools would reside.
- Would need to enable cross-account read/write access
- Enterprise Account – Direct Connect
- This account would be managed by the network team and used for AWS Direct Connect and other networking services
- Enterprise Account – Shared Services
- This is the first account on which is was stated that connectivity to the on-prem datacenter is necessary.
- This account would house services such as DNS, Active Directory, your deployment tools (AMIs and Pipeline), your scanning infrastructure, as well as monitoring tools
- Enterprise Account – Billing Tooling
- This account reduces the need to access the Master Organization Account
- Use this account to generate billing reports and view usage metrics and reporting
- Enterprise Account – Internal Audit
- This account is created for regulatory compliance and requires read-only access to logs
Business Unit, Product, and Resource accounts are created based on the isolation level required by your organization and should match your development lifecycle.
- BU Account – Dev
- Used to develop and innovate quickly. Use as a collaboration space for teams of developers.
- BU Account – Pre-Prod
- The Pre-Prod account is typically connected to the on-prem datacenter and is a “production like” staging and QA space. You can also test automated deployments/upgrades in this space prior to moving to full production
- BU Account – Production
- Certainly this account is also connected to the on-prem datacenter and this is where your production services/resources reside.
- BU Account – Shared Services
- This is an account in which any product-specific shared services or common tools would reside
- BU Account – Sandbox
- There would be no connectivity from this account to your on-prem datacenter.
- This is where any promising experiments or new initiatives from the developer sandboxes would be tested prior to testing within the BU – Dev account.
So now that you know the accounts you need, what’s the action plan?
- Consider your automation plan/strategy
- Remember, you want to automate as much as possible as manually managing thousands of accounts would be a pain.
- Define a tagging strategy and stick to it
- As you embark on this journey (not just accounts but AWS in general), you’ll find tags are key to automating processes and security checks.
- Use the AWS Tagging Strategy whitepaper to help you with that
- Define an IP address strategy
- endeavor to keep your various accounts from having overlapping IPs
- Create the Organizations Master account
- Create the Logging account
- Create the S3 bucket for CloudTrail and AWS Config
- Enable MFA and versioning
- Limit access
- Enable CloudTrail on root account to send logs to Logging account
- Create the S3 bucket for CloudTrail and AWS Config
- Create the Security account
- Cross-account roles with trust to security account for root and logging
- create read-only and read/write roles
- enable CloudTrail and send to Logging account
- Create security tooling/Lambda functions for security checks
- Cross-account roles with trust to security account for root and logging
- Create AWS Direct Connect account
- Create Billing Tooling account
- Create Shared Services account
- Connect to on-prem datacenter
- Launch common services
- DNS, LDAP, Active Directory, etc.
- Create the Staging and Development BU Accounts
- Create the Prod Account
- Create the individual developer sandboxes
- ensure cross-account security roles are present
- keep them isolated and disconnected from the corporate datacenter
- enable MFA on the root account
- Create Internal Audit account
You may find the AWS Multiple Account Security Strategy document helpful as you work you way through this.
