每当我运行aws elasticbeanstalk update-environment ...时，CLI都会返回成功，但是Elastic Beanstalk仪表板会在You do not have permission to perform the 'ec2:DescribeSubnets' action周围显示错误消息。
我创建了一个Elastic Beanstalk实例，并为其赋予了服务角色“ Beanstalk-Dev-ServiceRole”。该角色具有三个附加政策：
（我也尝试过使用AWSElasticBeanstalkFullAccess）
我已将一个zip软件包上传到具有预期环境版本（beanstalk-dev-server-2019-07-30--05-52-49）的S3中，并验证了它的存在。
当我运行aws elasticbeanstalk update-environment --environment-name Beanstalk-Dev-Server --version-label beanstalk-dev-server-2019-07-30--05-52-49时，CLI报告成功。但是，当我查看Beanstalk仪表板时，仅看到两条错误消息：
我看过很多帖子，其中说DescribeSubnets操作是AWSElasticBeanstalkFullAccess策略的一部分。看起来不再像以前了，但是AWSElasticBeanstalkService具有ec2：*，因此应该在此处进行介绍。对于踢球，我还尝试添加一个自定义策略，该策略明确允许ec2：DescribeSubnets进入资源*，但我的所有尝试都不断出现相同的错误消息。
期望使用CLI命令中指定的版本更新要更新的环境版本，或者至少是一条可行的错误消息。当前看到一条错误消息，提示我无法通过搜索引擎或文档找到任何实际操作。
答案 0 :(得分：0)
对于我来说，CLI命令来自CodeBuild，假定的角色是CodeBuild角色，而不是Beanstalk服务或EC2实例。
我从AWS控制台进行了一次部署，该部署使常规的beantalk基础结构摆脱了DescribeSubnets问题，然后从CLI尝试了另一次部署-这次它显示了更有用的错误消息
Service:AmazonCloudFormation, Message:User: arn:aws:sts::...:assumed-role/codebuild-.../AWSCodeBuild-... is not authorized to perform: cloudformation:DescribeStackResource on resource: arn:aws:cloudformation:us-east-1:...:stack/awseb-e-...-stack/...
这至少告诉我，它使用的是codebuild假定的角色，而不是像我期望的那样使用beantalk假定的角色。
如果AWS更改了DescribeSubnets错误消息以使其与大多数围绕权限的常规错误消息相匹配，那就太好了。