Cloud Integration

1. Why integration services exist

Once you start deploying more than one application, they will inevitably need to communicate with one another. The slides split that communication into two patterns:

1. Synchronous communication — application to application. The Buying Service calls the Shipping Service directly and waits for it.
2. Asynchronous / event-based communication — application to queue to application. The Buying Service drops a message on a queue, and the Shipping Service picks it up whenever it is ready.

Synchronous communication becomes a problem the moment traffic spikes. If you normally encode 10 videos but suddenly need to encode 1000, the caller overwhelms the callee and the whole chain falls over.

The answer is to decouple your applications, using one of three models:

• SQS — queue model
• SNS — pub/sub model
• Kinesis — real-time data streaming model

The point the deck keeps hammering: these services can scale independently from your application. The queue absorbs the spike; the consumer fleet catches up at its own pace.

Exam tip

If a question describes a sudden spike of traffic breaking a direct application-to-application call, the expected answer is “decouple with SQS/SNS/Kinesis”, not “make the caller bigger”.

2. Amazon SQS – Simple Queue Service

A queue sits between producers, who send messages, and consumers, who poll messages. There can be many of each.

Standard Queue

The slides describe the Standard Queue as follows:

• The oldest AWS offering (over 10 years old).
• Fully managed (~serverless), used to decouple applications.
• Scales from 1 message per second to 10,000s per second.
• Default retention of messages: 4 days, maximum of 14 days.
• No limit to how many messages can be in the queue.
• Messages are deleted after they are read by consumers.
• Low latency — under 10 ms on publish and receive.
• Consumers share the work to read messages and scale horizontally.

Real-world example

The deck’s tier-decoupling diagram: an Auto Scaling Group of web servers PUTs requests into an SQS queue, and a second Auto Scaling Group of video-processing EC2 instances polls that queue. The scaling of the processing tier is driven by the queue itself — web servers and video processing never call each other directly.

FIFO Queue

FIFO = First In First Out, meaning ordering of messages in the queue. Messages sent 1 2 3 4 are processed in order by the consumer as 1 2 3 4.

Exam tip

Message ordering is the single differentiator to remember between the two queue types. Standard = huge scale, no ordering guarantee; FIFO = ordering of messages preserved.

3. Amazon Kinesis Data Streams

For the exam: Kinesis = real-time big data streaming. It is a managed service to collect, process and analyze real-time streaming data at any scale.

The deck marks the details as too deep for Cloud Practitioner, but still worth knowing:

• Amazon Kinesis Data Streams — low-latency streaming to ingest data at scale from hundreds of thousands of sources.
• Amazon Data Firehose — load Kinesis Data Streams into Amazon S3, Redshift, OpenSearch, and so on.

The high-level overview on the slides lines up sources and destinations:

Sources	Through	Destinations
Click Streams, IoT devices, Metrics & Logs	Amazon Kinesis Data Streams → Amazon Data Firehose	Amazon S3, Amazon Redshift

Exam tip

Any wording involving “real-time”, “streaming data”, “click streams” or “IoT telemetry at scale” points at Kinesis, not SQS.

4. Amazon SNS – Simple Notification Service

SQS answers “one message, one consumer”. SNS answers the other question: what if you want to send one message to many receivers?

In the deck’s example, the Buying Service publishes once to an SNS Topic, and the Email notification, Fraud Service and Shipping Service all receive it — either through direct integration or through their own SQS queues fanned out from the topic.

How it works:

• The event publishers only send a message to one SNS topic.
• There can be as many event subscribers as you want listening to that topic’s notifications.
• Each subscriber to the topic gets all the messages.
• Limits: up to 12,500,000 subscriptions per topic and a 100,000 topics limit.

Subscriber types shown on the slide: SQS, Lambda, Amazon Data Firehose, HTTP(S) endpoints, SMS & mobile notifications, and emails.

Real-world example

Pub/sub with fan-out: the Buying Service publishes one “order placed” event to the topic; an SQS queue in front of the Shipping Service, another in front of the Fraud Service, and a plain email subscription all receive the same event without the Buying Service knowing any of them exist.

Exam tip

SNS has no message retention — if there is no subscriber when a message is published, that message is gone. SQS keeps messages up to 14 days. That contrast is a classic exam distractor.

5. Amazon MQ

SQS and SNS are “cloud-native” services: proprietary protocols from AWS. Traditional applications running from on-premises may instead use open protocols such as MQTT, AMQP, STOMP, Openwire and WSS.

When migrating to the cloud, instead of re-engineering the application to use SQS and SNS, you can use Amazon MQ:

• A managed message broker service.
• Does not “scale” as much as SQS / SNS.
• Runs on servers, and can run in Multi-AZ with failover.
• Has both queue features (~SQS) and topic features (~SNS).

The section summary names the broker engines: ActiveMQ and RabbitMQ in the cloud.

Exam tip

The trigger words for Amazon MQ are “migrating an existing on-premises application” plus a named open protocol (MQTT, AMQP…). If the application can be changed, AWS would rather you used SQS/SNS.

6. Section summary

The deck closes the section with a straight comparison:

• SQS — queue service in AWS. Multiple producers; messages are kept up to 14 days; multiple consumers share the read and delete messages when done. Used to decouple applications in AWS.
• SNS — notification service in AWS. Subscribers: Email, Lambda, SQS, HTTP, Mobile…. Multiple subscribers, sends all messages to all of them, no message retention.
• Kinesis — real-time data streaming, persistence and analysis.
• Amazon MQ — managed message broker for ActiveMQ and RabbitMQ in the cloud (MQTT, AMQP… protocols).

Decoupling also underpins the monitoring and event-routing services in Cloud Monitoring, where EventBridge can deliver events straight into SQS and SNS.

Quick recap

Concept	What to remember for the exam
Synchronous vs asynchronous	Direct app-to-app calls break under sudden spikes; decouple through a queue, a topic or a stream
Amazon SQS Standard	Fully managed queue, 1 to 10,000s of messages/second, retention 4 days by default and 14 days max, no queue size limit, messages deleted after being read, <10 ms latency
Amazon SQS FIFO	First In First Out — messages are processed in order by the consumer
Consumers	Share the work and scale horizontally; that is what absorbs the spike
Amazon Kinesis	Real-time big data streaming; Kinesis Data Streams ingests, Amazon Data Firehose loads into S3, Redshift, OpenSearch
Amazon SNS	Pub/sub: one publish to a topic, every subscriber gets every message; 12,500,000 subscriptions per topic, 100,000 topics; no retention
SNS subscribers	SQS, Lambda, Amazon Data Firehose, HTTP(S) endpoints, SMS & mobile notifications, emails
Amazon MQ	Managed broker for ActiveMQ and RabbitMQ; open protocols (MQTT, AMQP, STOMP, Openwire, WSS); runs on servers, Multi-AZ with failover; scales less than SQS/SNS
SQS vs SNS	Queue with one consumer per message and retention, versus fan-out to all subscribers with no retention