Introduction

To force HTTPS on an Elastic Beanstalk environment that uses NGINX as its reverse proxy, you need two pieces in place: the environment must already be able to serve HTTPS, and HTTP requests must then be redirected instead of forwarded to the app. On modern Amazon Linux 2 and Amazon Linux 2023 platforms, the cleanest instance-level solution is to extend the default NGINX server configuration through the .platform directory.

Confirm That HTTPS Already Works

A redirect only makes sense if port 443 is already configured. In a load-balanced environment, that usually means your Application Load Balancer has an HTTPS listener with a valid certificate. In a single-instance environment, the instance itself must terminate TLS.

If HTTPS is not configured yet, fix that first. Otherwise you will redirect users to an endpoint that cannot complete the TLS handshake.

Add an NGINX Redirect Rule on AL2 and AL2023

AWS documents that NGINX config snippets under .platform/nginx/conf.d/elasticbeanstalk/ are included inside the default server block on modern Linux platform versions. That makes this the right place for a redirect rule that should apply to the existing proxy server.

Create this file in your application source bundle:

1# .platform/nginx/conf.d/elasticbeanstalk/https_redirect.conf
2
3if ($http_x_forwarded_proto = "http") {
4    return 301 https://$host$request_uri;
5}

Then deploy the application again. Because the rule runs inside the NGINX server block, requests that arrive through the load balancer on plain HTTP are redirected before they reach your application process.

The X-Forwarded-Proto header matters here. In Elastic Beanstalk, the load balancer typically terminates TLS and forwards the original scheme to NGINX with that header, so the proxy can tell whether the client arrived through HTTP or HTTPS.

Keep Health Checks in Mind

AWS points out an important operational detail: if the environment relies on load balancer health checks over HTTP, you must not blindly redirect those health-check requests or the load balancer may mark instances unhealthy. One safe approach is to exempt the health endpoint before the redirect rule.

1# .platform/nginx/conf.d/elasticbeanstalk/https_redirect.conf
2
3location /health {
4    access_log off;
5    return 200 "ok";
6    add_header Content-Type text/plain;
7}
8
9if ($http_x_forwarded_proto = "http") {
10    return 301 https://$host$request_uri;
11}

Adjust /health to match the path your environment actually uses. If health checks already target HTTPS at the load balancer, you may not need the exception, but it is worth verifying before deployment.

Consider Redirecting at the Load Balancer Instead

AWS also documents a load-balancer-level option for Application Load Balancers. In a load-balanced environment, that approach is often simpler because the ALB can redirect port 80 traffic to 443 without involving instance NGINX at all.

Use the load balancer approach when:

• you want redirection enforced before traffic reaches EC2
• you do not need instance-specific exceptions
• your environment already uses an Application Load Balancer

Use the NGINX approach when:

• you need custom request logic on the instance
• you are in a single-instance environment
• you want the redirect behavior stored alongside application code

Both approaches are valid. The NGINX method is just more aligned with the specific question of configuring the Beanstalk proxy server itself.

Know the Platform Layout Difference

On current AL2 and AL2023 platforms, .platform/nginx/conf.d/elasticbeanstalk/ is the correct extension point for server-level NGINX directives. Older Amazon Linux AMI based platforms used .ebextensions/nginx/... layouts instead. If you copy old blog posts without checking the platform generation, the config may deploy successfully but never be included.

That distinction is one of the main reasons HTTPS redirect guides for Elastic Beanstalk look inconsistent across the internet.

Common Pitfalls

The most common mistake is adding a redirect rule before HTTPS is actually configured on port 443. Another frequent problem is placing the NGINX snippet in the wrong directory for the platform generation, so Elastic Beanstalk never includes it. Health checks are another easy way to break an environment, because redirecting the load balancer's probe path can make healthy instances look dead. Finally, some teams implement both ALB redirect rules and instance-level redirect rules without realizing they now have two places to debug the same behavior.

Summary

• Make sure the environment can already serve HTTPS before adding any redirect.
• On Elastic Beanstalk AL2 and AL2023, add the redirect snippet under .platform/nginx/conf.d/elasticbeanstalk/.
• Use X-Forwarded-Proto to detect original HTTP requests behind the load balancer.
• Exempt HTTP health checks if your load balancer still uses them.
• Prefer ALB redirects for simpler load-balanced setups, and NGINX redirects when you need proxy-level control.