AWS Application Integration, Developer Tools & Other Service Categories

Task 3.8 questions are pure recognition. A scenario describes a need in one sentence — "a company wants to decouple two application components" or "developers need virtual desktops accessible from anywhere" — and four service names appear as options. The distractors are usually real services from a different category, so your fastest path to the answer is a two-step match: first identify which category the need belongs to, then pick the one service in that category that fits.

Here is the full map. The middle column is what the current exam guide lists as in scope; the right-hand column holds neighbours the guide lists as out of scope (or no longer lists), which still show up as distractors and are explained briefly in this lesson for contrast. Memorize the category headings as firmly as the services, because a question can ask the category directly ("Which service is an application integration service?").

Compute, storage, database, networking, and AI/analytics services belong to sibling task statements (3.3–3.7) and only appear here as distractors. If an option is EC2, S3, RDS, or SageMaker in a Task 3.8-style question, it is almost certainly wrong.

Application integration services let the parts of a distributed system communicate without being directly wired together. That property is called decoupling: if the producer and the consumer never call each other directly, one can fail, slow down, or scale independently without breaking the other. Four services carry this category, and each has a distinct communication shape.

Amazon SQS (Simple Queue Service) is a fully managed message queue. Producers put messages on the queue; consumers pull messages off it when they are ready. Each message is processed by one consumer, and the queue acts as a buffer that absorbs traffic spikes — if orders arrive faster than the backend can process them, they simply wait in the queue instead of being dropped.

Amazon SNS (Simple Notification Service) is publish/subscribe messaging. A publisher sends one message to a topic, and SNS pushes a copy to every subscriber — email addresses, SMS numbers, mobile push, Lambda functions, HTTP endpoints, or SQS queues. One message in, many deliveries out.

Amazon EventBridge is a serverless event bus. It receives events from AWS services, integrated SaaS applications, and your own code, then routes each event to targets based on rules that match the event's content. Think of it as the routing layer for event-driven architectures — "when an EC2 instance changes state, trigger this Lambda function."

AWS Step Functions orchestrates multi-step workflows as visual state machines. When a process has ordered steps, branching, retries, or waits — "validate the order, then charge the card, then if payment succeeds, reserve inventory" — Step Functions coordinates the services that perform each step.

If you remember one thing from this lesson, make it this pair. CLF-C02 tests SQS against SNS more than any other comparison in the task statement, and the distinction comes down to three axes: who initiates delivery, how many receivers get each message, and what problem you are solving.

The mnemonic: SQS is a waiting line, SNS is a loudspeaker. A message in SQS sits patiently until exactly one worker takes it; a message published to SNS is shouted at everyone who signed up to listen.

The fan-out pattern: SNS and SQS together

The two services are not rivals — the classic fan-out pattern combines them. An application publishes one message to an SNS topic, and several SQS queues subscribe to that topic. Each queue receives its own copy, and each downstream system processes its copy independently at its own pace. For example, a single "order placed" message can fan out to a fulfillment queue, an analytics queue, and an invoicing queue simultaneously. SNS provides the one-to-many broadcast; SQS provides the durable, buffered processing behind each subscriber. If a question describes one event that multiple independent systems must reliably process, the answer is SNS fanning out to SQS queues.

Here is how the application integration services and X-Ray combine in a realistic architecture — the kind of narrative the exam condenses into single-sentence questions.

A retail company runs an online store. When a customer places an order, the checkout service publishes an "order placed" message to an Amazon SNS topic. Three Amazon SQS queues subscribe to the topic: one feeds the warehouse fulfillment system, one feeds the analytics pipeline, and one feeds the invoicing service. During a flash sale, orders arrive far faster than the warehouse system can pick and pack — but nothing is lost, because the fulfillment queue buffers the backlog and workers pull messages as capacity allows. That is decoupling in action: the checkout service never slows down because a downstream consumer is busy.

Payment processing is a multi-step process with strict ordering: validate the card, charge it, and on success reserve inventory — with a refund path if reservation fails. The company models this in AWS Step Functions, which coordinates each step, handles retries, and shows the whole workflow visually so failures are obvious.

The company also uses a third-party SaaS fraud-detection tool. When that tool flags a suspicious order, the event lands on Amazon EventBridge, where a rule matches high-risk events and routes them to a Lambda function that places the order on hold. EventBridge is the natural home for this because it natively ingests events from SaaS partners and applies content-based routing rules.

Finally, when customers report slow checkouts, engineers turn to AWS X-Ray, which traces each request as it travels through the checkout service, the payment workflow, and the downstream consumers, pinpointing exactly which hop adds the latency. One flow, five services, each doing the one job its category name promises.

Business applications is the smallest category — two services. Amazon Connect is a cloud-based contact center: everything a company needs to run customer service — inbound and outbound calls, chat, agent routing, call flows — without buying telephony hardware, scaling with call volume and priced by usage. Any mention of a "call center," "contact center," or "customer service agents" points at Connect. Amazon SES (Simple Email Service) sends email at scale — bulk email (marketing campaigns, newsletters) and transactional email (order confirmations, password resets) from within an application.

