To effectively manage infrastructure and environments, at some point, you realise multiple AWS accounts are necessary.
You might want to separate Dev and Test Accounts from Production ones ( so that billing and quotas are not mixed up, and maybe only few people, or CI Pipelines, can touch Live apps and so on), or you might want different departments or business units to have their own account and manage their own AWS services.
AWS accounts are natural boundaries for permissions, security, costs, and workloads. On the other hand, the more accounts and environments you have, the more risks and vulnerabilities ( due to loose or wrong configuration ) you are exposed, and the more management complexity you have.
That is why AWS Organizations is useful: to consolidate multiple AWS accounts, organise them into hierarchies, and centrally manage them.
AWS Organizations
AWS Organizations have a Management ( also called Master or Main) account and Member Accounts.
Members account can be created, migrated from other organizations, or simply invited.
All this actions can be accomplished via UI console but, when numbers are large, it is very handy to be able to do these via Organizations API.
AWS Organizations has 2 features set:
All features – The default. Basically the main point of entire service. ( especially tagging policies
Tag policies to enforce Tag Standardization across OU and Resources and SCPs)Consolidated Billing – a subset of features, which provides basic management tools to centrally manage the accounts.
Consolidated Billing
Consolidated Billing which means basically, one credit card and one bill, but still granular info about costs from each OU and accounts. Having one bill is also helpful to reduce costs because it allows to aggregate usage of specific services and leverage discounts per volume.
An organization has then a Paying Account, and ( by default ) up to 20 Linked accounts.
Organizational Units (OU)
Member Accounts can be grouped in hierarchies with Organizational Units.
An organizational unit (OU) is a group of AWS accounts within an organization.
Grouping account together ( like ProdOU, TestOU, AuditingOU ) allows you to use Service Control Policies ( SCPs) to control tagging and API Actions.
SCPs
An Service Control Policy defines the AWS service actions, such running EC2 Instances, that are available for use in different accounts within an organization.
In order to use SCP your Organization must have All-Features enabled.
It is worth remembering that SCP do not grant permissions!, they control the maximum available permissions, they set a boundary of permission.
SCP affect principals managed by your accounts in your organisation, they do not affect resource-based policies.
Remember that SCP are guard-rails to the what is permitted by IAM User and Role Policies (see previous post about IAM for more info).
By default AWS Organizations cascades a FullAWSAccess policy to every OU and account ( meaning that no particular boundary is applied). Organisations uses Deny List strategy - therefore if you want to set a boundary on some permissions you need to
add an explicit Deny List in whatever point of the hierarchy (root, OUs and individual accounts).
It is possible though to remove the FullAWSAccess and therefore having a Allow List strategy.
This means that you have to create SCPs to allow permissions and attach them to every account and every OU above it.
AWS Control Tower
AWS Control Tower is basically an extension of Organizations and provide additional control to:
- Create
- Manage
- Distribute
- Audit
large number of AWS accounts.
Main concepts, features of Control Tower are
Landing zone – A landing zone is a well-architected, multi-account environment that's based on security and compliance best practices.
It basically creates a solid blue print and starting point to set up your multi-account multi-environment aws accounts.
Controls – A control (aka guardrail) is a high-level rule that provides ongoing governance for your overall AWS environment.
Account Factory – An Account Factory is a configurable account template that helps to standardize the provisioning of new accounts with pre-approved account configurations.
Guardrails / Controls
Three kinds of controls exist:
- preventive
- detective
- proactive.
Three categories of guidance apply to controls:
- mandatory
- strongly recommended
- or elective.
Control tower create Preventive Guardrails, which disallow API actions using SCPs.
It also created Detective Guardrails ( based on AWS config rules and Lambda to monitor and govern compliance )
Already by just looking at their name, they clearly express the intentions of policies, check more in detail how they work here
Best practices and recommendations
- do not edit SCP through AWS Organizations that are being managed by Control Tower. Instead create a new one and attach it to the OE
- set up your landing zone in the Region you usually use the most and then deploy new accounts from that home region
Difference between Control Tower and Security Hub
Those 2 services are completely different and serve different purposes, but some aspect of them might seem to overlap, just to clarify:
AWS control tower is used by cloud administrators as a Preventative Service, where guardrails limit user access.
AWS Security Hub is for security and compliance professional and it more a Detection service that provides reports and highlight system vulnerabilities.
Photo by Alexander Grey on Unsplash
Digital Cloud AWS Solutions Architect Associate Certification Hands On Lab
Cloud Academy AWS Solutions Architect Associate Certification Preparation
Top comments (0)