AWS NAT Gateway -kustannusten optimointi 2026: näin leikkaat piilokulut jopa 90 %

Päivitetty: 25. elokuuta 2026

AWS NAT Gatewayn kulut syntyvät kahdesta osasta: kiinteästä tuntimaksusta (noin 0,045 $/tunti per käyttöönottovyöhyke) ja käsittelymaksusta 0,045 $ jokaista NAT:n läpi kulkevaa gigatavua kohden. Tehokkain tapa leikata ne on siirtää S3- ja DynamoDB-liikenne VPC Gateway Endpointeihin, muu AWS-palveluliikenne Interface Endpointeihin ja rakentaa arkkitehtuuri niin, ettei sama tavu koskaan lipsahda NAT:n läpi kahdesti. Tässä oppaassa käyn läpi hinnoittelun matematiikan, kolme yleisintä laskutuspiikin syytä ja rakennan VPC Flow Logs -kyselyn, jolla löydät suurimmat kustannuslähteet noin 15 minuutissa.

• NAT Gateway maksaa noin 32,85 $/kk per käyttöönottovyöhyke pelkän saatavuuden takia. Kolmen AZ:n asennus siis lähes 100 $/kk ennen ensimmäistäkään tavua.
• Käsittelymaksu 0,045 $/GB koskee molempia suuntia; 10 TB kuukausiliikenne = 450 $ pelkästä datankäsittelystä + normaali egress-hinta päälle.
• S3- ja DynamoDB-liikenteen ohjaaminen Gateway Endpointien kautta on maksutonta ja poistaa usein 40–70 % NAT-liikenteestä.
• ECR-, Secrets Manager- ja SSM-liikenne kannattaa reitittää Interface Endpointien kautta, jos volyymi ylittää 1 TB/kk.
• Yhteisöprojekti fck-nat (t4g.nano) hoitaa jopa 5 Gbps liikenteen noin 3–4 $/kk hinnalla, joka sopii kehitys- ja QA-ympäristöihin.
• Konsolidoi NAT-gatewayt yhteen AZ:hen non-prod-ympäristöissä ja hyväksy pieni riski. Säästö on tyypillisesti 60–66 % kiinteistä kuluista.

Miksi NAT Gateway on niin kallis?

No niin, mennään suoraan asiaan. NAT Gateway on kallis kahdesta syystä: hinnoittelumalli laskuttaa sekä ajasta että datasta, eikä useimmilla tiimeillä ole aavistustakaan siitä, että NAT istuu liikennepolun keskellä ennen kuin lasku saapuu. Kun luot yksityisen aliverkon EC2-instanssia varten, joka lataa Docker-imagen ECR:stä ja hakee salaisuuden Secrets Managerista, oletusarvoinen reititys ohjaa kaiken tuon liikenteen NAT Gatewayn läpi. Vaikka määränpää olisi AWS:n omassa selkärangassa.

Työskennellessäni CloudHealthilla mid-market-asiakkaiden kanssa näin saman kuvion toistuvan. Yritys, joka polttaa 800 000 $/kk EC2:een, huomaa maksavansa 42 000 $/kk NAT Gatewaystä pelkästään siksi, että eräajot vetävät 30 TB dataa S3:sta yksityisen aliverkon kautta. Yksi aws_vpc_endpoint-resurssi Terraformissa poisti 38 000 $ kuukausikulun kertaheitolla, eikä kellään toimistossa ollut selittää, miksi juttua ei ollut korjattu jo vuosi aiemmin. Tästä syystä NAT Gateway on FinOps-tiimien "hiljainen tappaja". Se ei näy CloudWatchin oletusdashboardeissa ennen kuin katsot Cost Explorerin UsageType-erittelyä.

Toinen kalleuden syy on kiinteä tuntimaksu käyttöönottovyöhykettä kohti. Kolmen AZ:n korkea saatavuus tarkoittaa kolmea gatewaytä ja kolmea samanaikaista tuntimaksua, eli noin 98,55 $/kk pelkästä olemassaolosta. Non-prod-ympäristöissä tämä on lähes aina hukkaan heitettyä rahaa.

