Application Integration

🧠 Free Recall ❓ Quiz 🔍 Cues 🔮 Simulation 🥷 ShadowBox 📐 Encode Cards

Application Integration
Orientation: why this category matters disproportionately
Generative AI applications are rarely one model call. They are pipelines: a document arrives, gets extracted, gets chunked, gets embedded, gets summarized, gets reviewed, gets stored, and someone gets notified. The model is one step; the rest is integration.
This category also carries an outsized share of the exam because of a property specific to foundation models: inference is slow, expensive, rate-limited, and occasionally fails. A model call taking thirty seconds breaks synchronous request patterns. Throttling under burst is normal rather than exceptional. Retrying is expensive because you pay per token. Every one of those pressures pushes generative architectures toward asynchronous, decoupled, orchestrated designs — which is exactly what this category provides.
Three services do most of the work and are worth understanding as a set:
Step Functions orchestrates — it knows the sequence and the state. EventBridge routes — it knows who cares about what happened. SQS buffers — it absorbs mismatches between how fast work arrives and how fast it can be processed.
Most integration questions are really asking which of those three verbs the scenario needs.

AWS Step Functions
What it is
Step Functions is a managed workflow orchestration service. You define a state machine — in JSON/YAML (Amazon States Language) or visually — where each state is a step: invoke a Lambda, call an AWS service API directly, run a choice branch, wait, run states in parallel, iterate over a collection with Map, or succeed and fail. Step Functions executes it, tracks state between steps, handles retries and error catching declaratively, and gives you a visual execution history showing exactly which path a given execution took and where it failed.
It integrates directly with over two hundred AWS services without Lambda glue, including optimized integrations for Bedrock (InvokeModel) and SageMaker.
Two workflow types:
Standard — durable, exactly-once, executions up to one year, full execution history retained, supports human-approval callbacks. Priced per state transition.
Express — high-volume, short-lived, up to five minutes, at-least-once, priced by execution count and duration. For event ingestion and streaming-scale processing where per-transition pricing would be prohibitive.
Why it matters for generative workloads
Four capabilities make Step Functions the default orchestrator here.
Duration. A workflow that extracts, calls a model several times, waits on a human, and stores results can run far past Lambda's fifteen minutes. Standard workflows run for a year.
Declarative error handling. Retry with exponential backoff and Catch blocks are configuration, not code. This is the clean answer to Bedrock throttling in an orchestrated pipeline: retry with backoff on ThrottlingException, declaratively, with no retry logic to write or get wrong.
Human-in-the-loop. The callback pattern (waitForTaskToken) pauses an execution — for up to a year — until an external system returns a task token. This is the mechanism for approval gates: generate a draft, pause, notify a reviewer, resume on approval. When a stem says a human must approve before the output takes effect, this is the architectural answer, with A2I as the alternative when the review is of model predictions specifically.
Distributed Map. Standard Map iterates inline with limited concurrency; Distributed Map fans out across up to ten thousand parallel child executions over objects in S3. This is the answer to "process millions of documents through a model" when you need orchestration, error isolation per item, and controlled concurrency — with the important caveat below.
Constraints
Payload size between states is limited (256 KB). Large documents and long model outputs must be passed by S3 reference rather than inline — a very common design point, and a plausible troubleshooting stem when a pipeline works in testing and fails on real documents.
Standard workflows are priced per state transition, so a chatty workflow at high volume gets expensive. That's the Express workflow argument, and also the argument for not decomposing a pipeline into more steps than it needs.
Express workflows are at-least-once, so steps must be idempotent — and duplicate execution of a model call costs real money.
Express has no callback pattern and a five-minute ceiling.
Step Functions orchestrates; it doesn't compute. Every actual unit of work runs somewhere else.
When not to use it
When the routing is event-driven fan-out rather than a sequence. "When X happens, three unrelated things should react" is EventBridge, not a workflow. Step Functions has a beginning and an end and knows the order.
When the work is simply queued and processed. A single-step consumer needs SQS and Lambda, not a state machine.
When the path must be decided by the model at runtime. That's an agent. Step Functions is deterministic by design — which is its virtue when auditability matters and its limitation when the problem is open-ended.
For short, simple, visual generative chains built by non-engineers — that's Prompt Flows, per the comparison below.
Step Functions vs. Prompt Flows vs. agents
The three ways to sequence generative work, distinguished by who decides the path:
Prompt Flows — you decide, at design time, visually, low-code. Short, generative-native, no long waits, no approval callbacks, limited error semantics. Right for a short deterministic chain built by someone who isn't an engineer.
Step Functions — you decide, at design time, in a durable orchestrator. Right whenever there's a human approval, a multi-hour runtime, serious error handling, or non-generative steps in the pipeline.
Agents (AgentCore / Bedrock Agents) — the model decides, at runtime. Right when the sequence isn't knowable in advance. Wrong when it is: an agent that always does the same three things is slower, costlier, and less auditable than a workflow, and the exam offers exactly that as a trap because agentic options sound more sophisticated.

