Elastic Beanstalk samples: .ebextensions and CloudFormation templates you can lift into a real deployment

A companion to the docs, not a package you install

The repository describes itself as a companion to the AWS Elastic Beanstalk documentation. It holds examples of configuration files and CloudFormation templates that you can use to improve your Elastic Beanstalk applications, and it is not a library, a module, or anything you add to a dependency list. There is no install step and no version to pin.

The distinction matters because the value of the repository is entirely in the examples. Every file in it is a starting point that a developer copies, adapts, and owns. A configuration file is a script that runs inside the environment during deployment, so you are effectively taking on someone else's operational decisions when you copy it, and you need to read it rather than trust it.

The top level of the tree shows the four families of material: a `configuration-files/` directory, a `cfn-templates/` directory, a `Deployment-packages/` directory, and a `cluster-mode-examples/` directory.

Alongside them sit `CONTRIBUTING.md`, the `LICENSE` file, `hello.py`, and the `README.md` itself. The primary language is recorded as JavaScript, though the code samples across the repository span many languages, which is normal for a collection whose main content is configuration.

The last push to the repository was on 2026-09-21, and there are no GitHub releases attached to it, so there is no versioned artifact and no release history to consult.

The .ebextensions folder is the whole install mechanism

Using a configuration file from this repository is a four step procedure, and the documentation is precise about it. You create a folder named `.ebextensions` in the root of your application source. You save the `.config` file from the repository into that folder. You follow the instructions inside the configuration file to make it work with your application. Then you deploy your application to an Elastic Beanstalk environment, making sure the `.ebextensions` folder is included in your source bundle.

That last clause is the part people miss. A configuration file that is not in the bundle simply does not run, and there is no error, only an environment that came up without the settings you expected. The folder name is dot prefixed and hidden, which means it is easy to leave out of an archive, a .gitignore rule, or a CI packaging step.

The two other resources behave differently. A CloudFormation template is applied through the CloudFormation console, where you create a stack from the template. The purpose of these templates is stated in the documentation: they create resources that you may want to manage independently of your Elastic Beanstalk environment. The worked example given is creating a VPC to run multiple environments in, so that terminating an environment does not take the network with it.

That is a genuinely useful pattern to copy, because network lifetime and application lifetime are usually different, and a CloudFormation stack gives the network its own lifecycle and its own stack history.

The sample applications show the platforms in anger

The second half of the repository is a set of sample applications that show the use of additional web frameworks, libraries and tools, published as open source projects on GitHub. The AWS-provided set is the more instructive half, because each one is a worked example of a specific platform concern.

Bob's Used Books sits under `cluster-mode-examples/heroku-migration-examples/bobs-bookstore-node` and is a Node.js, Express, and PostgreSQL sample for migrating application compute from Heroku to Elastic Beanstalk Cluster Mode. It is the one example in the collection that addresses an operational migration rather than a greenfield deployment.

The PHP samples come as configuration files with accompanying tutorials. Load Balanced WordPress and Load Balanced Drupal are both described as configuration files for installing the CMS securely in a load balanced Elastic Beanstalk environment, and there is a separate PHP sample, Share Your Thoughts, that shows the use of MySQL on Amazon RDS, Composer, and configuration files.

The Java samples are the deepest. Scorekeep is a RESTful web API using the Spring framework and the AWS SDK for Java, offering an interface for creating and managing users, sessions, and games, bundled with an Angular 1.5 web app that consumes the API over HTTP. It includes branches showing integration with Amazon Cognito, AWS X-Ray, and Amazon Relational Database Service. Two details are worth copying on their own: the application uses Java SE platform features to download dependencies and build on-instance, which minimises the size of the source bundle, and it includes nginx configuration files that override the default configuration to serve the frontend statically on port 80 through the proxy while routing requests under /api to the API running on localhost:5000.

Does it Have Snakes? is a Tomcat application showing the use of RDS in a Java EE web application, and it exercises Servlets, JSPs, Simple Tag Support, Tag Files, JDBC, SQL, Log4J, Bootstrap, Jackson, and Elastic Beanstalk configuration files in one project.

