anomalyco/sst · error · VisibleError

Missing "nat.type" for the "${name}" VPC. It is required whe

Error message

Missing "nat.type" for the "${name}" VPC. It is required when "nat.ec2" is not specified.

What it means

Thrown by normalizeNat when neither `nat.type` nor `nat.ec2` is provided. When any NAT configuration object is present, SST requires you to say whether you want a managed NAT gateway (type: "managed") or an EC2-based NAT instance (type: "ec2" or an ec2 block), because it cannot infer the mode.

Source

Thrown at platform/src/components/aws/vpc.ts:868

    function normalizeNat() {
      return all([args.nat, zones]).apply(([nat, zones]) => {
        if (nat === "managed") {
          return { type: "managed" as const };
        }
        if (nat === "ec2") {
          return {
            type: "ec2" as const,
            ec2: { instance: "t4g.nano", ami: undefined, role: undefined },
          };
        }
        if (nat) {
          if (nat.ec2 && nat.type === "managed")
            throw new VisibleError(
              `The "nat.type" cannot be "managed" when "nat.ec2" is specified.`,
            );

          if (!nat.type && !nat.ec2)
            throw new VisibleError(
              `Missing "nat.type" for the "${name}" VPC. It is required when "nat.ec2" is not specified.`,
            );

          if (nat.ip && nat.ip.length !== zones.length)
            throw new VisibleError(
              `The number of Elastic IP allocation IDs must match the number of AZs.`,
            );

          return nat.ec2 || nat.type === "ec2"
            ? {
                type: "ec2" as const,
                ip: nat.ip,
                ec2: {
                  instance: nat.ec2?.instance ?? "t4g.nano",
                  ami: nat.ec2?.ami,
                  role: nat.ec2?.role,
                },
              }

View on GitHub (pinned to a0bd20f762)

Solutions

Add `nat.type: "managed"` for managed NAT gateways.
Or add `nat.type: "ec2"` (or an `nat.ec2` block with instance/ami/role) for a NAT instance.
Check the SST VPC docs for the current nat schema.

Example fix

// before
new sst.aws.Vpc("MyVPC", { nat: { ip: ["eipalloc-123", "eipalloc-456"] } });
// after
new sst.aws.Vpc("MyVPC", { nat: { type: "managed", ip: ["eipalloc-123", "eipalloc-456"] } });

Defensive patterns

Strategy: validation

Validate before calling

function validateNat(nat, name) {
  if (nat && !nat.type && !nat.ec2)
    throw new Error(`Set nat.type ("managed" or "ec2") for the "${name}" VPC.`);
}
validateNat(args.nat, "MyVPC");

Prevention

Always pair nat.ip with an explicit nat.type
Use TypeScript types from sst (sst.aws.VpcArgs) to catch missing required fields at compile time
Refer to the SST VPC docs when enabling NAT

When it happens

Trigger: Passing `{ nat: { ip: [...] } }` or `{ nat: {} }` (any nat object without type or ec2) to `new sst.aws.Vpc()` for VPC "${name}".

Common situations: Setting only elastic IP allocation IDs (nat.ip) while forgetting nat.type; trimming a config example and accidentally removing the type field; upgrading SST where nat config became stricter.

Related errors

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