How to resolve the deprecation of the AWSElasticBeanstalkService Policy in Amazon Web Services (AWS)

The Problem

If you’ve recently received an email from Amazon Web Services informing you that you’re using the deprecated managed policy called AWSElasticBeanstalkService and that you should be using the newer policy named <takes a deep breath> AWSElasticBeanstalkManagedUpdatesCustomerRolePolicy then this blog will help you understand what it means and what to do.

Most developers using the Elastic Beanstalk are doing so to avoid the technical burden of managing clusters of Tomcat servers and auto-scaling. I would imagine many are using the standard default roles and using the beanstalk as a managed service with managed policies.

In this scenario I think it would have been more friendly if AWS created a new role with the new attached policy and provided simple instructions to migrate their beanstalk to the new policy, or even a button within the Elastic Beanstalk configuration screen to automatically switch them to use the new policy.

Please note that our Java War application uses the AWS SDK to create an SQS queue on startup and read/write data to S3 buckets. The SDK is accessed through an access key linked to an IAM user. The user has a custom policy that enables access to SQS and S3 for our app needs.

TLDR (Too long, didn’t read)

The quick solution is to change the existing aws-elasticbeanstalk-service-role to attach the new policy AWSElasticBeanstalkManagedUpdatesCustomerRolePolicy and then detach the deprecated AwsElasticBeanstalkService policy.

Background

Feeling pleased that that I had recently updated my Beanstalk environment from a deprecated platform to a shiny new AWS platform (Tomcat 8.5 with Corretto 11 running on 64bit Amazon Linux 2) I breathed a sigh of relief.

Less than a month later I received a new email from AWS informing me that my new environment was using a deprecated policy.

😳 Huh? I created this environment from scratch using the Elastic Beanstalk defaults, so how come it’s using a deprecated policy already?

The short answer is that when you create a new Elastic Beanstalk environment it continues to use the role aws-elasticbeanstalk-service-role which references the deprecated policy AwsElasticBeanstalkService 🤦‍♂️

What’s worse is that if you create a new role today for the explicit use-case of ‘Elastic Beanstalk’ it will still attach the deprecated policy AwsElasticBeanstalkService (instead of the new AWSElasticBeanstalkManagedUpdatesCustomerRolePolicy).

The Email

Hello,

We have detected that at least one user, group, or role in your account is currently employing the AWSElasticBeanstalkService managed policy. This policy is scheduled for deprecation and will no longer be available for attachment to new IAM users, groups, or roles after April 15, 2021.

What do I need to do?

The AWSElasticBeanstalkService policy should be replaced with the new versions of this policy: AWSElasticBeanstalkManagedUpdatesCustomerRolePolicy.

We recommend the following actions:

• Test your environments with the new policy. This new managed policy improves security for your resources by applying a more restrictive set of permissions. Therefore, we strongly recommend that customers perform testing to ensure their environments retain access to required resources, especially if you are using the following services: AutoScaling, CodeBuild, CloudWatch Metrics, CloudWatch Logs, EC2, ECS, S3, SNS and SQS.

With this updated managed policy, the stricter naming conventions will not allow you to manage resources that were not created through Elastic Beanstalk. Also, you will not be able to manage resources that were provisioned by Elastic Beanstalk that have been renamed. If your testing reveals that any required resources do not conform to the naming conventions in the new policy, you can create and add a custom policy to manage the additional resources. Attach your custom policy along with the new Elastic Beanstalk managed policy to retain all the required access while benefiting from the managed policy. For more information see Creating a custom user policy[1] in the AWS Elastic Beanstalk Developer Guide.

• Attach the new policy to your resources. For more information, including instructions to view the content of a policy, refer [2] in the AWS Elastic Beanstalk Developer Guide.

Why do I need to take action?

The new Elastic Beanstalk managed policy improves security for your resources by applying a more restrictive set of permissions. We strongly encourage you to employ the new policy as soon as possible. Because the deprecated managed policy will no longer be maintained or supported, permissions for all upcoming Elastic Beanstalk features will be added only to the new policy after April 15, 2021.

