Sikring av Lambda med VPC

Som standard kjører AWS Lambda-funksjoner i et sikkert, administrert AWS-nettverk. Noen ganger trenger imidlertid Lambda tilgang til ressurser som ikke er offentlig tilgjengelige, for eksempel en privat database eller en intern tjeneste.

I denne leksjonen ser vi på hvordan De kan plassere Lambda-funksjonene Deres i en Virtual Private Cloud (VPC) for å få bedre nettverkskontroll og tilgang til private ressurser.

En AWS-Virtual Private Cloud (VPC) er som Deres eget isolerte, virtuelle nettverk i AWS-skyen. De definerer IP-adresseområdet, subnettene, rutetabellene og nettverksgatewayene.

• Subnets: Inndelinger i VPC-en der De starter ressurser. De kan være public (med internettilgang) eller private (uten direkte internettilgang).
• Security Groups: Fungerer som virtuelle brannmurer som kontrollerer innkommende og utgående trafikk for ressursene Deres.

Når De oppretter en Lambda-funksjon uten å konfigurere VPC-innstillinger, kjører den i et administrert nettverksmiljø som eies av AWS. I dette standardoppsettet har Lambda-funksjonen direkte tilgang til det offentlige internettet og andre AWS-tjenester (som S3 og DynamoDB) via deres offentlige endepunkter.

Den kan imidlertid ikke få direkte tilgang til ressurser i private VPC-subnett.

Hovedgrunnen til å plassere en Lambda-funksjon i en VPC er å gi den sikker tilkobling til private ressurser i VPC-en. Vanlige scenarioer omfatter:

• Tilgang til en Amazon RDS-instans (Relational Database Service) i et privat subnett.
• Tilkobling til en Amazon ElastiCache-klynge.
• Tilgang til private EC2-instanser eller containere.
• Kommunikasjon med interne API-er eller tjenester som ikke er eksponert mot det offentlige internettet.

Når De konfigurerer Lambda for VPC, angir De to hovedkomponenter:

• Subnets: De må velge minst to private subnets i ulike Availability Zones for høy tilgjengelighet. Lambda oppretter et Elastic Network Interface (ENI) i disse subnettene.
• Security Groups: De knytter én eller flere security groups til Lambda-funksjonen. Disse kontrollerer nettverkstrafikken til og fra ENI-et, slik at det kan kommunisere med de private ressursene Deres.

De kan knytte Lambda-funksjonen Deres til en VPC via AWS Management Console, AWS CLI eller verktøy for Infrastructure as Code, som AWS SAM eller CloudFormation. Her er en konseptuell AWS CLI-kommando for å oppdatere en funksjons VPC-konfigurasjon:

Dette instruerer Lambda om å klargjøre nettverksgrensesnitt i de angitte subnettene og bruke security groups, slik at funksjonen kan koble seg til ressurser i denne VPC-en.

Et viktig poeng er at når De plasserer en Lambda-funksjon i private subnets i en VPC, mister den sin standardtilgang til det offentlige internettet.

Hvis Lambda trenger tilgang til eksterne tjenester (for eksempel et tredjeparts-API eller en annen AWS-tjeneste via det offentlige endepunktet) mens den befinner seg i et privat subnett, må De rute den utgående trafikken gjennom en NAT Gateway i et offentlig subnett. Dette gir internettilgang uten å eksponere Lambda direkte.

For at Lambda-funksjonen Deres skal kunne koble seg til en VPC, trenger kjøringsrollen bestemte AWS Identity and Access Management (IAM)-tillatelser. Disse tillatelsene gjør det mulig for Lambda å opprette og administrere de nødvendige Elastic Network Interfaces (ENI-er) i VPC-en.

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

Uten disse tillatelsene vil funksjonen ikke kunne knyttes til VPC-en.

Etter at De har konfigurert Lambda-funksjonen for VPC-tilgang, er det viktig å teste tilkoblingen. De kan:

• Kalle funksjonen: Utløs Lambda-funksjonen og kontroller CloudWatch-loggene.
• Se etter feil: Se etter nettverksrelaterte feil hvis funksjonen ikke kan koble seg til den private ressursen.
• Bekrefte tilkoblingen: Hvis testen lykkes, bør loggene vise tegn på samhandling med den private databasen eller tjenesten.

Selv om det gir betydelige fordeler å plassere Lambda i en VPC, medfører det også noen hensyn:

• Lengre cold start-tider: De første kjøringene av Lambda-funksjoner med VPC kan noen ganger være tregere på grunn av tiden det tar å konfigurere ENI-et.
• Kostnader for NAT Gateway: Hvis Lambda trenger utgående internettilgang, medfører en NAT Gateway ekstra kostnader.
• Nettverkskompleksitet: Administrasjon av subnett, ruting og security groups tilfører et ekstra lag med nettverkskompleksitet.

Vi har lært at konfigurering av Lambda-funksjoner i en VPC er avgjørende for sikker tilgang til private nettverksressurser. Dette innebærer å velge private subnett og security groups, samt å forstå konsekvensene for internettilgang (som krever en NAT Gateway).

Selv om dette tilfører nettverkskompleksitet og potensielt mer overhead ved cold start, er VPC-integrasjon viktig for å bygge sikre, datadrevne serverløse applikasjoner som samhandler med private AWS-tjenester.