Lesson 1: Every AWS Integration Service on One Page

Why start with a map

When someone says "just put a queue in front of it", you have at least four AWS services that could be "the queue" and several more that could be "the event". Most bad integration choices start with grabbing the familiar service without looking at what else exists. So before we look at limits, prices or quick starts, we'll lay every AWS integration service out on one page, in six groups, with the one-line job each one does.

Think of it like a building's plumbing plan. Some pipes hold water until someone uses it (queues). Some split one flow into many (publish-subscribe). Some send water to different places depending on what's in it (event routing). Some follow a fixed procedure (workflow). Some are the taps people touch (APIs). Some connect to the mains outside (connectors).

The one-page map

Gotcha: AppSync now covers two things: GraphQL APIs and, since October 2024, Event APIs (AppSync Events). If someone says "we use AppSync", ask which one.

Kinesis and MSK are on the map because they show up in integration discussions all the time. Their real home is data streaming, though. In this course they appear only briefly.

Walkthrough: inventory what you already have

Before you pick something new, find out what your account already runs. Every service has its own CLI namespace, and some of those names are traps:

# Queues
aws sqs list-queues                      # SQS standard and FIFO (FIFO names end in .fifo)
aws mq list-brokers                      # Amazon MQ brokers (engine: ACTIVEMQ or RABBITMQ)

# Publish-subscribe
aws sns list-topics

# Event routing: three namespaces, one product family
aws events list-event-buses              # 'events' = EventBridge buses and rules (the old CloudWatch Events API)
aws pipes list-pipes                     # EventBridge Pipes
aws scheduler list-schedules             # EventBridge Scheduler

# Workflow
aws stepfunctions list-state-machines    # type: STANDARD or EXPRESS

# APIs: two namespaces for API Gateway
aws apigateway get-rest-apis             # REST APIs (the original 'v1' API)
aws apigatewayv2 get-apis                # HTTP and WebSocket APIs ('v2')
aws appsync list-graphql-apis

# Connectors and streaming
aws appflow list-flows
aws kinesis list-streams
aws kafka list-clusters-v2               # MSK lives under 'kafka'

Here's some realistic output from aws stepfunctions list-state-machines:

{
  "stateMachines": [
    { "name": "order-fulfilment", "type": "STANDARD" },
    { "name": "thumbnail-burst",  "type": "EXPRESS" }
  ]
}

Best practice: run this inventory in each region you use and paste the results under your map. Half the value is finding the forgotten SNS topic or the broker nobody owns.

Overlaps, and the question that separates each pair

The map has deliberate overlaps. For each one there's a single question that usually settles it:

• SNS vs EventBridge (fan-out): Do subscribers need a copy of everything on a topic, or do you need to route each event by its content, including events from AWS services and SaaS partners? Plain broadcast points to SNS. Content-based routing across many sources points to EventBridge.
• SQS vs Amazon MQ (queuing): Are you bringing existing applications that already speak a broker protocol such as JMS, AMQP, MQTT or STOMP? If so, use Amazon MQ so you don't have to rewrite them. For new cloud-native code, SQS is the usual default.
• SQS vs Kinesis/MSK: Should a message disappear once one consumer handles it, or must many readers be able to replay an ordered stream? Work queue points to SQS. Replayable log points to the streaming services.
• Step Functions vs EventBridge: Does one place need to own the sequence and know whether the whole process finished, or do services just react to each other? Central orchestration points to Step Functions. Loose choreography points to EventBridge.
• API Gateway vs AppSync: Do clients want resource-style REST/HTTP endpoints, or one GraphQL schema they can query flexibly (or real-time channels)?
• EventBridge partner events vs AppFlow: Do you need individual events as they happen, or bulk records moved between a SaaS app and AWS?

Former names: reading old docs correctly

AWS renames services but rarely renames the APIs behind them. That's why old templates still work, and also why they confuse people.

For example, this Terraform is pure EventBridge, even though the name says CloudWatch:

# Despite the name, this creates an EventBridge rule on the default bus
resource "aws_cloudwatch_event_rule" "nightly" {
  name                = "nightly-report"
  schedule_expression = "cron(0 2 * * ? *)"  # 02:00 UTC daily
}

Trade-off note: for new schedules, EventBridge Scheduler (launched at re:Invent 2022 with Pipes) is the dedicated tool. Scheduled rules like the one above still work, and you'll find plenty of them in older stacks.

You'll also come across Amazon SWF (Simple Workflow Service) in old architectures. It's an older workflow service, separate from Step Functions, so don't read it as a former name for Step Functions.

Retirement watch: none of the core services on this map have been announced for retirement. One feature has: SNS message data protection moved to maintenance mode in 2026, so don't design new work around it.

Key takeaways

• Six groups: queues (SQS, Amazon MQ), publish-subscribe (SNS, AppSync Events), event routing (EventBridge buses, Pipes, Scheduler), workflow (Step Functions), APIs (API Gateway, AppSync GraphQL), connectors (AppFlow). Kinesis and MSK are streaming neighbours.
• Each overlapping pair comes down to one question: broadcast vs content routing, existing broker protocols vs new code, consume-once vs replay, orchestrate vs react.
• CloudWatch Events is EventBridge. aws events, AWS::Events::* and aws_cloudwatch_event_* all mean EventBridge.
• API Gateway REST lives under apigateway. HTTP and WebSocket live under apigatewayv2.
• Inventory what you already run before adding anything new.