Amazon EventBridge
What it is
EventBridge is a serverless event bus. Producers publish events; rules match them by content pattern or schedule; matched events are delivered to targets — Lambda, Step Functions, SQS, SNS, ECS tasks, API destinations, and many others. One event can fan out to multiple targets, and producers know nothing about consumers.
Its parts:
Default bus receives AWS service events automatically — S3 object created, SageMaker job state change, Bedrock batch job completion, and so on.
Custom buses carry your application's own events.
Partner event sources deliver events from SaaS providers (Salesforce, Zendesk, Datadog) directly.
Schema registry discovers and versions event structures, generating code bindings.
Archive and replay stores matched events and replays them later.
EventBridge Pipes provides point-to-point integration with optional filtering, enrichment, and transformation between a source and a target.
EventBridge Scheduler runs one-time or recurring scheduled invocations at scale.
Why it matters here
EventBridge is how generative pipelines start and how they chain without coupling. The canonical pattern: a document lands in S3, EventBridge routes the event to a Step Functions workflow that extracts and summarizes it. Nothing in S3 knows the workflow exists.
The decoupling property is what the exam tests. When a stem says a new consumer must be added without modifying the producer, or several systems must react to the same event independently, that's EventBridge. Contrast with the alternative designs: polling wastes money and adds latency; direct invocation couples producer to consumer and breaks when a consumer fails.
Archive and replay is the operational-resilience answer — reprocess events after fixing a bug, or rebuild a downstream store — and it's easy to forget because it's not part of the happy path.
Scheduler is the modern answer to recurring jobs (a nightly batch inference run), superseding CloudWatch Events rules for that purpose at scale.
Constraints
Delivery is asynchronous and at-least-once, so targets must be idempotent.
Event payloads are limited (256 KB) — large content goes in S3 with the event carrying a pointer.
Rules match on event content, so events need enough structure to match on; badly designed events produce rules that can't discriminate.
Ordering is not guaranteed. Where sequence matters, that's SQS FIFO or a workflow.
There is small routing latency, and target failures need a DLQ configured to avoid silent loss.
EventBridge vs. SNS vs. SQS
This is one of the most frequently tested discriminations in AWS generally, and the clean way to hold it is by what the mechanism is for:
SQS is a queue. One message, one consumer, pulled when the consumer is ready. Its purpose is buffering and decoupling of pace — the producer can run faster than the consumer without anything breaking.
SNS is a topic. One message, many subscribers, pushed immediately. Its purpose is fan-out — notifying multiple parties of the same thing, including to endpoints like email and SMS that no other service reaches.
EventBridge is a router. Events matched by content and delivered to targets chosen by rules. Its purpose is routing logic — different events going to different places based on what's in them, plus SaaS and AWS service integration, schema management, archive and replay.
So: smooth out load or process work reliably → SQS. Tell many things at once, or reach email/SMS → SNS. Route by content, integrate SaaS or AWS events, replay → EventBridge.
They compose constantly, and the composite pattern is worth memorizing: EventBridge or SNS fanning out to multiple SQS queues, each buffering for its own consumer. That gives fan-out and per-consumer pace independence, and it's a very common correct answer for resilient generative pipelines.

