Components — Deep Dive

The configuration surface that shows up repeatedly in scenario questions: how requests are structured, how they reach a backend, who's allowed to call them, and how traffic is controlled.

AWS Exam Thinking

Requirement → Keywords → Expected Answer → why every distractor fails.

Integrations With Other AWS Services

End-to-End Architecture Example: Serverless API With Authentication and Tracing

This exact pattern — API Gateway (HTTP API) → Lambda → DynamoDB with a Cognito authorizer and X-Ray tracing — is one of the canonical serverless architectures on the exam. See the Cross-Service Architectures guide for the fully worked version alongside four other end-to-end architectures.

Best Practices & Common Exam Traps

When to Use API Gateway — and When Not To

REST API vs HTTP API — The Core Comparison

Common Exam Traps

Memory Anchors

Hands-On Lab

Three self-contained exercises, all in eu-west-1, using AWS CLI v2. Exercise 1 builds an HTTP API with a Lambda proxy integration. Exercise 2 rebuilds the same conceptual endpoint on a REST API with a non-proxy integration and a real VTL mapping template, so you can see the proxy-vs-non-proxy trap from Components 1.3 happen on your own screen instead of just reading about it. Exercise 3 layers a usage plan and API key onto the REST API and deliberately triggers a 429. Replace <ACCOUNT_ID> with your account ID throughout.

Exercise 1 — HTTP API + Lambda Proxy Integration

1. Create the IAM trust policy and execution role the Lambda function will run as.

   cat > trust-policy.json <<'EOF'
   {
     "Version": "2012-10-17",
     "Statement": [{
       "Effect": "Allow",
       "Principal": { "Service": "lambda.amazonaws.com" },
       "Action": "sts:AssumeRole"
     }]
   }
   EOF
   
   aws iam create-role \
     --role-name orders-proxy-lambda-role \
     --assume-role-policy-document file://trust-policy.json
   
   aws iam attach-role-policy \
     --role-name orders-proxy-lambda-role \
     --policy-arn arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole

   CreateRole returns an Arn like arn:aws:iam::<ACCOUNT_ID>:role/orders-proxy-lambda-role; the policy attaches with no output.
2. Write the Lambda handler. Because this will sit behind a proxy integration, it must return the full API Gateway proxy response shape itself — statusCode, headers, and a JSON-string body.

   cat > index.js <<'EOF'
   exports.handler = async (event) => {
     const id = event.pathParameters && event.pathParameters.id;
     return {
       statusCode: 200,
       headers: { "Content-Type": "application/json" },
       body: JSON.stringify({
         id: id,
         status: "CONFIRMED",
         source: "lambda-proxy",
         rawQueryString: event.rawQueryString || ""
       })
     };
   };
   EOF
   zip function-proxy.zip index.js

   function-proxy.zip is created in the current directory.
   ⚠️ Why this step matters for the exam

   This is the proxy contract tested repeatedly on DVA-C02: if this function returned a bare object like { id, status } instead of the statusCode/headers/body shape, API Gateway would not attempt to interpret it — it would return a 500 error to the client. Proxy integrations do zero response transformation.

3. Create the function and grant it a Lambda alias-free deploy (using the $LATEST version is fine for this lab).

   aws lambda create-function \
     --region eu-west-1 \
     --function-name orders-proxy-fn \
     --runtime nodejs20.x \
     --handler index.handler \
     --role arn:aws:iam::<ACCOUNT_ID>:role/orders-proxy-lambda-role \
     --zip-file fileb://function-proxy.zip

   create-function returns FunctionArn: arn:aws:lambda:eu-west-1:<ACCOUNT_ID>:function:orders-proxy-fn, State ACTIVE (or Pending briefly).
4. Create the HTTP API itself (no target yet — the route and integration are wired up explicitly in the next steps).

   aws apigatewayv2 create-api \
     --region eu-west-1 \
     --name orders-http-api \
     --protocol-type HTTP

   Returns an ApiId (e.g. abc123xyz4) and an ApiEndpoint like https://abc123xyz4.execute-api.eu-west-1.amazonaws.com. Save the ApiId — it's needed in every following command.
5. Create the Lambda proxy integration on the API, then a route that points at it.

   aws apigatewayv2 create-integration \
     --region eu-west-1 \
     --api-id <API_ID> \
     --integration-type AWS_PROXY \
     --integration-uri arn:aws:lambda:eu-west-1:<ACCOUNT_ID>:function:orders-proxy-fn \
     --payload-format-version 2.0 \
     --integration-method POST
   
   aws apigatewayv2 create-route \
     --region eu-west-1 \
     --api-id <API_ID> \
     --route-key "GET /orders/{id}" \
     --target integrations/<INTEGRATION_ID>

   create-integration returns an IntegrationId to plug into --target as integrations/<INTEGRATION_ID>; create-route returns a RouteId.
