Protecting yourself in the AWS console: Adding a ‘sudo’ role

Posted in AWS Blog
05/10/2015 Ben Bridts


In this blogpost we describe how to use cross account roles to create a kind of ‘sudo’ protection. This method is easier to use than using different users/accounts and looks like this:



When designing applications to be fault tolerant, it may be easy to forget that there are still humans operating and managing the underlying environment. Even with automation and PaaS, (and sometimes even because of), there is still a risk of human error.

The elimination of single points of failure has a limit, and depending on your budget and environment it’s possible that you’re application will be offline if someone deletes the wrong resource. Consider what would happen if someone deletes one of these by accident:

  • Your Route53 Zone
  • An Elastic Load Balancer
  • The S3 bucket with your static assets.
  • Your RDS database

All these services can survive a complete Availability Zone going down, but if you run the wrong command (e.g. a script to cleanup your development environment) against your production instances, things are going to break.

That’s why “prevention of human error is generally seen as a major contributor to reliability and safety of (complex) systems“.


The easiest way to gain extra protection is to put all your production resources in a separate account and use cross account roles to only gain access when needed. AWS wrote a great walkthrough about delegating acces in the IAM user guide.

But not all environments are created equal, and sometimes you need extra protection for a subset of resources in one account. Maybe you need to do a lot of read only actions in the production account, or you only have one account, or you’re running a build server in the development account and you don’t want to impact all developers by shutting it down by accident.

So to add an extra layer of protection you can use cross account roles, in the same account. This will give you a kind of ‘sudo’ access in the console.


Let’s assume we have three groups of users:

  • (Readonly) users: They have access to all resources, but cannot modify them
  • (Privileged) power users: They can modify resources but should never be allowed to delete important resources
  • Administrators: On a day to day basis they have the same access as the power users, but they can ‘sudo’ (switch roles) to get full access to everything.

Step 1: Create the IAM policies

In this example we’ll restrict every action that start with ‘delete’ in EC2, ELB, Route53 and S3. We will also prevent stopping and terminating EC2 instances. You should create your own policy if you to make sure you protect the resources that are important to you. You can also make this more granular by using Conditions and matching on Tags, or if you have a consistent naming scheme, you could use more specific resource names.

Create the following (managed) policy and give it the name ‘ProtectAgainstDeletion’:

    "Version": "2012-10-17",
    "Statement": [
            "Effect": "Deny",
            "Action": [
            "Resource": [

Also create a new policy for power users, because we do not want them to assume the sudo role.
You can use the following policy and call it ‘PowerUserAccessNoSts’

    "Version": "2012-10-17",
    "Statement": [
            "Effect": "Allow",
            "NotAction": [
            "Resource": "*"

Step 2: Create users and groups

Create the following groups and attach the managed policies. We use the managed policies that are created by AWS and the two policies we created in step 1.

  • ‘Users’ group:
    • ‘ReadOnlyAccess’ policy
    • ‘ProtectAgainstDeletion’ policy
  • ‘PowerUsers’ group
    • ‘PowerUserAccessNoSts’ policy
    • ‘ProtectAgainstDeletion’ policy. This is not needed if we put every power user also in the users group, but it keeps us save if we forget to do that.
  • ‘Administrators’ group
    • ‘AdministratorAccess’ policy
    • ‘ProtectAgainstDeletion’ policy. This is not strictly needed, if we put everyone in the Users group.

You can now add your users in the right groups.

Step 3: Create the ‘sudo’ role

Use the console to create a new role, and specify the following policies:

  • Role Name: ‘sudo’
  • Role Type: ‘Role for Cross-Account Access’,  ‘Provide access between AWS accounts you own’
  • Account ID: your current account ID
  • Require MFA: you should select this.
  • Policy: ‘AdministratorAccess’

Make sure to copy the link you get in the review step, as you need to distribute this to everyone in the Administrators group.

Step 4: Use the ‘sudo’ role for the first time

Surf to the link from the review step ( to configure the role for the first time.

Here you can choose a display name and color to identify the role. I used ‘sudo’ and red, so I can see at a glance I’m doing dangerous stuff.

Step 5: Use the Role History to switch easily between roles

If you need to switch roles you can use the dropdown menu in the top right corner to select another role.  Click on your username to get an overview of your recent roles. You can switch back to your regular account in the same place.


Additional remarks:

It’s a best practice to avoid an explicit deny in the IAM policies, as it’s impossible to override and can be difficult to troubleshoot. However, switching roles will reset policies. That mitigates that concern here.

But if we didn’t use a role, we couldn’t add Administrators to the user group (because there would be no way to allow them to delete resources if there is an explicit deny), making permission management more complex.


Leave a Reply

Your email address will not be published. Required fields are marked *


Need a hand? Or a high five?
Feel free to visit our offices and come say hi
… or just drop us a message

We are ready when you are

Cloudar NV – Operations

Veldkant 7
2550 Kontich (Antwerp)

info @

+32 3 450 67 18

Cloudar NV – HQ

Veldkant 33A
2550 Kontich (Antwerp)

VAT BE0564 763 890

    This contact form is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

    • SHARE