Amazon SQS
What it is
SQS is a managed message queue. Producers send messages; consumers poll, process, and delete them. Two types:
Standard queues — nearly unlimited throughput, at-least-once delivery, best-effort ordering.
FIFO queues — strict ordering within a message group and exactly-once processing, at lower throughput.
Key mechanics: visibility timeout (a received message is hidden from other consumers while being processed; if not deleted before it expires, it reappears — which is what makes failure recovery automatic); dead-letter queues with a redrive policy after N failed receives; long polling to reduce empty receives and cost; delay queues; and a 256 KB message limit with the Extended Client Library storing larger payloads in S3 and passing a pointer.
Why it matters for generative workloads
SQS is the answer to the mismatch that defines these systems: requests arrive in bursts; foundation model capacity is rate-limited. Calling Bedrock directly from a request handler means users see throttling errors during peaks. Putting a queue in front means the burst lands in the queue and consumers drain it at whatever rate the model quota allows. Nothing is lost; work is merely delayed.
That single insight answers a family of questions. When a stem describes throttling under load, dropped requests during peaks, or the need to process a spike without over-provisioning, buffering with SQS is the architectural answer — often alongside backoff, and as a cheaper alternative to Provisioned Throughput.
The DLQ is the second thing to remember: model calls that fail repeatedly — malformed input, content that trips a guardrail, a document too large — need somewhere to go for inspection rather than infinite retry, which costs money each time.
Visibility timeout must exceed processing time, and since model calls can take tens of seconds, a default timeout that's too short causes the same message to be processed multiple times, each incurring inference cost. That's a good troubleshooting stem: duplicate outputs and unexplained cost.
Constraints
Standard queues are at-least-once, so consumers must be idempotent — and for generative work, duplicate processing is a cost problem as well as a correctness one. Standard queues don't guarantee order. FIFO queues trade throughput for ordering and exactly-once. Messages are retained for up to fourteen days. Polling means consumers must exist and run.
When not to use it
When multiple independent consumers each need the message — a queue message is consumed once, so that's SNS or EventBridge fanning out to per-consumer queues.
When the caller needs a synchronous response. A queue is fire-and-forget; a request/response pattern needs API Gateway with Lambda, or an asynchronous pattern where the client polls or gets notified.
When routing depends on content — that's EventBridge.

Amazon SNS
What it is
SNS is managed pub/sub. Publishers send messages to a topic; every subscriber receives a copy. Subscribers can be SQS queues, Lambda functions, HTTP/S endpoints, email, SMS, and mobile push. Message filtering policies let each subscriber receive only messages matching attributes it cares about. FIFO topics provide ordering when paired with FIFO queues. Messages can be archived and replayed, and delivery failures can route to a DLQ.
Where it fits
SNS is fan-out and notification. In generative architectures it appears in two recurring roles.
Notifying humans. Long-running asynchronous work — a batch inference job, a SageMaker training job, a Rekognition video analysis, a Textract async job — completes and someone must be told. SNS reaches email and SMS, which EventBridge and SQS do not. When a stem says "notify the team when processing completes," SNS is the answer.
Fanning out to multiple pipelines. One event, several independent downstream processes, each with its own SQS queue.
Constraints and the boundary with EventBridge
SNS pushes immediately with no buffering — if a subscriber is down, delivery fails (retried per policy, then DLQ). It filters on message attributes, which is coarser than EventBridge's content-based pattern matching, and it has no schema registry, no archive-and-replay in the EventBridge sense, and no SaaS partner integrations.
The rule of thumb: SNS for simple fan-out and for reaching humans; EventBridge when routing depends on event content or when you need AWS/SaaS event sources, schemas, or replay. Many AWS services emit to SNS natively, which is often why SNS appears in a correct answer.

Amazon AppFlow
What it is
AppFlow is a managed data transfer service between SaaS applications and AWS, without writing integration code. You configure a flow: a source (Salesforce, ServiceNow, Slack, Zendesk, Google Analytics, SAP, Marketo, and others), a destination (S3, Redshift, Snowflake, or back into a SaaS app), a trigger (on-demand, scheduled, or event-driven), and optional field mapping, filtering, validation, and transformation. Data can be encrypted with your KMS key and can travel over PrivateLink rather than the public internet.
Where it fits
The generative use case is getting SaaS data into a place a model or knowledge base can use. Support tickets in Zendesk, opportunities in Salesforce, incidents in ServiceNow — these live behind APIs with pagination, rate limits, and auth, and hand-building that ingestion is unglamorous work. AppFlow lands it in S3, where a Knowledge Base or an analytics pipeline picks it up.
The discrimination worth holding: AppFlow moves SaaS data on a schedule; connectors in Q Business and Knowledge Bases index it directly. If the requirement is a searchable assistant over Salesforce content, a native connector is less work. If the requirement is the data itself in S3 for multiple consumers — analytics, ML training, and a knowledge base — AppFlow is right. Ask whether the destination is a search index or a data store.
Constraints
Limited to supported connectors, though custom connectors are possible. Transformation is basic — real transformation belongs in Glue. Scheduled runs mean bounded freshness. Volume limits per flow run apply, and SaaS-side API quotas are a real constraint at scale.
Don't confuse it with Glue (ETL over data at scale, with a catalog), DataSync (bulk file transfer between storage systems), or Transfer Family (managed SFTP endpoints). AppFlow's specific niche is SaaS APIs.