6. Let API Gateway invoke the function, then deploy a stage.

   aws lambda add-permission \
     --region eu-west-1 \
     --function-name orders-proxy-fn \
     --statement-id apigw-invoke-proxy \
     --action lambda:InvokeFunction \
     --principal apigateway.amazonaws.com \
     --source-arn "arn:aws:execute-api:eu-west-1:<ACCOUNT_ID>:<API_ID>/*/*/orders/*"
   
   aws apigatewayv2 create-stage \
     --region eu-west-1 \
     --api-id <API_ID> \
     --stage-name dev \
     --auto-deploy

   add-permission returns a Statement JSON blob; create-stage returns StageName "dev" with AutoDeploy true, so future changes go live without a manual deployment call.
7. Test it.

   curl -s "https://<API_ID>.execute-api.eu-west-1.amazonaws.com/dev/orders/42?expand=items"

   {"id":"42","status":"CONFIRMED","source":"lambda-proxy","rawQueryString":"expand=items"} — the whole request (path param AND query string) reached the function untouched, with zero API Gateway configuration to parse them.

Exercise 2 — Same Endpoint, REST API + Lambda Non-Proxy Integration + VTL

Same conceptual GET /orders/{id} endpoint, rebuilt as a REST API with a non-proxy (custom) Lambda integration. This time API Gateway — not the function — is responsible for shaping both the request going in and the response coming out, via VTL mapping templates.

1. Write a second Lambda function. Because it sits behind a non-proxy integration, it can return whatever bare shape is convenient — no statusCode/headers/body envelope required.

   cat > index.js <<'EOF'
   exports.handler = async (event) => {
     return {
       orderId: event.orderId,
       status: "CONFIRMED",
       filter: event.queryParams ? event.queryParams.expand : null
     };
   };
   EOF
   zip function-nonproxy.zip index.js
   
   aws lambda create-function \
     --region eu-west-1 \
     --function-name orders-nonproxy-fn \
     --runtime nodejs20.x \
     --handler index.handler \
     --role arn:aws:iam::<ACCOUNT_ID>:role/orders-proxy-lambda-role \
     --zip-file fileb://function-nonproxy.zip

   FunctionArn arn:aws:lambda:eu-west-1:<ACCOUNT_ID>:function:orders-nonproxy-fn, State ACTIVE. Note the function never sees an "event" shaped like the raw HTTP request — it only sees whatever the request mapping template builds in the next steps.
2. Create the REST API and the /orders/{id} resource tree.

   aws apigateway create-rest-api \
     --region eu-west-1 \
     --name orders-rest-api \
     --endpoint-configuration types=REGIONAL
   
   # Get the auto-created root resource id ("/")
   aws apigateway get-resources --region eu-west-1 --rest-api-id <REST_API_ID>
   
   aws apigateway create-resource \
     --region eu-west-1 --rest-api-id <REST_API_ID> \
     --parent-id <ROOT_RESOURCE_ID> --path-part orders
   
   aws apigateway create-resource \
     --region eu-west-1 --rest-api-id <REST_API_ID> \
     --parent-id <ORDERS_RESOURCE_ID> --path-part "{id}"

   Two new resources exist: /orders and /orders/{id}, each returned with its own ResourceId to use below.
3. Add the GET method on /orders/{id} (no auth for this lab).

   aws apigateway put-method \
     --region eu-west-1 --rest-api-id <REST_API_ID> \
     --resource-id <ID_RESOURCE_ID> --http-method GET \
     --authorization-type NONE \
     --request-parameters "method.request.path.id=true,method.request.querystring.expand=false"

   put-method returns the method definition with httpMethod GET and the declared request parameters.
4. Write the request mapping template (VTL) that turns the raw HTTP request into the plain object the function expects, then wire up the non-proxy integration.

   cat > request-template.vtl <<'EOF'
   {
     "orderId": "$input.params('id')",
     "queryParams": {
       #foreach($p in $input.params().querystring.keySet())
       "$p": "$util.escapeJavaScript($input.params().querystring.get($p))"#if($foreach.hasNext),#end
       #end
     }
   }
   EOF
   
   aws apigateway put-integration \
     --region eu-west-1 --rest-api-id <REST_API_ID> \
     --resource-id <ID_RESOURCE_ID> --http-method GET \
     --type AWS \
     --integration-http-method POST \
     --uri "arn:aws:apigateway:eu-west-1:lambda:path/2015-03-31/functions/arn:aws:lambda:eu-west-1:<ACCOUNT_ID>:function:orders-nonproxy-fn/invocations" \
     --request-templates file://request-template-wrapped.json

   put-integration returns type AWS (not AWS_PROXY) — confirming this is a custom, mapping-template-driven integration.
   ⚠️ Why this step matters for the exam

   --request-templates takes a JSON object mapping content-type → template string (so the .vtl file above must be wrapped as {"application/json": "<escaped template>"} before passing it as request-template-wrapped.json). This extra packaging step is exactly the "more setup" the guide's Components tab warns about for non-proxy — API Gateway, not your function, now owns the request shape.