What will happen if I do not take action?

The AWSElasticBeanstalkService policy will continue to function normally for any IAM user, group, or role attached to it before April 15, 2021. However, this deprecated policy will not receive any future updates to support new Elastic Beanstalk functionality, which may lead to future permission errors from the console or command line interface (CLI).

If you have any questions or concerns, the AWS Support Team is available on the community forums and via AWS Premium Support [3].

The Policy Hunt

The first step I took was to review my AWS Elastic Beanstalk Configuration, there are multiple sub-sections but none of them specifically referenced the deprecated policy. The closest I could find was the security page, but it’s not explicitly mentioned here either.

Actually it’s the role aws-elasticbeanstalk-service-role that has the deprecated managed policy AWSElasticBeanstalkService attached to it.

The deprecated AWSElasticBeanstalkService policy is used by the role aws-elasticbeanstalk-service-role

You can tell this by searching around in the IAM portal.

IAM

I can’t get passed the acronym ‘IAM’ without thinking about “I am legend” with Will Smith, but putting that to one side. It stands for Identity & Access Management (I A M)…

I Am Legend — a problem shared is a problem halved 😘

Now that I’ve shared that image with you, hopefully I’m not the only one that recalls Will Smith when dealing with identity issues 😏

What I found shocking was the lack of guidance in that original email. Perhaps AWS think everyone understands IAM?

I had setup all my users eight years ago and I really couldn’t remember the difference between users, roles and policies.

If you search for the aws-elasticbeanstalk-service-role role and drill down into it you will see that it references the deprecated policy AwsElasticBeanstalkService.

The policies attached to the existing aws-elasticbeanstalk-service-role

Warning

Whether you use solution option 1 or option 2 it’s worth noting that the new policy AWSElasticBeanstalkManagedUpdatesCustomerRolePolicy is more restrictive, so you should test the policy in your test environment (UAT) if you have one. If not, it’s possibly a good idea to clone your live environment to test your policy changes first.

Option 1 is the way that AWS advised me after I raised a ticket for clarification.

Option 2 is the way that I worked out was best for us (thanks Rich Aplin for being my second pair of eyes and an extra brain). I also think option 2 is safer.

Solution — option 1

The quick solution is to change the existing aws-elasticbeanstalk-service-role, but this changes all environments that use this role. If you want to test the impact first then consider option 2.

  1. Attach the new AWSElasticBeanstalkManagedUpdatesCustomerRolePolicy policy and
  2. Remove the deprecated AwsElasticBeanstalkService policy.

Voila — you’re done (but it’s advised to follow my verify steps)

Solution — option 2

This option copies the aws-elasticbeanstalk-service-role so that you can detach the deprecated policy and add the newer policy. You can then selectively apply that role to individual Elastic Beanstalk configuratons to test first, e.g. you UAT environment. Once you’re confident that nothing breaks then you can apply your new role to your live environment(s).

  1. Create a new role, name it something like aws-elasticbeanstalk-service-role-2 (I added the ‘-2’ suffix), ensuring that you specify

2. Type of trusted entity as ‘AWS Service’

3. Choose the use-case of ‘Elastic Beanstalk — Customizable’

4. Use the defaults for Attached permission Policies

5. Use the defaults for Tags (or specify your own — i.e. ‘environment = uat / live’ etc)

6. Enter the new role name aws-elasticbeanstalk-service-role-2

7. Enter a description, such as ‘This is the replacement for aws-elasticbeanstalk-service-role that referenced the deprecated policy AWSElasticBeanstalkService, instead it references the new policy AWSElasticBeanstalkManagedUpdatesCustomerRolePolicy

8. Click “Create” to create the new role — NOTE it still references the deprecated policy, that’s because it’s the default policy added when you create a new ElasticBeanstalk role — crazy huh? I would have thought AWS would create the new Elastic Beanstalk role using the new policy. You can’t specify the new role yet — we will edit it shortly.

