DEV Community: Muhammad Usman Tahir

Designing a Scalable AI-Powered Serverless Text-to-Speech System with AWS Polly

Muhammad Usman Tahir — Mon, 02 Nov 2026 11:46:21 +0000

Recently, I engineered a fully serverless AI-powered Text-to-Speech application using AWS services, focused on scalability, intelligent voice handling, low operational cost, and production-level reliability.

What looked like a simple “text → audio” feature actually involved solving multiple real-world engineering challenges around AI voice generation, architecture design, fallback handling, latency, and cost optimization.

Project Goal
The objective was to create a system where:

Users can enter text
Select different AI voices
Generate natural human-like speech instantly
Receive a playable MP3 URL in real-time
All without managing traditional backend servers or GPUs
The complete system was designed around a fully Serverless Architecture.

Why I Chose AWS Polly Instead of Open-Source Models

One of the biggest decisions in this project was choosing the right AI speech engine.

Initially, open-source TTS models looked attractive, but after deeper evaluation, several practical issues appeared:

GPU dependency
High inference cost
Heavy deployment requirements
Long processing time
Complex scaling
Infrastructure maintenance overhead

Instead of spending resources managing ML infrastructure, I focused on solving the actual business problem efficiently.

That is where Amazon Polly became the ideal choice.

Intelligent Voice Engine Handling

One of the most interesting engineering parts of this project was how voice generation was handled dynamically.

AWS Polly provides multiple voice engine types:

Generative
Neural
Standard

But the challenge was: ⚠ Not every voice supports every engine type. For example:

Some voices support Generative AI voices
Some only support Neural
Others fallback to Standard synthesis

So I designed a smart fallback mechanism inside the Lambda layer.

Smart AI Voice Fallback Logic

Whenever a request comes from frontend:

System first tries the highest-quality engine (Generative)
If the selected voice does not support Generative, the system automatically switches to Neural
If Neural is also unavailable, the system falls back to Standard voice synthesis.

This solved multiple production problems:

Prevented request failures
Improved reliability
Maintained uninterrupted audio generation
Allowed dynamic voice compatibility handling
Delivered best possible voice quality automatically

This made the system more intelligent instead of relying on hardcoded voice-engine combinations.

Full Architecture Flow

1. Frontend Layer (React.js)
The user enters text and selects a voice.

2. API Gateway — Entry Point

API Gateway acts as the secure frontend-facing layer.
It handles:

Routing
CORS
Request validation
Lambda triggering

This removed the need for maintaining any servers.

3. AWS Lambda — AI Processing Layer

Lambda became the brain of the system.
Responsibilities included:

Parsing requests
Selecting optimal engine type
Calling Amazon Polly SDK
Handling fallback logic
Generating audio streams
Uploading files to S3

Since Lambda runs only when triggered:

No idle servers
No infrastructure management
Automatic scaling

4. Amazon Polly — AI Speech Synthesis
Amazon Polly processed the text using advanced speech synthesis models and generated highly natural MP3 audio.

Depending on compatibility:

Generative voices were prioritized
Neural voices were used as secondary fallback
Standard synthesis ensured universal compatibility

5. AWS S3 — Audio Storage Layer

Generated MP3 files were uploaded to S3 buckets.
Lambda returned the public audio URL back to frontend instantly.

Frontend Audio Playback

On frontend:

Audio URL was stored in React state
HTML5 audio player handled playback

<audio controls src={audioUrl} />
This created a smooth real-time AI audio experience for users.

Engineering Decisions That Improved the System

Serverless-First Architecture
No server deployment or DevOps overhead.

Cost Optimization
No GPU required. No always-running backend. Pure pay-per-use model.

Scalability
The architecture can automatically handle massive concurrent requests using AWS Lambda scaling.

Reliability Through Fallback Logic
Voice compatibility problems were solved dynamically.

Faster Development Cycle
Cloud-native services allowed focusing on product logic instead of infrastructure.

Technologies Used

AWS Lambda
Amazon Polly
API Gateway
AWS S3
Axios
Serverless Architecture
React.js

Key Learning
This project taught me that building AI systems is not only about training models.

Real engineering value comes from:

Designing scalable systems
Solving production edge cases
Optimizing cost
Improving reliability
Creating intelligent fallback mechanisms
Delivering real-world usable experiences

AI + Cloud Architecture together can create extremely powerful solutions when designed correctly.

Live Demo:
https://tts-flame.vercel.app/

The application demonstrates a fully serverless AI-powered Text-to-Speech workflow using AWS Polly, Lambda, API Gateway, and S3.

AWS #ArtificialIntelligence #Serverless #CloudComputing #AWSLambda #AmazonPolly #ReactJS #GenerativeAI #SoftwareEngineering #WebDevelopment #AIEngineering #FrontendDevelopment #CloudArchitecture #S3 #APIGateway @AWS @AWS-builders

Why My EC2 Instance Was Running but Still Not Accessible

Muhammad Usman Tahir — Wed, 21 Jan 2026 09:44:23 +0000

When I launched my first Amazon EC2 instance, everything looked fine in the AWS Console.

Instance state: Running
System status checks: Passed
Public IP assigned: Yes

But when I tried to connect:

SSH → Timeout
Browser → Connection refused

