The Dulin Report

Amazon describes their AWS Elastic BeanStalk service as follows:

AWS Elastic Beanstalk is an easy-to-use service for deploying and scaling web applications and services developed with Java, .NET, PHP, Node.js, Python, Ruby, Go, and Docker on familiar servers such as Apache, Nginx, Passenger, and IIS.

You can simply upload your code and Elastic Beanstalk automatically handles the deployment, from capacity provisioning, load balancing, auto-scaling to application health monitoring. At the same time, you retain full control over the AWS resources powering your application and can access the underlying resources at any time.

Over the past year it mostly met our expectations: it automatically creates and maintains all pieces necessary to run a web app; it simplifies deployments and monitoring of apps; and abstracts some of the more mundane aspects of EC2. However, there are a few areas where the service leaves much to be desired. I'll just straight to it.

With many developers on the team, each responsible for their own app, and with multiple environments under the same account (dev, qa and prod) there is no way to configure IAM properly to restrict developer access to resources only related to the application he is responsible for.

My attempt to configure a correct IAM policy to restrict a developer to only one AWS Elastic Bean Stalk application resulted in nothing but hours of frustration. Amazon offers a bit of documentation:

The following policy is an example. It gives a broad set of permissions to the AWS products that AWS Elastic Beanstalk uses to manage applications and environments. For example, ec2:* allows an IAM user to perform any action on any Amazon EC2 resource in the AWS account. These permissions are not limited to the resources that you use with AWS Elastic Beanstalk. As a best practice, you should grant individuals only the permissions they need to perform their duties.

There is a reason why their example does not show correct policies for other AWS products. As it turns out Amazon made it nearly impossible to follow the best practice they recommend. The issue is that simply giving permissions to EB resources is not enough.

Each operation in EB ends up performing tasks on the underlying EC2, auto scaling, S3, RDS, and pretty much every other AWS service. If I could just compose an ARN for those resources that says “any resource that may be generated by the EB infrastructure that is related to this app” it would have been easy. However, AWS EB creates obscure IDs for EB environments that are literally impossible to determine from looking at EB dashboard or running some command line tool.

What I would like to see from AWS that would make EB that much more useful to us is ability to hierarchically control an IAM policy for a developer simply by specifying which operations they can perform. AWS can then cascade that policy down to EC2, S3, etc. In the meantime, a solid piece of documentation on determining the resources on my own would go a long way towards saving me time.

Amazon says in their EB documentation: you retain full control over the AWS resources powering your application and can access the underlying resources at any time. Well, it works lovely if you have only one or two application environments. But as I said above, EB ends up spawning other AWS resources with obscure names that are impossible to identify! So how am I supposed to retain full control over underlying AWS resources if I cannot find them ?

This problem is exacerbated when there is an issue with one of the resources EB spins up. For example, yesterday I experienced a problem where EB could not deploy a new version to an environment because it thought there was something wrong with an instance. The error message simply stated something like this after 15 minutes: There was an error deploying to this environment because an instance timed out. See troubleshooting documentation Seriously ? What am I supposed to do with that ?

If I am to micromanage every aspect of Elastic BeanStalk environments and track the resources that it uses then I have no use for it. I am better off using EC2 instances directly and coming up with CloudFormation templates for my applications. If AWS is going to market EB as a valuable tool then they also need to fix the following:

• Abstract and hierarchically control IAM policies, such that a single policy controlling access to an EB application environment also controls access to underlying resources that EB may spin up on the behalf of the application.


• Abstract full control over the AWS resources spun up by EB so I don't need to look for them – or make them easier to identify.


• Abstract error conditions that happen in the underlying AWS resources. If during a deployment an instance doesn't respond – just terminate and recreate it.

I hope someone from AWS sees this post and acts on it, because the above issues make EB less useful to me by the day.

Resources

• AWS Elastic BeanStalk - Amazon's documentation


• AWS Elastic BeanStalk How To : IAM Policies: configuring IAM Policies for Elastic BeanStalk