Amazon Lex Pricing Per Request (2026): Text, Speech & Free Tier Breakdown

1. Introduction

Building conversational applications with Amazon Lex is relatively straightforward. Understanding what they cost over time is not.

At first glance, the pricing model appears simple pay per request, scale as usage grows. But in practice, costs are shaped by how conversations unfold, how long they last, and which supporting services are involved behind the scenes.

A short text interaction might cost almost nothing. A multi-turn voice conversation, on the other hand, can quickly add up when each exchange, second of audio, and integration contributes to the final bill.

This makes pricing less about individual rates and more about how the system behaves in real usage.

For a deeper look at how Amazon Lex applications are built and integrated, refer to this detailed blog.

2. Amazon Lex Pricing at a Glance (2026)

At a high level, Amazon Lex pricing is based on how users interact with a bot either through text, voice, or continuous streaming. Each interaction carries a small cost, but the total bill depends on how frequently and how long those interactions occur.

Quick Pricing Snapshot

Text Requests

Every message sent by a user is treated as a single request.
In short, a conversation is not billed as one unit it is broken down into multiple billable steps.

A simple exchange like:

• User asks a question
• Bot responds

…already involves at least one billable interaction. As conversations grow longer, so does the total count.

Speech Requests

Voice interactions follow the same structure but include additional processing layers. Because of this, they carry a higher cost compared to text.

They are commonly used in:

• Voice assistants
• Call center automation
• IVR systems

Streaming (15-Second Billing)

In real-time voice scenarios, Amazon Lex uses a streaming model, where billing is tied to time rather than discrete requests.

A useful way to think about it:

Sending a message is like sending a text. Streaming is like keeping a call open billing continues as long as the session is active.

Even short pauses or extended conversations can influence the total cost under this model.

Free Tier

Amazon Lex includes a limited free tier along with AWS credits introduced in recent updates.

This works well for:

• Initial development
• Testing conversation flows

However, once usage becomes consistent or user traffic increases, the system quickly moves into paid usage.

Where Costs Begin to Add Up

The pricing model itself is straightforward. The complexity comes from how it plays out in real usage:

• Conversations with multiple back-and-forth turns
• Voice-based interactions instead of text
• Long-running or continuous sessions
• Higher user concurrency

A chatbot handling short queries may remain inexpensive, while a voice-based system with longer conversations can scale costs much faster than expected.

3. Amazon Lex V1 vs V2: What You Need to Know Before Pricing

Amazon Lex has evolved significantly over time, and understanding the difference between its versions is important before looking at pricing in detail.

The Shift from V1 to V2

Earlier implementations of Amazon Lex were built on V1. While functional, it followed a more rigid structure and is now being phased out.

New deployments are expected to use V2, which reflects the current design, capabilities, and pricing model.

Why V2 Defines Pricing Today

All current pricing behavior aligns with how V2 operates:

• Conversations are handled more flexibly
• Bot configuration and scaling are more streamlined
• Integration with other AWS services is more consistent

As a result, any discussion around cost whether it’s request handling, scaling, or estimation assumes a V2-based system.

Why This Distinction Matters

Cost estimation depends on how interactions are processed under the hood. Using outdated assumptions from V1 can lead to incorrect expectations.

A simple way to look at it:

Pricing is tied to how the system behaves and V2 defines that behavior today.

For accurate planning:

• Calculations should reflect V2 interaction patterns
• Conversation flow and request handling should be considered in their current form

4. How Amazon Lex Billing Actually Works

Billing in Amazon Lex comes down to one simple rule:

Every user input that the system processes counts as a request.

Whether it is typed or spoken, the system receives input, interprets it, and generates a response. That full cycle is what gets billed.

The difference between text and speech is not in how they are counted, but in how much processing is involved. Text goes straight into intent recognition. Speech adds an extra layer audio has to be converted before it can be understood which makes it more expensive per request.

Where things start to become less obvious is in how conversations actually behave. Interactions are rarely one-off. A user asks something, the bot asks for clarification, the user responds again. Each of these steps is processed separately.

A single conversation can easily become multiple billable units.

A 5-turn interaction is not one request; it is 5.

The model remains simple at the surface, but the cost is driven by how conversations expand over time.

5. Amazon Lex Pricing Breakdown (2026 Rates)

Once billing is understood at the request level, pricing becomes a matter of how each type of interaction is charged in Amazon Lex.

Text interactions form the baseline. Each message sent by a user is treated as a single request, typically priced at around $0.00075 per request. This makes text-based applications predictable and relatively cost-efficient, especially when conversations are short and direct.

Speech follows the same request-based structure, but includes additional processing. Each voice input is converted, interpreted, and responded to, which results in a higher cost usually around $0.004 per request. The difference is not in how requests are counted, but in the processing required before a response is generated.

A different pricing behavior appears with streaming interactions. Instead of counting individual requests, billing is based on duration. Streaming is typically charged at approximately $0.002 per 15 seconds for text and $0.0065 per 15 seconds for speech.

