Exploring Cost-Efficient SSE Alternatives with AWS Lambda and API Gateway

Below are concise answers to your questions:

---

1. Do AWS Lambda and API Gateway support SSE natively?

As of now, the default Lambda/API Gateway integration (using the lambda‑proxy mode) does not support keeping HTTP connections open for streaming data (like SSE). With this integration, your Lambda works by receiving a complete HTTP request and then returning a full HTTP response – it isn’t designed for sending multiple, incremental responses over a single connection.

---

2. What are the cost-efficient alternatives?

Given your requirements and low user volume, some alternatives include:

• Application Load Balancer (ALB) with Lambda Integration:
  ALB supports integration with Lambda functions and supports HTTP/1.1 chunked responses, which might be adapted to a streaming-like behavior. However, you’ll need to verify that its behavior meets your SSE requirements.

• Running a Lightweight Container Service (ECS/Fargate):
  Although running containers might seem less cost‑efficient at first glance, a lean setup (such as a small Fargate task) can provide full control over HTTP connections. This means you can implement SSE directly in your application code. Given your relatively low usage, the cost could be very acceptable.

• AWS AppSync (GraphQL Subscriptions):
  This service is designed for real‑time updates using subscriptions. While it’s not SSE per se and uses WebSockets under the hood, it’s an AWS‑managed service that might offer the real‑time capabilities you need. If strictly avoiding WebSockets is a design decision rather than a technical limitation, it’s worth evaluating.

Each option has trade‑offs. ALB with Lambda is intriguing from a cost and serverless perspective, but you’ll need to test whether ALB’s support for chunked responses is sufficient for SSE’s real‑time streaming. A containerized solution provides full control at the expense of managing a container service.

---

Remember, if using the Serverless Framework, you can define your integrations easily for API Gateway (or even ALB in some cases). For example, here’s an outline of how you’d typically configure a Lambda function with API Gateway using the lambda‑proxy integration in your serverless YAML (note that this example uses standard HTTP responses):

YAMLCopied
functions:
  myFunction:
    handler: handler.myFunction
    events:
      - http:
          path: /endpoint
          method: GET
          integration: lambda-proxy

Since SSE streams require you to maintain an open connection and send multiple data chunks over time (which isn’t what lambda‑proxy is designed for), you’d need to adjust your architecture accordingly if you want true SSE support.

---

I hope this answers your questions and helps you decide on the best path forward. Let me know if you need more details on any particular approach!