Serverløs utvikling med AWS Lambda · leksjon

Lambda i en VPC for private ressurser

Forstå hvordan De konfigurerer Lambda-funksjoner til å kjøre i en VPC, slik at de får sikker tilgang til private ressurser som databaser og interne tjenester

Leksjon 1 av 412 trinn

Lambda i en VPC for private ressurser er en gratis leksjon i Serverløs utvikling med AWS Lambda på CoddyKit. Dette er leksjon 1 av 4. Du kan lese hele leksjonen gratis nedenfor – og deretter øve praktisk i nettleseren med en innebygd kodeeditor og en AI-veileder som er tilgjengelig døgnet rundt. Den er en del av læringsløpet i Serverløs utvikling med AWS Lambda, og fremdriften din synkroniseres mellom nettet og CoddyKit-appen. Kurset i Serverløs utvikling med AWS Lambda inneholder totalt 4 leksjoner.

Hvorfor Lambda trenger en VPC

Som standard kjører AWS Lambda-funksjoner i et nettverk som administreres av AWS. Dette nettverket gir internettilgang, men isolerer funksjonen din fra dine private AWS-ressurser.

For å få sikker tilgang til ressurser som databaser (for eksempel Amazon RDS eller DynamoDB-tabeller i en VPC) eller interne tjenester som ikke er offentlig tilgjengelige, må Lambda-funksjonen kjøre i din egen Virtual Private Cloud (VPC).

Din private sky

En Virtual Private Cloud (VPC) er som ditt eget isolerte, private nettverk i AWS. Du definerer IP-adresseområdet, subnettene og nettverksgatewayene.

  • Subnett: Inndelinger i VPC-en. Private subnett brukes til ressurser som ikke bør være offentlig tilgjengelige.
  • Sikkerhetsgrupper: Fungerer som virtuelle brannmurer som kontrollerer inn- og utgående trafikk for ressurser i VPC-en.

Tilgang til private ressurser

Se for deg at du har en database som inneholder sensitive kundedata. Du ønsker ikke at den skal være eksponert mot det offentlige internett.

Hvis Lambda-funksjonen din må lese fra eller skrive til en slik database, koble til en EC2-instans eller et internt API-endepunkt som bare finnes i VPC-en din, må Lambda-funksjonen også plasseres i denne VPC-en.

Lambdas nettverksgrensesnitt

Når du konfigurerer en Lambda-funksjon til å kjøre i en VPC, oppretter AWS et Elastic Network Interface (ENI) for funksjonen i de angitte subnettene.

Dette ENI-et gir Lambda-funksjonen en privat IP-adresse og gjør det mulig å kommunisere med andre ressurser i VPC-en, på samme måte som en EC2-instans.

Subnett og sikkerhetsgrupper

Når du kobler Lambda til en VPC, angir du:

  • Subnett: Minst to private subnett i ulike Availability Zones for høy tilgjengelighet. Lambda-funksjonene distribueres på tvers av disse.
  • Sikkerhetsgrupper: Én eller flere sikkerhetsgrupper som kontrollerer hvilken nettverkstrafikk som er tillatt til og fra Lambda-funksjonen. Sørg for at de tillater kommunikasjon med de private ressursene dine.

Koble Lambda til en VPC

I AWS Management Console finner du en "VPC"-seksjon under "Advanced settings" eller "Configuration" når du oppretter eller konfigurerer en Lambda-funksjon.

Her velger du ønsket VPC, minst to subnett (for redundans) og passende sikkerhetsgrupper. AWS håndterer opprettelsen av ENI automatisk.

En funksjon klar for VPC

Denne enkle Python-Lambda-funksjonen kobler seg ikke faktisk til en database, men viser strukturen til en funksjon som kan kjøre i en VPC og samhandle med private ressurser. Hvis den var i en VPC, kunne den opprettet en tilkobling til en privat database.

Prøv å kjøre dette eksempelet:

import json

def lambda_handler(event, context):
    # This function would typically connect to a private resource
    # if configured within a VPC.
    # For example:
    # import pymysql # Database connector
    # conn = pymysql.connect(host='your-private-db-endpoint', user='admin', password='password', database='mydatabase')
    # with conn.cursor() as cursor:
    #     cursor.execute("SELECT * FROM users")
    #     result = cursor.fetchall()

    message = "Hello from a Lambda function in a VPC context!"
    print(message)

    return {
        'statusCode': 200,
        'body': json.dumps(message)
    }

Utgående internettilgang fra VPC

Hvis Lambda-funksjonen din i et privat subnett trenger tilgang til internett (for eksempel for å kalle eksterne API-er eller hente oppdateringer), har den ikke direkte tilgang.