NAT Gateway -hinnoittelu 2026: matematiikka auki

AWS julkaisee NAT Gatewayn hinnoittelun kahdessa akselissa. Alla eu-west-1-alueen (Irlanti) hinnat elokuulle 2026. Tarkista aina viralliselta Amazon VPC -hinnoittelusivulta, sillä alueelliset erot voivat olla 20 %.

Komponentti	Yksikköhinta	Kuukausikulu esimerkkitilanteessa
NAT Gateway -tuntimaksu	0,045 $/h	32,85 $ per AZ per kuukausi
Datan käsittelymaksu (molemmat suunnat)	0,045 $/GB	10 TB → 450 $
Egress internetiin (NAT:n jälkeen)	0,09 $/GB (ensimmäiset 10 TB)	10 TB → 900 $
Cross-AZ datankäsittely	0,01 $/GB per suunta	Voi tuplata NAT-osuuden
Vertailu: VPC Gateway Endpoint (S3/DynamoDB)	0,00 $	Ilmainen
Vertailu: Interface Endpoint	0,01 $/h + 0,01 $/GB	7,30 $/kk + 100 $/10 TB

Huomaa: 10 TB kuukausiliikenne S3:een tuottaa NAT-reitityksellä 450 $ käsittelymaksun. Sama liikenne Gateway Endpointin kautta on 0 $. Kirjaimellisesti ilmainen säästö, ja silti näen sen joka toisessa auditoinnissa.

Tunnista kustannuspiikit VPC Flow Logs -kyselyllä

Ennen optimointia sinun on tiedettävä, mikä palvelu syö NAT-kuluja. Nopein tapa on Athena-kysely VPC Flow Logs -dataan. Ota Flow Logs käyttöön VPC-tasolla ja aja seuraava kysely, joka ryhmittelee NAT-verkkoliitännän liikenteen kohdekentän perusteella:

SELECT
  dstaddr AS kohde_ip,
  SUM(bytes) / (1024.0 * 1024 * 1024) AS gigatavua,
  SUM(bytes) / (1024.0 * 1024 * 1024) * 0.045 AS kasittely_usd
FROM vpc_flow_logs
WHERE interface_id = 'eni-0abc123def456'   -- NAT Gatewayn ENI-tunnus
  AND action = 'ACCEPT'
  AND date_partition >= '2026-08-01'
GROUP BY dstaddr
ORDER BY gigatavua DESC
LIMIT 25;

Kohde-IP-osoitteista näet, mitkä palvelut syövät eniten. Useimmiten top-10 sisältää S3:n julkiset IP-osoitteet (kääntyy s3.eu-west-1.amazonaws.com-nimellä), ECR-registryn (*.dkr.ecr.eu-west-1.amazonaws.com) ja jonkin kolmannen osapuolen API:n kuten Datadogin tai Segmentin. Käytä dig -x-komentoa tai whois-kyselyä IP-tunnistukseen.

Rehellisesti sanottuna: aseta samalla vaivalla Cost Explorerin ryhmittely USAGE_TYPE-akselille suodattimella Service = EC2-Other. Silloin näet välittömästi rivit "NatGateway-Hours", "NatGateway-Bytes" ja "EU-DataProcessing-Bytes", joilla saat trendin viimeisen 90 päivän ajalta. Sama peruslogiikka toistuu FinOps-käytäntöjen näkyvyystyössä laajemminkin.

VPC Gateway Endpointit: ilmainen tapa poistaa S3- ja DynamoDB-liikenne

VPC Gateway Endpoint on täysin ilmainen resurssi, joka lisää reititystaulukkoosi merkinnän niin, että S3- tai DynamoDB-liikenne kulkee suoraan AWS:n selkärangan kautta ja ohittaa NAT Gatewayn. Käyttöönotto vie kirjaimellisesti kolme minuuttia:

