.ebextensions: Infrastructure as Code for Elastic Beanstalk

WHY IT EXISTS AWS Elastic Beanstalk provides a managed platform (PaaS), but real-world applications often need customizations beyond the standard configuration. You might need a specific system library, a custom Nginx setting, or to run a command during deployment. .ebextensions provide a declarative, version-controlled way to make these changes without manually SSHing into instances.

THE MENTAL MODEL Think of .ebextensions as a set of instructions for CloudFormation, the engine Beanstalk uses under the hood. You place YAML or JSON formatted configuration files in a folder named .ebextensions at the root of your application source bundle. You're telling Beanstalk, "Before you deploy my app, please run these commands, create these files, and modify these AWS resources."

HOW IT WORKS When you deploy your code, Elastic Beanstalk finds the .ebextensions directory and processes the .config files inside in alphabetical order. These files contain sections like packages (for yum, apt), files (to write files to disk), commands (to run shell commands), and container_commands (commands that run after the app is staged but before it's deployed). A failed command in any script will cause the entire deployment to fail and roll back.

WHEN TO USE IT Use .ebextensions for environment customizations tied to your application's lifecycle. This is perfect for installing a monitoring agent on all instances, setting environment variables, running database migrations with container_commands, or modifying the load balancer's health check path. It's ideal for tasks that need to happen consistently on every instance in the environment.

WHEN NOT TO USE IT Avoid using .ebextensions for complex application logic or for managing resources with a lifecycle independent of your application, like a shared database. If your config files become too large and complex, it's a sign you might be better served by a more powerful Infrastructure as Code tool like Terraform or the AWS CDK. Don't use it for one-off administrative tasks.

ONE CANONICAL EXAMPLE A common use case is running database migrations on deploy. A file named .ebextensions/db_migrate.config could contain a container_commands section. This section runs commands after your application code is on the instance, but before the web server starts routing traffic to it. Using leader_only: true ensures the migration command only runs on one instance in a multi-instance environment, preventing race conditions.