Du trenger en NAT Gateway (Network Address Translation Gateway) distribuert i et offentlig subnett i VPC-en din. Trafikk fra de private subnettene rutes gjennom NAT Gateway for å nå internett.

VPC-endepunkter for AWS-tjenester

For å få tilgang til bestemte AWS-tjenester (som S3, DynamoDB og SQS) fra en Lambda-funksjon i et privat subnett kan du bruke VPC Endpoints i stedet for en NAT Gateway.

VPC Endpoints lar Lambda kommunisere privat med disse tjenestene uten å gå via det offentlige internettet, noe som kan være sikrere og mer kostnadseffektivt.

Viktige hensyn

Selv om det gir mange muligheter, har det konsekvenser å kjøre Lambda i en VPC:

  • Kalde starter: Tiden Lambda bruker på å opprette et ENI, kan noen ganger øke forsinkelsen ved kalde starter.
  • Håndtering av IP-adresser: Hvert ENI bruker en privat IP-adresse fra subnettet, så sørg for at du har tilstrekkelig med IP-adresser.
  • Nettverksoverhead: Administrasjon av subnett, sikkerhetsgrupper og eventuelle NAT Gateway-er gjør konfigurasjonen mer kompleks.

Rask kontroll: Fordeler med VPC

Du har lært hvorfor og hvordan Lambda-funksjoner kan kjøre i en VPC. La oss teste forståelsen din.

Oppsummering av leksjonen

I denne leksjonen har du lært at konfigurering av Lambda-funksjoner i en VPC gjør at de kan få sikker tilgang til private ressurser som databaser og interne tjenester.

Vi har sett på hvordan Lambda bruker Elastic Network Interfaces (ENI-er) til å koble seg til subnett og sikkerhetsgrupper, samt hva du må ta hensyn til ved internettilgang (NAT Gateway) og privat tilgang til AWS-tjenester (VPC Endpoints). Dette oppsettet er avgjørende for å bygge sikre, serverløse applikasjoner på bedriftsnivå.

Gratis å komme i gang

Lær deg Serverløs utvikling med AWS Lambda med en AI-veileder – gratis

Skriv og kjør ekte kode i nettleseren, få umiddelbar hjelp fra en AI-veileder som er tilgjengelig døgnet rundt, og fortsett der du slapp – på nettet eller i appen.

Kurs
12
Leksjoner
48

Ofte stilte spørsmål

Er leksjonen «Lambda i en VPC for private ressurser» gratis?

Ja – hele teksten i «Lambda i en VPC for private ressurser» er gratis å lese her på nettet. For å øve interaktivt med en innebygd kodeeditor og en AI-veileder som er tilgjengelig døgnet rundt, og for å låse opp resten av Serverløs utvikling med AWS Lambda-kurset, kan du oppgradere til CoddyKit PRO. Kurset i Serverløs utvikling med AWS Lambda inneholder totalt 4 leksjoner.

Hva lærer jeg i «Lambda i en VPC for private ressurser»?

Forstå hvordan De konfigurerer Lambda-funksjoner til å kjøre i en VPC, slik at de får sikker tilgang til private ressurser som databaser og interne tjenester Du øver på Serverløs utvikling med AWS Lambda med praktisk kode som du kjører direkte i nettleseren, mens en AI-veileder som er tilgjengelig døgnet rundt, svarer på spørsmålene dine mens du jobber deg gjennom leksjonen.

Trenger jeg erfaring for å begynne med Serverløs utvikling med AWS Lambda?

Ingen tidligere erfaring er nødvendig. Serverløs utvikling med AWS Lambda på CoddyKit er lagt opp for både nybegynnere og viderekomne, så De kan begynne her eller helt fra start og lære i Deres eget tempo. Dette er leksjon 1 av 4.

Hvor lang tid tar leksjonen «Lambda i en VPC for private ressurser»?

De fleste CoddyKit-leksjoner tar omtrent 5–10 minutter. Hver leksjon er kort og interaktiv, slik at De gjør jevne fremskritt og kan fortsette akkurat der De slapp – både på nettet og i appen.

Kan jeg skrive og kjøre kode i denne Serverløs utvikling med AWS Lambda-leksjonen?

Ja. Alle Serverløs utvikling med AWS Lambda-leksjoner har en innebygd kodeeditor, slik at De kan skrive og kjøre ekte kode direkte i nettleseren og få umiddelbar tilbakemelding fra AI – uten lokal konfigurering.

Alle leksjonene i dette kurset

  1. Lambda i en VPC for private ressurser
  2. Tilgang til databaser i VPC
  3. Beste praksis for nettverkssikkerhet
  4. NAT-gatewayer og internettilgang fra en VPC
← Tilbake til Serverløs utvikling med AWS Lambda