Development with AWS services

Architectural patterns

Stateless components keep no session data between requests, so any instance can serve any request and they scale freely. Keep state in DynamoDB, ElastiCache or S3. Lambda is stateless by design: anything in memory or in /tmp may vanish. Stateful components (a server holding sessions in memory) need sticky sessions or an external store.

Tightly coupled components call each other directly and synchronously, so one failure cascades. Loosely coupled components talk through a queue, topic or event bus, so each side can fail, scale and deploy on its own.

Synchronous means the caller waits for the answer (API Gateway to Lambda, RequestResponse invocation). Asynchronous means the caller hands off and moves on (Event invocation, SQS, SNS). Async gives resilience and absorbs spikes, but the caller must handle results another way (a callback, polling, a status in DynamoDB).

Idempotency

An operation is idempotent if repeating it has the same effect as doing it once. It matters because SQS standard queues deliver at least once, Lambda retries, and clients retry on timeouts.

• Generate an idempotency key (request ID, message ID, business key) and record it before or with the side effect. A DynamoDB conditional write (attribute_not_exists(pk)) rejects the duplicate.
• Prefer naturally idempotent operations: PutItem with a full item and a deterministic key, SET operations, and PutObject to a fixed key. ADD/increment is not idempotent.
• Powertools for AWS Lambda has an idempotency utility that does this with DynamoDB. API calls that create things often accept a client token (for example EC2 ClientToken) to make retries safe.
• SQS FIFO queues deduplicate within a 5-minute window, but consumers should still be idempotent.

Fault tolerance in code

Retries with exponential backoff and jitter

When a call fails with a throttling or transient error, retry after a growing delay (backoff) with a random component (jitter). Without jitter, many clients retry at the same moment and keep overloading the service.

• The AWS SDKs and CLI already retry with exponential backoff and jitter. Retry modes: legacy, standard (default in most SDKs) and adaptive (adds client-side rate limiting). Defaults are around 3 to 5 attempts depending on SDK and mode. Change them with AWS_MAX_ATTEMPTS, AWS_RETRY_MODE or client config.
• Retry only retryable errors: throttling (ThrottlingException, ProvisionedThroughputExceededException), 5xx and timeouts. Do not retry 4xx validation or authorization errors (ValidationException, AccessDeniedException). They fail the same way every time.
• Always set connection and read timeouts so a hung call does not hold a Lambda invocation or thread until the function timeout.

Dead-letter queues and failure handling

A dead-letter queue (DLQ) receives messages that failed repeatedly. SQS DLQs use a redrive policy with maxReceiveCount. After that many receives without deletion, the message moves to the DLQ. A DLQ must be the same type as the source (standard or FIFO). Set the DLQ retention longer than the source queue because the original enqueue time is kept. DLQ redrive moves messages back to the source after you fix the bug. SNS subscriptions, EventBridge targets and Lambda async invocations support DLQs too.

Using the SDKs and APIs

• Credential provider chain (SDKs and CLI), in order: explicit code or parameters, environment variables (AWS_ACCESS_KEY_ID…), shared config and credentials files (profiles, including SSO and assume-role profiles), container credentials (ECS task role), then EC2 instance profile (IMDS). Lambda supplies credentials from its execution role through environment variables. Never hard-code keys.
• Region comes from code, AWS_REGION, or the config file. A “resource not found” that works in the console is often the wrong Region.
• Pagination: list and query calls return a limited page plus a continuation token (NextToken, LastEvaluatedKey, Marker). Use SDK paginators. The CLI paginates automatically; --page-size changes the page size per call and --max-items caps the total result.
• Presigned URLs give time-limited access to one S3 object operation (GET or PUT) without credentials. They carry the permissions of whoever signed them, so a role-signed URL dies when the session expires.
• Waiters poll until a state is reached (for example a table becomes active).
• Service quotas and throttling: throttled calls return HTTP 429 or a Throttling code. Back off, batch, or request a quota increase.
• Multipart upload for S3 objects over 100 MB (required above 5 GB; a single PutObject caps at 5 GB). S3 Transfer Acceleration and byte-range fetches speed up transfers.
• CLI tips: --query (JMESPath) filters output client-side, --filter options filter server-side, --dry-run tests EC2 permissions, and aws sts get-caller-identity shows who you are.

Messaging services

Amazon SQS