At first, this felt confusing. If the instance is running, why can’t I access it?
This post explains why this happens, what I misunderstood, and how I fixed it.
The Problem
I faced two common symptoms:

1. SSH Access Failed

ssh ec2-user@192.168.1.0

Result:

Connection timed out
Or connection refused

2. Web App Not Opening

Browser showed "This site can’t be reached" Despite the EC2 instance being healthy, network access was blocked. The Key Realization Running EC2 ≠ Accessible EC2

AWS separates:

Compute (EC2 instance)
Network security (Security Groups + NACLs)
Networking (Public vs Private IP)

If any one of these is misconfigured, access will fail.

Security Groups vs NACLs (Most Common Confusion)
Security Groups

Act as a virtual firewall
Work at the instance level
Are stateful (responses are automatically allowed)

If inbound traffic is not explicitly allowed → access denied.

Network ACLs (NACLs)

wOrk at the subnet level
Are stateless
Require both inbound and outbound rules. Even if your Security Group is correct, a restrictive NACL can still block traffic. Required Ports Explained Depending on your use case, these ports must be open:

Use Case	Port	Protocol
SSH	22	TCP
HTTP	80	TCP
HTTPS	443	TCP

Missing even one required port = connection failure
Public IP vs Private IP (Critical Detail)
Public IP

Required to access EC2 from the internet
Changes when instance is stopped/started (unless Elastic IP is used)
Private IP
Works only inside the VPC
Not accessible from your local machine

If you use a private IP from your laptop, the connection will never work.
The Fix: Security Group Configuration
My issue was missing inbound rules in the Security Group.

Example: Allow SSH Access (Port 22)

{
  "IpProtocol": "tcp",
  "FromPort": 22,
  "ToPort": 22,
  "IpRanges": [
    {
      "CidrIp": "0.0.0.0/0",
      "Description": "Allow SSH access"
    }
  ]
}

Example: Allow HTTP Access (Port 80)

{
  "IpProtocol": "tcp",
  "FromPort": 80,
  "ToPort": 80,
  "IpRanges": [
    {
      "CidrIp": "0.0.0.0/0",
      "Description": "Allow HTTP traffic"
    }
  ]
}

For production, never keep SSH open to 0.0.0.0/0. Restrict it to your IP.
What I Checked Step-by-Step

EC2 instance state → Running
Public IP assigned → Yes
Security Group inbound rules → Missing
NACL rules → Allowed
Correct username used (ec2-user, ubuntu, etc.)
Correct key permissions (chmod 400)

After fixing the Security Group, SSH worked instantly.
Key Takeaways

EC2 running status only confirms compute availability
Network access depends on Security Groups + NACLs
Security Groups must explicitly allow required ports
Public IP is mandatory for internet access
AWS prioritizes security over convenience

Final Thoughts
This issue taught me how layered AWS security really is.
Instead of assuming something is broken, it’s better to trace the request path:
Client → Internet → Security Group → NACL → EC2
Once I understood this flow, debugging became much easier.
If you’re learning AWS, trust me everyone hits this problem at least once.

Why My S3 Object URL Still Gave Access Denied (And How I Fixed It)

Muhammad Usman Tahir — Wed, 21 Jan 2026 09:22:36 +0000

When you’re new to AWS S3, one of the most confusing things is public access.
Recently, I faced an issue where I uploaded a file to S3, disabled Block all public access, but still got Access Denied when opening the Object URL.
Here’s what happened, why it happened, and how I fixed it.

The Problem
I uploaded a file to an S3 bucket and wanted to access it using the Object URL.
Steps I had already taken:

Uploaded the file successfully
Disabled Block all public access at the bucket level
Tried opening the Object URL in the browser

Result: AccessDenied
At this point, I thought:
"Public access is disabled, so why is it still denying access?"

The Important Concept I Missed
Disabling Block all public access does NOT automatically make your objects public.
It only means:
AWS will now allow you to create public permissions — but you still have to define them.
So unless you:

Add a bucket policy, or
Make the object public via ACL (not recommended anymore) Your objects will remain private.

The Solution That Worked
I added a bucket policy to explicitly allow public read access for objects.
Here is the policy I used:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "PublicReadGetObject",
            "Effect": "Allow",
            "Principal": "*",
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::usman-bucket-v1/*"
        }
    ]
}

What This Policy Does

Allows anyone (Principal: "*")
To read objects (s3:GetObject)
Inside my bucket (usman-bucket-v1/*)

After adding this policy, I refreshed the Object URL and it worked.
Why AWS Does This (Security Reason)
AWS follows secure-by-default principles.
Even if public access blocking is disabled:

Objects are still private
You must explicitly allow public access

This prevents accidental data leaks, especially in production environments.

Important Warning
This policy makes all objects in the bucket public.
Do NOT use this for:

Sensitive files
User data
Production buckets without proper review

Safer Alternatives

Use CloudFront + OAC
Use pre-signed URLs
Restrict access to specific IPs or principals

Key Takeaways

Disabling Block all public access ≠ public files
You still need a bucket policy
AWS forces explicit permission for security
Bucket policies are powerful — use carefully

Final Thoughts
This small issue helped me better understand how S3 security actually works.
If you're learning AWS (like me), these "Access Denied" errors are not failures — they’re lessons.
If this post helped you, feel free to share or drop a comment on dev.to.