NAT-gateway och privata subnät

När Ni har skapat en NAT Gateway lägger Ni till en route i routningstabellen för det privata subnätet: destination 0.0.0.0/0 → NAT Gateway-ID. Detta anger att all trafik från instanser i det privata subnätet som är avsedd för internet ska gå till NAT Gateway, som sedan vidarebefordrar den via Internet Gateway till internet. Routningstabellen har fortfarande den lokala VPC-routen (t.ex. 10.0.0.0/16 → local) för intern trafik. Utan denna route har instanser i det privata subnätet fortfarande ingen internetåtkomst, även om en NAT Gateway har distribuerats.

En NAT Gateway är specifik för en AZ – den hanterar endast trafik från subnät i samma AZ. För hög tillgänglighet distribuerar Ni en NAT Gateway per AZ och skapar AZ-specifika routningstabeller för privata subnät: den privata routningstabellen i AZ-a dirigerar 0.0.0.0/0 till NAT-GW i AZ-a, och den privata routningstabellen i AZ-b dirigerar trafiken till NAT-GW i AZ-b. Detta undviker avgifter för dataöverföring mellan AZ:er och säkerställer att instanserna i AZ-b, med sin egen NAT, fortsätter att ha internetåtkomst om AZ-a slutar fungera.

En NAT Instance är en egenhanterad EC2-instans som kör en NAT AMI – den äldre lösningen från tiden innan NAT Gateways fanns. NAT Instances kräver att Ni inaktiverar source/destination check på EC2-instansen, hanterar bandbredd och skalning, installerar säkerhetsuppdateringar för operativsystemet och hanterar fel. De är billigare vid användningsfall med mycket låg bandbredd och kan användas som bastionvärdar. NAT Gateways är det rekommenderade valet i produktion: de är helt hanterade, skalas automatiskt, har ett tillgänglighets-SLA på 99,99 % inom en AZ och kräver inga säkerhetsuppdateringar. På provet har denna jämförelse traditionellt testats.

Prissättningen för NAT Gateway består av två delar: en timkostnad per NAT Gateway (cirka 0,045 USD/timme i us-east-1, ungefär 32 USD/månad) och en databehandlingsavgift per GB (cirka 0,045 USD/GB i us-east-1). För arbetsbelastningar som överför stora datamängder via NAT, till exempel hämtning av stora containeravbildningar eller massnedladdningar, kan kostnaden för databehandling bli den största kostnadsposten. Optimera NAT-kostnaderna genom att dirigera S3- och DynamoDB-trafik via VPC Gateway Endpoints (kringgår NAT helt och är kostnadsfria) och AWS API-anrop via VPC Interface Endpoints i stället för via NAT.

Databasinstanser i privata subnät bör inte dirigeras via NAT Gateway – de har inget behov av att initiera anslutningar till internet. Databaser behöver endast ta emot anslutningar från applikationslagret (inom VPC:n) och eventuellt nå AWS-tjänster som S3 (för export och import) via en VPC-endpoint. RDS är en hanterad tjänst, så vid korrigeringar och uppdateringar av databasen installerar Ni inte operativsystemets säkerhetsuppdateringar direkt. För egenhanterade databaser på EC2 använder Ni Systems Manager Patch Manager, som kan installera uppdateringar via SSM utan internetåtkomst om SSM VPC-endpointen är konfigurerad.

NAT Gateway tillhandahåller tillståndsbaserad NAT endast för utgående trafik: den tillåter initierade utgående anslutningar och deras svar, men blockerar all oinitierad inkommande trafik. Den är inte en brandvägg och inspekterar eller filtrerar inte trafikinnehåll. För filtrering av utgående trafik, till exempel för att endast tillåta specifika destinationsdomäner eller IP-adresser från privata subnät, behöver Ni ytterligare kontroller: AWS Network Firewall distribuerad i VPC:n eller en brandväggsapparat från tredje part bakom en Gateway Load Balancer. Säkerhetsgrupper och NACL:er gäller fortfarande för instanser i privata subnät, oavsett NAT.

Utöver publika NAT Gateways (med EIP:er för internetåtkomst) stöder AWS privata NAT Gateways utan EIP. Privata NAT Gateways används för att översätta privata IP-adresser för trafik mellan VPC:er eller mellan en VPC och lokala nätverk när CIDR-intervallen överlappar. Om VPC-A (10.0.0.0/16) till exempel behöver kommunicera med ett lokalt nätverk som också använder 10.0.0.0/16, översätter en privat NAT Gateway i VPC-A käll-IP-adresserna till ett icke-överlappande intervall innan trafiken dirigeras via en Transit Gateway till det lokala nätverket.

Övervaka NAT Gateways hälsa och prestanda via CloudWatch-mätvärden. Viktiga mätvärden är: ActiveConnectionCount (aktuella aktiva TCP-anslutningar genom NAT), BytesInFromDestination / BytesInFromSource (dataöverföring i båda riktningarna), PacketDropCount (bortkastade paket – kan indikera bandbreddsbegränsningar eller fel) och ErrorPortAllocation (NAT har slut på portallokeringar – kan indikera portbrist på grund av för många anslutningar). Varje NAT Gateway stöder upp till 55 000 samtidiga anslutningar per unik destination. Därefter kan anslutningar komma att tappas.

Alla arbetsbelastningar i privata subnät behöver inte en NAT Gateway. Ta hänsyn till åtkomstmönstret: om instanserna endast behöver kommunicera med andra VPC-resurser och AWS-tjänster som är åtkomliga via VPC-endpoints (S3, DynamoDB, SSM, ECR, Secrets Manager), kan Ni ta bort NAT Gateway helt och spara cirka 32 USD per månad och AZ samt databehandlingsavgifterna. Detta är det idealiska mönstret för helt privata mikrotjänster som använder VPC Interface Endpoints för all åtkomst till AWS-tjänster. Utvärdera varje tjänst som instanserna anropar och kontrollera om en kostnadsfri Gateway Endpoint eller en avgiftsbelagd Interface Endpoint kan ersätta NAT.

I den här lektionen har Ni lärt Er att: NAT Gateways möjliggör utgående internetåtkomst för instanser i privata subnät genom att översätta deras privata IP-adresser till en Elastic IP, Ni måste lägga till en 0.0.0.0/0-route i routningstabellen för det privata subnätet som pekar på NAT Gateway och Ni bör distribuera en NAT Gateway per AZ för att uppnå hög tillgänglighet och undvika dataavgifter mellan AZ:er. Härnäst jämför vi Network ACL:er och säkerhetsgrupper för lagerbaserat VPC-skydd.