• Visibility timeout (default 30 s, max 12 hours): after a consumer receives a message it is hidden. If not deleted in time, it reappears. Set it to at least the processing time (for Lambda consumers, at least 6x the function timeout). ChangeMessageVisibility extends it for one message.
• Long polling (WaitTimeSeconds up to 20) reduces empty responses and cost. Short polling returns immediately and can miss messages on small queues.
• Delay queue (0 to 15 minutes) hides new messages. Message timers do it per message (not on FIFO queues).
• Retention 1 minute to 14 days (default 4 days). Max message size is 1 MiB (it was 256 KB earlier). Larger payloads: store in S3 and send a pointer (Extended Client Library).
• A batch returns up to 10 messages. Delete each message after successful processing with DeleteMessage.
• Lambda with SQS: Lambda polls for you (event source mapping), scales up with the queue, and deletes messages on success. With partial batch response (ReportBatchItemFailures) you return the failed IDs so only those return to the queue. Without it, one failure retries the whole batch.
• On FIFO queues, order is only kept within a message group, and a failing message blocks its group.

Amazon SNS

A pub/sub topic pushes each message to all subscribers: SQS, Lambda, HTTP/S, email, SMS, mobile push, Firehose. Use SNS + SQS fanout to give each consumer its own durable queue. FIFO topics pair with FIFO queues. Message filtering uses a subscription filter policy (on message attributes by default, or on the message body) so each subscriber gets only what it needs and does not need code to discard messages. Failed deliveries retry according to the delivery policy and can go to a subscription DLQ. SQS subscribers need a queue policy allowing the topic to send.

Amazon EventBridge

An event bus matches events against rules (event patterns) and routes to targets (Lambda, SQS, Step Functions, API destinations, and many more). The default bus receives AWS service events. Use schedules (EventBridge Scheduler or rules) for cron. Pipes connect a source (SQS, Kinesis, DynamoDB Streams) to a target with optional filtering and enrichment. Choose EventBridge for routing on event content, SaaS and cross-account events, and a schema registry. Choose SNS for high-volume simple fanout. Choose SQS when you need a buffer that consumers pull from.

AWS Step Functions

Orchestrates steps as a state machine written in Amazon States Language.

• State types: Task, Choice, Parallel, Map (inline or distributed), Wait, Pass, Succeed, Fail.
• Retry (with IntervalSeconds, BackoffRate, MaxAttempts, jitter) and Catch handle errors inside the workflow, so you do not write retry loops in code.
• Service integrations: request response (default, move on after the call), .sync (wait for the job to finish), and .waitForTaskToken (pause until something calls SendTaskSuccess or SendTaskFailure). Optimized integrations exist for Lambda, DynamoDB, SQS, SNS, ECS, Batch and more, and the AWS SDK integrations cover most other API actions without Lambda glue.
• Pick Step Functions over Lambda calling Lambda: no waiting costs, built-in retries, visible state.

Streaming with Kinesis

• Provisioned shard: 1 MB/s or 1,000 records/s in, 2 MB/s out. On-demand mode scales automatically.
• A hot shard (bad partition key) causes ProvisionedThroughputExceededException. Fix with a higher-cardinality key, more shards or retry with backoff. Producers batch with PutRecords or the KPL; consumers use the KCL (checkpoints in DynamoDB) or Lambda.
• Enhanced fan-out gives each consumer its own 2 MB/s per shard through push (HTTP/2) delivery. Without it, consumers share the 2 MB/s.
• Lambda reads a stream shard in order. A failing batch blocks that shard until it succeeds or expires. Mitigate with BisectBatchOnFunctionError, MaximumRetryAttempts, MaximumRecordAgeInSeconds, parallelization factor (up to 10 batches per shard) and an on-failure destination.

Amazon API Gateway

Integration types: Lambda proxy (the whole request goes to the function in a fixed event format and the function returns statusCode, headers, body), Lambda custom (non-proxy) (mapping templates transform request and response), HTTP / HTTP proxy, AWS service (call DynamoDB, SQS, Step Functions directly with no Lambda), and Mock (return a response from API Gateway itself with no backend).

• Request/response transformation uses Velocity Template Language (VTL) mapping templates. Request validation with models (JSON Schema) rejects bad requests with 400 before invoking the backend. Gateway responses override default error bodies, and method/integration responses map backend status codes to different status codes.
• Throttling: default account limit of 10,000 requests per second with a 5,000 burst. Client over the limit gets 429. Usage plans with API keys apply per-client throttling and quotas (API keys identify clients but are not authorization).
• Caching (REST only): per stage, TTL default 300 s (max 3,600), keyed on method, path and optionally query strings and headers. Clients bypass it with Cache-Control: max-age=0 if permitted.
• Integration timeout: 29 seconds by default for REST (raisable in some cases), 30 s for HTTP APIs. Longer work needs async patterns.
• CORS: enable on the resource. With proxy integration your function must also return the Access-Control-Allow-Origin header.
• Error codes: 400 bad request, 403 forbidden (authorizer or WAF denied or missing key), 429 throttled, 502 bad Lambda response format (malformed proxy output), 503 service unavailable, 504 integration timeout.

AWS AppSync