SES vs SNS email is the trap. Both can put a message in an inbox, but they solve different problems. SES is an email-sending service: an application sends individual, often personalized messages — a receipt to one customer, a newsletter to a mailing list — to any recipient address. SNS sends the same notification to everyone subscribed to a topic, and an email address only receives it after the owner confirms the subscription; SNS can also reach SMS, mobile push, Lambda, HTTP endpoints and SQS queues, while SES is email only. The two often sit side by side in one application, each doing the job it is built for: SES for messages composed for individual recipients, SNS for notifications broadcast to whoever subscribed, on whatever channels they chose.

The customer enablement category is about who helps you use AWS. The exam guide lists one service in scope here, AWS Support, and lists AWS Managed Services, AWS Activate and AWS IQ as out of scope; they are covered briefly below because they are the natural contrasts when a question asks for the right kind of support assistance. AWS Support gives you access to AWS’s own engineers under a support plan; the current plans are Basic, Business Support+, Enterprise Support and Unified Operations (Developer and Business Support are discontinued on 1 January 2027, and Enterprise On-Ramp customers are being moved to Enterprise Support). A designated technical account manager (TAM) comes with Enterprise Support and Unified Operations, not Business Support+. Plan-by-plan detail belongs to Domain 4. AWS Managed Services (AMS) goes further: AWS operates your infrastructure for you on an ongoing basis — day-to-day operational tasks and incident response, following AWS best practices — for organizations that want to offload cloud operations. AWS Activate is AWS’s program for startups: eligible early-stage companies get AWS credits, support benefits and training.

The key distinction is advise vs operate. Support engineers and a TAM answer questions, troubleshoot and give architecture guidance, but your team still runs the environment; AMS takes over the running of it. The two are not exclusive — a company can use AMS for operations and an Enterprise Support plan for its TAM and engineering guidance.

For hired, project-based help two routes remain. AWS Professional Services is AWS's own consulting team, engaged for time-bound projects such as a migration or a new platform design — not ongoing operations. AWS Partners (the AWS Partner Network) sell consulting and managed services, many of them through AWS Marketplace as professional-services listings. AWS IQ, which the exam guide mentions only in its out-of-scope list, was a marketplace for hiring third-party AWS-certified freelancers; it is discontinued (no new proposals from 20 August 2025, and the service closed on 28 May 2026), and AWS now points customers to AWS Marketplace professional services and AWS Partners. If you meet the name in older material, recognise it as "hire an outside certified expert for a project" — never as AWS operating or supporting your account.

The developer tools category collapses into a simple story: each service owns one stage of building and running software. Learn the stage, and the name follows. The exam guide lists four developer tools as in scope — the AWS CLI, AWS CodeBuild, AWS CodePipeline and AWS X-Ray. CodeDeploy, CodeArtifact, CloudShell and AppConfig are listed as out of scope, and CodeCommit, CodeStar and Cloud9 are not listed at all; they are described here briefly because they fill in the lifecycle around the in-scope tools and appear as distractors.

The Code* family covers CI/CD. AWS CodeCommit is the managed Git repository service — private source control hosted on AWS. (AWS closed CodeCommit to new customers in 2024 but returned it to full general availability in November 2025, so it is a current choice again.) AWS CodeBuild compiles source code, runs tests, and produces build artifacts — a managed build server with no infrastructure to maintain. AWS CodeDeploy automates deploying those artifacts to EC2 instances, on-premises servers, Lambda, or ECS. AWS CodePipeline is the CI/CD orchestrator that chains the whole release process — source, build, test, deploy — into an automated pipeline. AWS CodeArtifact is a managed package (artifact) repository for dependencies such as npm, Maven, and PyPI packages. AWS CodeStar was a unified dashboard for creating and managing software projects in one place; AWS discontinued it in July 2024, so know it only as the exam-guide name.

Two services put a development environment in your browser. AWS Cloud9 is a full cloud-based IDE — write, run, and debug code from a browser. It has been closed to new customers since July 2024 (existing customers keep it), so for a new account CloudShell or a local IDE with the AWS Toolkit is the practical route. AWS CloudShell is lighter: a browser-based terminal, pre-authenticated with your console credentials and the AWS CLI pre-installed, for running commands without configuring anything locally. IDE for writing code = Cloud9; shell for running CLI commands = CloudShell. (The AWS CLI itself — the command-line interface for managing AWS from scripts and terminals — also sits in this category.)

Two more handle running applications. AWS X-Ray provides distributed tracing: it follows individual requests as they pass through microservices so you can debug errors and find latency bottlenecks. Any question about "tracing requests across services" or "analyzing performance of a distributed application" is X-Ray. Three services are easy to mix up because all of them "record what happened":