# AWS CLI, luo Gateway Endpoint S3:lle
aws ec2 create-vpc-endpoint \
  --vpc-id vpc-0abc123 \
  --service-name com.amazonaws.eu-west-1.s3 \
  --route-table-ids rtb-priv-a rtb-priv-b rtb-priv-c \
  --vpc-endpoint-type Gateway

# Terraform-vastine
resource "aws_vpc_endpoint" "s3" {
  vpc_id            = aws_vpc.main.id
  service_name      = "com.amazonaws.eu-west-1.s3"
  vpc_endpoint_type = "Gateway"
  route_table_ids   = aws_route_table.private[*].id
}

Muista liittää endpoint kaikkiin yksityisiin reititystaulukoihin. Yleinen virhe (johon itsekin lankesin ensimmäisellä kerralla) on lisätä se vain yhteen AZ:hen, jolloin muiden AZ:iden liikenne kulkee edelleen NAT:n läpi. Tarkista käyttöönoton jälkeen VPC Flow Logs -kyselyllä, että S3-liikenne katosi NAT-ENI:ltä.

DynamoDB-endpointti asennetaan samalla tavalla vaihtamalla service-name arvoon com.amazonaws.eu-west-1.dynamodb. Molemmat tukevat vain samaa aluetta. Jos sovelluksesi hakee cross-region-dataa, joudut edelleen käyttämään NAT:iä tai VPC Peeringiä.

Interface Endpointit (PrivateLink): milloin ne kannattavat

Interface Endpointit (PrivateLink) tukevat yli 200 AWS-palvelua, mukaan lukien ECR, Secrets Manager, SSM, CloudWatch Logs ja SQS. Ne eivät ole ilmaisia: kiinteä hinta on 0,01 $/tunti per endpoint per AZ (noin 7,30 $/kk) ja 0,01 $/GB käsitellystä datasta. Neljäsosa NAT Gatewayn 0,045 $/GB hinnasta, joten kannattavuusraja tulee vastaan yllättävän nopeasti.

Yksinkertainen kannattavuuslaskenta kolmen AZ:n ympäristössä:

• Kiinteät kulut: 3 × 7,30 $ = 21,90 $/kk
• Muuttuva säästö: (0,045 $ − 0,01 $) × GB = 0,035 $/GB
• Kannattavuusraja: 21,90 $ / 0,035 $ ≈ 626 GB/kk per palvelu

Toisin sanoen: jos ECR-liikenne ylittää 626 GB/kk (yksi CI-pipeline hakee tyypillisesti 50–500 GB kuvia päivässä), Interface Endpoint maksaa itsensä takaisin. Jos organisaatiosi kaikki palvelut yhdessä hakevat 5 TB/kk ECR:stä, säästö on noin 175 $/kk per AZ. Täydellinen palvelulista löytyy AWS PrivateLink -dokumentaatiosta.

fck-nat ja NAT-instanssi vaihtoehtona

fck-nat on avoimen lähdekoodin AMI, joka toteuttaa NAT-toiminnallisuuden yhdellä EC2-instanssilla. Tyypillisesti t4g.nano-tyypillä (2 vCPU ARM Graviton, 0,5 GB muistia, noin 3,80 $/kk on-demand-hintaan). Se hoitaa noin 5 Gbps liikenteen ja tukee automaattista feilaus-skenaariota Auto Scaling Groupin avulla.

Milloin fck-nat kannattaa:

• Kehitys- ja QA-ympäristöt: vähäinen liikenne, riittää yksi instanssi per AZ.
• Sisäiset työkalut: Grafana-, Airflow- tai Jenkins-hostit, joilla ei ole SLA-vaatimuksia.
• Verkkoraskaat eräajot: jos käsittelet 100+ TB/kk, EC2-verkkoläpisyötön kustannus (0 $ datankäsittelymaksua) tappaa NAT Gatewayn.

Milloin fck-nat ei kannata: tuotannon SLA vaatii AWS:n hallitseman palvelun, tai kaistanleveystarve ylittää 10 Gbps. Silloin kannattaa harkita useaa suurempaa NAT-instanssia tai palata takaisin NAT Gatewayn pariin. Muista myös patchayksestä huolehtiminen. NAT Gateway on täysin hallittu, fck-nat ei ole.

