Why do my API Gateway request return 307 status codes from envoy?

Hi, excellent question. When integrating API Gateway with ECS Service Connect, this is a frequent source of misunderstanding. Envoy's 307 redirect is a clear indicator that the problem stems from the way your Rails application handles the host and HTTP request headers that the API Gateway is sending. Let's dissect the situation: The Primary Cause: The Host Header and X-Forwarded-For Inconsistency

1. The Request Path: This is how your HTTP request proceeds: Client -> Cloud Map -> API Gateway -> Service Connect Proxy (Envoy) -> Your Rails App

2. The Redirect (307): Your Rails application is not the source of the 307 error. It originates from the Envoy sidecar proxy that is injected into your task by ECS Service Connect. Envoy is set up to manage routing and service discovery.

3. The Reason Envoy Redirects: Envoy is getting a request in which it thinks the target is not correct. A mismatch between the Host header and the Service Connect endpoint name is the most frequent cause of this.

The Service Connect endpoint, such as my-service.us-east-1.amazonaws.com, receives the request when you set up a Cloud Map integration in API Gateway. Nevertheless, the hostname of your API Gateway (for example, "yeeeeeeeee.execute-api.us-east-1.amazonaws.com") is automatically set to the Host header of the outgoing request by API Gateway. The Service Connect endpoint for which the Envoy proxy is configured must match the Host header. It creates a loop when it sees the hostname of your API Gateway instead, interpreting it as a request to the incorrect "virtual host" and replying with a 307 redirect to the "correct" location, which is the URL of your API Gateway.

The solution is to override the host header in the API gateway. The Host header that API Gateway sends to your Cloud Map service must be overridden. A parameter mapping in your API Gateway integration can be used for this.

1. Locate the Service Connect Endpoint: You specified a Namespace and a Service Connect Name in your ECS service configuration for Service Connect. [ServiceName] is the complete endpoint. [Namespace]. For instance, the endpoint is rails-app.my-namespace if your service is rails-app and your namespace is my-namespace.

2. Set up the API Gateway integration: Open the route integration for your API in the API Gateway console. Modify how your Cloud Map service is integrated. Locate the "Configuration" or "Parameter Mapping" section. The Host header requires a mapping to be added. Include a fresh mapping:

Type: Header request Important: Host Value: your-service-connect-endpoint (rails-app.my-namespace, for example) This compels API Gateway to substitute the precise hostname that your Service Connect Envoy proxy is anticipating for the default Host header (api-gw-host). Extra Verifications Additionally, after using the Host header fix, make sure:

1. Health Checks: Cloud Map's health checks, which are based on the health checks specified in your ECS service, are what API Gateway depends on. Make sure the healthy route (such as /health) in your Rails application is appropriately returning 200-level status codes. The API Gateway will not direct traffic to a service that is unhealthy in Cloud Map.
2. Security Groups: The application port must be open to incoming traffic from the API Gateway VPC or, if a VPC Link is being used, from the security group of the VPC Link. It's good that you said that this is probably true.
3. VPC Endpoints (if using private APIs): If your API is private, you need to have execute-api VPC endpoints in the VPC where your customers are located. Does the ALB Need to Be Removed? You're correct that this pattern may eliminate the need for an ALB, but there's a big catch:

• Benefits: It is a more straightforward service-to-service pattern, simplifies architecture, and can save costs (no ALB cost). • Drawbacks (The Caution): The integration of Cloud Maps is a pass-through integration. Unlike ALBs, API Gateways are not capable of Layer 7 processing. This implies that you lose.

Path-Based Routing: On the same API Gateway API, you cannot route /users* to one service and /orders* to another. Each service would require its own API route.

Advanced Health Checks: ALB health checks are more reliable and adaptable. SSL Offloading/Termination: The integration to Service Connect is via HTTP, which is acceptable internally, even though API Gateway manages TLS with the client.

In conclusion, begin by integrating the Host header override into your API Gateway. There is a 99% chance that this will fix the 307 redirect problem. You can then assess whether the pass-through model satisfies all of your requirements for departing from the ALB. I wish you luck!

✅ Problem:

Using API Gateway → ECS (via Cloud Map / Service Connect).

Envoy responds with 307 redirect instead of passing traffic to Rails app.

💡 Likely Causes:

Envoy’s 307 usually comes from HTTP → HTTPS redirect behavior.

Your Rails app might be behind middleware that enforces HTTPS (e.g., config.force_ssl = true) but Envoy is forwarding traffic as plain HTTP.

Fix:

Add x-forwarded-proto header mapping in API Gateway → Service Connect integration.

Or disable HTTPS redirect in Rails for internal traffic:

config.force_ssl = false if ENV['INTERNAL_TRAFFIC'] == 'true'

Or configure Envoy to rewrite scheme before proxying (via VirtualNode config).

The 307 Temporary Redirect status code you're receiving from Envoy suggests that your API Gateway setup is encountering a routing issue when trying to connect to your ECS services via Cloud Map.

This specific issue is likely related to how API Gateway is handling the HTTP/HTTPS protocol transition when connecting to your backend service. When you receive a 307 redirect with a location header pointing back to your API Gateway endpoint, it indicates that Envoy (the Service Connect proxy) is trying to redirect the request rather than forwarding it to your Rails application.

Here are some potential causes and solutions:

1. Protocol mismatch: Ensure that the protocol (HTTP/HTTPS) configured in your API Gateway integration matches what your Service Connect expects. If your API Gateway is sending HTTPS requests but your Service Connect is configured for HTTP, this could cause redirection issues.

2. Path configuration: Check that the path in your API Gateway route configuration matches the path your Rails application is expecting. The location header in the response suggests the request might be getting redirected due to path mismatches.

3. Host header handling: API Gateway might be sending a host header that Envoy doesn't recognize. You may need to configure your API Gateway to pass through the correct host header that Service Connect expects.

4. Service Connect configuration: Review your Service Connect configuration to ensure it's properly set up to accept requests from API Gateway. The default Envoy configuration might need adjustments to handle the API Gateway integration properly.

5. Security Groups: While you mentioned your security groups seem correct, double-check that they allow traffic on the specific ports that Service Connect is using, not just the ports your Rails app listens on.

To troubleshoot further:

• Check CloudWatch logs for both API Gateway and your ECS tasks to see more detailed error information
• Try setting up a simple test endpoint in your Rails app specifically for API Gateway testing
• Consider temporarily configuring your API Gateway to connect through your ALB as a baseline test, then migrate to the Cloud Map integration once you understand the differences

If the issue persists, you might need to examine the Envoy configuration more closely, even though it's using the standard setup. The redirection behavior suggests there's something in the request that's triggering Envoy to issue a redirect rather than proxying the request to your application.
Sources
AWS Gateway: API does not respond in Postman | AWS re:Post
HTTP API Gateway is only forwarding the first parameter string. | AWS re:Post
Why does the Error occurred | AWS re:Post