Administration of Cloud services
There is a lot to be said about how our cloud infrastructure is deployed, which tools we’re using, how to select our architecture and overall to ask and answer on countless technical decisions. But what about all the bureaucracy that comes with managing a cloud account?
I often see large organizations working with AWS or with GCP where each team has their own billing account, payment method, tax information and other administrative information that is duplicated across the company. You wouldn’t do that with code, so why do that in this area?
There are many benefits for working with an Organization definition on the cloud.
In AWS for example, each account is a separated logical unit, and only the root account user has access to the billing service (or unique IAM permissions to enable IAM users to access billing). We’re talking about managing cost allocation tags, tax information, cost explorer, report exports, tax invoices and much more. Managing each account separately is a huge overhead and can cause human errors, for example, to set the wrong tax information and being billing the wrong VAT. Using a consolidated billing account will only require access to one account where all the sub-accounts under it get the same information, billing reports contain all accounts across all organizations, so even if you have an account in your organization that you don’t have the root access for – you can still monitor the costs and if it was created as part of the organization you can also manage the account itself.
In GCP it is a bit different, but with great similarities. Under an organization, we have a main billing account, and we can define sub-accounts to have better project management costs visibility. When you create a new project in GCP you need to either put billing information or associate it with a billing account. Either way – we’re talking about the same benefit – one centralizes location to manage administration and billing for your organization.
By the way – it is not just visibility on costs, but also visibility on usage – as the total usage in the organization is aggregated for the main consolidated account and this is how you can have visibility and commit to usage amount for better prices, have tiering discounts, and much more.
We have also decided on general guidelines to manage accounts:
1. Root account user - the account root user and email should be the managing team email + identifier for the account. For example system+account_name@yourdomain.com. The ‘+’ sign will allow you to append strings to your existing email system@yourdomain.com.
2. Root accounts should have a team’s email (PDL) and not attached to a single employee email. You don’t want to get stuck with a root account with ex-employee email and MFA enabled.
3. No one other than the infrastructure team should get root access to the accounts, but users with administrative access. Managing of accounts should be handled by one group, and not by different individuals across the company.
4. Accounts forecast and usage limitations - Once creating a new account we will need to set a budget for this account based on predicted usage and estimations. We will not set accounts without consolidating all the information related to the account - no more "Black boxes".
Summary
Using an organization features in managing our cloud infrastructure will help us in saving administration time, keep everything in one place, gives us better visibility for cost and usage, and help us focus on more important things once we configure everything once.
