NAT Gateway — Megaport CLI

A Megaport NAT Gateway is a managed network address translation service hosted on the Megaport fabric. It gives outbound internet egress to private networks (typically attached to an MCR) without you running your own NAT appliance.

Provisioning a NAT Gateway is a four-step flow:

list-sessions — discover valid speed and session-count combinations
create — build a NAT Gateway in DESIGN state (no charges yet)
validate — confirm pricing and configuration
buy — kick off provisioning and begin billing

Step 1 — Find valid speed / session-count combinations

Not every speed pairs with every session count. Run list-sessions first to see what the API will accept:

bash

megaport-cli nat-gateway list-sessions

Example output:

text

SPEED (Mbps)  SESSION COUNT
500           100
1000          100
1000          250
2500          500
5000          1000
10000         2000

For scripting, use JSON:

bash

megaport-cli nat-gateway list-sessions --output json

💡

Pick the smallest tier that fits peak load

NAT Gateway is billed on the speed tier. Start with the lowest combination that covers expected peak concurrent sessions — you can resize later in place with nat-gateway update --speed --session-count.

Step 2 — Find a location

NAT Gateways are provisioned at a specific data centre. Use the same metro as the MCR you plan to attach it to:

bash

megaport-cli locations list --metro Sydney --output json | jq '.[] | {id, name}'

Note the numeric location ID — you'll need it for --location-id.

Step 3 — Create the design

create builds a NAT Gateway in DESIGN state. Nothing is provisioned yet and no charges accrue until you run buy.

Interactive

bash

megaport-cli nat-gateway create --interactive

Flags

bash

megaport-cli nat-gateway create \
  --name "Sydney NAT" \
  --location-id 3 \
  --speed 1000 \
  --session-count 100 \
  --term 12

JSON

bash

megaport-cli nat-gateway create --json '{
  "name": "Sydney NAT",
  "locationId": 3,
  "speed": 1000,
  "sessionCount": 100,
  "term": 12,
  "diversityZone": "blue"
}'

The command returns a UID — save it as NAT_UID, you'll use it for the next three steps.

Parameter reference

Parameter	Values	Notes
`--name`	String, 1–64 chars	Shown in portal and invoices
`--location-id`	Integer	Get from `locations list`
`--speed`	From `list-sessions`	Mbps
`--session-count`	From `list-sessions`	Must pair with `--speed`
`--term`	`1`, `12`, `24`, `36` months	Longer terms = lower rates
`--diversity-zone`	e.g. `blue`, `red`	For redundant gateway pairs
`--auto-renew`	`true` / `false`	Auto-renew the contract term
`--service-level-reference`	String	Optional reference for SLAs

Step 4 — Validate the design

validate checks the design against the API and previews pricing. Still no charges.

bash

megaport-cli nat-gateway validate <NAT-UID>
megaport-cli nat-gateway validate <NAT-UID> --output json

If validation fails, fix the design (delete and recreate, or update via the portal) before continuing.

Step 5 — Buy and provision

buy accepts the design and begins provisioning. This is where billing starts.

bash

megaport-cli nat-gateway buy <NAT-UID>

Skip the confirmation prompt in automation:

bash

megaport-cli nat-gateway buy <NAT-UID> --yes

Check provisioning state:

bash

megaport-cli nat-gateway get <NAT-UID>
megaport-cli nat-gateway list

The gateway starts as CONFIGURED and transitions to LIVE automatically.

Step 6 — Monitor telemetry

Once the gateway is live, retrieve traffic metrics with telemetry. Three metric types are available: BITS, PACKETS, SPEED.

Rolling window

bash

# Last 7 days, bits per second
megaport-cli nat-gateway telemetry <NAT-UID> --types BITS --days 7

# Multiple metrics, last 30 days, JSON output
megaport-cli nat-gateway telemetry <NAT-UID> --types BITS,PACKETS,SPEED --days 30 --output json

Absolute time range

bash

megaport-cli nat-gateway telemetry <NAT-UID> \
  --types BITS \
  --from 2026-05-01T00:00:00Z \
  --to 2026-05-31T23:59:59Z

ℹ️

`--days` and `--from`/`--to` are mutually exclusive

Use one or the other. --days is easiest for rolling dashboards; --from/--to is needed when you want a specific calendar month or incident window.

Step 7 — Update or delete

Update

nat-gateway update changes name, term, speed, session count, and a handful of other fields:

bash

megaport-cli nat-gateway update <NAT-UID> --name "Sydney NAT — Prod"

# Resize speed and session count in one call (pick a pair from `list-sessions`)
megaport-cli nat-gateway update <NAT-UID> --speed 2500 --session-count 500

# JSON input works too
megaport-cli nat-gateway update <NAT-UID> --json '{"name":"Sydney NAT — Prod","term":24}'

Delete

⚠️

Delete is permanent — no restore window

Unlike Ports, MCRs, and MVEs, a deleted NAT Gateway cannot be restored. Once you confirm the delete, the resource is gone. Triple-check the UID and any dependent VXCs before running this in production.

bash

megaport-cli nat-gateway delete <NAT-UID>

# Skip the confirmation prompt
megaport-cli nat-gateway delete <NAT-UID> --force

Best practices

Plan capacity

Pick a speed/session-count tier that covers peak load with headroom — resizing live (update --speed --session-count) is supported but each tier change is a billing event, so churn costs real money
Bigger tier = pay more idle; smaller tier = risk session-count drops at peak

Diversity

For production, deploy two NAT Gateways in different diversity zones at the same metro
Attach each to a different MCR (or both to a single MCR) and let BGP failover handle the rest

Telemetry

Pull BITS + SPEED daily into your monitoring tool to spot saturation
PACKETS is useful for diagnosing flow churn before traffic volume changes

Lifecycle

The create → validate → buy split lets you script the design separately from the commit — useful for change-management approval gates

What's next?

MCR Routing — attach the NAT Gateway to an MCR for centralised internet egress
Automation — scripting patterns for the imperative create → validate → buy flow (NAT Gateway is not yet supported by megaport-cli apply)
Command Reference — NAT Gateway — full CLI surface