AWS AppConfig manages application configuration and feature flags, letting you roll out configuration changes safely and gradually without redeploying code.

End-user computing services answer one question: how do you present a computing environment running in AWS on an end user's own machine? The three services differ only in how much of an environment they deliver — a whole desktop, a single application, or a secured browser session.

Amazon WorkSpaces provides full virtual desktops — Desktop-as-a-Service (DaaS). Each user gets a persistent Windows or Linux desktop running in AWS that they can access from a laptop, thin client, or tablet anywhere. It replaces buying and managing physical desktop fleets and is the go-to answer for remote workforces, contractors who must not hold data locally, and bring-your-own-device policies.

Amazon AppStream 2.0 (renamed Amazon WorkSpaces Applications in November 2025; the exam guide still uses the AppStream 2.0 name) streams individual applications — not whole desktops — to any device with a browser. The application runs on AWS; only the pixels travel to the user. Classic uses: giving students access to heavyweight engineering or design software from any laptop, or delivering a legacy Windows application to users without installing anything. Desktop vs single app is exactly the WorkSpaces vs AppStream distinction the exam draws.

Amazon WorkSpaces Secure Browser (formerly Amazon WorkSpaces Web) provides low-cost, secure browser access to internal websites and SaaS applications. Users browse company-internal web apps through a session hosted in AWS, so corporate content never touches the local device. When the need is only secure browsing — not a full desktop or a native app — this is the answer.

This category also carries the skill the guide phrases as "identifying the services that can present the output of virtual machines on end-user machines" — read that sentence in a question and jump straight to this trio.

The exam guide lists one frontend web and mobile service as in scope, AWS Amplify. Two neighbours — AWS AppSync (not listed) and AWS Device Farm (listed as out of scope) — are worth recognising because they share the territory and appear as distractors.

AWS Amplify is the fastest way to build, deploy, and host full-stack web and mobile applications. It bundles frontend hosting with continuous deployment from a Git repository and backend building blocks — authentication, data, storage, APIs — so a small team can ship a working app without assembling a dozen services by hand. Trigger phrases: "quickly build and host a web app," "full-stack mobile backend," "frontend developers with minimal AWS experience."

AWS AppSync is a managed GraphQL API service. It lets applications query exactly the data they need through a single GraphQL endpoint, aggregates data from multiple sources (DynamoDB, Lambda, HTTP APIs), and supports real-time subscriptions and offline data synchronization for mobile clients. If the question says GraphQL, the answer is AppSync — that keyword alone decides it.

AWS Device Farm is an application testing service that runs your web and mobile apps on real, physical phones, tablets, and browsers hosted by AWS. Instead of buying hundreds of handset models, you upload the app and Device Farm executes tests across the device matrix in parallel, returning logs, screenshots, and videos. Trigger: "test the app on many real devices."

Amplify vs AppSync in one line: Amplify is the whole toolkit for shipping an app; AppSync is the specific managed API layer (and Amplify can use AppSync under the hood).

The Internet of Things category is anchored by AWS IoT Core, the in-scope service; AWS IoT Greengrass is listed as out of scope but is the natural contrast, because the two split by where the work happens — in the cloud, or on the device.

AWS IoT Core lets connected devices communicate with the AWS Cloud securely and at massive scale. Sensors, appliances, vehicles, and industrial equipment connect using lightweight protocols such as MQTT, authenticate with certificates, and publish messages to IoT Core. IoT Core rules (the rules engine) then filter and transform those messages with SQL-like statements and send them to other AWS services — a database such as DynamoDB, a stream or analytics service, Lambda, S3, SNS and more — and one rule can send the same message to several destinations. General-purpose messaging services such as SQS are not device-connection services; in an IoT design they are destinations a rule can send to. It also lets applications send commands back to devices. If a scenario says "connect millions of sensors to AWS" or "securely ingest device telemetry," the answer is IoT Core.

AWS IoT Greengrass extends AWS to the edge: it is software that runs on the devices (or on local gateways) themselves, letting them execute compute, run Lambda functions, perform machine-learning inference, cache data, and communicate with each other locally — even while disconnected from the internet. When connectivity returns, Greengrass syncs with the cloud. The trigger phrases are unmistakable: "process data locally on the device," "run inference at the edge," "must keep operating offline or with intermittent connectivity."

The two are complements, not competitors, and edge designs usually use both. Greengrass on a device or gateway evaluates readings and acts locally — including while the link to AWS is down — then sends data (often filtered or summarized) to IoT Core when connected; IoT Core rules route it on to storage and analytics in the Region. The general principle: logic that must keep working when the network is down has to run on or near the device, and anything that must reach cloud storage and analytics needs a cloud-side entry point to receive and route it.

One caution: do not confuse IoT "edge" with content-delivery "edge." CloudFront edge locations (network-services territory) cache web content near users; Greengrass puts your compute on your devices.