Exams / SAP-C03 / Study guide / Ingress, edge functions and real-time APIs (ALB, NLB, API Gateway, CloudFront)
Ingress, edge functions and real-time APIs (ALB, NLB, API Gateway, CloudFront): SAP-C03 study notes and practice questions
What to know about Ingress, edge functions and real-time APIs (ALB, NLB, API Gateway, CloudFront) for the SAP-C03 exam, from the Architecture Design and Implementation Built for the Cloud domain (25% of the exam guide), then 1 free question to test it. Part of the SAP-C03 study guide.
SAP-C03 asks you to choose the front door for an application, push logic to the edge to cut latency, and build real-time, two-way messaging without managing servers.
Ingress options
Front door
Layer and strengths
ALB
HTTP/HTTPS, gRPC; host and path routing, weighted target groups, Lambda targets, Cognito or OIDC authentication, WAF
NLB
TCP, UDP, TLS; millions of requests per second, static IPs or Elastic IPs per AZ, client IP preserved, fronts PrivateLink endpoint services
Global edge caching, TLS termination near users, origin protection, WAF and Shield at the edge
On EKS, the AWS Load Balancer Controller creates an ALB for Kubernetes Ingress resources and an NLB for Service resources of type LoadBalancer, using IP targets to route straight to pods.
API Gateway REST and HTTP APIs have a 10 MB payload limit and a 29-second default integration timeout for REST (raisable for Regional and private APIs). For long work, return quickly and finish asynchronously with SQS or Step Functions.
Calling external services, origin selection, auth needing a lookup, body inspection
CloudFront KeyValueStore gives CloudFront Functions a low-latency key-value lookup (redirect maps, feature flags) without a network call.
Real-time with WebSocket APIs
API Gateway WebSocket APIs keep a persistent two-way connection. Routes $connect, $disconnect and $default (plus custom routes chosen by a message field) invoke Lambda or other integrations.
Store connection IDs in DynamoDB on connect; to push a message, the backend calls the @connections management API with the connection ID.
Connections last up to 2 hours and close after 10 minutes idle, so clients must reconnect and send heartbeats.
For pub/sub fan-out, publish to SNS or EventBridge and have a function push to each subscribed connection.
How to choose
Scenario wording
Choose
“Partners must allowlist fixed IP addresses”
NLB with Elastic IPs (or Global Accelerator)
“Path-based routing to microservices, OIDC login”
ALB
“Throttle and meter external API customers”
API Gateway REST with usage plans
“Lowest latency header rewrite for every request”
CloudFront Functions
“Pick origin by looking up user data”
Lambda@Edge on origin request
“Chat or live dashboard pushing updates to browsers”
API Gateway WebSocket API
Common traps
Lambda@Edge for simple header changes, which costs more and adds latency compared with CloudFront Functions.
Polling REST endpoints for live updates instead of WebSockets.
Synchronous API calls for work that takes minutes.
Expecting an ALB to have static IPs.
Hand-creating load balancers for EKS instead of using the Load Balancer Controller.
A streaming news site serves most of its article pages from Amazon CloudFront. Readers who hold a paid subscription have a signed subscriber cookie, and non-subscribers must be redirected to the subscription page before they can read a paywalled article.
The check must run on every viewer request, including requests that CloudFront could otherwise answer from its cache. It must add almost no latency, and the team wants no network call to a subscription service on each request.
Which solution meets these requirements at the LOWEST cost?
Choose one answer.
AA. Attach a CloudFront Function to the viewer request event that reads the subscriber cookie and returns a redirect to the subscription page when the cookie is missing or invalid.
BB. Attach a Lambda@Edge function to the origin request event that checks the subscriber cookie against the subscription service.
CC. Move the check to the origin by placing an Application Load Balancer with an OIDC authentication action in front of the site, so every request is authenticated before it reaches the content.
DD. Attach a Lambda@Edge function to the viewer request event that looks up the reader's subscription status in a DynamoDB table on every request.
Show the answer and explanation
Answer: A
A. Right: Correct. CloudFront Functions run on every viewer request at the edge with very low latency and cost, and they can read cookies and return redirects without a network call. This covers cached and uncached requests alike.
B. Wrong: The origin request event runs only when CloudFront forwards a request to the origin, so cached article pages would be served without the check. The function also makes a network call on each cache miss.
C. Wrong: Authentication at the origin means every request, including those that could be cached, reaches the load balancer. That raises origin load and cost, and it adds latency that the edge check avoids.
D. Wrong: This check does run on every viewer request, so it meets the coverage need. The per-request network call to DynamoDB adds latency and cost, which breaks the requirement to add almost no latency and avoid network calls.
Explanation
The check has to run on every viewer request, with almost no latency and no network call, so the viewer request event and a CloudFront Function fit. Origin request logic misses cache hits, and the other options add origin load or a network call on every request.
Want more on Ingress, edge functions and real-time APIs (ALB, NLB, API Gateway, CloudFront)? The 5 full-length practice sets have 5 more Ingress, edge functions and real-time APIs (ALB, NLB, API Gateway, CloudFront) questions, 375 in all, none of them in the free exam. One payment of $14.99, no subscription. See the practice sets →
Study Ingress, edge functions and real-time APIs (ALB, NLB, API Gateway, CloudFront)