anomalyco/sst · error · VisibleError

The "nat.type" cannot be "managed" when "nat.ec2" is specifi

Error message

The "nat.type" cannot be "managed" when "nat.ec2" is specified.

What it means

Thrown by the VPC's normalizeNat when the user configures both `nat.ec2` (a custom EC2 NAT instance block) and `nat.type: "managed"` (AWS-managed NAT gateways). These two NAT modes are mutually exclusive: you either use managed NAT gateways or you supply your own EC2 NAT instance configuration.

Source

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

            .map((_, i) => zones.names[i]),
        );
      });
    }

    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: {

View on GitHub (pinned to a0bd20f762)

Solutions

1. Remove `nat.ec2` to use managed NAT gateways.
2. Or change `nat.type` to "ec2" (or omit type) when supplying `nat.ec2`.
3. Use `sst.env`/config typing or IDE hints to confirm only one NAT mode is set.

Example fix

// before
new sst.aws.Vpc("MyVPC", { nat: { type: "managed", ec2: { instance: "t4g.nano" } } });
// after
new sst.aws.Vpc("MyVPC", { nat: { ec2: { instance: "t4g.nano" } } });

function validateNat(nat) {
  if (nat && nat.ec2 && nat.type === "managed")
    throw new Error('Remove either nat.ec2 or set nat.type to "ec2".');
}
validateNat(args.nat);

When it happens

Trigger: Passing an object like `{ nat: { type: "managed", ec2: { instance: "t4g.nano" } } }` to `new sst.aws.Vpc()` — setting nat.ec2 while nat.type is "managed".

Common situations: Copy-pasting NAT config examples and leaving both keys; migrating from managed NAT to EC2 NAT by adding ec2 without removing/removing type; schema confusion about which property wins.

Related errors

• Missing "nat.type" for the "${name}" VPC. It is required whe
• The number of Elastic IP allocation IDs must match the numbe
• You cannot provide both "vpc.containerSubnets" and "vpc.serv
• Bastion instance profile must be a name, not an ARN.
• VPC bastion is not enabled. Enable it with "bastion: true" o

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