3. Application Integration
These services enable asynchronous communication and workflow orchestration to decouple components and improve system resilience.
Amazon AppFlow
Service Introduction: A managed integration service for secure data transfer between SaaS applications (e.g., Salesforce, Zendesk) and AWS.
Common Usage: Automating bidirectional data movement without writing custom API integration code.
Project Examples:
- Syncing Salesforce customer records into an Amazon S3 data lake.
- Automating the transfer of Zendesk support tickets to Redshift for analysis.
AWS AppSync
Service Introduction: A serverless GraphQL and Pub/Sub API service that simplifies application development by providing a single endpoint for multiple data sources.
Common Usage: Building real-time, collaborative applications with built-in offline data synchronization and conflict resolution.
Project Examples:
- Developing a real-time collaborative whiteboarding application.
- Building a mobile app with offline sync capabilities for field technicians.
Amazon EventBridge
Service Introduction: A serverless event bus that uses rules to route events from AWS services, custom apps, or SaaS partners to targets.
Common Usage: Coordinating event-driven architectures; replaces simple CloudWatch Events with advanced filtering and schema discovery.
Project Examples:
- Triggering a Lambda function whenever an EC2 instance state changes to "terminated."
- Routing custom "order placed" events to multiple downstream microservices.
Amazon MQ
Service Introduction: A managed message broker service for industry-standard protocols like MQTT, AMQP, and STOMP (ActiveMQ/RabbitMQ).
Common Usage: Facilitating the migration of legacy applications that rely on standard messaging protocols to the cloud.
Project Examples:
- Migrating a RabbitMQ-based banking system to a managed AWS environment.
- Connecting hybrid-cloud applications using standard MQ protocols across Direct Connect.
Amazon SNS
Service Introduction: A high-throughput, push-based pub/sub messaging service for both application-to-application and application-to-person delivery.
Common Usage: Implementing the "Fan-out" pattern where one message is sent to multiple subscribers (SQS, Lambda, Email, SMS).
Project Examples:
- Sending critical system alerts to an administrator’s mobile device.
- Broadcasting a single "new user" event to five different backend processing queues.
Amazon SQS
Service Introduction: A fully managed message queuing service for decoupling and scaling microservices through asynchronous communication.
Common Usage:
Buffering requests to handle traffic spikes; use Standard queues for high throughput or FIFO for exact ordering.
Dead-Letter Queues (DLQ) (exam-critical): A separate SQS queue configured directly on the source queue (via maxReceiveCount redrive policy) that automatically receives messages after they've failed processing N times — no consumer-side code needed to move them. This is the standard, correct pattern; manually moving failed messages from application code is the wrong-answer distractor.
Standard vs. FIFO Queues (exam-critical):
| Feature | Standard Queue | FIFO Queue |
|---|---|---|
| Ordering | Best-effort — messages may arrive out of order | Guaranteed exact order (per message group) |
| Delivery | At-least-once — possible duplicates | Exactly-once processing — no duplicates |
| Throughput | Nearly unlimited | 300 msg/sec default (3,000/sec with batching) |
| When to use | Maximum throughput, order/duplicates don't matter | Order matters (e.g., financial transactions) or duplicates would corrupt state |
The tell: "order must be preserved" or "must be processed exactly once, no duplicates" → FIFO. "Maximize throughput" with no ordering constraint → Standard.
Visibility Timeout (exam-critical): When a consumer retrieves a message, it becomes invisible to other consumers for the visibility timeout window (0s–12h, default 30s) — if the consumer doesn't delete it (i.e., fails to finish processing) before the timeout expires, the message becomes visible again and another consumer can pick it up, which is how SQS avoids losing in-flight messages on a worker crash. If a question describes a message being processed twice by two different workers, the fix is usually to increase the visibility timeout to exceed the actual processing time.
Other Queue Parameters (exam-critical distractors):
| Parameter | Range / Default | Purpose | Common wrong-answer trap |
|---|---|---|---|
| DelaySeconds (Delay Queue) | 0s–900s, default 0 | Postpones delivery of new messages so they aren't visible to any consumer immediately after being sent | Does not fix duplicate processing and has no bearing on message ordering |
| MessageRetentionPeriod | 60s–14 days, default 4 days | How long an unconsumed message stays in the queue before SQS auto-deletes it | Not a concurrency or ordering control |
| WaitTimeSeconds | 0s–20s | Enables long polling — a ReceiveMessage call waits up to this long for a message instead of returning empty immediately, cutting empty-response cost |
Controls polling behavior, not visibility or duplicate delivery |
Fan-Out Pattern: SNS + SQS (exam-critical, extremely common architecture): Combines SNS's pub/sub broadcast with SQS's durable, poll-based buffering: a single event is published once to an SNS topic, which fans it out to multiple SQS queues subscribed to that topic, each feeding an independent consumer/microservice. This gets you both parallel, decoupled processing across services and the durability/retry guarantees of SQS (a message sitting in a queue survives a consumer outage, unlike a raw SNS-only push to an HTTP endpoint that can be lost if the endpoint is down). The standard answer whenever a question wants "one event, multiple independent downstream systems, each processing at its own pace without dropping messages."
Project Examples:
- Decoupling an order ingestion API from an order processing backend.
- Implementing a worker-pool pattern where multiple EC2 instances poll a queue for tasks.
- Using SNS fan-out to SQS so that a single "order placed" event durably reaches separate inventory, billing, and shipping microservices.
AWS Step Functions
Service Introduction: A serverless orchestrator that allows you to coordinate multiple AWS services into visual workflows and state machines.
Common Usage: Managing long-running business processes, error handling, and retry logic across distributed components.
Project Examples:
- Orchestrating a multi-step image processing pipeline with human-in-the-loop approval.
- Managing a complex checkout process involving inventory checks, payment, and shipping.