Managed GraphQL (and Pub/Sub over WebSockets) with resolvers to DynamoDB, Lambda, OpenSearch and HTTP. Choose it when clients need to fetch exactly the fields they want, combine data sources, or get real-time subscriptions and offline sync.

Lambda development

Configuration

Execution environment lifecycle: Init (download code, start runtime, run code outside the handler), Invoke, Shutdown. A reused (warm) environment skips init, so put SDK clients, database connections and config loading outside the handler and reuse them. A cold start is the init on a new environment. Do not store per-request data in globals. Provisioned concurrency keeps environments initialized for consistent latency. SnapStart (Java, and some other runtimes) restores from a snapshot to cut cold start.

Invocation types and event sources

• For async invocations, configure Lambda destinations (on success and on failure) to SQS, SNS, EventBridge or Lambda, which carry more context than a DLQ. A DLQ (SQS or SNS) on the function is the older option. Destinations are preferred. These apply to async and stream mappings only, not to synchronous calls.
• Event source mapping settings: batch size, batching window, filter criteria (drop events before invoking, which saves cost), concurrency scaling, and failure handling as above. For SQS the visibility timeout should exceed the function timeout, and a DLQ belongs on the queue, not the function.
• Concurrency: account default 1,000 concurrent executions per Region (can be raised). Reserved concurrency guarantees and caps a function (setting 0 stops it, which is also a throttle switch). Provisioned concurrency pre-warms. Throttled sync calls return 429. Throttled async calls are retried by Lambda for up to 6 hours.
• Function URL: built-in HTTPS endpoint with AWS_IAM or no auth, optional CORS, no API Gateway needed.

Versions, aliases, and VPC

• $LATEST is mutable. Publishing a version makes an immutable snapshot (code and config). An alias is a named pointer to a version. It can split traffic between two versions (weighted alias) for canary releases. Event sources should point at an alias so you can roll back by moving it.
• VPC access: attach the function to subnets and security groups to reach private resources (RDS, ElastiCache). Functions in a VPC have no internet or AWS API access unless the subnet routes through a NAT gateway or you add VPC endpoints. Lambda uses Hyperplane ENIs shared across environments, so VPC no longer adds major cold start delay. Connections to relational databases should go through RDS Proxy to avoid exhausting connections.
• Unit testing: keep handler logic thin and separate business logic so it can be tested without AWS. Mock SDK clients. Use sam local invoke and sam local start-api for local tests, and generate events with sam local generate-event.

Data stores

DynamoDB

Keys: a partition key alone, or partition key plus sort key. The partition key is hashed to choose the partition, so use a high-cardinality key that spreads traffic evenly (user ID, not status or date). A hot key throttles even if total capacity is fine. Fix with a better key, write sharding (random suffix), or DynamoDB Accelerator (DAX) for read-heavy hot items.

• Filter expressions apply after the read, so they save bandwidth but not capacity. Projection expressions return fewer attributes. Each Query/Scan page is at most 1 MB.
• Conditional writes (ConditionExpression) give optimistic locking: keep a version attribute and require it to be unchanged. A failed condition raises ConditionalCheckFailedException.
• Atomic counters use UpdateItem with ADD or SET x = x + :n.
• Item size limit 400 KB. Put big blobs in S3.

Indexes

A GSI that is under-provisioned throttles writes to the base table.

Consistency: reads are eventually consistent by default (half the cost). Strongly consistent reads (ConsistentRead=true) cost 2x, are not available on GSIs or global tables’ remote Regions, and can fail during an outage with a 500.

Capacity maths (a classic question):

• 1 RCU = one strongly consistent read per second of up to 4 KB, or two eventually consistent reads, or half a transactional read.
• 1 WCU = one write per second of up to 1 KB (transactional writes cost 2).
• Round item sizes up to the next 4 KB (reads) or 1 KB (writes).
• Example: 10 strongly consistent reads per second of 6 KB items needs 10 x 2 = 20 RCU. Eventually consistent halves it to 10.
• Modes: provisioned (with auto scaling, burst capacity) and on-demand (pay per request, for unpredictable load). Exceeding capacity gives ProvisionedThroughputExceededException. Retry with backoff (SDKs do).

Other features: TTL deletes expired items for free (a number attribute with an epoch-seconds timestamp, deleted within about 48 hours of expiry, so filter expired items in reads). DynamoDB Streams gives a 24-hour ordered change log (key only, new image, old image, both) that triggers Lambda. Global tables replicate across Regions (last writer wins). DAX is an in-memory write-through cache for eventually consistent reads with microsecond latency and the same API. PartiQL gives SQL-like access. Backups: on-demand and point-in-time recovery (35 days). Export to S3 for analytics. Serialization: the low-level API uses typed attribute values ({"S": "x"}), while the SDK document/resource interfaces and the DynamoDB Enhanced Client (Java) or object mappers convert to and from native types.

Amazon S3

