Module Objective: Redesign tightly coupled components of an architecture into a loosely coupled one using AWS application integration services.

Builds on Module 9: Decoupling is what makes the elasticity and high availability designed in Module 9 resilient to a single component's failure or slowdown.

Tight vs. Loose Coupling Revisited

Building on AWS Academy Cloud Foundations Module 9, this module identifies where the café architecture built so far is still tightly coupled — for example, a compute tier calling another service synchronously and waiting on its response — and redesigns those points using an intermediary.

🔵 Note A synchronous call from one component directly to another is the simplest design, but it means a slowdown or failure in the second component immediately becomes a slowdown or failure in the first — the core problem loose coupling solves.

Amazon SQS in Depth

Building on AWS Academy Cloud Foundations Module 9, Amazon SQS is applied here as the mechanism that lets a producer (such as an order-processing web tier) hand off work to a consumer (such as a fulfillment service) without either needing the other to be available at the same instant.

SQS FeatureArchitectural Benefit
Standard queueAt-least-once delivery, very high throughput, best-effort ordering
FIFO queueExactly-once processing and strict ordering, at lower throughput
Dead-letter queueCaptures messages that repeatedly fail processing, instead of losing or endlessly retrying them
Visibility timeoutHides a message from other consumers while one consumer is processing it
✅ Tip — Queues Absorb Traffic Spikes Because a queue can hold messages until a consumer is ready, SQS lets the consumer tier scale at its own pace rather than needing to match the producer's peak rate instantly — a direct implementation of elasticity from Module 9.

Amazon SNS in Depth

Amazon SNS is applied here for fan-out scenarios — for example, a single "order placed" event that needs to notify inventory, billing, and customer notification systems simultaneously, each as an independent subscriber.

🔵 Note — SNS + SQS Fan-Out Is a Named Pattern Publishing one SNS message to multiple SQS queue subscribers — one per downstream service — is one of the most common decoupling patterns in AWS reference architectures, combining fan-out with each consumer's own durable queue.

Amazon EventBridge in Depth

Amazon EventBridge is applied here where the architecture needs more sophisticated event routing than a simple queue or topic — filtering and routing events by content, and integrating with both AWS services and external SaaS applications through a shared event bus.

✅ Tip — EventBridge Adds Content-Based Routing Unlike SNS, which delivers every message to every subscriber, EventBridge rules can route based on the content of the event itself — sending only "high-value order" events to a fraud-review service, for example.

Choosing an Integration Pattern

As with every other layer in this course, the specific integration service follows from the actual communication need between components.

NeedLikely Fit
One producer, one consumer, work queued for later processingAmazon SQS
One event, many independent subscribersAmazon SNS
Complex, content-based event routing across servicesAmazon EventBridge
⚠️ Warning — Decoupling Adds Points to Monitor Every queue, topic, or event bus added is also a new thing that needs monitoring — an architecture with SQS, SNS, and EventBridge components should extend the CloudWatch monitoring from Module 9 to cover them too.

Key Terms for Module 12

dead-letter queue
An SQS queue that captures messages which repeatedly fail processing
visibility timeout
The period an SQS message is hidden from other consumers while one consumer processes it
fan-out pattern
Publishing one event to multiple independent subscribers, commonly via SNS to multiple SQS queues
content-based routing
Routing events based on their actual content, as supported by Amazon EventBridge rules

Review Questions

  1. What problem does a synchronous, tightly coupled call between two components create that a queue solves?
  2. What is the difference between a standard and a FIFO Amazon SQS queue?
  3. How does the SNS-to-multiple-SQS-queues fan-out pattern combine the strengths of both services?
  4. What capability does Amazon EventBridge add that Amazon SNS alone does not provide?