Archive

The Dulin Report

Browsable archive from the WordPress export.

2015

On Managing Stress, Multitasking and Other New Year's Resolutions Jan 1, 2015 Configuring Master-Slave Replication With PostgreSQL Jan 31, 2015 Trying to Replace Cassandra with DynamoDB ? Not so fast Feb 2, 2015 On apprenticeship Feb 13, 2015 Where AWS Elastic BeanStalk Could be Better Mar 3, 2015 Finding Unused Elastic Load Balancers Mar 24, 2015 Do not apply data science methods without understanding them Mar 25, 2015 Microsoft and Apple Have Everything to Lose if Chromebooks Succeed Mar 31, 2015 Two developers choose to take a class Apr 1, 2015 What can Evernote Teach Us About Enterprise App Architecture Apr 2, 2015 Exploration of the Software Engineering as a Profession Apr 8, 2015 Ordered Sets and Logs in Cassandra vs SQL Apr 8, 2015 Building a Supercomputer in AWS: Is it even worth it ? Apr 13, 2015 Apple is (or was) the Biggest User of Apache Cassandra Apr 23, 2015 My Brief Affair With Android Apr 25, 2015 Why I am not Getting an Apple Watch For Now: Or Ever Apr 26, 2015 The Clarkson School Class of 2015 Commencement May 5, 2015 The Clarkson School Class of 2015 Commencement speech May 5, 2015 We Need a Cloud Version of Cassandra May 7, 2015 Guaranteeing Delivery of Messages with AWS SQS May 9, 2015 Smart IT Departments Own Their Business API and Take Ownership of Data Governance May 13, 2015 Big Data is not all about Hadoop May 30, 2015 The longer the chain of responsibility the less likely there is anyone in the hierarchy who can actually accept it Jun 7, 2015 Your IT Department's Kodak Moment Jun 17, 2015 Attracting STEM Graduates to Traditional Enterprise IT Jul 4, 2015 Book Review: "Shop Class As Soulcraft" By Matthew B. Crawford Jul 5, 2015 The Three Myths About JavaScript Simplicity Jul 10, 2015 Social Media Detox Jul 11, 2015 Big Data Should Be Used To Make Ads More Relevant Jul 29, 2015 On Maintaining Personal Brand as a Software Engineer Aug 2, 2015 Ten Questions to Consider Before Choosing Cassandra Aug 8, 2015 What Every College Computer Science Freshman Should Know Aug 14, 2015 We Live in a Mobile Device Notification Hell Aug 22, 2015 Top Ten Differences Between ActiveMQ and Amazon SQS Sep 5, 2015 Setting Up Cross-Region Replication of AWS RDS for PostgreSQL Sep 12, 2015 I Stand With Ahmed Sep 19, 2015 Banking Technology is in Dire Need of Standartization and Openness Sep 28, 2015 IT departments must transform in the face of the cloud revolution Nov 9, 2015 Operations costs are the Achille's heel of NoSQL Nov 23, 2015 Our civilization has a single point of failure Dec 16, 2015

Where AWS Elastic BeanStalk Could be Better

March 3, 2015

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



Last updated January 20, 2026. Return to home.