AWS AppConfig
What it is
AppConfig, a capability of Systems Manager, manages application configuration and feature flags separately from application code. You store configuration profiles, apply validators (JSON Schema or a Lambda) so bad configuration is rejected before deployment, and roll changes out with a deployment strategy defining growth rate, bake time, and automatic rollback triggered by CloudWatch alarms. Applications retrieve configuration through polling or the AppConfig Agent, picking up changes without redeployment.
Why it matters for generative applications
Several things you'd otherwise hard-code are exactly what you want to change without a deployment, and often quickly under pressure: which model a feature uses, temperature and max-token settings, feature flags for a generative capability, and thresholds for guardrails or human review routing.
Two exam-relevant patterns:
Gradual rollout with automatic rollback. Switching to a new model version is risky; a deployment strategy that ramps traffic and rolls back on a CloudWatch alarm is the safe pattern, and the answer when a stem asks how to roll out a model change safely.
A kill switch. A feature flag that disables a generative feature instantly, without a deployment, is the answer to "we need to be able to turn it off immediately if it misbehaves."
The boundary with Prompt Management
Both change behavior without redeploying, and both are offered as distractors for each other. Bedrock Prompt Management is purpose-built for prompts — versions, variants, variables, invocation by ARN. AppConfig is general application configuration — flags, thresholds, model selection, timeouts, with validation, staged rollout, and automatic rollback.
If the stem is about prompt text being iterated by non-developers, Prompt Management. If it's about operational configuration — turning a feature off, ramping a change, adjusting a threshold — AppConfig. And note AppConfig has the rollback machinery Prompt Management lacks, which is why "safely roll out and automatically revert" points at AppConfig even in a generative context.
Constraints
Configuration is retrieved by polling, so changes propagate on that interval rather than instantly. Configuration data has size limits, and this is not a secrets store — credentials belong in Secrets Manager or Parameter Store. Rollback depends on having meaningful CloudWatch alarms defined, which is a prerequisite the stem sometimes hides.

The composite patterns worth recognizing
Exam answers are usually architectures, not services, and a handful of shapes recur:
Event-driven document processing. S3 → EventBridge → Step Functions → (Textract → Bedrock → DynamoDB/S3) → SNS notification. The default answer for "process documents as they arrive."
Buffered inference. API Gateway → SQS → Lambda consumer → Bedrock, with a DLQ. The default answer for throttling, spiky load, or protecting a rate-limited model behind unpredictable demand.
Fan-out with independent pace. EventBridge or SNS → several SQS queues → separate consumers. The default when multiple downstream systems must react independently and at their own speed.
Large-scale batch. Distributed Map over S3, or Bedrock batch inference directly. Prefer Bedrock batch when the work is purely inference and cost dominates; prefer Distributed Map when each item needs multi-step processing, per-item error isolation, or non-Bedrock steps.
Human approval. Step Functions waitForTaskToken → notification → resume on approval. Use A2I instead when what's being reviewed is a model prediction with a confidence score.

Test yourself
A generative endpoint throttles during business hours. Give three answers in ascending order of cost, and say what each trades away.
When does Distributed Map beat Bedrock batch inference, and vice versa?
A pipeline works in testing and fails on real documents at a Step Functions boundary. What's the likely cause and the fix?
Duplicate summaries appear and inference cost is double the estimate, in an SQS-driven pipeline. What's misconfigured?
One event, four unrelated downstream systems, each processing at its own speed. What's the shape?
A stem needs a model change rolled out gradually with automatic revert on error. Which service, and why not Prompt Management?
Salesforce data must feed both a knowledge base and an analytics pipeline. AppFlow or a native connector — and what decides it?
Why is an agent the wrong answer for a fixed five-step pipeline, and which two services are right depending on runtime and approval needs?

Unstarred

Dunk (exclude from study)

Application Integration

Review Questions

Todos

Sensemaker