profile

AWS for the Real World

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

Published 21 days 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

Hi Reader πŸ‘‹πŸ½ This week, we're diving headfirst into the deep end of AWS's pool of innovations with the IAC Generator β€” a tool that's been causing quite the buzz. The promise AWS gives us is quite bold: Generate AWS CloudFormation templates and AWS CDK apps for existing AWS resources in minutes. But does it really work? Let's find out together. This will be a hands-on πŸ‘·πŸ½β€β™€οΈ issue. For the impatient, TL;DR, in a nutshell, πŸ₯œ: Good for a start, but far away from usable in production. The...

6 days agoΒ β€’Β 5 min read

Hey Reader, amazing that you're interested in creating the CloudWatch Book together with us. This is the third CloudWatch Update. Coincidentally, Sandro (I'm writing this update) turned 30 last week πŸ₯³ In this update, we'll introduce you to our newly created web application: The GitHub Repository Tracker. While it is not the fanciest name it, the project will help you a lot in learning & understanding CloudWatch for the real world. We thought it would be much easier to show it in a video so...

29 days agoΒ β€’Β 6 min read

This is not properly displayed? Read all of our issues online! πŸ’‘ Hi Reader πŸ‘‹πŸ½ we now finished all service introductions which we also showed you in the AWS Fundamentals Book πŸŽ‰. That doesn't mean we run out of content! There are still many services we want to give you introductions and 1x1 to. Once we finish this, we will grow together with you and do more deep dives into use cases, configurations, and all you can do with AWS. Today's newsletter is about another API service: AppSync. AppSync...

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