In the past years, AWS Organizations has grown to be a powerful tool to centralize the management of the whole cloud environment, and all things related to compliance and architecture. With Organizations, you'll get more visibility to your cloud environment, and also have a better grip on your cost management and data security. Read about some of the most useful ways to use AWS Organizations.
AWS released Organizations and StackSets in 2017, which made managing large environments with multiple accounts a lot easier. However, the capabilities back then were much more limited than they are today. It’s interesting to take a look at how things have progressed over the last three years, and how we manage AWS account structures and organizations today.
When Organizations first came out, it allowed you to create groups of accounts and apply Service Control Policies (SCPs) to them—nice, but could we do more?
Now the list of services that are incorporated into Organizations is long, covering all the tools you need to operate your cloud environment in a centralized way, rather than one individual account at the time. This enables you to have a single viewpoint on access management, cost management, data security, and auditing the environment.
In this article we’ll go through some of the services, and how we at Cybercom use them.
Manage your AWS accounts through Organizations
Today most companies opt for a multi-account architecture, having one account per service and environment. For example, you can have two services and three environments, which would mean altogether six accounts. Organizations have one central management account (originally master account) to manage these separate accounts.
Here are some key factors that help you determine the appropriate architecture for your company:
An example architecture could look like this:
Optimize your costs
Even though Organizations is not a cost management tool as such, you can leverage it to optimize costs. Organizations provides you with data to analyze and allows you to track the use of the services and capacity in your accounts. It’s important to identify which costs can be minimized, and alert when budgets are exceeded—otherwise anomalies are detected in costs for usage.
For example, you might identify that you have QA, testing, and production environments, and only the production environment needs to be available 24/7. Automation is built to handle shutting down the environment when not needed.
Or if one of your developers launches expensive instances for testing and fails to shut them down, you could get an alert for the anomaly or forecasted budget overdraft.
Another way to optimize your costs with Organizations is by purchasing a Savings Plan and Reserved Instances for supported capacity types from the management account for the whole organization, making management for commitments easier. Consolidation of billing also brings some benefits via volume pricing discounts.
Use CloudFormation StackSets with Organizations
CloudFormation StackSets gives you the opportunity to create and remove stacks across your AWS accounts. For example, when a new account is created into the Organizations, you can automatically create or remove stacks, removing the need for manual work when deploying common infrastructure to all accounts in Organizations, or Organizational Unit (OU).
You will get a flying start by having StackStets automatically configure necessary IAM permissions using service managed permissions to deploy stacks to all accounts in your organisations.
When you need to update a stack across the whole organization, it is recommended that you test your update first on a smaller group of accounts in Dev OU, and wait for status to turn green, and then update Test OU, and finally Prod OU.
Make the most of AWS Resource Access Manager
By using AWS Resource Access Manager you eliminate the need to manage resources on every individual account, and instead share resources across the accounts within your Organization or Organizational Unit.
This could be useful, for example, in a hybrid cloud environment where Route 53 Resolver is used to make internal DNS queries to external data centers connected to AWS.
Or maybe you need to share hardened AMI (Amazon Machine Images) within your organization.
Set up service control policies
As mentioned above, SCPs have been around AWS Organizations since the beginning. It was originally built to limit the use of Actions to things like denying CloudTrail from being stopped.
In 2019 support for fine-grained permission controls was added to SCP. Support for policy condition elements opened possibilities to use SCPs in more complex scenarios.
At Cybercom, we’re using them to limit users from doing certain actions including:
- Modifying CloudTrail setup
- Deny modifying MSP IAM roles
- Breaking common infrastructure setup like Identity provider (IDP) configuration
- Protecting security baseline set by company governance
- Enforcing use to certain regions
- Denying ability to make VPC accessible from Internet
- Denying ability to create IAM access keys
For example, a user's role could have a full access policy attached to be able to do anything they want—except modify/delete key elements operated by Cybercom as MSP. Changes are only allowed by the MSPAdministrator role.
Note that SCPs only support Conditions and Resource restrictions when Effect is Deny, so don’t try to use complex Allow statements.
Sometimes SCPs can also cause headaches—when SCPs deny an action, there is no indication in the error message from an API or in the CloudTrail log to show what denied the call. A developer might debug their IAM policy for hours before asking if there is an organizational policy denying the action they’re trying to use.
So I hope AWS adds the ability for a member account to query which SCPs are applied to them in the future, and more details to error messages when denying actions. Until then I recommend transparency to users, for example storing the SCPs in version control and giving developers read only access to the policies.
Create tagging policies
Companies often have written policies on how assets in the cloud should be tagged, which information needs to be present, and how it must be presented.
In reality users don’t follow these guidelines, or they forget parts of them. So you’ll see the following kinds of tagging practices when reviewing multi-account environments:
Tag Policy, as well as Service Control Policy (SCP), works on the Organization level and allows you to define schemas how tags are used on AWS resources. You define tag keys and their allowed values. After rolling out your Tag Policy, you can audit how well it has been applied on each of the member accounts.
Be it sharing bills by tags or operating access management with those, writing a policy lets you tackle this issue in larger environments. As Jeff Bezos has said, “Good intentions don’t work, but mechanisms do.” In this way you'll also prevent creating new resources that are not tagged in accord with your organization's internal standards.
Let´s have a discussion on how you can utilize Organizations in your cloud environment! Book a meeting with us!
Jussi Siuro, Sales Executive Finland - See Calendar and book a meeting
Henrik Danielsson, Sales Executive Sweden - See Calendar and book a meeting
Sten Grønning, Sales Executive Denmark - See Calendar and book a meeting