Cloud & IT Cert Prep · Lektion

Listenerregler og sti-baseret routing

Skriv listenerregler på ALB'en for at dirigere forespørgsler til forskellige target groups ud fra hostheadere, stidern eller forespørgselsstrenge.

Lektion 3 af 413 trin

Listenerregler og sti-baseret routing er en gratis Cloud & IT Cert Prep-lektion på CoddyKit. Dette er lektion 3 af 4. Du kan læse hele lektionen gratis nedenfor — og derefter øve dig praktisk i browseren med en indbygget kodeeditor og en AI-vejleder, der er tilgængelig døgnet rundt. Den er en del af læringsforløbet i Cloud & IT Cert Prep, og dine fremskridt synkroniseres på tværs af nettet og CoddyKit-appen. Cloud & IT Cert Prep-kurset indeholder 4 lektioner i alt.

ALB-listenere forklaret

En ALB-listener er en proces, der kontrollerer forbindelsesanmodninger ved hjælp af en protokol og port, som du angiver (f.eks. HTTP på port 80 eller HTTPS på port 443). Hver listener har en eller flere regler, som bestemmer, hvor anmodninger skal videresendes, baseret på deres indhold.

En listener skal have en standardregel (standardhandlingen, når ingen anden regel matcher) og kan have op til 100 yderligere regler. Regler evalueres efter prioritet (laveste tal = højeste prioritet). Når en anmodning matcher en regels betingelse, anvendes den tilsvarende handling, og ingen yderligere regler evalueres.

# Create an HTTP listener on port 80
aws elbv2 create-listener \
  --load-balancer-arn arn:aws:elasticloadbalancing:us-east-1:123456789:loadbalancer/app/my-alb/abc123 \
  --protocol HTTP \
  --port 80 \
  --default-actions Type=forward,TargetGroupArn=arn:aws:elasticloadbalancing:us-east-1:123456789:targetgroup/default-tg/def456

Regelbetingelser

Listenerregler matcher anmodninger baseret på betingelser. Du kan kombinere flere betingelser i én regel (alle betingelser skal matche, for at reglen anvendes). Tilgængelige betingelsestyper:

