Development with AWS Services
Application Patterns, APIs, Messaging, and Resilient Integrations
CoreBuild AWS-hosted application code by choosing the right state, coupling, timing, coordination, API, messaging, stream, SDK, and failure-handling boundary.
Aligned to AWS Certified Developer - Associate (DVA-C02) Version 2.1, verified August 23, 2026.
Why this matters
Developer questions rarely stop at naming a service. They ask where state belongs, whether a caller should wait, how work survives a dependency failure, and which integration keeps producers and consumers independently changeable.
Must Know
- Keep replaceable compute stateless by storing durable session and application state outside the process; stateless does not mean that the application has no state.
- Loose coupling removes a direct availability or timing dependency. Amazon SQS buffers work, Amazon SNS fans one message out, EventBridge routes events by rules, and Step Functions coordinates explicit workflow state.
- Synchronous calls fit immediate request/response decisions. Asynchronous handoff fits work that may finish later, absorb bursts, or tolerate temporary consumer unavailability.
- A resilient write or third-party call combines bounded retries with backoff, error classification, timeouts, and idempotency where a repeated request could duplicate a side effect.
- API Gateway can validate requests, transform request or response payloads, and map integration outcomes to client-meaningful status codes at the API boundary.
- AWS SDKs use the credential provider chain and service APIs; application code should not embed long-term access keys.
- Stream consumers process ordered records in batches and must account for retries, duplicate delivery, checkpoint progress, and partial failure behavior.
- Amazon Q Developer can assist with understanding, generating, improving, and testing code, but generated output still needs developer inspection and deterministic tests.
Compare and Distinguish
- Stateful vs stateless: stateful instances retain required durable context locally; stateless instances can be replaced because durable context lives in an external store.
- Tight vs loose coupling: a direct call makes the caller depend on the callee now; a durable asynchronous boundary lets each side operate at a different rate.
- Synchronous vs asynchronous: synchronous returns the completion result to the waiting caller; asynchronous acknowledges handoff and completes later.
- Choreography vs orchestration: choreography lets services react to events without one coordinator; Step Functions makes sequence, branches, retries, and state explicit.
- SQS vs SNS vs EventBridge vs Step Functions: queue buffering, pub/sub fanout, rule-based event routing, and stateful workflow coordination solve different problems.
- Unit tests vs integration tests: unit tests isolate code and mock dependency boundaries; integration tests verify real contracts and configured service behavior.
Scenario examples
- Scenario: An API must validate a request immediately, but image processing can take minutes. Validate and acknowledge synchronously, then enqueue the long-running work.
- Scenario: Billing, fulfillment, and analytics each need their own copy of an order event. Publish once and fan out to independently consumed subscriptions or queues.
- Scenario: A payment provider sometimes times out after accepting a charge. Retry only with a stable idempotency key, bounded backoff, and a terminal error path.
- Scenario: A multi-step order needs visible branches, retries, and compensation. Use an orchestrated workflow rather than a hidden chain of independent reactions.
Exam traps
- Asynchronous does not automatically mean durable or loosely coupled; the selected handoff must actually retain and deliver work.
- One SQS queue distributes messages among consumers; it does not give every subscriber its own copy.
- A response mapping changes representation or status behavior; it does not replace request validation.
- Exponential backoff alone does not prevent duplicate business effects after an ambiguous timeout.
- Do not prefer microservices merely because they are distributed; a cohesive monolith can be the correct developer boundary.
- Do not treat Amazon Q Developer output as verified simply because it compiles.
Key takeaways
- Choose the communication pattern from timing, delivery, fanout, ordering, and coordination requirements.
- Place durable state outside replaceable compute.
- Make retries bounded, classified, observable, and safe for repeated execution.
- Keep API contract enforcement at the boundary and AWS credentials outside source code.
- Test AI-assisted and SDK-integrated code against the same behavioral requirements as manually written code.
How it works
- A producer emits a command, message, or event through the selected integration surface.
- The integration buffers, copies, routes, or coordinates according to its contract.
- Consumers authenticate with workload credentials, validate input, and make retry-safe service calls.
- Errors are classified into retryable and terminal outcomes and are retained or surfaced for recovery.
When to use it
- Use SQS when work needs durable buffering and consumer-rate independence.
- Use SNS when one publication must reach multiple subscribed destinations.
- Use EventBridge when event content and rules decide among targets.
- Use Step Functions when sequence, state, branches, retries, and execution history must be explicit.
- Use direct synchronous APIs when the caller genuinely needs the result before continuing.
Security and governance implications
- Use runtime roles and the SDK credential chain instead of source-controlled secrets.
- Validate untrusted API and event input before using it in application logic or downstream calls.
- Do not place tokens, credentials, or sensitive payloads in retry diagnostics or AI prompts without an approved data boundary.
- Grant producers and consumers only the publish, send, receive, delete, or invoke actions they require.
Failure signals and diagnosis
- For missing work, inspect producer success, rule or subscription matching, queue backlog, consumer errors, and terminal failure destinations in order.
- For duplicate effects, correlate request IDs and idempotency keys before changing retry counts.
- For API contract failures, separate validation, transformation, integration response, and application errors.
- For SDK failures, identify authentication, authorization, throttling, validation, timeout, and terminal service errors before widening permissions.
More detail
- The Associate boundary is implementation inside an existing application, not greenfield enterprise architecture design.
- Fault tolerance comes from explicit failure behavior: timeouts, retries, circuit breaking, fallback, durable handoff, and observable terminal failure.
- Event-driven code must validate event shape, distinguish matched from unmatched events, and tolerate the delivery semantics of the selected source.
- Request transformation, validation, and status mapping are independent API responsibilities.
Ready for the quiz?
- When does a queue solve a problem that a topic does not?
- What evidence makes orchestration preferable to choreography?
- Why must idempotency accompany retries for some write operations?
- Which API Gateway feature rejects malformed input, and which changes payload shape?
- What makes a stream consumer safe when a batch is delivered again?
Related objectives
- D1.1 — Develop code for applications hosted on AWS
- 1.1.1 — Describe architectural patterns (for example, event-driven, microservices, monolithic, choreography, orchestration, fanout)
- 1.1.2 — Describe differences between stateful and stateless concepts
- 1.1.3 — Describe differences between tightly coupled and loosely coupled components
- 1.1.4 — Describe differences between synchronous and asynchronous patterns
- 1.1.5 — Create fault-tolerant and resilient applications in a programming language (for example, Java, C#, Python, JavaScript, TypeScript, Go)
- 1.1.6 — Create, extend, and maintain APIs (for example, response/request transformations, enforcing validation rules, overriding status codes)
- 1.1.7 — Write and run unit tests in development environments (for example, using AWS SAM)
- 1.1.8 — Write code to use messaging services
- 1.1.9 — Write code that interacts with AWS services by using APIs and AWS SDKs
- 1.1.10 — Handle streaming data using AWS services
- 1.1.11 — Use Amazon Q Developer to assist with development
- 1.1.12 — Use Amazon EventBridge to implement event-driven patterns
- 1.1.13 — Implement resilient application code for third-party service integrations (for example, retry logic, circuit breakers, error handling patterns)