This shifts the cost model entirely.

A short interaction remains inexpensive, but a prolonged session continues to accumulate cost even if the interaction pace is slow. In this case, time becomes the primary cost driver, not the number of inputs.

Across regions, pricing remains broadly consistent. While there may be minor variations depending on deployment location, they are rarely significant enough to influence cost decisions. In practice, usage patterns how often users interact and how long conversations last have a far greater impact than geography.

6. Amazon Lex Free Tier & Post-2025 Credit System

The free tier in Amazon Lex is often the first reference point for estimating cost, but it can be misleading if taken at face value.

It provides a limited number of text and speech requests that reset periodically. This works well for testing, small prototypes, or controlled environments where interaction volume is low.

The challenge appears when usage starts to resemble real-world behavior.

Conversations become longer, users interact more frequently, and request counts increase quickly. At that point, the free tier stops being representative of actual cost.

To understand this better, it helps to separate how the free tier and credit system behave:

Free Tier vs Credit System (with Actual Limits)

The introduction of AWS credits adds another layer. Instead of fixed limits alone, usage is now supported by a pool of credits that can be consumed across services. This makes early usage feel almost negligible, but only temporarily.

Once credits are exhausted, the system shifts fully into pay-as-you-go pricing.

This creates a common gap in expectation:

• Early usage feels inexpensive
• Production usage behaves very differently

The free tier helps in getting started, but it does not reflect how cost scales.

7. Hidden Costs of Amazon Lex: AWS Services That Increase Your Bill

The cost of using Amazon Lex rarely comes from Lex alone. In most real-world setups, it operates alongside other AWS services, each contributing quietly to the overall cost.

A single interaction may appear simple on the surface—user input and bot response but behind that interaction, multiple services are often involved.

AWS Lambda: Execution Behind Every Interaction
AWS Lambda is often used to handle validations, database lookups, or business logic. Each time it is triggered, it incurs cost based on execution time and number of invocations. In multi-turn conversations, this can happen several times within a single user flow.

Amazon Polly: The Cost of Voice Responses
For voice-enabled applications, Amazon Polly converts responses into speech. While each response may seem small, frequent or longer responses increase total usage quickly.

Amazon Connect: When Conversations Become Call Duration
In contact center setups, Amazon Connect introduces a different pricing dimension. Billing is tied to call duration, meaning longer conversations continue to accumulate cost regardless of request count.

Amazon CloudWatch: Logging at Scale
Monitoring through Amazon CloudWatch tracks interactions and system behavior. At scale, logging can generate large volumes of data, adding incremental but consistent cost.

Amazon S3: Storing Conversations Over Time
Logs, transcripts, and audio files are often stored for analysis or compliance. Over time, this data grows and contributes to ongoing storage costs.

Individually, these costs are small. But in combination, they often exceed the base cost of Lex itself.

For a deeper understanding of how these services integrate within a Lex-based architecture, refer here

8. Real-World Amazon Lex Cost Scenarios

Pricing becomes easier to understand when viewed through actual usage patterns. The same pricing model behaves very differently depending on how the system is used.

A simple text-based chatbot handling a limited number of queries each day remains inexpensive. Each interaction is short, request counts are low, and no additional services are heavily involved. In such cases, costs grow slowly and remain predictable.

The behavior changes with voice-based applications. When responses are generated using Amazon Polly, each interaction includes both processing and audio generation. Even with moderate usage, costs increase due to the added layer of speech processing.

In contact center environments, the cost structure shifts further. With Amazon Connect in the flow, billing is influenced by call duration. A single interaction is no longer just a request it becomes a time-based session. Longer conversations, even with fewer requests, can result in higher costs.

At scale, the pattern becomes more pronounced. Applications handling large volumes of users with multi-turn conversations accumulate cost across multiple dimensions requests, processing, and supporting services. What starts as a small cost per interaction begins to multiply across thousands or millions of interactions.

The key difference across these scenarios is not the pricing itself, but how usage evolves. Short, direct interactions remain efficient. Longer, layered conversations introduce complexity and with it, higher cost.

9. How to Estimate Your Amazon Lex Costs

Estimating costs in Amazon Lex is not just about applying pricing rates—it starts with understanding how interactions translate into billable units.

At the most basic level, Amazon Lex follows a simple rule:

Each user input is processed as a separate request.

This means cost estimation begins by translating real usage into request volume.

Step 1: Estimate Total Requests

Start with how users interact with the system:

• Number of users per day or month
• Average conversations per user
• Average turns per conversation

A practical way to calculate this:

Total Requests = Users × Conversations per User × Turns per Conversation

For example:

• 1,000 users
• 2 conversations each
• 4 turns per conversation

Total = 8,000 requests

This is where most underestimation happens. Conversations rarely stay single-turn—each clarification or follow-up increases the request count.

Step 2: Apply Pricing Based on Interaction Type

Once request volume is known, it maps directly to pricing:

