Einführung
Eine Statusseite benötigt einen HTTP-Endpunkt, der meldet, ob eine Anwendung fehlerfrei ist. Du verbindest einen bereitgestellten Lambda-Handler mit einer HTTP-API, sendest Anfragen, diagnostizierst seine Aufrufberechtigung und entfernst deine Ressourcen.
Schließe Eine Lambda-Funktion mit einem JSON-Ereignis ausführen und Eine Lambda-Funktion konfigurieren und diagnostizieren einschließlich ihrer Voraussetzungen zu Rollen und Logs ab. Diese neue Umgebung stellt Handler und Ausführungsrolle bereit.
Bezug zu Zertifizierungen
Dieses Lab bietet praktische Übungen zu den folgenden Prüfungsthemen.
- Solutions Architect – Associate (SAA-C03) · Aufgabe 2.1: HTTP-API-Routen, Lambda-Integration und Aufrufberechtigungen.
- Developer – Associate (DVA-C02) · Aufgabe 1.1, Aufgabe 1.2: HTTP-API-Routen, Lambda-Integration und Aufrufberechtigungen.
- DevOps Engineer – Professional (DOP-C02) · Aufgabe 3.2: Grundlagenübung: HTTP-API-Routen, Lambda-Integration und Aufrufberechtigungen.
Die Zustandsfunktion bereitstellen
In diesem Schritt verpackst du den bereitgestellten Zustands-Handler und stellst eine Funktion bereit, die auf ein HTTP-Ereignis antworten kann.
Wechsle in den vorbereiteten Arbeitsbereich:
cd /home/labex/project
Öffne AWS View neben Terminal, um denselben Funktions-, API- und Log-Zustand wie mit deinen Befehlen zu verfolgen. Anfangs existieren nur unbeteiligte Referenz-Logs; erhalte sie.
Lies die bereitgestellte Anwendung, bevor du sie verpackst:
cat app.py
Der Handler empfängt ein Ereignis, protokolliert diese Eingabe und gibt eine Proxy-Antwort mit statusCode, headers und einer JSON-Zeichenkette in body zurück. Das HTTP-Payload-Format 2.0 legt URL-Abfrageparameter in queryStringParameters ab. Der optionale Parameter name ändert die Begrüßung. RELEASE_LABEL ist eine Umgebungseinstellung, die daneben zurückgegeben wird.
Verwende zip, um app.py im Stamm des Bereitstellungsarchivs abzulegen:
zip health.zip app.py
Lies den ARN der vorbereiteten Rolle in eine Shellvariable ein. --query wählt ein Antwortfeld aus, und --output text macht es für den nächsten Befehl nutzbar:
ROLE_ARN=$(aws iam get-role --role-name labex-a01-execution --query 'Role.Arn' --output text)
Stelle app.handler mit Python 3.12 und der vorbereiteten Ausführungsrolle bereit. fileb:// lädt die Zip-Bytes hoch. Die JSON-Zuordnung Variables verwendet dasselbe Format wie im Lambda-Konfigurations-Lab. Ihr Zeichenkettenwert kennzeichnet die erste Freigabe:
aws lambda create-function \
--function-name labex-a01-health \
--runtime python3.12 \
--role "$ROLE_ARN" \
--handler app.handler \
--timeout 5 \
--environment '{"Variables":{"RELEASE_LABEL":"initial"}}' \
--zip-file fileb://health.zip \
--query '{Name:FunctionName,Handler:Handler,Runtime:Runtime}'
Die Antwort sollte labex-a01-health, app.handler und python3.12 identifizieren. Öffne AWS View und prüfe die Karte Function. Eine bereitgestellte Funktion allein stellt noch keine HTTP-Route bereit; die Karte HTTP APIs bleibt leer.
Die HTTP-Route verbinden und eine Anfrage senden
In diesem Schritt verbindest du eine HTTP-Anfrage mit deiner bereitgestellten Funktion. Amazon API Gateway stellt den HTTP-Einstieg bereit. Eine Route wählt eine Backend-Integration für eine Methode und einen Pfad aus, etwa GET /health.
Erstelle eine HTTP-API und speichere ihre erzeugte ID in einer Shellvariable. Die Befehlssubstitution $(...) übernimmt die ausgewählte API-ID, statt sie anzuzeigen:
API_ID=$(aws apigatewayv2 create-api --name labex-a01 --protocol-type HTTP --query ApiId --output text)
Halte diese ID für deinen Ressourcenbestand fest. Die Umleitung > schreibt den Wert in eine Datei:
printf '%s\n' "$API_ID" > api-id.txt
Eine Stage ist der Bereitstellungseinstieg der API. Die Stage $default hat keinen URL-Abschnitt für einen Stage-Namen. --auto-deploy wendet Änderungen automatisch an. Einfache Anführungszeichen erhalten das wörtliche Dollarzeichen:
aws apigatewayv2 create-stage --api-id "$API_ID" --stage-name '$default' --auto-deploy --query '{Stage:StageName,AutoDeploy:AutoDeploy}'
Lies den ARN der bereitgestellten Funktion ein und erstelle anschließend eine AWS_PROXY-Integration. Lambda-Integrationen verwenden POST zum Aufruf des Backends, obwohl die eingehende Clientroute unten GET verwendet. Das Payload-Format 2.0 passt zum bereitgestellten Handler:
FUNCTION_ARN=$(aws lambda get-function-configuration --function-name labex-a01-health --query FunctionArn --output text)
INTEGRATION_ID=$(aws apigatewayv2 create-integration --api-id "$API_ID" --integration-type AWS_PROXY --integration-method POST --integration-uri "$FUNCTION_ARN" --payload-format-version 2.0 --query IntegrationId --output text)
Ein Routenschlüssel kombiniert die HTTP-Methode des Clients mit dem Pfad. Sein Ziel verweist auf die gerade erstellte Integration:
aws apigatewayv2 create-route \
--api-id "$API_ID" \
--route-key 'GET /health' \
--target "integrations/$INTEGRATION_ID" \
--authorization-type NONE \
--query '{Route:RouteKey,Authorization:AuthorizationType}'
Diese öffentliche Zustandsroute verwendet NONE; die Anmeldung bei der Anwendung wird später eingeführt. Die Ausführungsrolle steuert, was der Funktionscode tun kann, während die Ressourcenrichtlinie der Funktion steuert, wer sie aufrufen darf. API Gateway benötigt weiterhin eine präzise Aufrufberechtigung.
Lies die ausgewählte Konto-ID ein und bilde den Quell-ARN für die Route GET /health in der Default-Stage dieser API. Das maskierte Dollarzeichen erhält $default wörtlich innerhalb der erweiterten Zeichenkette:
ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text)
SOURCE_ARN="arn:aws:execute-api:us-east-1:$ACCOUNT_ID:$API_ID/\$default/GET/health"
Erlaube ausschließlich dieser API-Route den Aufruf der Funktion:
aws lambda add-permission \
--function-name labex-a01-health \
--statement-id ApiHealth \
--action lambda:InvokeFunction \
--principal apigateway.amazonaws.com \
--source-account "$ACCOUNT_ID" \
--source-arn "$SOURCE_ARN" \
--query Statement \
--output text
Verwende für HTTP-Anfragen in diesem Arbeitsbereich die vorbereitete API-Adresse mit deiner erzeugten API-ID. Dies ist der API-Einstieg des Arbeitsbereichs, kein öffentlicher AWS-Hostname:
API_URL="http://127.0.0.1:8081/api/$API_ID"
Die offizielle Konsole zeigt dieselbe API-ID, die Stage $default und die Einstellung Auto deploy. Ihre Invoke URL ist ein AWS-Endpunkt; fahre für dieses Lab mit deiner obigen Arbeitsbereichsadresse API_URL fort.
Quelle: AWS API Gateway.
curl -i zeigt sowohl HTTP-Header als auch den Antwortinhalt. Der URL-Abfrageparameter wird Teil des tatsächlichen Lambda-Ereignisses:
curl -i "$API_URL/health?name=Maya"
Erwarte HTTP 200 und diesen JSON-Inhalt:
{"healthy": true, "message": "Hello, Maya", "release": "initial"}
Kehre zu AWS View zurück. Die Karte HTTP APIs sollte GET /health, NONE und $default · AutoDeploy true zeigen. Die Karte CloudWatch Logs sollte die tatsächliche Route, den Status und die Antwort zeigen. Klicke auf Show logs und finde queryStringParameters mit name: Maya. Diese manuelle Beobachtung verbindet die HTTP-Anfrage mit der Eingabe der bereitgestellten Funktion; die Verifikation prüft die entfernte Konfiguration und die tatsächliche Ausführung.
Dieses Beispiel zeigt die konfigurierte Route und ihre erfolgreiche Antwort Maya / initial. Deine erzeugte API-ID und dein Code-Fingerabdruck unterscheiden sich.
Aufrufberechtigung diagnostizieren und eine neue Freigabe veröffentlichen
In diesem Schritt beobachtest du eine unterbrochene Aufrufgrenze, stellst die genaue Berechtigung wieder her und testest eine geänderte Funktionseinstellung.
Entferne das Statement anhand seiner ID. API, Integration und Ausführungsrolle bleiben dabei bestehen:
aws lambda remove-permission --function-name labex-a01-health --statement-id ApiHealth
Sende eine weitere Anfrage, während die Berechtigung fehlt:
curl -i "$API_URL/health?name=Noah"
Erwarte HTTP 502 mit Invocation permission denied. API-Bereitstellung und Routenkonfiguration gewähren selbst keine Lambda-Aufrufberechtigung. In AWS View bleibt der bestehende erfolgreiche Aufruf erhalten; diese abgelehnte Anfrage hat den Handler nicht ausgeführt. Vergleiche die Logs manuell vor und nach der Anfrage. Die automatische Prüfung leitet keine frühere Ablehnung aus der abschließend wiederhergestellten Richtlinie ab.
Stelle dieselbe auf Konto und Route begrenzte Berechtigung wieder her:
aws lambda add-permission \
--function-name labex-a01-health \
--statement-id ApiHealth \
--action lambda:InvokeFunction \
--principal apigateway.amazonaws.com \
--source-account "$ACCOUNT_ID" \
--source-arn "$SOURCE_ARN" \
--query Statement \
--output text
Ändere die Funktionsumgebung, um die Freigabe ready zu kennzeichnen. Der Handler liest diese Einstellung bei seiner Ausführung:
aws lambda update-function-configuration --function-name labex-a01-health --environment '{"Variables":{"RELEASE_LABEL":"ready"}}' --query 'Environment.Variables'
Die Route verweist weiterhin auf dieselbe Funktion. Sende eine Anfrage mit einem anderen Abfragewert:
curl -i "$API_URL/health?name=Noah"
Erwarte HTTP 200 und eine aus der neuen Abfrage und Umgebung berechnete Antwort:
{"healthy": true, "message": "Hello, Noah", "release": "ready"}
Prüfe in AWS View die neueste Antwort und klappe ihre Logs auf. Bestätige, dass die Eingabe Noah und der Inhalt ready sagt. Die frühere Antwort Maya sollte weiterhin verfügbar sein. Diese unterschiedlichen Ergebnisse zeigen, dass die Integration die bereitgestellte Funktion ausführt, statt eine einzige feste Zustandsmeldung zurückzugeben.
Deine API und Funktion löschen
In diesem Schritt entfernst du die erstellten Ressourcen und weist nach, dass unbeteiligte Referenz-Logs erhalten bleiben.
Dein Bestand besteht aus der API-ID in api-id.txt, labex-a01-health und /aws/lambda/labex-a01-health. Die API besitzt ihre Route, Integration und Default-Stage. Lösche zuerst die API, damit sie keine weiteren Anfragen empfangen kann:
aws apigatewayv2 delete-api --api-id "$API_ID"
Entferne die Funktion und ihre eigene Aufrufrichtlinie:
aws lambda delete-function --function-name labex-a01-health
Lambda-Log-Gruppen haben ihren eigenen Lebenszyklus. Lösche nur die Gruppe dieser Funktion:
aws logs delete-log-group --log-group-name /aws/lambda/labex-a01-health
Rufe die nativen Bestände erfolgreich ab; Anfragefehler belegen keine Löschung:
aws apigatewayv2 get-apis --query 'Items[].Name'
aws lambda list-functions --query 'Functions[].FunctionName'
Beide Listen sollten leer sein. Lies die verbleibenden Log-Gruppen:
aws logs describe-log-groups --query 'logGroups[].logGroupName'
Nur /labex/labex-a01-reference sollte erhalten bleiben. Erhalte diese Gruppe und die vorbereitete Ausführungsrolle. Bestätige in AWS View, dass die Karten API, Function und Aufrufe leer sind, während Reference logs weiterhin INFO platform reference keep unchanged zeigt.
Zusammenfassung
Du hast einen Python-Zustands-Handler bereitgestellt, eine HTTP-API-Route über eine Integration mit Payload 2.0 verbunden und ihre Default-Stage aktiviert. Du hast die Lambda-Aufrufberechtigung der API begrenzt, ihr Entfernen diagnostiziert und unterschiedliche Antworten aus tatsächlichen Abfragewerten und Funktionseinstellungen beobachtet. Abschließend hast du deine API, Funktion und Log-Gruppe entfernt und unbeteiligte Ressourcen erhalten.
