How to do sentiment analysis on AWS (2026).

IWhat sentiment analysis on AWS actually involves

Sentiment analysis sounds like one thing — "is this text positive or negative?" — but in production it is three or four questions stacked on top of each other, and the architecture you build depends on which of them you actually need to answer.

The naïve version is a single label per piece of text: this review is Positive, this ticket is Negative. That is genuinely useful and AWS makes it a single API call. But the moment a team starts acting on the results, the questions multiply. What is the sentiment about? A hotel review can be glowing about the location and scathing about the staff in the same paragraph — one overall label hides that. Why is the customer unhappy? Sentiment without a theme ("billing," "shipping delay," "a specific feature") tells you the temperature but not the cause. What does the customer want? Sentiment is not intent — an angry message can be a cancellation, a refund request, or a bug report, and you route each differently.

So "sentiment analysis" in practice is usually a small family of related tasks: overall sentiment (one label or score per item), aspect-based / targeted sentiment (sentiment per topic or entity within the text), intent or category classification (what the message is about or asking for), and theme extraction (the recurring topics across a whole corpus of feedback). The more of these you need — and the more nuance the text carries — the more the right tool shifts from a fixed-label NLP API toward a language model you can instruct.

On AWS that maps cleanly onto two engines. Amazon Comprehend is the managed NLP service: it returns sentiment, targeted sentiment, entities, key phrases, PII, and language detection through a simple API, with no prompt engineering and a low per-character price. Amazon Bedrock gives you foundation models (Claude, Amazon Nova, Llama, Mistral, and more) that read the text and return whatever you define — a nuanced score, sentiment per custom aspect, intent, reason codes, all as structured JSON. The first decision in any sentiment project on AWS is which of these does the work — and the honest answer is often "both, for different slices."

One framing worth keeping throughout: sentiment analysis is a high-value, low-risk GenAI use case. The input is text you already have, the output is a label or a small JSON object you can check against the source, errors are bounded (a mislabelled review is recoverable, not catastrophic), and you can measure accuracy directly against human labels. That is exactly why it is often the first analytics or GenAI workload a team ships — and why it is a natural fit for a funded proof-of-concept.

IIAmazon Comprehend vs an LLM on Bedrock — the core choice

The decision that shapes the whole system is which engine reads the text. Comprehend is a fixed-output NLP API; a Bedrock LLM is an instruction-following model. They overlap in the easy cases and diverge sharply as the task gets nuanced or custom — and the cost and effort profiles are very different.

The honest framing: if the standard labels are enough and the text is straightforward, use Comprehend; when you need nuance, your own categories, intent, or a custom schema, use an LLM. Comprehend is cheaper per item, faster to ship (no prompt to write, no JSON to coax), and entirely deterministic in shape — you always get the same fields back. A Bedrock LLM is more expensive and needs prompt and evaluation work, but it reads context, handles sarcasm and mixed feelings, scores sentiment on a scale, classifies against categories you define in the prompt, extracts intent, and returns exactly the JSON you ask for. The two are not rivals so much as different tools — and a large fraction of production systems use both.

IIIThe reference architecture on AWS, stage by stage

Whether you analyse one message live or a hundred million overnight, the system runs the same logical stages. Knowing each one is what lets you debug a pipeline that returns wrong labels or vague themes, because nearly every quality and cost problem traces back to a specific stage.

It helps to see the whole shape first. Feedback arrives from many sources, lands somewhere durable, gets cleaned and (where needed) PII-redacted, is analysed by Comprehend and/or a Bedrock LLM, and the structured results are stored and visualised. The split between a real-time path (a user is waiting — a live chat sentiment, an incoming ticket to route) and a batch path (a backlog with a deadline, not a person, waiting) is the most important architectural decision after the engine choice, because it determines both latency and cost.

IVGetting aspect-based sentiment and clean JSON out of an LLM

The whole reason to reach for a Bedrock LLM over Comprehend is the richer, custom output — nuanced scores, sentiment per aspect you define, intent, reason codes. Getting that reliably is a prompt-and-validation problem, and a handful of patterns do almost all of the work.

The through-line of every good sentiment prompt is define the exact schema, constrain the labels, and force the model to ground its answer in the text. Unlike Comprehend, the LLM will happily return prose, vary its format, or invent a category if you let it — so the prompt's job is to pin the output shape, enumerate the allowed values, and stop embellishment. Set a low temperature for consistency and always validate the returned JSON.