• Text requests ≈ $0.00075 per request
• Speech requests ≈ $0.004 per request

If the application uses both, the cost becomes a mix of the two.

For example:

• 8,000 text requests → ~$6
• 8,000 speech requests → ~$32

Same interaction volume, very different cost behavior

Step 3: Account for Streaming (If Used)

If the application uses streaming instead of request-based interaction, the model changes.

Instead of counting requests:

• Cost depends on session duration
• Typically billed per short time intervals (e.g., 15 seconds)

This means:

• Short conversations → low cost
• Long sessions → cost accumulates continuously

In this model, time replaces request count as the primary driver.

Step 4: Add Supporting Service Costs

This is where most estimates fall short.

In real deployments, Lex rarely works alone. Additional services contribute to the final cost:

• AWS Lambda → per invocation + execution time
• Amazon Polly → per character generated
• Amazon Connect → per-minute call duration
• Amazon CloudWatch → logs and metrics
• Storage (e.g., transcripts, audio)

For example, in a contact center scenario:

• A 10-minute call may cost ~$0.38 just in call duration alone
• Lex requests are only one part of the total cost

Step 5: Combine Everything into a Working Estimate

A practical estimation model looks like this:

Total Cost = (Requests × Cost per Request) + Voice/Streaming Costs + Supporting AWS Services

The formula itself is simple.
The challenge lies in estimating inputs correctly.

What Actually Impacts Accuracy

The difference between a rough estimate and a realistic one comes down to:

• Underestimating conversation length
• Ignoring multi-turn behavior
• Not accounting for voice processing
• Overlooking supporting AWS services

Amazon Lex pricing is predictable at the unit level but real-world usage introduces compounding factors.

10. Amazon Lex Pricing vs Google Dialogflow vs Microsoft Azure Bot Service vs Rasa

Pricing across conversational AI platforms is broadly similar in structure, but differs in how usage is measured and where costs accumulate.

Amazon Lex follows a request-based model, where each user input is billed individually. Other platforms use variations of this approach per request, per message, or per session while some shift cost away from usage entirely and into infrastructure.

Pricing and Cost Behavior Comparison

How to Read This

The main difference lies in what is counted.

In Amazon Lex, each turn in a conversation directly increases cost. This makes pricing predictable, but also sensitive to conversation length.

Dialogflow follows a similar pattern, though pricing may be grouped at a session or request level depending on configuration.

Azure Bot Service measures usage as messages, which simplifies counting but shifts more responsibility toward managing supporting services.

Rasa operates differently. There is no per-interaction pricing, but infrastructure must be provisioned and maintained. Cost is therefore less visible per interaction and more dependent on system design and scale.

When Amazon Lex Fits Well

Amazon Lex aligns well with scenarios where:

• Interaction patterns are measurable
• Conversations are relatively structured
• Usage can be estimated in terms of request volume

Where Alternatives May Differ

Other platforms may be considered when:

• Pricing needs to be grouped (per session or per message) rather than per request
• The system is not tied to a single cloud ecosystem
• Infrastructure control is preferred over managed services

Rasa, in particular, shifts the cost model entirely. Instead of paying per interaction, cost is tied to infrastructure decisions such as compute, scaling, and maintenance.

What This Comparison Shows

The pricing difference is not only in the rate, but in how cost grows with usage:

• Request-based models → sensitive to conversation length
• Message/session models → grouped interaction cost
• Infrastructure-based models → cost tied to system scale

Choosing between them depends less on individual rates and more on how usage is expected to evolve.

11. Frequently Asked Questions (FAQs)

Is Amazon Lex free to use?
Amazon Lex offers a limited free tier along with AWS credits for new users. This is useful for testing and early-stage usage. Beyond these limits, pricing follows a pay-as-you-go model based on the number and type of interactions.

How is a request counted?
A request is counted each time a user input is processed by the system. This includes both text messages and voice inputs. Every interaction that triggers intent recognition and a response is treated as a separate request.

Why do multi-turn conversations increase cost?
Each turn in a conversation—every user input followed by a system response—is counted individually. As conversations include more steps such as clarifications or confirmations, the total number of requests increases, which directly impacts cost.

Is speech always more expensive than text?
Yes. Speech interactions involve additional processing, such as converting audio into text before interpretation. This added step results in a higher cost per request compared to text-based interactions.

Does region affect pricing?
Pricing is generally consistent across regions, with only minor variations. In most cases, overall cost is influenced more by usage patterns such as request volume and conversation length—than by deployment location.

Regional Pricing Overview (Illustrative)

In practice, while regional differences may exist, they are usually small compared to the impact of how the system is used. Factors such as conversation length, request volume, and use of voice or streaming have a far greater effect on total cost.

How can Amazon Lex costs be reduced?
Costs can be managed by designing shorter and more efficient conversations, reducing unnecessary interaction steps, and using text instead of voice where appropriate. Monitoring usage and identifying patterns in conversation flow also helps in controlling overall cost.