Auto-stop EC2 on low CPU, then auto-start on HTTPS request — how to keep a “front door” while the instance is off?

Source: Dev.to

What I want to achieve

• Automatically stop the EC2 instance when it’s idle (e.g., CPU utilization < 5%).
• When an incoming HTTPS request hits my API:
  1. The EC2 instance should be started automatically if it’s stopped.
  2. The request should eventually be served by the application running on that EC2 instance.

What I’ve already done

• Auto‑stop the EC2 instance using a CloudWatch alarm that triggers StopInstances.
• Created a Lambda function with the required IAM permissions to start the EC2 instance.
• Exposed that Lambda through API Gateway (HTTP API → Lambda → Start EC2); calling the API starts the instance.

The problem

• The API Gateway endpoint is not the EC2 endpoint. When the instance is stopped:
  • The HTTPS request triggers the Lambda and starts the EC2 instance.
  • The original request is never forwarded to the application once the instance finishes booting.
• Consequently, the requester’s request is lost because the EC2 instance was off at the time the request arrived.

My question

Is there a practical way to keep a “front door” (proxy, ALB, API Gateway, etc.) in front of the EC2 instance such that:

1. Incoming HTTPS requests trigger the instance to start if it’s stopped, and
2. The request is either
   • forwarded to the app once the instance is ready, or
   • responded to with a friendly message like “Service is starting, please retry in X seconds”.

Considered options

• Application Load Balancer
• API Gateway + Lambda
• A reverse proxy setup

I’m not sure which pattern is best, or the trade‑offs in terms of latency, complexity, and user experience.

What I’m looking for

• Recommended architectures or existing AWS patterns.
• Implementation tips.
• Comments on cold‑start latency and UX considerations.

Thanks!