• Object store with strong read-after-write consistency. Max object 5 TB. Keys are flat (prefixes only look like folders). Performance scales per prefix: at least 3,500 writes and 5,500 reads per second.
• Storage classes: Standard, Intelligent-Tiering (unknown or changing access, auto tiers), Standard-IA, One Zone-IA, Glacier Instant Retrieval, Glacier Flexible Retrieval, Glacier Deep Archive (cheapest, hours to restore, 180-day minimum). IA classes have a 30-day minimum and a retrieval fee.
• Lifecycle rules transition objects between classes and expire them (and clean up incomplete multipart uploads and old versions). Versioning keeps old versions and delete markers. Replication (CRR/SRR) needs versioning.
• Event notifications go to Lambda, SQS, SNS or EventBridge. S3 Select / Glacier and Athena query objects in place. Object Lock gives WORM retention. Requester pays moves transfer costs to the caller.
• Access: bucket policies, IAM, presigned URLs, and Block Public Access (on by default for new buckets).

Other data stores

• RDS read replicas scale reads (asynchronous, eventually consistent). Multi-AZ is for availability, not scaling. Use RDS Proxy for Lambda and connection storms, and IAM database authentication to avoid stored passwords.
• Ephemeral storage (instance store, Lambda /tmp, in-memory) is lost when the compute stops. Persistent storage (EBS, EFS, S3, databases) survives.
• Relational vs non-relational: pick relational for complex joins and flexible ad hoc queries. Pick DynamoDB for known access patterns, huge scale and predictable latency.

Caching strategies

Usually combine lazy loading plus write-through plus TTL. Memcached is multi-threaded and simple with no persistence; Redis offers data structures, persistence, replication and pub/sub. Where to cache: CloudFront (edge, content), API Gateway cache (API responses), DAX (DynamoDB), ElastiCache (anything else), and the client.

Graceful degradation and serialization

• Graceful degradation: when a dependency fails, keep the core feature working in a reduced form. Serve cached or default data, skip an optional call, queue the work for later, or return a partial result with a clear status. Combine it with timeouts, retries with backoff, and a circuit breaker (stop calling a failing dependency for a while). Do not retry forever.
• Serialization turns objects into bytes or text to store or send (JSON is the usual format, also Avro and Protobuf for streams). Deserialization rebuilds the object. Where it shows up: the DynamoDB low-level API’s typed attribute values versus document-style helpers, SQS and SNS message bodies (strings, so you JSON-encode), Kinesis record data (bytes, Base64 in some APIs), Lambda event and response JSON, and S3 object bodies. Typical bugs are numbers becoming strings or floats (DynamoDB numbers are decimals, so use Decimal in Python), missing Base64 decoding, date formats, and unknown fields breaking strict parsers. Validate input after parsing, and version your message schemas so old consumers survive new fields.

Event-driven code with S3, SQS, SNS and EventBridge

• S3 Event Notifications fire on object created, removed, restore and replication events. Destinations are Lambda, SQS, SNS and EventBridge. Filter by key prefix and suffix. Deliveries are at least once and are not ordered, so handlers must be idempotent. Writing the processed output to the same bucket and prefix that triggers the function causes an infinite loop. Use a different prefix or bucket. EventBridge delivery adds richer filtering and many targets.
• Choose by need: API Gateway for synchronous request and response, SQS for buffered asynchronous work with consumers pulling, SNS for push fanout, EventBridge for content-based routing and many targets, Step Functions when the order and state of steps matter.

AI-assisted development and managed AI services

The current exam expects you to use AI tools to build code faster, and to call managed AI services from application code. It does not ask you to select foundation models, engineer prompts or design retrieval (RAG) architectures.

AI-assisted development tools

Treat AI output as untrusted draft code: read it, test it, and review it like a teammate’s pull request. Check generated IAM policies for over-broad permissions, generated SDK calls for real operation names and parameters, and dependencies for safety. Give the tool context (project rules, steering or instruction files, specs, tests) to get better output, and never paste secrets or customer data into prompts. Keep a human reviewer for anything that reaches production. Pair generated code with generated and hand-written tests (see the deployment notes).

Integrating managed AI services

• Integration patterns: API Gateway then Lambda then Bedrock for a synchronous endpoint (watch the 29 s limit, so stream or go asynchronous for long generations), SQS or Step Functions around AI calls for long or bursty work, and S3 event notification then Lambda to run Textract or Comprehend on new files.
• AI calls are slow, rate limited and billed by tokens. Handle ThrottlingException with backoff, set generous client read timeouts, cap output length, cache repeated answers, and use asynchronous or batch modes where available. Quotas apply per model and Region.
• Model output is non-deterministic, so validate it (JSON schema, length, allowed values) before acting on it, and handle refusals and empty responses.
• Securing AI calls is covered in the security notes.