anomalyco/sst · error · VisibleError

Request count scaling is only supported for http/https proto

Error message

Request count scaling is only supported for http/https protocols.

What it means

Request-count-based auto scaling relies on ALB `Application` request counts per target. When the effective load balancer type is `network` (NLB) or the service has no ALB attachment, `scaling.requestCount` cannot be honored, so SST throws this `VisibleError` during normalization.

Source

Thrown at platform/src/components/aws/service.ts:1914

          securityGroups: vpc.securityGroups,
          cloudmapNamespaceId: vpc.nodes.cloudmapNamespace.id,
          cloudmapNamespaceName: vpc.nodes.cloudmapNamespace.name,
        };
      }

      // "vpc" is object
      return output(args.cluster.vpc).apply((vpc) => ({
        isSstVpc: false,
        ...vpc,
      }));
    }

    function normalizeScaling() {
      // External ALB is always "application" type
      const lbType = albAttachment ? output("application" as const) : lbArgs?.type;
      return all([lbType, args.scaling]).apply(([type, v]) => {
        if (type !== "application" && v?.requestCount)
          throw new VisibleError(
            `Request count scaling is only supported for http/https protocols.`,
          );

        return {
          min: v?.min ?? 1,
          max: v?.max ?? 1,
          cpuUtilization: v?.cpuUtilization ?? 70,
          memoryUtilization: v?.memoryUtilization ?? 70,
          requestCount: v?.requestCount ?? false,
          scaleInCooldown: v?.scaleInCooldown ? toSeconds(v.scaleInCooldown) : undefined,
          scaleOutCooldown: v?.scaleOutCooldown ? toSeconds(v.scaleOutCooldown) : undefined,
        };
      });
    }

    function normalizeCapacity() {
      if (!args.capacity) return;

View on GitHub (pinned to a0bd20f762)

Solutions

1. Remove `scaling.requestCount` and use `scaling.cpuUtilization` or `scaling.memory` for non-HTTP services.
2. Switch the service ports/protocol to http/https so an application LB is used and request-count scaling is valid.
3. If attached to an external ALB, confirm the attachment is an application-type load balancer.

Example fix

// before
scaling: { min: 1, max: 10, requestCount: 500 } // tcp service

// after
scaling: { min: 1, max: 10, cpuUtilization: 70 }

const isHttp = (listen: string) => /https?\//.test(listen) || listen.endsWith("/http") || listen.endsWith("/https");
if (scaling.requestCount && !usesApplicationLb) {
  throw new Error("requestCount scaling requires http/https protocols");
}

function supportsRequestCountScaling(args: { scaling?: { requestCount?: number }, protocol?: string }): boolean {
  return !args.scaling?.requestCount || args.protocol === "http" || args.protocol === "https";
}

try {
  normalizeScalingConfig(args);
} catch (e) {
  if (e instanceof VisibleError && e.message.includes("Request count scaling")) {
    delete args.scaling.requestCount; // fall back to cpu/memory scaling
  } else throw e;
}

When it happens

Trigger: Setting `scaling: { requestCount: ... }` on a Service whose load balancer is a network load balancer (`lbArgs.type === "network"`), or with an external NLB attachment.

Common situations: Copying an HTTP service config that used `requestCount` scaling onto a TCP/UDP (NLB) service; switching a service from http to tcp ports and keeping the scaling block.

Related errors

• Cannot access `nodes.loadBalancer` in dev mode.
• Cannot access `nodes.loadBalancer` when no public ports are
• The ALB VPC "${albVpcId}" does not match the cluster VPC "${
• You must provide the ports to expose via "loadBalancer.rules
• You must provide a container name in "loadBalancer.rules" wh

AI-assisted analysis of anomalyco/sst@a0bd20f762 (2026-08-30). Data as JSON: /api/errors/ffb37b76757fd3dd. Report an issue: GitHub.