Single-AZ vs. multi-AZ NAT: hyväksyttävä riski

Multi-AZ-NAT on tuotannossa perusteltu: jos yksi AZ menee alas, muiden AZ:iden yksityiset instanssit menettävät internet-yhteyden. Non-prod-ympäristöissä tämä riski on kuitenkin lähes olematon. Suosittelen konsolidointia yhteen AZ:hen kaikille dev/staging/QA-VPC:ille. Säästö on 66 % kiinteistä kuluista, eli noin 65 $/kk per VPC.

Toteutus on yksinkertainen: luo NAT Gateway vain yhteen julkiseen aliverkkoon ja päivitä kaikkien yksityisten aliverkkojen reititystaulukot osoittamaan siihen. Terraformissa muutos on kaksi riviä.

resource "aws_nat_gateway" "single" {
  count         = var.environment == "prod" ? length(var.azs) : 1
  subnet_id     = aws_subnet.public[count.index].id
  allocation_id = aws_eip.nat[count.index].id
}

resource "aws_route" "private_nat" {
  count                  = length(var.azs)
  route_table_id         = aws_route_table.private[count.index].id
  destination_cidr_block = "0.0.0.0/0"
  nat_gateway_id         = var.environment == "prod" \
                             ? aws_nat_gateway.single[count.index].id \
                             : aws_nat_gateway.single[0].id
}

Vertaa tätä lähestymistapaa AWS Organizationsin monitilihallinnan kanssa: kun ei-tuotantotilit on eristetty omaan OU:hun, voit ajaa SCP-käytännön, joka rajoittaa NAT Gateway -luomista non-prod-tileillä yhteen per VPC. Yksi ohjaus, joka estää kalliin virheen jo etukäteen.

Cross-AZ-liikenne: kaksinkertainen lasku

Kun EC2-instanssi AZ:ssa eu-west-1a lähettää dataa NAT Gatewaylle AZ:ssa eu-west-1b, maksat sekä NAT-käsittelymaksun (0,045 $/GB) että cross-AZ-tiedonsiirron (0,01 $/GB per suunta = 0,02 $/GB). Yhteensä 0,065 $/GB, mikä on 44 % enemmän kuin same-AZ-liikenne.

Tästä syystä jokaisessa AZ:ssa tuotannossa pitää olla oma NAT Gateway. Reititystaulukoiden tulee myös ohjata liikenne aina saman AZ:n NAT Gatewaylle. Yleinen virhe on jakaa yksi reititystaulukko kaikille yksityisille aliverkoille. Silloin liikenne satunnaisesti oikaisee toiseen AZ:hen ja lasku kasvaa hiljaa.

Tarkista tämä komennolla:

aws ec2 describe-route-tables \
  --filters "Name=vpc-id,Values=vpc-0abc123" \
  --query 'RouteTables[*].[RouteTableId,Associations[*].SubnetId,Routes[?NatGatewayId!=null].NatGatewayId]'

Jos yksi reititystaulukko on assosioitu useaan AZ:aan kuuluvaan aliverkkoon, korjaa se välittömästi. Tiedonsiirtokustannusten optimointi laajemmin kuvaa saman logiikan muille pilviverkoille.

Terraform-esimerkki: optimoitu VPC-rakenne

Alla minimaalinen tuotantovalmis VPC, joka yhdistää kaikki edellä käydyt optimoinnit: per-AZ NAT Gateway tuotannolle, single-AZ non-prodille, Gateway Endpoint S3:lle ja DynamoDB:lle, sekä Interface Endpoint ECR:lle ja Secrets Managerille. Rakenteen kloonaus tuottaa 40–70 % pienemmän NAT-laskun heti.

locals {
  is_prod = var.environment == "prod"
  interface_services = [
    "ecr.api", "ecr.dkr", "secretsmanager",
    "ssm", "logs", "monitoring"
  ]
}

