🎉 We are launching a new weekly show: Hot off the Cloud

🎉 We are launching a new weekly show

Your AWS Account is a mess? Learn how to fix it!

Michael Wittig – 28 Jul 2016

Have you no wildcard ec2:* in your IAM policies? Your Security Group rules are as strict as possible? Your S3 Bucket Access Policies only contain rules you know? You know about every single resource that runs in your account?

If so, stop reading and please tell me how you achieve that!
Otherwise: I’m sorry, your AWS Account is a mess! A security problem is likely!

As an independent AWS consultant, I see many accounts and most of them are messy. I observed that the level of mess is related to:

  • Awareness and Visibility: If the mess is visible to the users, they will care about it.
  • Number of Users per Account: The more users, the more mess. More than ten users are going to be hard.
  • Degree of Automation: Manual work creates a mess. Automation reduces mess.

I developed three approaches to clean up and prevent a mess. I suggest that you tackle them one after the other to not feel overwhelmed.

1. Awareness and Visibility

Awareness and visibility

If your users are not aware of the problem, they can’t fix it. Monthly reviews can help to make problems visible to your team.

Security Groups

  • Are your inbound rules as strict as possible?
  • Do you have IP address based rules where Security Group references are possible?

IAM roles

  • Are the policies (inline and attached) as strict as possible? Especially look for wildcards (*) in actions and resources. Also look for managed policies that end with FullAccess or the evil AdministratorAccess with root permissions. You can use our Complete AWS IAM Reference!
  • Who is allowed to assume the role? Look at the trust policy.

IAM users & groups

  • Are they still needed? Maybe a user left the company?
  • Are the policies (inline and attached) as strict as possible? Especially look for wildcards (*) in actions and resources. Also look for managed policies that end with FullAccess or the evil AdministratorAccess with root permissions. You can use our Complete AWS IAM Reference!
  • Have your users MFA enabled? Learn how to check and enable MFA.
  • How old are the access keys? If they are older than 30 days, rotate them!

S3 access policies

  • Do you allow public access and are you okay with that? Look for "Principal": "*" in the statements.
  • Are the policies as strict as possible?

Now it’s time to book a meeting room for one hour, invite 2-3 users and have a look at one of the topics. You will be surprised! Make sure you document the finding, assign responsibilities and set due dates. Track the progress in the next review meeting.

2. Reduce Number of Users per Account

Reduce Number of users per account

Looking for a new challenge?

  • tecRacer

    Cloud Consultant • AWS Migrations

    tecRacer • Premier AWS Consulting Partner • Germany, Austria, Portugal, and Switzerland
    Assessment Transformation Change Management

    Senior Lead Full Stack Developer

    DEMICON • AWS Advanced Consulting Partner • Remote
    AWS JavaScript/TypeScript Angular React

Reducing the number of users per account works even in enterprises with thousands of employees. No one said that you only need one account! Create many accounts. One per team, one per service, one per customer. Whatever partition make sense for you.

If you choose a multi-account strategy, you will introduce additional complexity. Tackle it with:

3. Automation

Automate all the things

A typical web application consists of many parts:

  • Load Balancer
  • RDS instance
  • Auto Scaling Group
  • Launch Configuration
  • EC2 instances
  • Security Groups for EC2, RDS, and ELB
  • IAM role for EC2
  • Key Pair for EC2
  • CloudWatch Alarms for EC2, RDS, and ELB
  • Route53 Zone + Record Set
  • CloudFront Distribution
  • S3 bucket for static files

The day will come where one of your applications is approaching end-of-life. The chances are high that you forget about on of the many parts you created years before or that your co-worker added a few months before.

Instead of creating all the resources manually use CloudFormation to deploy them. You have to write a JSON template that contains a definition of the resources you need. The CloudFormation service will use that template to create a stack with all the resources for you. The cool thing is that if you delete the stack, all the resources are deleted. Nothing is forgotten. You can even use CloudFormation to update a stack when you need to change something in your template.

If you CloudFormation all the things, you can go one step further. Reduce the IAM permissions of your users and protect your CloudFormation managed AWS account from human intervention.

Become a cloudonaut supporter

Michael Wittig

Michael Wittig ( Email, Twitter, or LinkedIn )

We launched the cloudonaut blog in 2015. Since then, we have published 360 articles, 49 podcast episodes, and 48 videos. It's all free and means a lot of work in our spare time. We enjoy sharing our AWS knowledge with you.

Please support us

Have you learned something new by reading, listening, or watching our content? With your help, we can spend enough time to keep publishing great content in the future. Learn more

Amount must be a multriply of 5. E.g, 5, 10, 15.

Thanks to Alan Leech, Alex DeBrie, ANTHONY RAITI, Christopher Hipwell, Jaap-Jan Frans, Jason Yorty, Jeff Finley, Jens Gehring, jhoadley, Johannes Grumböck, Johannes Konings, John Culkin, Jonas Mellquist, Juraj Martinka, Kamil Oboril, Ken Snyder, Markus Ellers, Ross Mohan, Ross Mohan, sam onaga, Satyendra Sharma, Shawn Tolidano, Simon Devlin, Thorsten Hoeger, Todd Valentine, Victor Grenu, and all anonymous supporters for your help! We also want to thank all supporters who purchased a cloudonaut t-shirt.