A service has run on AWS Elastic Beanstalk for two years, and each release now changes more .ebextensions configuration than application code. How do you judge whether the team has hit the platform's ceiling, and what would you try before migrating off it?

## What the abstraction is actually buying Elastic Beanstalk buys you a composed stack and a deployment story: an Auto Scaling group, a load balancer, health reporting, batch or immutable deploys, and a CNAME you can swap. It does not buy cheaper compute or hidden capacity — the resources are ordinary ones in your account. So the question "have we outgrown it?" is really "is the composition still doing more work for us than we are doing to keep it?" ## Signals you have hit the ceiling None of these is fatal alone; together they are decisive. 1. **Configuration outgrows code.** Releases that touch `.ebextensions` more than the application mean the team is maintaining a bespoke platform inside someone else's platform. 2. **You have a custom AMI.** Pointing `ImageId` in `aws:autoscaling:launchconfiguration` at your own image is supported, but you now own OS patching and image builds — the largest single thing the platform was doing for you. 3. **You need two things scaled independently in one unit.** Beanstalk scales instances. A worker that must scale on queue depth while the web tier scales on requests is two environments at best, and often the point at which a container orchestrator's model fits better. 4. **The shape of scaling is wrong.** Per-request scaling, scale to zero, or sub-minute reaction are not what an instance-based environment does well. 5. **Deployments have become slow enough to shape behaviour.** Immutable deploys replace a whole set of instances; when a release takes long enough that people batch changes to avoid it, the release process is now a design constraint. 6. **Platform retirement is driving the roadmap.** Platform branches are retired on a published schedule. Staying supported means periodic managed upgrades and, for a major OS generation change, a deliberate migration to a new environment. If that upgrade is already a project each time, so is a migration off. ## The escape hatches, in order Before concluding, work down the supported list: - **Option settings** for anything Beanstalk models — scaling bounds, instance type, health check path, deployment policy, environment variables, load-balancer listener settings. - **`.platform` hooks** on Amazon Linux 2 and 2023: executables under `.platform/hooks/prebuild`, `predeploy` and `postdeploy`, plus `.platform/confighooks/` for configuration updates. These replace `container_commands` and are the right home for on-instance setup, because they run again on every replacement instance. - **`Resources:` in an `.ebextensions` `.config` file**, which adds raw CloudFormation resources to the environment's stack. This is the powerful one and the one that most often signals the ceiling: it lets you add almost anything, which is exactly why a large `Resources:` block means you are hand-writing infrastructure while still paying the abstraction's constraints. - **A shared load balancer** you own, rather than one Beanstalk creates, when the ALB itself is what you need control over. If a requirement survives all four, it is structural, and no amount of cleverness inside the environment will fix it. ## Why the exit is cheaper than it looks The key argument, and the one that separates a senior answer from a nervous one: **the environment is already an Auto Scaling group of EC2 instances behind a load balancer**. Leaving Beanstalk is not a rewrite of the application; it is taking direct ownership of primitives that already exist and are already sized. The deployable artifact — the bundle, its `Procfile`, its runtime — is the portable part, and the on-instance work already lives in hook scripts you can reuse in a bootstrapping script or an image build. What you lose is real and worth naming: health reporting, the batching logic of the deployment policies, and the CNAME-swap release ritual all have to be re-provided by whatever you adopt. Budget for those, not for the application. ## Migrating without a big bang Stand up the replacement alongside the environment, running the same version. Point a weighted DNS record at both the Beanstalk CNAME and the new endpoint, start at a small percentage, and watch error rate and latency at the two targets separately. Sticky sessions and any in-instance state decide how fast you can shift, so make the app stateless first if it is not. Keep the Beanstalk environment warm until you have been fully cut over through at least one peak and one deploy — the rollback is a DNS weight change, which is the cheapest rollback you will ever have. ## The judgment to show An interviewer is testing whether you treat "we outgrew the PaaS" as a fashion or a measurement. The good answer names the specific requirement the platform cannot express, shows you tried the supported hatches, quantifies what you give up, and describes a reversible cutover.