profile

AWS for the Real World

πŸ› οΈ Build Smarter, Not Harder: Leveraging AWS Organizations and SCPs for Efficiency and Security

Published 2 months agoΒ β€’Β 4 min read

πŸ‘€ 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:

AWS IAM is the most complete but still underlooked service out there.

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 ✌️

​

​

​

AWS for the Real World

by Tobi & Sandro

Join our community of over 8,800 readers delving into AWS. We highlight real-world best practices through easy-to-understand visualizations and one-pagers. Expect a fresh newsletter edition every two weeks.

Read more from AWS for the Real World

βŒ› Reading time: 6.3 minutes πŸŽ“ Main Learning: Observability Aggregation with OAM πŸ‘¨πŸ½πŸ’» GitHub Code πŸ“ Blog Post Hey Reader πŸ‘‹πŸ½ Ever tried setting up an AWS Landing Zone? If you have, you know it's not easy. AWS recommends using a separate account just for monitoring all your log data. We're here to introduce the AWS Observability Access Manager (OAM), designed to make this task easier. Previously, we couldn't use OAM effectively due to a major limitation, but that's changed. Interested in diving...

11 days agoΒ β€’Β 3 min read

Hey Reader Imagine diving into AWS without a solid foundation on observability. It will lead to inefficiencies, wasted resources and money, and countless hours of troubleshooting. πŸ› The CloudWatch Book is here to guide you, ensuring you understand not just the how, but most importantly the why behind using AWS effectively so you'll work with ease, turning even complex infrastructure into a well-oiled machine. πŸ€– In this issue, we want to show you the first sample chapter about Logs and...

22 days agoΒ β€’Β 1 min read

Hey Reader! Hope you're having an awesome week! This week's edition is about implementing Step Function Workflows. One major use-case that Step Functions enable is the Wait for Callback pattern. Code Included πŸ‘¨πŸ½πŸ’» This edition comes with a special bonus - for the first time, we're including a GitHub repository just for you! Clone the repo and deploy it in your AWS Account. ⚑ Step Functions Orchestrate Workflows What are even Step Functions? Step Functions orchestrate workflows with different...

about 1 month agoΒ β€’Β 5 min read
Share this post