Configure apache on elastic beanstalk
Master System Design with Codemia
Enhance your system design skills with over 120 practice problems, detailed solutions, and hands-on exercises.
Introduction
On Elastic Beanstalk, Apache is usually part of the platform's web-server layer rather than something you edit manually on a long-lived EC2 instance. The modern way to configure it is to ship configuration files with your application source so Beanstalk applies them during deployment.
Know which platform generation you are on
The exact file location depends on the Beanstalk platform generation. On current Amazon Linux 2 based platforms, custom web-server configuration normally goes under .platform/. Older platform generations often used .ebextensions/ for more of this work.
For Apache on modern platforms, a common path is:
Files placed there are merged into the Apache configuration during deployment.
A simple Apache config example
Suppose you want to add a few security headers. Create this file in your application bundle:
Then deploy the application normally. Elastic Beanstalk provisions the instance, lays down the app bundle, and includes the custom Apache snippet.
This pattern is much better than SSH-ing into an instance and editing /etc/httpd/conf/httpd.conf by hand, because manual changes disappear on replacement instances.
Use .ebextensions for environment-level settings
.ebextensions is still useful for Beanstalk option settings, packages, files, and commands that should run during environment provisioning.
Example:
That is different from raw Apache directives. Think of .platform/ as web-server customization and .ebextensions/ as broader environment orchestration.
Deploy and validate the result
After deployment, validate both Beanstalk health and Apache behavior.
Useful checks include:
and Beanstalk logs from the console or CLI to confirm that the configuration file was picked up successfully.
If a bad Apache directive is shipped, the deployment may fail or the proxy layer may not start correctly. That is why small, incremental changes are safer than large server rewrites.
When rewrites and proxies are involved
Apache configuration becomes more interesting when you add rewrite rules, reverse-proxy behavior, or custom static-file handling. Keep these changes narrow and environment-aware.
For example, a redirect rule might look like this:
In Beanstalk, test these carefully because the load balancer, proxy headers, and HTTPS termination model can affect how Apache sees the request. The more your rule depends on request headers or forwarded protocol values, the more important it is to validate behavior in the real environment rather than assuming local Apache behavior matches production. Logging and deployment health checks are part of configuration work, not separate cleanup tasks.
Common Pitfalls
The most common mistake is editing Apache directly on a running EC2 instance. Elastic Beanstalk treats instances as replaceable, so manual changes do not survive scaling events or redeployments.
Another common issue is using the wrong configuration location for the active platform generation. A file placed in the wrong folder may be silently ignored.
Be careful with rewrite logic behind a load balancer. If HTTPS terminates before Apache, naive redirect rules can loop or behave unexpectedly unless proxy headers are considered.
Finally, validate configuration changes incrementally. A single invalid Apache directive can turn a normal deployment into a failing environment health incident.
Summary
- On Elastic Beanstalk, ship Apache config with the application instead of editing instances manually.
- On modern platforms, Apache snippets commonly live under
.platform/httpd/conf.d/. - Use
.ebextensions/for environment settings and provisioning tasks, not as a substitute for every Apache config file. - Test small changes and validate them after deployment.
- Treat Beanstalk instances as disposable and keep configuration fully declarative.
