In 2016 AWS rolled out the feature of ‘AWS Organisations’ to manage multiple accounts with single root user account access. In this blog, we will revisit the concept of AWS organisations and compare it with Google Cloud Platform
In simple words, AWS organisation is the collection of AWS accounts, that we can organise into a hierarchy and manage centrally. As per AWS organisations FAQs,
AWS Organizations offers policy-based management for multiple AWS accounts. With Organizations, you can create groups of accounts and then apply policies to those groups. Organizations enables you to centrally manage policies across multiple accounts, without requiring custom scripts and manual processes.
Now you may be wondering what the AWS account is. AWS account (similar to GCP projects) is a container for your AWS resources. You create and manage your AWS resources in an AWS account, and the AWS account provides administrative capabilities for access and billing. Typically you, as an individual user, create an account with AWS, with your email address (e.g. Gmail) and password, which is also the root user account.
If your organisation has already existing account with AWS, then you can log in to AWS console as IAM user as shown below:
AWS offers ‘Free-Tier Account’ where you get 12 months free access to AWS resources with certain constraints (free-tier eligible resources). Free-Tier account is sufficient for demo/trials/PoC purposes but not recommended for production purpose.
Before we proceed further, let’s understand another key concept of organisation units or OU. An organizational unit (OU) is a group of AWS accounts within an organization. An OU can also contain other OUs enabling you to create a hierarchy.
Now let’s assume you are in charge of your organisation’s IT departments and planned to move the current IT infrastructure to AWS. The first thing you need to do is to organise access to AWS resources among various stakeholders, including difference departments and sub-units, such as Development, QA, Productions, Customer-Care, Finance and so on. Moreover, not all departments should have similar requirements for resources and access rights. Production department might be having more stringent demands, while the development team might want a separate pool of EC2 instances for developing new features for your organisation’s cloud-native app. Operations team themselves don’t need access to resources beyond monitoring and alerting to relevant stakeholder if something goes wrong to take appropriate action. How do you handle these all requirements without messing up access to resources?
The most straightforward answer would be AWS Organisations. You will need to create different OUs (e.g. one for each department) and organise them under hierarchy to control access to resources. Once you charted out the plan for OUs, you need to create individual member/user accounts with ‘least privilege’ policies as per their profile. So your organisation structure might look like as below.
In above example, you could see a root user (IT head), created and organised different departments as OUs (Four OUs) and also created seven AWS accounts under these OUs. These OUs applied different access policies, which then also applies to all AWS accounts under the OU (Parent-Child). Each AWS account holder then logs in AWS console and deploy/use resources as per governing policy.
Another big advantage of AWS organisation is consolidated billing with central access. If we take above example, the root user can centrally monitor, restrict and administer the entire organisation and also has visibility into AWS resources billing for the whole of the organisation each month. If we don’t have the choice of using AWS organisation, then each OU or each AWS account will have their own resource usage bill and will be very difficult to manage the entire org structure. The solution gets justied.
In fact, AWS earlier has only consolidated billing option, but with the creation of AWS organisations, all those consolidated billing accounts either moved to AWS organisation with consolidated billing or full access options or in other words consolidated billing is now part of AWS organisations.
Now before we close this subject, let me briefly share how Google Cloud Platform (GCP) handles the similar challenge of organising resources among various organisation stakeholders with GCP organisations.
GCP offers ‘Resource Manager’, which allows you to organise and manage cloud resources under different resource containers, namely organisations, folders and projects. The overall concept is similar to that of
Inside GCP, as root (or admin) user, once you signup your organisation with GCP (either G Suite or Cloud Identity Customers), you can then create Organisations different folder (similar to OUs) for individual departments and group resources as per your requirement. Under Folders, you might have another system of sub-folders (Dev-QA), or you can directly create projects under each folder. A project is a logical grouping of resources (similar to AWS Accounts) which is linked to the billing account. You can refer here for more information about GCP Resource Hierarchy. Moreover, Cloud IAM defines who (identity) gets what access for which resources.
In the
With GCP, individual user or service accounts (application access) can assume different roles (a group of policies). These roles have parent level access policies, while all children (under the parent) will automatically inherit the policy of parents. The highest level of role anyone can assume is organisation administrator, below which you can have a folder admins, and project and individual resource level fine grain access roles (predefined or custom roles), which are based on ‘least privilege’ principle. The best practice is to define more granular resource level access policies than allowing primitive role based access policies.
There’s a difference in billing though. Although the detailed discussion of GCP Cloud Billing concept is beyond the scope of the blog, you need to create a billing account and link your payment details while creating the account. Once the billing account created, you need to link projects to the billing account. E.g below three projects, A, B and C linked to the billing account. You will have a consolidated bill for resources consumed under these three projects.
Moreover, there are different IAM Billing roles defined, and a user or service account can assume these roles. E.g. billing account admin role is the owner of the billing account, while billing account viewer role allows the user to view bills, but doesn’t allow to link/unlink projects linked to the billing account. The billing account viewer role generally associated with finance department (Folder), who needs visibility into resource usage and costs associated with it.
GCP offers a free-tier account with a credit of $300 for 12 months period. There are two different part of GCP free-tier, where under 12 months free trial period you can use/deploy GCP resources without any charges until you consume all your free credits (or before 12 months). The other part is always-free, which is different from the free-tier part, where you can access different GCP resource free (without any credits) but comes with a different set of constraints.
