Struggling with AWS API Gateway silently dropping HTTP requests? A senior cloud architect breaks down why this “feature” exists and provides three battle-tested solutions to properly handle HTTP to HTTPS redirection.

My API Gateway is Ignoring HTTP. What Gives, AWS? A Veteran’s Guide.

I still remember the night we launched the new registration flow for a major client. It was 2 AM, the coffee was stale, and we were staring at a Grafana dashboard that was depressingly flat. The new microservice, sitting behind a shiny new API Gateway HTTP API, was getting zero traffic. We checked security groups, NACLs, VPC routing, everything. A junior engineer on the call, bless his heart, tentatively asked, “Hey, I’m trying to curl the endpoint with plain HTTP just to see if the DNS is working, and it just hangs. Is that normal?” That was it. That was the ‘aha’ moment. We’d all been testing with HTTPS like good little engineers, but the legacy client system that was supposed to call us was still using an old `http://` endpoint. The API Gateway wasn’t rejecting the request; it was just… ignoring it. Utter silence.

The Root of the Problem: It’s a Feature, Not a Bug

Let’s get this out of the way first: your API Gateway isn’t broken. Both REST and HTTP APIs on AWS API Gateway are, by design, HTTPS-only endpoints. When AWS provisions your API, they give you a URL like `https://{api-id}.execute-api.{region}.amazonaws.com`. That DNS name resolves to an IP address that is only listening on port 443 (HTTPS). There is nothing listening on port 80 (HTTP). It’s a security-first design decision from AWS, and honestly, it’s a good one. In 2024, your public APIs should be HTTPS. Period.

The confusion comes because we’re used to services like Application Load Balancers (ALBs) or NGINX servers where setting up a listener on port 80 to redirect to 443 is trivial. With API Gateway, that control plane doesn’t exist. It expects the client to be smart enough to use HTTPS from the start. But as my war story shows, the real world is messy, and you can’t always control the client.

So, how do we fix it? We have a few options, ranging from the quick-and-dirty to the architecturally sound.

Solution 1: The Quick Fix (The “Just Use HTTPS” Shove)

This is the simplest, and sometimes most pragmatic, approach. If you control the client application (like a React frontend you also wrote), the easiest fix is to ensure the client never makes an HTTP request in the first place.

For a web app, you can enforce this with a tiny bit of JavaScript. It’s a band-aid, but it works.

if (window.location.protocol === "http:") {
    const httpsURL = "https:" + window.location.href.substring(window.location.protocol.length);
    window.location.replace(httpsURL);
}

When to use this: When you have full control over the client code, it’s an internal tool, or you can confidently tell all your API consumers, “Update your configs.” It’s a bit lazy, but for a dev environment or an internal dashboard, it’s often good enough.

Solution 2: The Right Fix (CloudFront in Front)

This is the canonical, AWS-recommended way to solve the problem. You put an AWS CloudFront distribution in front of your API Gateway. CloudFront acts as our new front door, and it’s a door that knows how to handle both HTTP and HTTPS.

Here’s the game plan:

1. Create a new CloudFront distribution.
2. For the “Origin Domain,” use the “Invoke URL” of your API Gateway, but remove the `https://` prefix and the stage name. For example, use `{api-id}.execute-api.us-east-1.amazonaws.com`.
3. Set the “Origin Path” to your stage name (e.g., `/prod`).
4. Under “Viewer,” set the “Viewer Protocol Policy” to “Redirect HTTP to HTTPS”. This is the magic setting.
5. Set up your custom domain (e.g., `api.my-app.com`) as an “Alternate Domain Name” in CloudFront and point your DNS CNAME record to the CloudFront distribution URL (e.g., `d12345abcdef.cloudfront.net`).

Darian’s Pro Tip: Be patient. CloudFront distributions can take a while to deploy and propagate globally. Go grab a coffee. Also, if you make changes later, remember that you might need to run a cache invalidation, especially if you’re caching responses.

This is the most robust and scalable solution. You get the benefits of a global CDN (caching, DDoS protection) and proper handling of HTTP traffic, all in one service.

Solution 3: The ‘Heavy Machinery’ Fix (Using an ALB)

Sometimes, you can’t use CloudFront. Maybe your organization has a policy against it, or you have complex VPC routing and network requirements that make an Application Load Balancer (ALB) a better fit. While it feels like using a sledgehammer to crack a nut, you can absolutely put an ALB in front of your API Gateway.

This setup is more complex:

1. Deploy an internet-facing ALB in your VPC.
2. Create two listeners: one on port 80 (HTTP) and one on port 443 (HTTPS).
3. Configure the listener for port 80. Add a rule with a “Redirect” action. Set it to do a permanent (301) redirect to HTTPS, port 443.
4. Configure the listener for port 443. This is the tricky part. The target will be your API Gateway.
   • For an HTTP API with a Private Integration, you can use a VPC Link and have the ALB target an NLB, which then forwards to the VPC Link.
   • For a simpler setup, you can have the ALB target a Lambda function, and that Lambda function acts as a proxy to invoke the API Gateway endpoint.

Here’s a comparison of the robust solutions:

Ultimately, don’t get frustrated with AWS over this. Think of it as a nudge towards a more secure, modern architecture. For 95% of use cases, slapping CloudFront in front is the right call. It’s a ten-minute job that will save you from a 2 AM fire drill.

Darian Vance

Lead Cloud Architect & DevOps Strategist

With over 12 years in system architecture and automation, Darian specializes in simplifying complex cloud infrastructures. An advocate for open-source solutions, he founded TechResolve to provide engineers with actionable, battle-tested troubleshooting guides and robust software alternatives.

🤖 Frequently Asked Questions