host-header: matcher HTTP-headeren Host (f.eks. api.example.com)
path-pattern: matcher URL-stien (f.eks. /api/*, /images/*.jpg)
http-header: matcher ethvert HTTP-headernavn og -værdimønster
http-request-method: matcher HTTP-metoder (GET, POST, DELETE osv.)
query-string: matcher nøgleværdi-par i forespørgselsstrengen
source-ip: matcher klientens IP-CIDR-intervaller

Stibaseret routing

Stibaseret routing sender anmodninger til forskellige målgrupper baseret på URL-stien. Dette er det mest almindelige routingmønster for mikrotjenester bag en enkelt ALB. Eksempel på regler på én ALB:

Stien er /api/* → målgruppe: api-service
Stien er /images/* → målgruppe: image-processor
Stien er /admin/* → målgruppe: admin-app
Standard → målgruppe: frontend-app

Det gør det muligt for en enkelt ALB at stå foran flere adskilte tjenester uden behov for flere load balancere, hvilket reducerer omkostninger og DNS-kompleksitet.

# Create a path-based routing rule
aws elbv2 create-rule \
  --listener-arn arn:aws:elasticloadbalancing:us-east-1:123456789:listener/app/my-alb/abc123/lis456 \
  --priority 10 \
  --conditions Field=path-pattern,Values='/api/*' \
  --actions Type=forward,TargetGroupArn=arn:aws:elasticloadbalancing:us-east-1:123456789:targetgroup/api-service/xyz789

Værtsbaseret routing

Værtsbaseret routing dirigerer anmodninger baseret på HTTP-Host-headeren, så flere domænenavne (virtuelle værter) kan leveres fra en enkelt ALB. Eksempel:

Værten er api.example.com → målgruppe: api-service
Værten er admin.example.com → målgruppe: admin-app
Værten er www.example.com → målgruppe: frontend

Hvert domænenavn har sin egen CNAME- eller ALIAS-post, der peger på det samme ALB-DNS-navn, men ALB'en dirigerer hver anmodning til den relevante backend baseret på værtsheaderen. Værtsbaseret routing er ideel til SaaS-løsninger med flere lejere eller monolitiske applikationer, der opdeles i mikrotjenester.

# Create a host-based routing rule
aws elbv2 create-rule \
  --listener-arn arn:aws:elasticloadbalancing:us-east-1:123456789:listener/app/my-alb/abc123/lis456 \
  --priority 5 \
  --conditions '[{"Field":"host-header","HostHeaderConfig":{"Values":["api.example.com"]}}]' \
  --actions '[{"Type":"forward","TargetGroupArn":"arn:aws:elasticloadbalancing:us-east-1:123456789:targetgroup/api-service/xyz789"}]'

Regelhandlinger

Når en regels betingelser matcher, udfører ALB'en en af disse handlinger:

forward: videresend anmodningen til en eller flere målgrupper (med valgfri vægtning)
redirect: returner en HTTP-omdirigering (301 eller 302) til en ny URL; nyttigt til omdirigeringer fra HTTP til HTTPS
fixed-response: returner et statisk HTTP-svar med en angiven statuskode, indholdstype og brødtekst – nyttigt til vedligeholdelsessider eller enkle svar på sundhedstjek
authenticate-cognito: godkend brugere via en Cognito User Pool før videresendelse
authenticate-oidc: godkend brugere via en hvilken som helst OIDC-kompatibel identitetsudbyder

# Create a redirect rule: HTTP to HTTPS
aws elbv2 create-rule \
  --listener-arn arn:aws:elasticloadbalancing:us-east-1:123456789:listener/app/my-alb/abc123/http80 \
  --priority 1 \
  --conditions '[{"Field":"path-pattern","PathPatternConfig":{"Values":["/*"]}}]' \
  --actions '[{"Type":"redirect","RedirectConfig":{"Protocol":"HTTPS","Port":"443","StatusCode":"HTTP_301"}}]'

Mønster for omdirigering fra HTTP til HTTPS

Det mest almindelige listenerregel-mønster er at omdirigere HTTP til HTTPS:

Opret en HTTP-listener på port 80 med én regel: omdiriger al trafik (/*) til HTTPS med statuskoden 301
Opret en HTTPS-listener på port 443 med dine faktiske routingregler, der peger på målgrupper

Det sikrer, at brugere, der skriver http:// eller følger gamle HTTP-links, gennemsigtigt omdirigeres til HTTPS uden ændringer på applikationsniveau. Omdirigeringen håndteres udelukkende på load balancer-laget.

Handling med fast svar

Handlingen fixed-response returnerer et statisk HTTP-svar fra ALB'en uden at videresende anmodningen til noget mål. Brug den til:

at returnere en vedligeholdelsesside med status 503 for bestemte stier under vedligeholdelse
at levere et letvægts-slutpunkt til sundhedstjek direkte fra ALB'en (returnerer 200 OK med det samme uden belastning af backend)
at blokere bestemte stier med svaret 403 Forbidden

Faste svar er nyttige, når du midlertidigt vil tage stier ud af drift uden at ændre applikationskoden eller udrulle igen, fordi du dynamisk kan justere listenerreglerne.

# Return 503 maintenance page for a specific path
aws elbv2 create-rule \
  --listener-arn arn:aws:elasticloadbalancing:us-east-1:123456789:listener/app/my-alb/abc123/lis456 \
  --priority 20 \
  --conditions '[{"Field":"path-pattern","PathPatternConfig":{"Values":["/checkout/*"]}}]' \
  --actions '[{"Type":"fixed-response","FixedResponseConfig":{"StatusCode":"503","ContentType":"text/html","MessageBody":"<h1>Maintenance</h1>"}}]'

ALB-godkendelse med Cognito

ALB'ens authenticate-cognito-handling integreres med Amazon Cognito User Pools for at håndtere brugergodkendelse, før anmodninger videresendes til din applikation. Når en bruger uden godkendelse når en beskyttet listenerregel, omdirigerer ALB'en brugeren til den Cognito-hostede brugergrænseflade til login. Efter vellykket godkendelse indstiller ALB'en en krypteret cookie og videresender anmodningen med headere, der indeholder brugerens identitet.

Det flytter al godkendelseslogik væk fra din applikation. Din backend modtager headerne X-Amzn-Oidc-Identity, X-Amzn-Oidc-Data og X-Amzn-Oidc-Access-Token med den godkendte brugers claims.

Routing baseret på forespørgselsstreng og headere

ALB-lytterregler kan dirigere trafik baseret på parametre i forespørgselsstrengen og HTTP-headere, så du kan opnå meget præcis dirigering af forespørgsler:

Dirigér mobile klienter ved at registrere headeren User-Agent: *Mobile* og sende dem til en mobiloptimeret backend
Dirigér premium-API-forespørgsler ved at kontrollere den brugerdefinerede header X-API-Tier: premium og sende dem til en hurtigere målgruppe
Dirigér A/B-testvarianter ved at læse parameteren ?variant=beta i forespørgselsstrengen

Headerbaseret dirigering giver dig mulighed for at implementere funktionsflag og trafikopdeling på infrastrukturlaget uden at ændre applikationskoden.

Regelprioritet og evalueringsrækkefølge

Regler evalueres i stigende prioritetsrækkefølge. Regler med lavere prioritetsnumre evalueres først. Handlingen for den første regel, der matcher, udføres, og ingen efterfølgende regler evalueres. Standardreglen har ikke noget prioritetsnummer og evalueres altid sidst som opsamlingsregel.

Bedste praksis: Tildel prioritetsnumre med intervaller på 10 (10, 20, 30...) i stedet for fortløbende heltal. Det giver plads til at indsætte nye regler mellem eksisterende regler uden at omnummerere dem. Mere specifikke regler (f.eks. sti + vært-header) bør have lavere numre (højere prioritet) end generiske regler.

# List rules for a listener (shows priorities)
aws elbv2 describe-rules \
  --listener-arn arn:aws:elasticloadbalancing:us-east-1:123456789:listener/app/my-alb/abc123/lis456 \
  --query 'Rules[*].{Priority:Priority,Conditions:Conditions[0].Field,Actions:Actions[0].Type}' \
  --output table

Lytterregler til mikrotjenester

En enkelt ALB kan stå foran en hel mikrotjenesteplatform ved hjælp af lytterregler. Her er et eksempel fra virkeligheden, hvor alle tre betingelsestyper kombineres:

Prioritet 10: Vært=api.example.com + Sti=/v2/* → api-v2-målgruppe
Prioritet 20: Vært=api.example.com + Sti=/v1/* → api-v1-målgruppe
Prioritet 30: Vært=auth.example.com → auth-service-målgruppe
Prioritet 40: Vært=www.example.com + Sti=/static/* → CloudFront-omdirigering
Standard: Vært=www.example.com → frontend-målgruppe

Dette design reducerer omkostningerne ved at fjerne behovet for separate belastningsfordelere pr. tjeneste.

Hurtig kontrol

Test din forståelse af AWS Solutions Architect-koncepterne (SAA-C03) fra denne lektion.

Besvar den i den interaktive lektion

Opsummering af lektionen

I denne lektion har du lært, at lytterregler dirigerer forespørgsler baseret på vært, sti, headere, metoder og forespørgselsstrenge, at regler evalueres i prioritetsrækkefølge, hvor det første match vinder, og at handlinger omfatter videresendelse, omdirigering, fast svar og Cognito-godkendelse. Sti- og værtbaseret dirigering gør det muligt for en enkelt ALB at stå foran flere mikrotjenester. Næste emne er SSL-terminering og klæbrige sessioner.

Gratis at komme i gang

Lær Cloud & IT Cert Prep med en AI-underviser — gratis

Skriv og kør rigtig kode i din browser, få øjeblikkelig hjælp fra en AI-underviser døgnet rundt, og fortsæt, hvor du slap, på web eller i appen.

Kurser: 150
Lektioner: 600

Start gratis Se hele kurset

Ofte stillede spørgsmål

Er lektionen “Listenerregler og sti-baseret routing” gratis?

Ja — hele teksten til “Listenerregler og sti-baseret routing” kan læses gratis her på nettet. Hvis du vil øve dig interaktivt med en indbygget kodeeditor og en AI-vejleder døgnet rundt og få adgang til resten af Cloud & IT Cert Prep-kurset, skal du opgradere til CoddyKit PRO. Cloud & IT Cert Prep-kurset indeholder 4 lektioner i alt.

Hvad lærer jeg i “Listenerregler og sti-baseret routing”?

Skriv listenerregler på ALB'en for at dirigere forespørgsler til forskellige target groups ud fra hostheadere, stidern eller forespørgselsstrenge. Du øver dig i Cloud & IT Cert Prep med praktisk kode, som du kører direkte i browseren, og en AI-vejleder døgnet rundt besvarer dine spørgsmål, mens du arbejder dig gennem lektionen.

Skal jeg have erfaring for at begynde på Cloud & IT Cert Prep?

Der kræves ingen tidligere erfaring. Cloud & IT Cert Prep på CoddyKit er tilrettelagt for både begyndere og øvede, så du kan starte her eller fra begyndelsen og lære i dit eget tempo. Dette er lektion 3 af 4.

Hvor lang tid tager lektionen “Listenerregler og sti-baseret routing”?

De fleste CoddyKit-lektioner tager cirka 5–10 minutter. Hver lektion er kort og interaktiv, så du gør løbende fremskridt og kan fortsætte, hvor du slap – på både web og app.

Kan jeg skrive og køre kode i denne Cloud & IT Cert Prep-lektion?

Ja. Alle Cloud & IT Cert Prep-lektioner har en indbygget kodeeditor, så du kan skrive og køre rigtig kode direkte i din browser og få øjeblikkelig feedback fra AI – uden lokal opsætning.

Alle lektioner i dette kursus

ALB vs NLB vs GLB: Hvornår skal De bruge hvad
Target groups og health checks
Listenerregler og sti-baseret routing
SSL-terminering og sticky sessions

← Tilbage til Cloud & IT Cert Prep