# Gateway Endpointit – ilmaisia
resource "aws_vpc_endpoint" "gateway" {
  for_each          = toset(["s3", "dynamodb"])
  vpc_id            = aws_vpc.main.id
  service_name      = "com.amazonaws.${var.region}.${each.value}"
  vpc_endpoint_type = "Gateway"
  route_table_ids   = aws_route_table.private[*].id
}

# Interface Endpointit – maksullisia, vain kun volyymi > 1 TB/kk
resource "aws_vpc_endpoint" "interface" {
  for_each            = toset(local.interface_services)
  vpc_id              = aws_vpc.main.id
  service_name        = "com.amazonaws.${var.region}.${each.value}"
  vpc_endpoint_type   = "Interface"
  subnet_ids          = aws_subnet.private[*].id
  private_dns_enabled = true
  security_group_ids  = [aws_security_group.vpce.id]
}

# NAT Gateway – per-AZ prodissa, single-AZ muualla
resource "aws_nat_gateway" "this" {
  count         = local.is_prod ? length(var.azs) : 1
  subnet_id     = aws_subnet.public[count.index].id
  allocation_id = aws_eip.nat[count.index].id
  tags = {
    Environment = var.environment
    CostCenter  = var.cost_center
  }
}

Kun tämä on käytössä, jäljelle jäävä NAT-liikenne on käytännössä vain kolmannen osapuolen API-kutsuja (Datadog, Stripe, GitHub API). Se on lähtökohtaisesti perusteltua liikennettä, jota ei voi kiertää AWS-tuotteilla. Jos noiden osuus on merkittävä, harkitse reverse proxy -mallia CloudFrontin tai Global Acceleratorin kautta, mutta se on kokonaan oman artikkelinsa aihe.

Usein kysytyt kysymykset

Kuinka paljon AWS NAT Gateway maksaa kuukaudessa?

Yksi NAT Gateway maksaa noin 32,85 $/kk pelkästä olemassaolostaan (0,045 $/h) plus 0,045 $ jokaisesta läpi kulkevasta gigatavusta. Kolmen AZ:n asennus 10 TB:n liikenteellä maksaa siis noin 98,55 $ + 450 $ = 548,55 $/kk, ennen normaaleja egress-maksuja internetiin.

Miten NAT Gatewayn voi korvata halvemmalla?

Kolme päätapaa: 1) VPC Gateway Endpoint S3- ja DynamoDB-liikenteelle (ilmainen), 2) Interface Endpoint (PrivateLink) muille AWS-palveluille kun liikenne ylittää ~626 GB/kk per palvelu, 3) fck-nat EC2-pohjainen NAT non-prod-ympäristöissä (noin 4 $/kk).

Mitä eroa on VPC Gateway Endpointilla ja Interface Endpointilla?

Gateway Endpoint tukee vain S3:a ja DynamoDB:tä, on ilmainen ja toimii reititystaulukkoon lisättynä reittinä. Interface Endpoint (PrivateLink) tukee yli 200 palvelua, käyttää ENI:tä yksityisessä aliverkossa ja maksaa 0,01 $/h per AZ + 0,01 $/GB. Käytä aina Gateway Endpointia kun mahdollista.

Kannattaako non-prod-ympäristössä käyttää yhtä NAT Gatewaytä?

Kyllä. Kolmen AZ:n redundanssi maksaa noin 100 $/kk pelkkinä tuntimaksuina, ja non-prod-ympäristössä yhden AZ:n vika ei aiheuta liiketoimintavaikutusta. Konsolidointi yhteen AZ:hen säästää 66 % kiinteistä kuluista ja on triviaali muutos Terraformissa.

Miten löydän mikä palvelu syö eniten NAT Gateway -liikennettä?

Aktivoi VPC Flow Logs ja aja Athena-kysely, joka ryhmittelee NAT Gatewayn ENI:n liikenteen kohde-IP:n mukaan. Käänteinen DNS-haku (dig -x) paljastaa palvelut. Yleisimmät syypäät ovat S3, ECR ja kolmannen osapuolen API:t kuten Datadog tai Segment.