Example of cloning the existing role with the aim to edit it afterwards

If by any chance you get this error ‘Rate Exceeded’…

Ambiguous Rate Exceeded banner

… then you may need to re-authenticate with AWS (logout and log back in).

Once you’ve successfully created the role a confirmation banner will be displayed and your new role should appear in the table. It’s not any different as this stage to the other role with the deprecated policy.

The new role (albeit no different to the original at this stage)

9. The next step is to tweak this new role to be what we want by removing the deprecated policy (you’ll have to confirm this by clicking the detach button). This is safer because no environments are using it.

Detach the deprecated AWSElasticBeanstalkService policy

10. Then click the ‘Attach policies’ button. Add the new AWSElasticBeanstalkManagedUpdatesCustomerRolePolicy policy by searching for the policy and then place a tick ✔️ in the left-margin

Attach the new AWSElasticBeanstalkManagedUpdatesCustomerRolePolicy Policy

11. Click the Attach Policy button and now the new role will have the two expected policies

The new role has the two expected policies

Perfect, the new role is ready and the old role remains as-is, so that you’re in control which Elastic Beanstalk environments are moved to the new role.

Let’s update our first Elastic Beanstalk environment to use the new role and therfore the new policy.

  1. Navigate to the Elastic Beanstalk portal
  2. Select the environment that you want to change the policy for
  3. Click on the ‘Configuration’ option in the left-side menu
  4. Scroll until you can see the ‘Security’ section and choose select/edit
  5. Select your new role aws-elasticbeanstalk-service-role-2. If the role isn’t present then double-check you created it using the ‘Elastic Beanstalk’ use-case — this will ensure it’s setup as trusted by Elastic Beanstalk and ensures it’s available from the combo drop-down.
  6. Click ‘Apply’ and the new policy will be used by your environment
Test the new aws-elasticbeanstalk-service-role-2 with the new policy

Verify

I knew that my app uses auto-scaling, S3 and SQS. For this reason I changed my UAT test environment auto-scaling rules from min & max 1 node, to min & max 2 nodes. This process would spin up one new EC2 instance. During my app startup it creates a new SQS queue. I manually invoke the app feature that uploads and downloads from S3.

Your testing may vary, but here are my steps and rational for verifying.

It is assumed that you have already set the role with the new policy against the specified environment in Elastic Beanstalk prior to verifying…

  1. The Elastic Beanstalk portal select the ‘Events’ option (from the left-menu)

2. The events will update to show that the environment has been updated

Verify that the Elastic Beanstalk environment updated

3. Adjust a config to force a new EC2 instance (in my case I increased auto-scaling from min 1, max 1 to min 2, max 2 to force a scale-up).

Verified a new EC2 was added via the auto-scaling group

4. Check the app still works (requests are distributed between the two instances so you may need to sample 10–20 requests to be confident that you’ve hit the 2nd instance successfully). Specifically I tested that the app continues to have access to Amazon S3 by uploading and downloading through my mobile app which sends JSON and images into various S3 buckets.

5. Check the queues (SQS) had been dynamically created during app startup. As you can see the new queue was added when my new EC2 instance was started (our app does this on startup; it’s not expected behaviour for a hello-world app), but the original queue from the original EC2 instance hasn’t changed. This is why I wanted to verify scaling because it creates the EC2 instance and creates the SQS queue, which is perfect to ensure everything continues to operate as expected.

Verify that the new EC2 instances can create and delete SQS queues

From the above screenshots you can see that ElasticBeanstalk didn’t restart my original EC2 instance, so in my eyes satisfactory testing wasn’t complete until I set auto-scaling to force a fresh EC2 instance.

I was then confident to apply these changes to the LIVE environment.

If you found this blog useful then please do follow me here on Medium, I’m also @CodingRob on Twitter.

Co-founder and CTO of Vehicle Smart and owner of Devology Ltd (client work on MyTeamSafe and a playground for my geeky ideas, including Social Scheduler).

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store