• Fix the output schema explicitly: Ask for JSON only and describe every field and its type: e.g. { "overall": "positive|negative|neutral|mixed", "score": 1-5, "aspects": [{ "aspect": "...", "sentiment": "...", "evidence": "..." }], "intent": "...", "reason": "..." }. A fixed schema makes outputs comparable, machine-parseable, and easy to store as columns. Use the model's tool-use / structured-output mode where available to enforce it.
• Enumerate the allowed labels: Do not let the model freelance categories. List the exact sentiment values and, for intent or theme, the exact closed set of allowed categories ("billing, shipping, product_quality, account, other"). An open-ended "classify the intent" produces inconsistent, unaggregatable labels; a closed list produces clean facets you can chart.
• Define the aspects (for aspect-based sentiment): For aspect-based sentiment, tell the model which aspects to score — either a fixed list you care about ("battery, screen, price, support") or "extract the aspects mentioned and score each." A fixed list gives consistent columns across items; open extraction discovers aspects you did not anticipate. Many systems do a discovery pass to find the aspects, then lock the list for production.
• Ground each judgement in evidence: Ask the model to attach the supporting phrase or sentence to each aspect or to the overall sentiment ("evidence": the exact span). This both improves faithfulness and lets a human verify why an item was labelled the way it was — invaluable when a stakeholder disputes a result.
• Ask for intent and reason alongside sentiment: The LLM's edge is doing several jobs in one call. In the same schema, capture the customer's intent (what they want) and a one-line reason for the sentiment. This is what turns "47% negative this week" into "47% negative, driven by checkout failures and slow support replies" — the actionable version.
• Handle edge cases honestly: Tell the model what to do with empty, off-topic, spam, or non-text inputs — return "neutral" with intent "none" or a flag, not a fabricated sentiment. This matters most in batch, where a bad input should produce an honest null rather than noise that pollutes the aggregate.
• Few-shot the tricky cases: A handful of labelled examples in the prompt — especially sarcasm, mixed sentiment, and your domain's edge cases — sharply raises consistency on exactly the items where the LLM beats Comprehend. Draw them from your evaluation set (section V) so they reflect real, hard inputs.

VEvaluating accuracy — because "it looks right" is not a metric

Sentiment is a classification task, which is good news: accuracy is directly measurable. Build a labelled test set once and you can compare Comprehend against an LLM, compare models and prompts, and catch regressions — instead of trusting a vibe.

Assemble a golden set first: a few hundred to a few thousand real items, each hand-labelled by humans with the ground-truth overall sentiment and (if you do aspect-based) the per-aspect labels and intent. Label a few hundred per important segment (product line, language, channel) so you can see where each engine is weak. Then score every candidate — Comprehend, each LLM, each prompt — on the same set and read standard classification metrics, not a single accuracy number that hides the failure modes.

• Per-class precision, recall, F1: Overall accuracy lies when classes are imbalanced (most reviews are positive). Read precision and recall per class — especially for Negative, the class you most need to catch. A model that is 92% accurate but misses half your negative feedback is failing at the actual job. The confusion matrix shows exactly which classes get confused (Neutral vs Mixed is the classic).
• Agreement with human labels: Treat the human labels as ground truth and measure how often each engine agrees. Sentiment is partly subjective, so also sanity-check human–human agreement on a sample — if two annotators disagree 15% of the time, no model will exceed that ceiling, and you should not chase it.
• Aspect and intent accuracy separately: When you do aspect-based sentiment and intent, score them as their own tasks: did the model find the right aspects, assign the right sentiment to each, and pick the right intent from the allowed set? An item can have correct overall sentiment but wrong aspects, and you want to know.
• Segment the metrics: Break accuracy down by language, channel, length, and product area. Sentiment models are reliably weaker on short text (a three-word review), on non-English, and on sarcasm-heavy channels (social). Segmenting tells you exactly where to send the cascade's LLM tier and where Comprehend is fine.

VIAnalysing millions of items — batch, and the bulk pattern

Scoring one live message is an API call. Scoring a backlog of ten million reviews, or re-scoring a corpus when you switch models, is a data-engineering job — and the right tools for it on AWS halve the bill for work nobody is waiting on in real time.