Two samples exist to make infrastructure behave predictably

Some of the harder problems in Beanstalk are not application problems at all, and two samples address them directly.

The Locust Load Generator is the first. It shows the use of Java SE platform features to install and run Locust, a load generating tool written in Python. The project includes configuration files that install and configure Locust, a build script that configures a DynamoDB table, and a Procfile that runs Locust. This is the sample to look at if you need to generate load against a Beanstalk environment from inside the same account, because it solves the bootstrapping problem: the tool has to exist in the environment before it can measure the environment, and the DynamoDB table setup is part of the build rather than a manual step.

The Cognito Quickstart is the second, an AngularV4-based QuickStart web app that uses Amazon Cognito, S3 or Elastic Beanstalk, and DynamoDB, described as a serverless architecture. It is the one sample in the set where the deployment target is optional, since the list of services it uses includes both S3 and Elastic Beanstalk.

There is also a community-provided entry, go-beanstalk-gin, which demonstrates deploying a simple web app built with `gin` to Elastic Beanstalk, with dependencies managed using `dep`, provided by Suhas Karanth. It is the only Go sample listed, and it is the one entry that comes from outside AWS.

How the samples differ from building infrastructure by hand

The alternative to this repository is writing the platform configuration yourself, and the difference is in who absorbs the first mistake.

A hand-written `.config` file is written against one environment and one application. It is short, it is readable, and it is the artifact you actually want to own six months later, because it contains only the decisions your application makes. A sample configuration file is written to be generally useful across applications, so it carries settings you probably do not need and assumptions you have to read carefully before accepting.

The CloudFormation templates take a different trade. Hand-writing a VPC for a Beanstalk environment means writing a subnet plan, a routing setup, and a set of outputs, and then discovering which of those the platform expects. A template from the cfn-templates directory has already resolved that, and the difference in approach is that the template produces a stack you own and update, while a configuration file produces settings inside an environment the platform owns.

The sample applications are a third kind of thing again, and they are the best learning tool in the collection because they are complete. A configuration file shows you a setting. A sample application shows you the setting in the context of a working app, including the parts that look obvious only once you have seen them, like the nginx override in Scorekeep that splits static frontend traffic from the API on localhost:5000.

What the repository cannot do is tell you which sample is current. With no releases and no changelog, the practical approach is to read the sample, understand why each line exists, and carry the idea rather than the file.

Licence and the absence of a changelog

The licence is Apache-2.0, with the terms in the `LICENSE` file at the repository root. That is a permissive licence, so copying a configuration file or a template into your own application and shipping it does not create an obligation to publish your application source. It does require that the copyright notice and licence terms travel with any substantial redistribution of the copied material, which in practice means keeping the file headers intact if you redistribute a template as a template.

The maintenance story is where this repository differs from a normal library, and the differences are all in the same direction. There are no GitHub releases, so there is no version to pin and no upgrade note to read. The last push was on 2026-09-21, which tells you the samples are still being adjusted, but it does not tell you which samples changed.

The documentation takes the position that the full set of Elastic Beanstalk documents is the reference, at the AWS documentation address, with the repository filling in the gap between prose and a working configuration. Issues, pull requests, and contributed resources are all invited, and the stated goal is helping developers learn the service.

For a team, the practical consequence is that a sample from this repository should be treated as a dated example rather than a supported component, and reviewed against the current Elastic Beanstalk documentation before it goes anywhere near production.

Editorial conclusion

This repository suits a team deploying to Elastic Beanstalk who wants a working reference for platform configuration, VPC layout, or a full sample application before writing their own, and it does not suit a team looking for a versioned library with release notes. Before copying anything out of it, check three things: that the sample you pick matches your platform version, since the repository has no GitHub releases and no changelog to date the samples against, that the .config file you copy has been reviewed for the resources it creates on your behalf, and that the Apache-2.0 licence in the LICENSE file covers how you intend to redistribute the derived configuration.

Frequently asked questions

Official sources

1. awsdocs/elastic-beanstalk-samples on GitHub
2. Issues
3. License: Apache-2.0
4. README