MCP Server ALB — Application Load Balancer target groups, health checks, sticky sessions, WebSocket

Target group: IP type for ECS awsvpc

ECS Fargate tasks with awsvpc networking each receive a private ENI. The ALB registers these tasks by their ENI IP address, not by the host EC2 instance ID. If you create the target group with the default INSTANCE type, ECS cannot register the task, or registers it but the health check never passes.

// CDK: ALB + target group with IP target type for ECS Fargate
import * as elbv2 from "aws-cdk-lib/aws-elasticloadbalancingv2";

const alb = new elbv2.ApplicationLoadBalancer(this, "McpAlb", {
  vpc,
  internetFacing: true,
  securityGroup: albSg,
});

const targetGroup = new elbv2.ApplicationTargetGroup(this, "McpTargetGroup", {
  vpc,
  targetType: elbv2.TargetType.IP,    // REQUIRED for ECS awsvpc networking
  port: 3000,
  protocol: elbv2.ApplicationProtocol.HTTP,
  healthCheck: {
    path: "/health",                  // dedicated health endpoint — not "/"
    interval: Duration.seconds(30),
    timeout: Duration.seconds(5),
    healthyThresholdCount: 2,
    unhealthyThresholdCount: 3,
    healthyHttpCodes: "200",
  },
  deregistrationDelay: Duration.seconds(30),  // default is 300s — too slow for rolling deploys
  stickinessCookieDuration: Duration.days(1), // enable sticky sessions for SSE/WebSocket
});

// HTTPS listener (TLS termination at ALB)
const httpsListener = alb.addListener("Https", {
  port: 443,
  protocol: elbv2.ApplicationProtocol.HTTPS,
  certificates: [elbv2.ListenerCertificate.fromArn(certArn)],
  defaultTargetGroups: [targetGroup],
});

// HTTP → HTTPS redirect
alb.addListener("Http", {
  port: 80,
  defaultAction: elbv2.ListenerAction.redirect({
    protocol: "HTTPS",
    port: "443",
    permanent: true,
  }),
});

ECS registers the Fargate task IP into the target group automatically when using the ApplicationLoadBalancedFargateService construct, or when the FargateService is attached to the target group via service.attachToApplicationTargetGroup(targetGroup).

Health check endpoint

The health check path must respond immediately without triggering MCP protocol initialization. A separate express route (or equivalent) that returns 200 in under 500ms is the correct pattern.

// Node.js: lightweight health endpoint that does not initialize MCP session
import express from "express";
import { createServer } from "@modelcontextprotocol/sdk/server/index.js";

const app = express();

// Health endpoint — must respond before any MCP setup
app.get("/health", (_req, res) => {
  res.json({ status: "ok", timestamp: Date.now() });
});

// MCP SSE endpoint (or Streamable HTTP)
app.get("/mcp", async (req, res) => {
  // ... MCP transport setup
});

// ALB checks /health every 30 seconds
// The health endpoint must return 200 within the 5-second timeout configured above
// If /health returns 200 for 2 consecutive checks (healthyThresholdCount: 2),
// the target is marked healthy; 3 failures marks it unhealthy
app.listen(3000);

Do not use / as the health check path if it triggers middleware chains, authentication checks, or session initialization. The ALB sends a bare GET /health HTTP/1.1 with no auth headers — any 401/403 response marks the target unhealthy.

Sticky sessions for SSE and WebSocket transports

MCP servers using Server-Sent Events (SSE) or WebSocket transport maintain per-connection state in memory. If the ALB routes a client reconnection to a different task, the new task has no state for that session. Sticky sessions pin a client to the same target for the duration of the session.

// CDK: sticky sessions via duration-based cookie
const targetGroup = new elbv2.ApplicationTargetGroup(this, "McpTargetGroup", {
  // ...
  stickinessCookieDuration: Duration.hours(24),
  // ALB sets AWSALB cookie on first response
  // Subsequent requests from the same client include the cookie
  // ALB routes cookie-bearing requests to the same registered target
});

// Alternative: application-controlled cookie (AWSALBAPP)
// Use this if you want to control the cookie name or set it from your app
const targetGroup2 = new elbv2.ApplicationTargetGroup(this, "McpTargetGroupApp", {
  stickinessCookieDuration: Duration.hours(24),
  stickinessCookieName: "MCPSESSION",   // application stickiness — requires app to set this cookie
});

Sticky sessions and rolling deploys: when a task is deregistered (during a rolling deploy), the ALB immediately stops routing new connections to it. Existing sticky sessions on that task will fail when the client next requests — the deregistrationDelay window allows in-flight requests to complete, but long-lived SSE connections will be interrupted. Design your MCP client to reconnect automatically when an SSE connection drops.

Common failure modes