16. Serverless

Serverless services abstract the underlying infrastructure, allowing for event-driven architectures that scale automatically from zero.

AWS AppSync

Service Introduction: A managed GraphQL service that simplifies application development by providing a single endpoint for multiple data sources with real-time sync.

Common Usage: Serverless API; ideal for mobile/web apps requiring real-time data and offline capabilities.

Project Examples:

• Building a serverless real-time chat application.
• Syncing user data between a mobile app and a DynamoDB backend.

AWS Fargate

Service Introduction: A serverless, pay-as-you-go compute engine for containers that works with both Amazon ECS and Amazon EKS.

Common Usage: Running containers without managing EC2 instances; removes the need for instance patching and capacity management.

Project Examples:

• Hosting a microservice in a container that scales based on CPU demand without managing servers.
• Running periodic, scheduled container tasks to process data.

AWS Lambda

Service Introduction: A serverless compute service that lets you run code in response to events without provisioning or managing servers.

Common Usage: Core of event-driven architectures; scales automatically and you only pay for the time the code is executing. Pricing Model (exam-critical): Cost is driven by memory allocated × execution duration (billed in GB-seconds), not just duration. Counter-intuitively, increasing memory can lower total cost if it proportionally speeds up execution enough (more memory also linearly increases allocated vCPU). Always compute the GB-seconds breakeven point before assuming "more memory = more cost."

Concurrency Controls (exam-critical — cold starts and throttling questions live here):

• Reserved Concurrency — Sets both a guaranteed maximum number of concurrent executions for a function and caps it — protects downstream systems (e.g., an RDS database) from being overwhelmed by a traffic spike, but requests beyond the reserved limit are throttled, not queued (for synchronous invokes).
• Provisioned Concurrency — Pre-initializes a specified number of execution environments so they're already warm and ready to respond with no cold-start latency. The correct answer whenever a question requires consistently low, predictable latency (e.g., a customer-facing API where cold starts are unacceptable), at the cost of paying for that capacity whether it's used or not.
• The tell: "eliminate cold starts" / "consistent low latency" → Provisioned Concurrency. "Prevent this function from overwhelming a downstream resource" / "limit maximum concurrent executions" → Reserved Concurrency.

Invocation Types (exam-critical):

• Synchronous — Caller waits for a response (e.g., API Gateway → Lambda). Errors are returned directly to the caller; the caller is responsible for retry logic.
• Asynchronous — Caller hands off the event and returns immediately (e.g., S3 event notifications, SNS). Lambda automatically retries on failure (twice, by default), and after exhausting retries, failed events can be sent to a configured Dead Letter Queue (DLQ) (via SQS or SNS) or the newer on-failure destination — the standard answer for "don't lose failed asynchronous invocations."
• Event Source Mapping (poll-based) — Lambda internally polls a stream/queue (Kinesis Data Streams, DynamoDB Streams, SQS) and invokes the function with a batch of records. For SQS specifically, failed messages become visible again after the visibility timeout and are retried; a DLQ configured on the SQS queue itself (not on Lambda) catches messages that repeatedly fail processing.

Lambda in a VPC (exam-critical): By default, a Lambda function runs outside any customer VPC, in an AWS-managed network with direct internet access — this is why it can reach public S3/DynamoDB endpoints natively without extra configuration. Attaching a Lambda function to a VPC (to reach a private RDS instance or ElastiCache cluster, for example) requires an ENI in a private subnet, and that function loses direct internet access unless the subnet also routes outbound traffic through a NAT Gateway. Forgetting the NAT Gateway is a classic "why can my VPC-attached Lambda reach RDS but not call an external API" exam trap.

Project Examples:

• Triggering an image-resizing function whenever a photo is uploaded to S3.
• Processing streaming data from a Kinesis Data Stream in real-time.
• Using Provisioned Concurrency to guarantee sub-100ms response times for a customer-facing checkout API.
• Attaching a Lambda function to a VPC (with a NAT Gateway for outbound internet) to query a private RDS instance and also call a third-party payment API.