A huge share of sentiment work is not interactive: digesting an archive of reviews, scoring a quarter of survey responses, condensing a year of support tickets, or back-filling sentiment across an entire feedback history. Nobody is staring at a spinner — you just need the whole job done by a deadline. Both engines have a batch mode for exactly this. Amazon Comprehend async jobs (StartSentimentDetectionJob, StartTargetedSentimentDetectionJob) read a corpus from S3 and write results back to S3 in one managed job. Amazon Bedrock batch inference does the same for the LLM path: write your requests as JSONL to S3, submit one asynchronous job (CreateModelInvocationJob), and Bedrock processes them in the background and writes one structured result per input back to S3 — at roughly 50% of the on-demand token rate. For corpus-scale sentiment, batch is the single easiest cost win.

The bulk pattern, end to end: land the corpus in S3, run a cheap Comprehend async pass over everything for overall sentiment, language, and PII; select the slice that needs more (Mixed/low-confidence, high-value accounts, anything needing aspect-based sentiment or intent) and write those as JSONL requests; run a Bedrock batch job on a right-sized small model for that slice; reconcile both result sets back to your items by record id; and load the combined output into S3/Athena (or your warehouse) for the dashboard. Because each item is independent, both batch modes parallelise perfectly. Keep the real-time path (a user pastes text and waits, a ticket needs instant routing) on the synchronous APIs — often with prompt caching on the LLM if a long instruction or shared rubric repeats across calls — and send the bulk backlog to batch. See amazon-bedrock-batch-inference for the full mechanics and the cost math.

The two cost levers multiply here, which is the whole point. Use the cheap engine where it suffices (Comprehend, or a small Bedrock model) and run it on batch (~50% off). For a large corpus the combined effect over a frontier-model-on-demand baseline is routinely an order of magnitude or more. The cascade is what makes this affordable at scale: the expensive LLM only ever touches the fraction of items that genuinely need it, and even that fraction runs on batch on a small model.

VIIThe sentiment cost stack on AWS — where the money goes

A sentiment bill has a few line items, and which one dominates depends entirely on the engine. Comprehend is priced per unit of text; the LLM path is priced per token. Here is the full stack, the lever on each, and a worked example so you can reproduce the math for your own job.

The figures below are representative as of 2026 to show the shape of the bill, not a quote — always check the AWS pricing page for current rates. The headline: Comprehend bills per 100-character "unit" (a typical short review is one or two units), with a small per-unit price that drops for async/bulk; the LLM path bills per input + output token, so cost scales with how long each item is and how much JSON you ask back. For straightforward sentiment at scale, Comprehend is usually the cheaper engine by a wide margin; the LLM earns its higher price only on the items where its nuance and custom output matter — which is exactly what the cascade exploits.

VIIIWho pays for it: partner-filed funding and Activate credits

Everything above prices a sentiment pipeline if you pay AWS directly. Two kinds of AWS funding can offset it: funding a partner files for you when the work qualifies, and Activate credits you apply for yourself.

Partner-filed funding. If the work qualifies, your matched AWS partner can file POC (proof of concept) funding to test a sentiment pipeline on your own feedback data, or incremental workload (IW) funding if you already run on AWS and are launching new work. If you are moving to AWS from another cloud, it can file MAP migration funding. For startups this is typically $50K to $150K. Depends on the workload; AWS approves. Only a partner can request it, and it is tied to real work the partner does with you. See AWS partner funding.

AWS Activate credits. You apply for these yourself at aws.amazon.com/startups/credits: Activate Founders gives $1,000 to start, up to $5,000; Activate Portfolio gives up to $200,000 with an Org ID from your VC, accelerator or angel group if it is an Activate Provider. A consulting partner cannot file Activate for you. Bedrock usage generally draws down promotional credits, but check your credit terms: AWS promotional credits do not pay Savings Plans or Reserved Instance upfront fees.

CloudRoute matches you with one vetted AWS partner that can file that funding and help build the pipeline: ingestion, PII redaction, the Comprehend vs LLM split, aspect-based prompts, batch jobs, evaluation and the dashboard. Startups pay CloudRoute nothing; partners pay CloudRoute a monthly membership plus 10% of AWS-approved funding. If you only need Activate credits, apply yourself; you do not need us.