👀 This is not properly displayed? Read all of our issues online! 💡

Hi Reader 👋🏽

We've said it more than once and we still stand with it:

Overwhelmingly, engineers look at the way of least resistance via "Which permissions do I have to grant to make this work? 🤔" or directly using wildcards for actions and resources on all policies, instead of diving into all the aspects of the service and its possibilities.

Nevertheless, it's not optional to work with AWS IAM as by default all actions to all resources are denied in the first place.

So you have to put in at least some explorative work to get to know the basics.

But that's often where it ends. 🙅‍♂️

And if it does, you'll maybe never notice that there's a crucial service that can immensely elevate your IAM management, operations, and general security of one or several AWS accounts: AWS Organizations!

In this issue, we'll explore this unsung hero of the AWS ecosystem! 🦸‍♀️

Buckle up and take your time ✌️

​

P.S.: Before directly jumping into this, you can also give yourself an overview with one of our infographics 👇

​

Starting from the Beginning

When we're making the first steps with a new project on AWS, we can easily put all of our workloads into a single account...

• ... even without compromising on security 🔐
• ... and with multiple environments... 👥
• ... and dedicated cost breakdowns 💸

Surely, you can also work your way up to an ecosystem of hundreds or thousands of resources in a single account - even perfectly secure - but maybe this is not the ideal way to go.

AWS accounts come with natural security barriers that we should utilize! 🔐

This is where AWS Organizations come into play: a service to split your infrastructure into multiple accounts while still keeping control in a single place.

​

Arguments for a Multi-Account Setup

Using multiple accounts comes with multiple benefits. Amongst them, but not limited to:

• Enhanced security through isolation of resources.
• Reduced impact of security breaches.
• Environment segregation, e.g. development, staging, production.
• Customized access controls per account.
• Simplified operational management with clear boundaries.
• Easier compliance with regulatory requirements.
• More granular cost tracking and budgeting.

Additionally, for enterprises, it's easily possible to map down their organizational structure into their AWS Organization!

This can simplify things immensely.

​

Key Concepts

Using AWS Organizations is better than just one account for security, access control, and billing purposes.

Within our Management Account, we'll then keep control over all of our Member Accounts - we're even able to define Service Control Policies and apply them to one or several Organizational Units. With billing in a single place - via consolidated billing!

But now we've introduced a lot of new fancy words 🙇‍♂️
​What do they mean and what are organizations all about?

⭐️ Management Account: The initial account used to create the organization with full access to all AWS resources and services, intended for setup and account management tasks.

🏘️ Organization: A container for managing multiple AWS accounts centrally, allowing policy and permission application across all accounts.

🏛️ Organizational Units: Logical groupings within an organization that can contain accounts and other units, used for structured management.

🔐 Service Control Policies: Policies that restrict access to AWS resources and services, applicable to the organization, organizational units, or individual accounts for compliance and security.

💸 Consolidated Billing: A feature that centralizes payment for all member accounts to the management account, providing a unified view of billing and spending.

🔑 Federated and Delegated Access: Allows users to access multiple accounts with a single set of credentials and manage permissions and roles centrally.

​

Service Control Policies

Service Control Policies (SCPs) are one of the greatest features of AWS Organizations.

They are a type of policy that you can use to manage permissions in your AWS Organization.

SCPs offer central control over the maximum available permissions for one or several accounts / organizational units in your organization, allowing you to ensure your accounts stay within your organization’s access control guidelines.

SCPs are used to allowlist or denylist permission for AWS services and actions and do not grant permissions but instead act as a guardrail 🔐.

They can be applied to...

• the organization as a whole
• to organizational units
• or to individual accounts

Why SCPs are Fundamental

Service Control Policies are fundamental in AWS security because they provide a mechanism to centrally manage permissions and prevent unauthorized use of AWS services, which can be crucial in the context of security breaches.

For instance, if an AWS account gets compromised, the attacker might attempt to launch instances in regions that the account owner does not typically use, to mine cryptocurrency.

AWS Hero Yan Cui recently made us aware of this 👇

This kind of activity can go unnoticed for a significant period, incurring substantial costs! 💸

An SCP can mitigate this risk by explicitly denying the ability to perform actions related to EC2 and ECS in regions that are not typically used by your organization.

Here's an example of how to create an SCP to deny certain EC2/ECS actions in all regions except for us-east-1 👇

You would attach this policy to the root of your AWS Organization (or to specific OUs or accounts as needed).

This way, even if an account gets compromised, the attacker would be unable to launch resources in any region that the SCP does not explicitly allow.

If you're anyway going full Serverless with Lambda ƛ, you can even remove the condition and completely avoid any EC2/ECS usage! 🤖

With the applied policy from above, we could not try to start an EC2 instance in a region that is not us-east-1.

And certainly, this action will be denied! 🔐
​

Best Practices

Let's wrap up this issue with best practices for your most critical asset: your management account!

• Use a strong password and enable Multi-Factor Authentication (MFA) for the management user and other AWS account root users.
• Use the management account only for tasks that strictly require it and avoid creating AWS resources in this account, except for CloudTrail trails.
• Regularly track who has access to the management account and ensure there’s a process to recover or reset access to the root user.
• Use a non-personal email address for the management account’s root user and forward emails to the responsible individuals’ personal addresses.

​

Further Resources

We wrote a detailed article about AWS Organizations, explicitly showing how you can enable SCPs and how to set up everything in one of our articles: AWS Organizations - The Key to Managing Your Cloud Infrastructure Effectively​

Feel free to check it out and get your hands on it immediately! 🧑‍💻

​

Thanks for making it this far and we hope you enjoyed this issue and learned something new!

See you in two weeks!

Sandro & Tobi ✌️

​

​

​