Sikring af Lambda med VPC

Som standard kører AWS Lambda-funktioner i et sikkert, administreret AWS-netværk. Nogle gange har din Lambda-funktion dog brug for adgang til ressourcer, der ikke er offentligt tilgængelige, f.eks. en privat database eller en intern tjeneste.

I denne lektion undersøger vi, hvordan du placerer dine Lambda-funktioner i en Virtual Private Cloud (VPC) for at opnå bedre netværkskontrol og adgang til private ressourcer.

En AWS-Virtual Private Cloud (VPC) er som dit eget isolerede, virtuelle netværk i AWS-skyen. Du definerer dets IP-adresseområde, undernet, routingtabeler og netværksgateways.

• Undernet: Opdelinger i din VPC, hvor du starter ressourcer. De kan være offentlige (med internetadgang) eller private (uden direkte internetadgang).
• Sikkerhedsgrupper: Fungerer som virtuelle firewalls, der styrer indgående og udgående trafik for dine ressourcer.

Når du opretter en Lambda-funktion uden at konfigurere VPC-indstillinger, kører den i et administreret netværksmiljø, der ejes af AWS. I denne standardopsætning har din Lambda-funktion direkte adgang til det offentlige internet og andre AWS-tjenester (som S3 og DynamoDB) via deres offentlige slutpunkter.

Den kan dog ikke få direkte adgang til ressourcer i dine private VPC-undernet.

Den primære grund til at placere en Lambda-funktion i en VPC er at give den mulighed for at oprette sikker forbindelse til private ressourcer i din VPC. Almindelige scenarier omfatter:

• Adgang til en Amazon RDS-instans (Relational Database Service) i et privat undernet.
• Forbindelse til en Amazon ElastiCache-klynge.
• Adgang til private EC2-instanser eller containere.
• Kommunikation med interne API'er eller tjenester, der ikke er eksponeret på det offentlige internet.

Når du konfigurerer Lambda til VPC, angiver du to hovedkomponenter:

• Undernet: Du skal vælge mindst to private undernet i forskellige tilgængelighedszoner for at opnå høj tilgængelighed. Lambda opretter et Elastic Network Interface (ENI) i disse undernet.
• Sikkerhedsgrupper: Du knytter en eller flere sikkerhedsgrupper til din Lambda-funktion. De styrer netværkstrafikken til og fra ENI'et, så det kan kommunikere med dine private ressourcer.

Du kan knytte din Lambda-funktion til en VPC via AWS Management Console, AWS CLI eller værktøjer til Infrastructure as Code som AWS SAM eller CloudFormation. Her er en konceptuel AWS CLI-kommando til opdatering af en funktions VPC-konfiguration:

Det fortæller Lambda, at den skal klargøre netværksgrænseflader i de angivne undernet og anvende sikkerhedsgrupperne, så den kan oprette forbindelse til ressourcer i den pågældende VPC.

Et vigtigt punkt: Når du placerer en Lambda-funktion i private undernet i en VPC, mister den sin standardadgang til det offentlige internet.

Hvis din Lambda-funktion skal have adgang til eksterne tjenester (f.eks. et tredjeparts-API eller en anden AWS-tjeneste via dens offentlige slutpunkt), mens den er i et privat undernet, skal du dirigere dens udgående trafik gennem en NAT Gateway i et offentligt undernet. Det giver internetadgang uden at eksponere din Lambda-funktion direkte.

For at din Lambda-funktion kan oprette forbindelse til en VPC, skal dens eksekveringsrolle have bestemte tilladelser i AWS Identity and Access Management (IAM). Disse tilladelser gør det muligt for Lambda at oprette og administrere de nødvendige Elastic Network Interfaces (ENI'er) i din VPC.

• ec2:CreateNetworkInterface
• ec2:DeleteNetworkInterface
• ec2:DescribeNetworkInterfaces

Uden disse tilladelser kan funktionen ikke knyttes til VPC'en.

Når du har konfigureret din Lambda-funktion til VPC-adgang, er det vigtigt at teste forbindelsen. Du kan:

• Kal­d funktionen: Udløs din Lambda-funktion, og kontrollér dens CloudWatch-logge.
• Kontrollér fejl: Se efter netværksrelaterede fejl, hvis forbindelsen til din private ressource mislykkes.
• Bekræft forbindelsen: Hvis det lykkes, bør loggene vise tegn på kommunikation med din private database eller tjeneste.

Selvom det giver betydelige fordele at placere Lambda i en VPC, medfører det også nogle overvejelser:

• Længere cold-start-tider: De første kald til Lambda-funktioner med VPC kan undertiden være langsommere på grund af den tid, det tager at konfigurere ENI'et.
• Udgifter til NAT Gateway: Hvis din Lambda-funktion har brug for udgående internetadgang, medfører en NAT Gateway ekstra omkostninger.
• Netværkskompleksitet: Administration af undernet, routing og sikkerhedsgrupper tilføjer et ekstra lag af netværkskompleksitet.

Vi har lært, at konfiguration af Lambda-funktioner i en VPC er afgørende for sikker adgang til private netværksressourcer. Det indebærer valg af private undernet og sikkerhedsgrupper samt forståelse af konsekvenserne for internetadgang (som kræver en NAT Gateway).

Selvom det tilføjer netværkskompleksitet og mulig ekstra cold-start-tid, er VPC-integration afgørende for at bygge sikre, datadrevne serverløse applikationer, der interagerer med private AWS-tjenester.