AWS Account Strategy for every business

You read it right, this blog is for every business running AWS workloads. Not just for enterprises but even for startups. In this blog i’ll try to cover the various account strategies i have come across working with different customers and why having a robust account strategy is useful for any business in the longterm.

So without adding more curiosity in your minds,

Credits: tenor.com

To begin with, let’s go through the various scenarios.

We ❤ one account (“the no complexity” myth)

I have seen this approach taken up not just by startups but some medium scale businesses as well. The reasons given by some of the IT managers for such a setup were

1. I don’t wish to segregate my workloads. It just increases my operational overhead of maintaining so many accounts. (You’ll know later!!)
2. Why do you need different accounts? I have 5 servers only and i don’t think my business would scale. (You are kidding right? :P )
3. The two reasons above ain’t enough?

Scattered accounts (one company owning multiple accounts)

“Hey Yash, what’s the issue here mate?”. Yes i saw that coming :) So companies with different teams holding different accounts with no central governance in place is a clear recipe for disaster.

Reasons being:

1. No clear path for cost management
2. No governance in terms of security and internal compliances.
3. Increased operational overhead for finance teams to make separate payments for the different invoices.
4. No AWS organisations related benefits (not so detailed walkthrough later in the blog)

Now does this happen?

1. No central cloud team to roll out policies.
2. No inter team communication.
3. Office politics? (#kthxbye)

Whenever you are planning an account strategy for your organization, the following questions/concerns need to be raised internally to finalise the approach

1. How many customer facing applications would you be hosting?
2. How many B2B applications are supposed to be hosted?
3. How many internal applications (such as HR, Finance etc) are to be hosted.
4. Are you planning to host any IOT based apps?
5. Who would be managing your infrastructure (internal or some MSP)
6. How would the chargeback be handled?
7. Networking considerations (VPN, DX, CIDR allocation, Internet and intranet flows etc.)
8. Are you planning to use multi region deployment strategies?
9. What tools would be used to monitor the infrastructure? Are their any compliances you need to adhere to? (Example: HIPAA, MAS, etc)
10. How would you be managing your identity requirements? (AD, Okta etc)
11. How do you carry out your current deployments? What is your envisioned devops practice?

The above questions are quite generic and need to deep dived into once you start rolling out accounts for your teams. Only once you have some clear answers you can define the networking, security and compliance strategies for all your AWS accounts.

For startups and mid sized enterprises it would make sense to segregate the accounts based on

1. Environments (Dedicated account per environments) — This basically means you have separate accounts for all your environments. This brings in isolation in terms inter-environment mingling as well as user access. No one accessing the dev environment can go and fiddle with the prod environment (oh yes this also depends on your access management)
2. Shared Services — This account would usually handle shared services such as AD, internet and intranet traffic along with the network firewalls (like Palo Alto, Checkpoint etc). When you have such an account you need to consider things such as automated on boarding of other environments. Try making this as seamless as possible using automation scripts or tools. Have a plan for that beforehand.
3. Devops account — Some enterprises tend to create the pipeline in the shared account but having a dedicated account for carrying out all the deployments would make more sense in terms of making things a bit less error prone.
4. Security and Logging account: Would be used to host security related functionalities, like guardduty, config, security hub, detective and logs from different sources such as VPC flow logs, Cloudtrail logs, application logs etc which can be piped to an SIEM tool for analysis.
5. POC accounts: This might be the “go kids play” account where you allow your team to make use of services which might not be available in other accounts (due to some stringent SCP’s etc). Intelligent managers would set a budget for that account so that they are not questioned later on by the management.

When you consolidate or have a proper account strategy in place you get the following benefits:

1. Cost: You can distribute the discounts you receive from AWS across accounts from an org perspective. Be it from EDP, Savings plan or reserved instances. All these benefits can distributed when carried out on an org level. (yes, just the tip of the iceberg)
2. Governance: Central tagging policies, centralised logging, centralised networking, centralised billing (do you need more?)
3. User lifecycle management: Once the user leaves the organisation/changes teams, you don’t need to login to each account where the IAM user has been created, just use the central IAM service to activate/deactivate the user from the accounts.
4. Faster go to market — Oh yes copied directly from the AWS slide deck :P Faster account creation with prebuilt security and compliance checks makes it easier to roll out environments and pass quality checks before moving into production.

So after reading this, you might want to relook into the way you handle the environments/accounts in your organisation and if you need help in getting a better understanding, DM me on LinkedIn, coz why not?

So if you think there are any pointers missing (i know quite a lot) or any specific topic that you want me to cover in the next blog, do let me know and i’ll take it up.