NAT-gateway og private undernet

Ressourcer i private subnets har kun private IP-adresser og ingen rute til en Internet Gateway, så de kan ikke starte udgående forbindelser til internettet. Men de skal ofte have adgang til internettet for at downloade OS-rettelser, hente Docker-images, kalde tredjeparts-API'er eller opdatere software. Løsningen er at dirigere trafik fra det private subnet gennem en enhed, der har internetadgang og udfører NAT (Network Address Translation), så de private IP-adresser skjules bag en offentlig IP-adresse. AWS tilbyder to muligheder: NAT Gateway (administreret) og en selvadministreret NAT Instance (ældre løsning).

En NAT Gateway er en fuldt administreret tjeneste med høj tilgængelighed, der gør det muligt for instanser i private subnets at starte udgående forbindelser til internettet, samtidig med at uopfordret indgående trafik blokeres. Den findes i et offentligt subnet, har en Elastic IP og skalerer automatisk op til 100 Gbps båndbredde. Du behøver aldrig at patche, skalere eller administrere den underliggende infrastruktur. NAT Gateway oversætter den private kilde-IP-adresse for udgående pakker til sin egen EIP og sender derefter svarene tilbage til den oprindelige private IP-adresse.

Efter du har oprettet en NAT Gateway, skal du tilføje en rute til det private undernets routingtabel: destination 0.0.0.0/0 → NAT Gateway-id. Det fortæller al internetbundtet trafik fra instanser i det private undernet, at den skal gå til NAT Gateway, som derefter videresender den gennem Internet Gateway til internettet. R outingtabellen har stadig den lokale VPC-rute (f.eks. 10.0.0.0/16 → local) til intern trafik. Uden denne rute har instanser i det private undernet stadig ingen internetadgang, selv om der er implementeret en NAT Gateway.

En NAT Gateway er specifik for en AZ—den håndterer kun trafik fra undernet i den samme AZ. For høj tilgængelighed skal du implementere én NAT Gateway pr. AZ og oprette private routingt abeller, der er specifikke for hver AZ: Den private routingtabel i AZ-a sender 0.0.0.0/0 til NAT-GW i AZ-a, og den private routingtabel i AZ-b sender trafikken til NAT-GW i AZ-b. Det undgår gebyrer for dataoverførsel mellem AZ'er og sikrer, at instanserne i AZ-b (med deres egen NAT) fortsat har internetadgang, hvis AZ-a svigter.

En NAT Instance er en selvadministreret EC2-instans, der kører et NAT AMI—den ældre tilgang fra før NAT Gateways fandtes. NAT Instances kræver, at du deaktiverer kilde-/destinationskontrollen på EC2-instansen, administrerer båndbredde og skalering, installerer rettelser til operativsystemet og håndterer fejl. De er billigere til anvendelser med meget lav båndbredde og kan bruges som bastionværter. NAT Gateways er det anbefalede valg i produktion: fuldt administrerede, skaleres automatisk, har en tilgængeligheds-SLA på 99,99 % inden for en AZ, og kræver ingen installation af rettelser. Eksamen har historisk testet denne sammenligning.

Prisen for NAT Gateway består af to dele: en timepris pr. NAT Gateway (ca. 0,045 USD/time i us-east-1, omkring 32 USD/måned) og et databehandlingsgebyr pr. GB (ca. 0,045 USD/GB i us-east-1). For arbejdsbelastninger, der overfører store datamængder gennem NAT (f.eks. hentning af store containerafbildninger eller massehentninger), kan databehandlingsomkostningen blive den største udgift. Optimér NAT-omkostningerne ved at sende S3- og DynamoDB-trafik gennem VPC Gateway Endpoints (omgår NAT helt og er gratis) og ved at sende AWS API-kald gennem VPC Interface Endpoints i stedet for gennem NAT.