5. Write the response mapping template so the client sees a clean, gateway-defined response shape regardless of what the function returned.

   cat > response-template.vtl <<'EOF'
   #set($inputRoot = $input.path('$'))
   {
     "order": {
       "id": "$inputRoot.orderId",
       "status": "$inputRoot.status"
     },
     "source": "lambda-nonproxy-vtl"
   }
   EOF
   
   aws apigateway put-method-response \
     --region eu-west-1 --rest-api-id <REST_API_ID> \
     --resource-id <ID_RESOURCE_ID> --http-method GET \
     --status-code 200
   
   aws apigateway put-integration-response \
     --region eu-west-1 --rest-api-id <REST_API_ID> \
     --resource-id <ID_RESOURCE_ID> --http-method GET \
     --status-code 200 \
     --response-templates file://response-template-wrapped.json

   Both calls return 200 with the method/integration response objects echoed back — the pipeline from Lambda's raw return value to the client-facing JSON is now fully defined by API Gateway, not by the function.
6. Grant invoke permission and deploy to a stage.

   aws lambda add-permission \
     --region eu-west-1 \
     --function-name orders-nonproxy-fn \
     --statement-id apigw-invoke-nonproxy \
     --action lambda:InvokeFunction \
     --principal apigateway.amazonaws.com \
     --source-arn "arn:aws:execute-api:eu-west-1:<ACCOUNT_ID>:<REST_API_ID>/*/GET/orders/*"
   
   aws apigateway create-deployment \
     --region eu-west-1 --rest-api-id <REST_API_ID> \
     --stage-name dev

   create-deployment returns a DeploymentId — remember Components 1.2: nothing above this step was visible to callers until this deployment happened.
7. Test it and compare against Exercise 1's output.

   curl -s "https://<REST_API_ID>.execute-api.eu-west-1.amazonaws.com/dev/orders/42?expand=items"

   {"order":{"id":"42","status":"CONFIRMED"},"source":"lambda-nonproxy-vtl"} — a differently-shaped, gateway-defined response, versus Exercise 1's function-defined response. Same conceptual endpoint, opposite party (function vs. gateway) controlling the contract.

Exercise 3 — Usage Plan, API Key, and a Live 429

Layer metering and throttling onto the REST API built in Exercise 2, then push past the limit on purpose.

1. Require an API key on the method, then redeploy.

   aws apigateway update-method \
     --region eu-west-1 --rest-api-id <REST_API_ID> \
     --resource-id <ID_RESOURCE_ID> --http-method GET \
     --patch-operations op=replace,path=/apiKeyRequired,value=true
   
   aws apigateway create-deployment \
     --region eu-west-1 --rest-api-id <REST_API_ID> \
     --stage-name dev

   apiKeyRequired is now true on the method. A redeploy is mandatory — re-run the earlier curl and confirm it now returns 403 Forbidden with message "Forbidden" (no x-api-key header sent).
2. Create an API key and a usage plan with a deliberately low throttle so you can hit it in seconds, then link the two together.

   aws apigateway create-api-key \
     --region eu-west-1 \
     --name orders-lab-key --enabled
   
   aws apigateway create-usage-plan \
     --region eu-west-1 \
     --name orders-lab-plan \
     --api-stages apiId=<REST_API_ID>,stage=dev \
     --throttle burstLimit=2,rateLimit=1 \
     --quota limit=1000,period=MONTH
   
   aws apigateway create-usage-plan-key \
     --region eu-west-1 \
     --usage-plan-id <USAGE_PLAN_ID> \
     --key-id <API_KEY_ID> \
     --key-type API_KEY

   create-api-key returns an id and a value (the actual key string). The plan is set to rateLimit=1 request/sec, burstLimit=2 — intentionally tight so throttling is easy to reproduce.
   ⚠️ Why this step matters for the exam

   rateLimit/burstLimit here are the method/stage-level throttle from Components 1.6's token-bucket model — they can only be as generous as the account-level ceiling, never more. This is also the setup for the classic "per-customer quota" exam scenario: a real usage plan would set a realistic rate but the mechanism is identical.

3. Fetch the key value, then confirm an authenticated call now succeeds.

   aws apigateway get-api-key \
     --region eu-west-1 --api-key <API_KEY_ID> --include-value
   
   curl -s -H "x-api-key: <API_KEY_VALUE>" \
     "https://<REST_API_ID>.execute-api.eu-west-1.amazonaws.com/dev/orders/42?expand=items"

   200 OK with the same VTL-shaped body from Exercise 2 — the key identifies/meters the caller but note it did not need to prove any identity, exactly as Components 1.6 describes.
4. Trigger and observe the 429.

   for i in $(seq 1 10); do
     curl -s -o /dev/null -w "%{http_code}\n" \
       -H "x-api-key: <API_KEY_VALUE>" \
       "https://<REST_API_ID>.execute-api.eu-west-1.amazonaws.com/dev/orders/42"
   done

   The first couple of lines print 200 (covered by the burst of 2), then subsequent lines print 429 as the sustained request rate exceeds rateLimit=1/sec — this is API Gateway's own throttling response, returned before the Lambda function is ever invoked.

Flashcards — 22 Cards

Click card to flip. Mark right or wrong to track score.

Practice Quiz — 13 Questions

DVA-C02 scenario style, Easy → Specialty. Select an answer to reveal the explanation.