Course PreviewAWS Serverless
AWS serverless services run code and manage infrastructure without requiring you to provision or administer servers. Lambda executes functions on demand, API Gateway handles HTTP routing, and supporting services like DynamoDB and Step Functions scale automatically with request volume.
itCloud computing | OpenSkills.info
Intro
AWS Serverless
Serverless on AWS is an operating model for applications. You choose managed services, connect them with events or requests, and let AWS manage much of the underlying capacity. You still own the application, data, access, configuration, failure behavior, and cost.
AWS Lambda is one serverless compute service. It is not the whole architecture. A useful serverless system often combines an entry point, event transport, compute, workflow coordination, and durable data.
The central shift is from managing hosts to designing interactions. You spend less time patching an operating system. You spend more time defining event contracts, permissions, retry behavior, concurrency limits, and observability across managed services.
The request and event model
Every serverless workload starts with a signal. A client sends an HTTP request. A file arrives in Amazon S3. A message enters Amazon SQS. A scheduled event fires. A business event reaches Amazon EventBridge.
The signal reaches a consumer. That consumer may be a Lambda function, a Step Functions workflow, or another AWS service integration. The consumer performs work and writes a result, emits another event, or returns a response.
This path has five useful stages:
- Entry: API Gateway, an event source, or a schedule accepts the signal.
- Routing: EventBridge rules, queues, topics, or direct integrations select a destination.
- Compute: Lambda or another managed service performs a bounded unit of work.
- Coordination: Step Functions records workflow state, applies choices, and handles retries or catches.
- State: DynamoDB, S3, or another durable service stores data beyond one invocation.
You do not need every stage in every design. Keep the shortest path that preserves the required reliability and control.
Continue the course
This section is part of the paid course.
See pricing to subscribe, or log in if you already have access.
Where this skill leads
Relevant careers
See how this topic contributes to broader role-level skill maps.
Sources
- https://docs.aws.amazon.com/wellarchitected/latest/serverless-applications-lens/general-design-principles.html
Supports
- Serverless design emphasizes short single-purpose functions, concurrency, durable external state, event-driven transactions, and explicit workflow orchestration
- Serverless consumers must be designed for failures, retries, duplicate delivery, and idempotent operations
- https://docs.aws.amazon.com/lambda/latest/dg/lambda-functions-chapter.html
Supports
- Lambda runs code without requiring customers to provision or manage servers
- Lambda functions receive events through handlers and run in language-specific execution environments
- AWS manages capacity provisioning, scaling, operating system maintenance, and infrastructure for Lambda default functions
- https://docs.aws.amazon.com/lambda/latest/dg/lambda-invocation.html
Supports
- Lambda supports synchronous invocation, asynchronous invocation, and event source mappings
- Synchronous callers wait for responses, asynchronous invocation queues events, and event source mappings poll supported streams or queues
- https://docs.aws.amazon.com/lambda/latest/dg/lambda-runtime-environment.html
Supports
- Lambda runs functions in secure isolated execution environments with initialization, invocation, and shutdown phases
- Execution environments may be reused, including initialized objects and temporary storage, but must not be treated as durable state
- Creating an execution environment adds initialization latency, while provisioned concurrency prepares environments before requests
- https://docs.aws.amazon.com/lambda/latest/dg/gettingstarted-limits.html
Supports
- Lambda applies quotas to concurrency, function configuration, runtime, memory, payloads, storage, and API requests
- Some quotas are adjustable and others are fixed, so workloads must check the values that apply to their account and Region
- https://docs.aws.amazon.com/lambda/latest/dg/invocation-retries.html
Supports
- Retry ownership and behavior differ for direct, synchronous, asynchronous, and indirect invocations
- Lambda retries failed asynchronous invocations under documented rules, while synchronous callers or invoking services decide their own retry behavior
- Repeated invocation can produce duplicate side effects unless function code is idempotent
- https://docs.aws.amazon.com/lambda/latest/dg/configuration-concurrency.html
Supports
- Lambda concurrency is the number of in-flight requests handled by a function
- Reserved concurrency reserves capacity and caps a function, including to protect downstream resources
- Provisioned concurrency prepares execution environments to reduce initialization latency and incurs additional charges
- https://docs.aws.amazon.com/lambda/latest/dg/best-practices.html
Supports
- Lambda workload design should account for downstream throughput, quotas, idempotency, timeout values, least privilege, and load testing
- Reserved concurrency can limit scaling against a constrained downstream service
- Partial batch responses reduce unnecessary record reprocessing for supported batch event sources
- https://docs.aws.amazon.com/lambda/latest/dg/with-sqs.html
Supports
- Lambda event source mappings poll SQS, invoke functions with batches, and delete messages after successful batch processing
- Messages remain hidden during the visibility timeout and failed batches can become visible again
- SQS event source mappings process at least once, duplicates can occur, and consumers should be idempotent
- https://docs.aws.amazon.com/lambda/latest/dg/services-sqs-errorhandling.html
Supports
- SQS event source mappings apply retry and backoff behavior after function errors or throttling
- Partial batch responses allow a function to report failed records so successful records are not retried unnecessarily
- https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-dead-letter-queues.html
Supports
- An SQS dead-letter queue isolates messages that a source queue could not process successfully after its redrive threshold
- Dead-letter queues require deliberate monitoring, diagnosis, retention, and redrive decisions
- https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-available-cloudwatch-metrics.html
Supports
- SQS publishes queue metrics including visible message count and approximate age of the oldest unprocessed message
- Queue depth and message age provide evidence of backlog growth and consumer throughput pressure
- https://docs.aws.amazon.com/apigateway/latest/developerguide/getting-started.html
Supports
- API Gateway HTTP APIs provide HTTP endpoints, route requests to Lambda integrations, and return function responses to clients
- API Gateway also supports REST and WebSocket APIs with different feature and connection models
- https://docs.aws.amazon.com/apigateway/latest/developerguide/http-api-access-control.html
Supports
- API Gateway HTTP APIs support Lambda authorizers, JSON Web Token authorizers, and IAM authorization
- A managed API endpoint still requires an explicit access-control and authorization design
- https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-event-bus.html
Supports
- An EventBridge event bus receives events and rules evaluate them against patterns
- EventBridge sends matching events to configured targets and supports routing from sources to several consumers
- https://docs.aws.amazon.com/step-functions/latest/dg/welcome.html
Supports
- Step Functions state machines coordinate distributed applications as workflows made of states and tasks
- Workflows support task order, choices, parallel work, mapping, service integrations, waits, and different Standard or Express execution models
- https://docs.aws.amazon.com/step-functions/latest/dg/concepts-error-handling.html
Supports
- Step Functions states can use Retry and Catch policies for documented error handling
- Unhandled state errors fail the execution by default
- https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/on-demand-capacity-mode.html
Supports
- DynamoDB on-demand mode provides automatic throughput management and request-based charging
- On-demand tables still have scaling behavior, throughput quotas, and optional maximum throughput controls
- https://docs.aws.amazon.com/lambda/latest/dg/lambda-permissions.html
Supports
- A Lambda execution role grants the function permissions to access AWS resources and read from supported event sources
- Identity-based and resource-based policies control access to Lambda resources from users, accounts, and AWS services
- AWS recommends least-privilege permissions for Lambda workloads
- https://docs.aws.amazon.com/lambda/latest/dg/with-secrets-manager.html
Supports
- AWS Secrets Manager stores credentials, API keys, and other secrets used by Lambda functions
- Secrets can be retrieved and cached through supported Lambda integrations instead of being embedded in application code
- https://docs.aws.amazon.com/lambda/latest/dg/lambda-monitoring.html
Supports
- Lambda publishes request counts, duration, errors, logs, and other monitoring data through CloudWatch
- CloudTrail, X-Ray, Lambda Insights, and Application Signals provide additional control-plane, trace, and performance evidence
- https://aws.amazon.com/lambda/pricing/
Supports
- Lambda default functions are charged by requests and execution duration
- Provisioned Lambda features can add separate charges
- https://aws.amazon.com/api-gateway/pricing/
Supports
- API Gateway HTTP and REST API pricing includes API calls and applicable data transfer
- WebSocket API pricing uses messages and connection duration
- https://aws.amazon.com/eventbridge/pricing/
Supports
- EventBridge charges depend on event source, event delivery, payload size, and optional features
- https://aws.amazon.com/sqs/pricing/
Supports
- Amazon SQS uses request and payload-size pricing dimensions
- https://aws.amazon.com/step-functions/pricing/
Supports
- Step Functions pricing dimensions differ between Standard and Express workflows
- https://aws.amazon.com/dynamodb/pricing/
Supports
- DynamoDB pricing includes read, write, storage, and optional feature dimensions
- https://aws.amazon.com/cloudwatch/pricing/
Supports
- CloudWatch pricing includes logs, metrics, alarms, dashboards, and analysis features
- https://docs.aws.amazon.com/serverless-application-model/
Supports
- AWS SAM is an open-source framework with a template specification and command line tool for serverless applications
- AWS SAM supports defining, building, testing, and deploying serverless applications
- https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/using-sam-cli-build.html
Supports
- The sam build command prepares application artifacts for local testing and deployment
- AWS SAM build output feeds sam local and sam deploy workflows
- https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/using-sam-cli-local-invoke.html
Supports
- The sam local invoke command runs one Lambda function locally with an optional event payload
- Local invocation helps test function logic but does not validate every cloud interaction or permission
- https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/using-sam-cli-deploy.html
Supports
- The SAM command line interface builds and uploads artifacts, creates a CloudFormation change set, and deploys a stack
- Guided deployment records configuration for subsequent deployments