Databaseinstanser i private undernet bør ikke sende trafik gennem NAT Gateway—de har ingen grund til at oprette forbindelser til internettet. Databaser skal kun modtage forbindelser fra applikationslaget (inden for VPC'en) og eventuelt få adgang til AWS-tjenester som S3 (til eksport og import) via et VPC-endpoint. RDS er en administreret tjeneste, så du installerer ikke rettelser til operativsystemet direkte i forbindelse med rettelser og opdateringer af databasen. Til selvadministrerede databaser på EC2 skal du bruge Systems Manager Patch Manager, som kan installere rettelser via SSM uden internetadgang, hvis du har konfigureret SSM VPC-endpointet.

NAT Gateway leverer tilstandsbevarende, kun udgående NAT: Den tillader udgående forbindelser, der er startet indefra, samt deres svar, men blokerer alle uopfordrede indgående forbindelser. Den er ikke en firewall—den inspicerer eller filtrerer ikke trafikindhold. Til filtrering af udgående trafik (f.eks. kun at tillade bestemte destinationsdomæner eller IP-adresser fra private undernet) har du brug for yderligere kontroller: AWS Network Firewall implementeret i VPC'en eller en firewall-appliance fra en tredjepart bag en Gateway Load Balancer. Sikkerhedsgrupper og NACL'er gælder stadig for instanser i private undernet uanset NAT.

Ud over offentlige NAT Gateways (med EIP'er til internetadgang) understøtter AWS private NAT Gateways uden en EIP. Private NAT Gateways bruges til at oversætte private IP-adresser for trafik mellem VPC'er eller mellem en VPC og lokale netværk, når CIDR-intervaller overlapper. Hvis VPC-A (10.0.0.0/16) f.eks. skal kommunikere med et lokalt netværk, der også bruger 10.0.0.0/16, oversætter en privat NAT Gateway i VPC-A kilde-IP-adresserne til et ikke-overlappende interval, før trafikken routes gennem en Transit Gateway til det lokale netværk.

Overvåg NAT Gateways tilstand og ydeevne via CloudWatch-målepunkter. Vigtige målepunkter er: ActiveConnectionCount (det aktuelle antal aktive TCP-forbindelser gennem NAT), BytesInFromDestination / BytesInFromSource (dataoverførsel i begge retninger), PacketDropCount (tabte pakker—angiver begrænsninger på båndbredden eller fejl) og ErrorPortAllocation (NAT har opbrugt porttildelinger—kan angive, at der er opbrugt porte på grund af for mange forbindelser). Hver NAT Gateway understøtter op til 55.000 samtidige forbindelser pr. unik destination; derefter kan forbindelser blive droppet.

Ikke alle arbejdsbelastninger i private undernet har brug for en NAT Gateway. Overvej adgangsmønstret: Hvis instanserne kun har brug for at kommunikere med andre VPC-ressourcer og AWS-tjenester, der er tilgængelige via VPC-endpoints (S3, DynamoDB, SSM, ECR, Secrets Manager), kan du helt fjerne NAT Gateway og dermed spare ca. 32 USD/måned pr. AZ samt databehandlingsgebyrer. Dette er det ideelle mønster for fuldt private mikrotjenester, der bruger VPC Interface Endpoints til al adgang til AWS-tjenester. Gennemgå hver tjeneste, som instanserne kalder, og kontrollér, om et gratis Gateway Endpoint eller et betalt Interface Endpoint kan erstatte NAT.

I denne lektion har du lært, at NAT Gateways giver instanser i private undernet udgående internetadgang ved at oversætte deres private IP-adresser til en Elastic IP, at du skal tilføje en 0.0.0.0/0-rute i det private undernets routingtabel, som peger på NAT Gateway, og at du skal implementere én NAT Gateway pr. AZ for at opnå høj tilgængelighed og undgå dataomkostninger på tværs af AZ'er. Næste emne er en sammenligning af Network ACL'er og Security Groups for lagdelt VPC-forsvar.