Question posted in 
Since last week, all our systems on Elastic Beanstalk suddenly failed to install the latest platform update, 4.2.7 to 4.3.0, as part of a weekly managed update process. This came as an unwelcome surprise, as platform updates have been working without any issues for at least the last 36 months.
The reason for the failure is that the ec2:CreateTags permission is not available for arn/**/elastic-ip/ in the AwsElasticBeanstalkManagedUpdatesCustomerRolePolicy, which is attached to the aws-elasticbeanstalk-service-role.
Adding this permission to the role resolves the issue. However, I have the following two questions:
- Why does the
AwsElasticBeanstalkManagedUpdatesCustomerRolePolicynot contain this permission in the first place, if it is required for the platform update? - Why is this permission suddenly required when it has not been required for at least the last 36 months? Have we missed an important update? Is
AwsElasticBeanstalkManagedUpdatesCustomerRolePolicyno longer the correct policy for managed updates?
2
Answers
Experiencing exactly the same issue with multiple Beanstalk environments for years without issue.
We were using an older built-in policy and simply replaced it with
AWSElasticBeanstalkManagedUpdatesCustomerRolePolicybecause it did – at the time – contain the necessaryec2:createTagspermission.This weekend all our Beanstalk environments suffered failures when performing the managed weekly maintenance; once again due to the missing
ec2:createTagspermission.Having a look through
AWSElasticBeanstalkManagedUpdatesCustomerRolePolicyI’m surprised to see that it no longer contains this permission. This is all very strange.Will be adding in the permission as an in-line policy to prevent further issues.
We are facing the same problem, we opened an issue on the roadmap