DEV Community: Sohana Akbar

Cost of hosting a React app on AWS vs Vercel — real numbers

Sohana Akbar — Wed, 08 Jul 2026 16:10:05 +0000

Let's cut through the marketing fluff and look at the actual numbers. If you're building a React app in 2026, the choice between AWS and Vercel often comes down to one question: how much are you willing to pay for convenience?

Here's the honest breakdown.

The quick verdict
For a typical production React app with moderate traffic (35K visitors/month, 180GB bandwidth):

Platform Monthly Cost
Vercel Pro $20/month
AWS (S3 + CloudFront) $5–8/month
AWS is 60–75% cheaper at this scale.

But that $12–15/month difference comes with tradeoffs. Here's what you're really buying.

Vercel's pricing model: the convenience tax
Vercel's pricing looks simple at first glance:

Hobby: Free (personal/non-commercial only)

Pro: $20/user/month — includes 1TB bandwidth, 10M edge requests, 1M function invocations, 40 CPU hours

Enterprise: Custom (starts around $20–25K/year)

The catch: You get billed for overages once you exceed those limits. And the limits are per-billing-cycle, not cumulative, so they reset monthly.

Resource Included (Pro) Overage rate
Fast Data Transfer 1 TB $0.15/GB
Edge Requests 10M $2 per 1M
Function Invocations 1M $0.40 per 1M
Active CPU Time 40 hours $5/hour
At scale, overages add up fast:

text
100K visitors, 2TB bandwidth, 50M edge requests

Vercel Pro:

Base: $20
Bandwidth overage (1TB extra): $150
Edge requests overage (40M extra): $80
Total: $250/month

AWS:

CloudFront (2TB): $170
S3: $5
Lambda: $10
Total: $185/month

You save: $65/month (26%)
AWS pricing: pay for what you use
AWS offers multiple ways to host a React app. The most cost-effective for static React apps?

S3 + CloudFront (recommended for most React apps)
For a static React app (no server-side rendering), this is the sweet spot:

Component Cost
S3 storage $0.023/GB/month
S3 requests ~$0.005 per 10K GET requests
CloudFront (CDN) $0.085–0.12/GB data transfer
Lambda@Edge (optional) Pay per request
Real-world example: A small SaaS app with 35K visitors and 180GB bandwidth:

CloudFront: $3–5

S3: $1–2

Lambda: $0.50

Total: $5–8/month

For a portfolio or low-traffic site, you can stay within AWS Free Tier entirely.

AWS Amplify (the Vercel-like experience)
If you want Git-based deployments and preview URLs without the complexity, AWS Amplify is Vercel's direct competitor:

Free tier: 1,000 build minutes/month, 15GB bandwidth, 30K requests

Beyond free tier: $0.01/build minute, $0.15/GB transfer, $0.023/GB storage

MVP cost (low traffic with Cognito + RDS): ~$16–25/month.

EC2 + CloudFront (for full-stack or SSR)
If you need server-side rendering or custom backend logic:

Component Monthly Cost
t4g.medium EC2 ~$24.53
EBS storage ~$0.80
ALB ~$16.50
CloudFront usage-based
Total base ~$54–63/month
The multi-project math
Here's where AWS really shines. I run 6 production SaaS apps:

Platform Cost
Vercel: 6 apps × $20/month $120/month minimum
AWS: All 6 apps combined ~$20/month total
That's $100+/month savings — $1,200/year. Real money you can spend on marketing, hiring, or your own salary.

Hidden costs and traps
Vercel gotchas
Hobby plan is non-commercial only — if you deploy client work, you're on Pro

AI apps are expensive — streaming responses keep functions running longer (45-second stream = 45x cost of a quick API call)

No gradual upgrade path — the jump from Pro to Enterprise is a cliff (from $20/user to ~$20K/year)

Regional pricing varies — bandwidth costs $0.15–0.35/GB depending on region

AWS gotchas
Complex pricing — you need to understand S3, CloudFront, Lambda, and data transfer costs

Learning curve — configuring IAM roles, CloudFront invalidations, and build pipelines takes time

Surprise bills — set billing alerts from day one (stories of $10K+ surprise AWS bills aren't urban legends)

Which should you choose?
Choose Vercel if:
You're building with Next.js (first-class support, zero config)

You want preview deployments for every PR

You hate infrastructure and want to focus on code

Your traffic is predictable and within Pro plan limits

You're willing to pay $20–150/month for convenience

Choose AWS if:
You have multiple projects (savings compound fast)

You want cost predictability at scale

You already use AWS services (Cognito, RDS, DynamoDB, SES)

You have time to learn the basics of S3 + CloudFront

You're building a SaaS where every dollar of margin matters

Real numbers comparison
Scenario Vercel Pro AWS (S3+CF) Savings
Portfolio (low traffic) $20 ~$0–3 ~$17
Small SaaS (35K visitors, 180GB) $20 ~$5–8 ~$12–15
Growing SaaS (100K visitors, 2TB) ~$250 ~$185 ~$65
6 production apps $120+ ~$20 ~$100+
Bottom line
Vercel is the premium experience — you pay for simplicity, preview deployments, and Next.js optimization. It's worth it if your time is valuable and your traffic is predictable.

AWS is the cost-effective choice — you trade setup complexity for significantly lower costs, especially as you scale or run multiple projects.

For most solo developers and small teams, the answer is: start on Vercel (it's free), and move to AWS when the bill starts to hurt.

CloudFront Invalidations from CI: Automate Cache Clears

Sohana Akbar — Tue, 07 Jul 2026 14:21:35 +0000

If you've ever deployed a website to S3 and CloudFront, you know the frustration: you push your changes, wait a minute, refresh the page, and... still see the old version. 😅

The problem is CloudFront caching—it's great for performance, but it means users can see stale content after you deploy updates . By default, CloudFront serves cached content until it expires (up to 24 hours!) .

The solution? Automate CloudFront cache invalidation from your CI/CD pipeline. Let's break down why and how.

Why Automate Invalidation?
Doing invalidations manually through the AWS Console is:

❌ Error-prone (forgetting to do it)

❌ Slow (breaks your deployment flow)

❌ Not scalable (as your team grows)

Automating invalidation ensures users always see the latest content immediately after deployment .

The Core Command
Whether you use GitHub Actions, Jenkins, or AWS CodePipeline, the underlying AWS CLI command is the same:

bash
aws cloudfront create-invalidation \
--distribution-id EDFDVBD6EXAMPLE \
--paths "/"
The --paths parameter supports wildcards—/ invalidates everything, while /index.html or /assets/* invalidates specific paths .

CI/CD Integration Patterns

GitHub Actions This is probably the most popular approach. In your workflow YAML, add a step to create the invalidation after your deployment:

yaml

name: Invalidate CloudFront run: | aws cloudfront create-invalidation \ --distribution-id ${{ secrets.CLOUDFRONT_DISTRIBUTION_ID }} \ --paths "/*" env: AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }} AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }} AWS_DEFAULT_REGION: us-east-1 Store your distribution ID and AWS credentials as GitHub Secrets .

AWS CodePipeline with Lambda CodePipeline can trigger a Lambda function after S3 sync, which then creates the invalidation :

python
import boto3

def lambda_handler(event, context):
cloudfront = boto3.client('cloudfront')
response = cloudfront.create_invalidation(
DistributionId='YOUR_DISTRIBUTION_ID',
InvalidationBatch={
'Paths': {
'Quantity': 1,
'Items': ['/*']
},
'CallerReference': str(event.get('timestamp', 'manual'))
}
)
return response

Terraform The aws_cloudfront_distribution resource doesn't natively support invalidation. However, you can use local-exec provisioner as a workaround :

hcl
resource "aws_cloudfront_distribution" "s3_distribution" {
# ... configuration ...

provisioner "local-exec" {
command = "aws cloudfront create-invalidation --distribution-id ${self.id} --paths '/*'"
}
}
⚠️ Note: This runs after resource creation, but for every terraform apply, consider using a null_resource with triggers for more control.

Jenkins Pipeline Similar to GitHub Actions—just call the AWS CLI from your Jenkinsfile:

groovy
stage('Invalidate Cache') {
steps {
sh '''
aws cloudfront create-invalidation \
--distribution-id ${CLOUDFRONT_DIST_ID} \
--paths "/*"
'''
}
}

Package.json Scripts For smaller projects, you can chain commands in npm scripts :

json
{
"scripts": {
"build.prod": "ng build --prod --aot",
"aws.deploy": "aws s3 sync dist/ s3://www.mywebsite.com --delete",
"aws.invalidate": "aws cloudfront create-invalidation --distribution-id [ID] --paths /",
"deploy": "npm run build.prod && npm run aws.deploy && npm run aws.invalidate"
}
}
IAM Permissions
Your CI user needs at minimum:

json
{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": ["cloudfront:CreateInvalidation"],
"Resource": "*"
}]
}
If you need to wait for completion (e.g., for testing), add cloudfront:GetInvalidation .

Best Practices & Considerations
Don't invalidate everything every time. If only index.html and main.js change, invalidate just those paths to be more efficient .

Cache invalidation costs money. The first 1,000 paths per month are free; after that, it's charged . Invalidate with intention.

Consider using versioned filenames (e.g., main.a1b2c3.js) so you can keep caching forever and invalidate only the entry point. This is how modern frameworks roll.

Wait for completion? Some plugins (like ember-cli-deploy-cloudfront) offer a waitForInvalidation flag, but this can take several minutes—only use it when absolutely necessary .

Real-World Example
A typical CI/CD flow looks like this :

Developer pushes code to GitHub

GitHub Actions/AWS CodePipeline triggers build

Build assets are uploaded to S3

CloudFront invalidation runs automatically

Users see fresh content instantly

No manual steps. No stale cache. 🚀

Summary
CloudFront invalidations are a necessary evil when deploying sites with a CDN. The good news is that automating them is straightforward with any CI/CD tool—GitHub Actions, AWS CodePipeline, Jenkins, or Terraform.

Choose the approach that fits your stack, add the invalidation step to your pipeline, and never think about stale cache again.

What's your preferred way to handle CloudFront invalidations? Drop a comment below!

Deploying Preview Environments on AWS with PR Labels

Sohana Akbar — Mon, 06 Jul 2026 14:38:59 +0000

Preview environments have become an essential part of modern development workflows. They allow teams to review changes in a live environment before merging code, significantly improving collaboration and reducing bugs.

In this article, I'll walk you through setting up preview environments on AWS that are triggered by PR labels. This approach gives you complete control over your infrastructure while keeping costs low and workflows simple.

Why Preview Environments?
Preview environments (also called review apps) are temporary deployments of your application from pull requests. They let teammates, product managers, and QA teams visually review changes before they hit production .

The benefits are clear:

Faster feedback loops – reviewers see exactly what changed

Reduced risk – issues are caught before merging

Better collaboration – non-technical stakeholders can participate in reviews

Confidence in changes – you can run E2E tests against real infrastructure

The Label-Based Approach
Using PR labels to trigger preview deployments is a pattern that's gained significant traction. Here's why it works so well:

Intent-based activation – you choose when to spin up an environment

Automatic cleanup – removing the label or closing the PR tears everything down

Team-friendly – no complex commands required, just add a label

As one popular implementation describes it: "You can manage preview environments by adding or removing the pullpreview label on your Pull Requests" .

Architecture Overview
The architecture depends on your specific needs, but a typical setup includes:

Option 1: Simple VM-based (using PullPreview)

This approach provisions AWS Lightsail instances for each preview environment . Each instance runs Docker Compose to spin up your application and its dependencies. It's simple, cheap, and works with any app that can be containerized.

Option 2: Infrastructure as Code (AWS CDK)

For more complex applications, you can use AWS CDK to define your infrastructure in TypeScript. This gives you more control and enables sophisticated setups with:

CloudFront CDN in front of S3 buckets

RDS databases with proper lifecycle management

VPC configurations and security groups

Option 3: Kubernetes with GitOps

Larger teams might use Kubernetes with ArgoCD's ApplicationSet and PullRequest generator. This approach creates isolated namespaces per PR, with full service mesh capabilities .

Implementation: PullPreview Approach
Let me show you the simplest way to get started, using the PullPreview GitHub Action.

Set Up AWS Credentials First, create an IAM user with Lightsail permissions. AWS doesn't provide a default Lightsail policy, so you'll need to create one :

json
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "lightsail:",
"Resource": ""
}
]
}
Then store the access keys as repository secrets:

AWS_ACCESS_KEY_ID

AWS_SECRET_ACCESS_KEY

AWS_REGION (e.g., us-east-1)

Create the Workflow File Add .github/workflows/pullpreview.yml to your repository:

yaml
name: PullPreview
on:
pull_request:
types: [labeled, unlabeled, synchronize, closed, reopened]

jobs:
deploy:
permissions:
contents: read
deployments: write
pull-requests: write
statuses: write
runs-on: ubuntu-latest
timeout-minutes: 30
steps:
- uses: actions/checkout@v4
- uses: pullpreview/action@v5
with:
admins: your-github-username
compose_files: docker-compose.pullpreview.yml
ports: 80,443
default_port: 443
env:
AWS_ACCESS_KEY_ID: "${{ secrets.AWS_ACCESS_KEY_ID }}"
AWS_SECRET_ACCESS_KEY: "${{ secrets.AWS_SECRET_ACCESS_KEY }}"
AWS_REGION: "us-east-1"

Create the Docker Compose File Your docker-compose.pullpreview.yml defines what runs in the preview environment:

yaml
services:
proxy:
image: caddy:2
command: "caddy reverse-proxy --from '${PULLPREVIEW_URL}' --to web:4567"
ports:
- "80:80"
- "443:443"

web:
build: .
environment:
DATABASE_URL: "postgres://user:pass@db/postgres"

db:
image: postgres:13
environment:
POSTGRES_PASSWORD: p4ssw0rd

Create the Label In your GitHub repository, create a label called pullpreview. When you add this label to a PR, the preview environment will spin up automatically.

Implementation: CDK Approach
For teams needing more infrastructure control, the AWS CDK approach offers greater flexibility .

Define Your Stack
typescript
// lib/awesome-stack.ts
import * as cloudfront from "@aws-cdk/aws-cloudfront";
import * as s3 from "@aws-cdk/aws-s3";
import * as cdk from "@aws-cdk/core";

export default class AwesomeStack extends cdk.Stack {
constructor(scope: cdk.Construct, id: string, props?: cdk.StackProps) {
super(scope, id, props);

const bucket = new s3.Bucket(this, "Bucket", {
  autoDeleteObjects: true,
  removalPolicy: cdk.RemovalPolicy.DESTROY, // Clean up when PR closes
});

const distribution = new cloudfront.Distribution(this, "Distribution", {
  defaultBehavior: {
    origin: new cloudfrontOrigins.S3Origin(bucket),
    viewerProtocolPolicy: cloudfront.ViewerProtocolPolicy.REDIRECT_TO_HTTPS,
  },
});

// Export the URL for GitHub Deployments API
new cdk.CfnOutput(this, "DeploymentUrl", {
  value: "https://" + distribution.distributionDomainName
});

}
}
Trigger Based on PR Number
Use the PR number and branch name to create unique stack names:

yaml

name: set STAGE variable
run: echo "STAGE=pr-${{ github.event.number }}-${{ env.GITHUB_HEAD_REF_SLUG }}" >> $GITHUB_ENV
name: deploy the stack
run: yarn deploy
This ensures each PR gets its own isolated infrastructure .

Cleanup: Don't Leave Resources Running
Preview environments should be ephemeral. Here's how to ensure cleanup:

With PullPreview: Removing the pullpreview label or closing the PR automatically destroys the Lightsail instance.

With CDK: Create a cleanup workflow that triggers on PR closure:

yaml
name: "Pull Request clean-up"

on:
pull_request:
types: [unlabeled, closed]

jobs:
clean-up:
if: |
(github.event.action == 'unlabeled' && github.event.label.name == '🚀 deploy') ||
(github.event.action == 'closed' && contains(github.event.pull_request.labels.*.name, '🚀 deploy'))
runs-on: ubuntu-latest
steps:
- name: destroy the stack
run: cdk destroy "AwesomeStack-${{ env.STAGE }}" --force
Cost Considerations
One of the advantages of this approach is cost control:

Lightsail instances start at ~$10/month, prorated to actual usage

CDK resources can be set to auto-delete with RemovalPolicy.DESTROY

Spot instances in Kubernetes can further reduce costs for non-critical workloads

Advanced Features to Consider
Multi-service dependencies: When Service A depends on Service B, developers should be able to point to either staging or another preview environment .

Persistent state: Keep database volumes across deploys so reviewers don't lose data when new commits arrive .

SSH access: Grant trusted team members SSH access to preview instances for troubleshooting .

Conclusion
Preview environments triggered by PR labels provide a powerful way to review changes in a production-like setting. Whether you choose the simplicity of PullPreview with Lightsail, the control of AWS CDK, or the scalability of Kubernetes, the core pattern remains the same: code → label → preview → review → cleanup.

The key benefits are clear:

Low cost – pay only for what you use

Simple activation – just add a label

Automatic cleanup – no manual resource management

Privacy – your code stays in your AWS account

Start small, get the workflow working for a simple app, then expand to your full microservices architecture. Your team's confidence in shipping changes will increase dramatically when everyone can see and test the real thing before it merges.

Deploying Preview Environments on AWS with PR Labels

Sohana Akbar — Sun, 05 Jul 2026 14:58:35 +0000

Preview environments—temporary, isolated deployments of your code—have become essential for modern development workflows. They let you test changes in a production-like setting before merging, catch issues early, and give stakeholders a tangible way to review work in progress.

One of the most elegant ways to trigger these environments? PR labels. Slap a label on a pull request, and boom—a full environment spins up on AWS. Remove the label, and it tears down. Simple, powerful, and cost-effective. Let me walk you through how to set this up.

Why PR Labels?
Managing preview environments manually is a nightmare. You don't want to:

Spin up environments for every PR ($$$)

Manually track which PRs need environments

Remember to clean up after merge

PR-based labels solve this beautifully. You're in control—only PRs flagged with your chosen label (like preview or deploy) get environments. Remove the label or close the PR? Environment destroyed.

The Architecture at a Glance
There are several solid approaches depending on your stack and complexity needs. Here are the main patterns:

The Simple Path: PullPreview + AWS Lightsail If you want the simplest route and your app runs on Docker Compose, PullPreview is hard to beat . It's a GitHub Action that provisions a cheap AWS Lightsail instance (around $10/month, prorated) whenever you label a PR . The workflow stays entirely within GitHub Actions—your code never touches third-party servers .

Here's a minimal workflow file:

yaml

.github/workflows/pullpreview.yml

name: PullPreview
on:
pull_request:
types: [labeled, unlabeled, synchronize, closed, reopened]
push:
branches:
- main

jobs:
deploy:
if: github.event_name == 'push' || github.event.label.name == 'pullpreview' || contains(github.event.pull_request.labels.*.name, 'pullpreview')
runs-on: ubuntu-latest
timeout-minutes: 30
steps:
- uses: actions/checkout@v4
- uses: pullpreview/action@v5
with:
admins: your-github-username
always_on: main # Keeps a staging environment for main branch
compose_files: docker-compose.yml
default_port: 80
env:
AWS_ACCESS_KEY_ID: "${{ secrets.AWS_ACCESS_KEY_ID }}"
AWS_SECRET_ACCESS_KEY: "${{ secrets.AWS_SECRET_ACCESS_KEY }}"
AWS_REGION: "us-east-1"
What makes this great:

No Kubernetes complexity—each preview is a single VM

State persistence across deploys via Docker volumes

SSH access for troubleshooting (GitHub keys auto-installed)

Privacy-first—code never leaves your infrastructure

The CDK Approach: Full Infrastructure as Code If you want total control and your team is comfortable with TypeScript, AWS CDK gives you infrastructure-as-code superpowers . You define your entire preview environment in code, and CDK handles the heavy lifting.

The basic flow:

Label a PR → triggers GitHub Action

Action derives a unique stack name (AwesomeStack-pr-42-feat-new-feature)

CDK deploys a full stack (CloudFront + S3, ECS, or whatever you need)

Deployment URL shows up in GitHub's UI via Deployments API

Remove label or close PR → cdk destroy cleans everything up

Key CDK snippets:

typescript
// lib/awesome-stack.ts - Infrastructure defined as code
const bucket = new s3.Bucket(this, "Bucket", {
autoDeleteObjects: true,
removalPolicy: cdk.RemovalPolicy.DESTROY, // Critical for cleanup!
});

const distribution = new cloudfront.Distribution(this, "Distribution", {
defaultBehavior: {
origin: new cloudfrontOrigins.S3Origin(bucket),
viewerProtocolPolicy: cloudfront.ViewerProtocolPolicy.REDIRECT_TO_HTTPS,
},
});

// Export the URL for GitHub integration
new cdk.CfnOutput(this, "DeploymentUrl", {
value: "https://" + distribution.distributionDomainName
});
Pro tip: The removalPolicy: cdk.RemovalPolicy.DESTROY is essential—without it, your S3 buckets and databases stick around even after PRs close, costing you money .

The Kubernetes Route: ArgoCD + EKS For teams already running Kubernetes on AWS (EKS), ArgoCD's ApplicationSet with PullRequest generator offers a GitOps-native approach .

The workflow:

Developer creates PR with preview label

GitHub Actions builds Docker image, pushes to ECR

ArgoCD detects the PR via ApplicationSet, provisions resources in a dedicated namespace

Preview environment gets its own Ingress URL

Remove label or close PR → ArgoCD deletes everything

This approach works especially well for microservices with dependencies. One neat trick from production implementations: use a hybrid approach where databases are provisioned per-PR but dependent services are shared from staging, saving costs while keeping data isolated .

Two Big Considerations
Cost Control
Preview environments can get expensive if you're not careful. Here are strategies to keep costs in check:

Spot instances for non-critical workloads (perfect for previews)

Auto-cleanup—remove the preview label if a PR goes stale for a certain period

Lightsail nano instances (512MB RAM) for lighter workloads

Scheduled cleanup jobs to catch dangling resources

Security
IAM policies should be least-privilege—give actions only what they need

CIDR restrictions to limit access to specific IP ranges

Never hardcode credentials—use GitHub Secrets for AWS access keys

The Bottom Line
PR-based preview environments on AWS transform how you ship code. Whether you go with:

PullPreview + Lightsail for dead-simple setup

AWS CDK for full infrastructure-as-code flexibility

ArgoCD + EKS for Kubernetes-native GitOps

…the core principle is the same: label-driven, ephemeral environments that give your team confidence to ship faster.

My recommendation: Start with PullPreview if you're using Docker Compose and want to be live in minutes. Graduate to CDK if you need custom infrastructure. And if you're already deep in Kubernetes, ArgoCD is your friend.

The key is to make preview environments so easy that your team actually uses them. Because when you combine speed with safety, that's when development gets truly enjoyable.

Happy deploying! 🚀

EBS vs EFS vs S3 for Frontend Assets — Which and When?

Sohana Akbar — Sat, 04 Jul 2026 13:55:49 +0000

Let's cut through the cloud storage noise. You're building a frontend on AWS, and suddenly you're faced with three storage options that sound suspiciously similar. EBS, EFS, S3 — they all store stuff, right?

Wrong. Picking the wrong one is like using a forklift to hang a picture frame. It might work, but you're going to have a bad time.

Here's the developer-friendly breakdown of which storage service to use for your frontend assets, and exactly when to use it .

The Short Answer (Because You're Busy)
Your Frontend Need Use This Why
Static files (HTML, CSS, JS, images) served to users S3 + CloudFront Built for this. Scalable, cheap, globally fast
A server's OS and application code EBS It's your virtual hard drive. Fast, low-latency
Multiple servers sharing the same content EFS Shared network drive. Perfect for web farms
S3 — The Static Asset Superhero 🦸
What it is: Object storage. Think of it as an infinite Dropbox for your files .

When to use: This should be your default choice for frontend assets. S3 is designed to store and serve static files — your HTML, CSS, JavaScript bundles, images, videos, and fonts .

Why it wins for frontend:

Virtually unlimited scale — handles traffic spikes without breaking a sweat

11 nines durability — your files aren't going anywhere (99.999999999%)

Cheap — pay for what you use

HTTP access — files are accessible via URL, perfect for web browsers

Pro tip: Pair S3 with CloudFront (AWS's CDN) for production. CloudFront caches your assets at edge locations worldwide, reducing latency and saving you S3 data transfer costs .

When NOT to use S3:

For files your EC2 instances need to read/write like a file system

For server-side code execution (it's just storage, not compute)

When you need low-latency block-level access

javascript
// Pseudo-code: Upload your frontend build
aws s3 sync ./build/ s3://my-frontend-bucket/ --delete
EBS — The Personal Hard Drive 💽
What it is: Block storage that attaches to a single EC2 instance. It's your virtual hard drive .

When to use: For the server itself, not the assets it serves. EBS is what your EC2 instance uses as its boot volume and for any data that needs fast, low-latency access .

The frontend connection:

Your EC2 server's operating system lives on an EBS volume

Your application code on the server runs from EBS

If you're running a database on EC2 (like PostgreSQL or MySQL), that lives on EBS

Why NOT for frontend assets:

Single-instance only — can't share across multiple servers

AZ-specific — tied to one Availability Zone

Overkill for serving files — you're paying for provisioned capacity whether you use it or not

Example: Your Node.js/Next.js application running on an EC2 instance uses EBS for the OS, runtime, and application code. But the static images your users download? Those should be in S3.

EFS — The Team Shared Drive 📂
What it is: A managed NFS file system that multiple EC2 instances can mount simultaneously .

When to use: When multiple servers need to access the same files at the same time .

Frontend use cases:

A web server farm where all instances need access to the same content files

Shared configuration files across microservices

Content management systems where uploaded media must be accessible from any instance

Development environments where team members share code

The EFS architecture in action: Imagine you have 5 EC2 instances behind a load balancer running the same WordPress site. They all need access to the uploaded media files. EFS lets them all mount the same file system .

Why NOT for frontend assets:

Higher cost than S3 — you pay per GB used

NFS overhead — adds latency compared to direct S3 access

Overkill if you don't need shared write access

The Real-World Architecture 🏗️
In production, you often use all three together:

text
[User Browser]
↓
[CloudFront CDN]
↓
[S3 Bucket] ← Static assets (images, CSS, JS)
|
[Application Load Balancer]
↓
[EC2 Instance #1] ←─┐
↓ │
[EBS Root Volume] │
↓ │
[Application Code] │
│
[EFS Shared Storage]←┘ ← Shared content (CMS uploads, configs)
This pattern uses:

S3 for globally accessible static assets

EBS for each server's OS and application

EFS for content shared across servers

Decision Tree 🌳
Start here:

Do users need to access these files via URL?

Yes → S3 (add CloudFront for production)

No → Go to #2

Does a single server need this as a mounted drive?

Yes → EBS

No → Go to #3

Do multiple servers need to read/write the same files?

Yes → EFS

No → You probably want S3 anyway

The Bottom Line
Stop overthinking this. For 90% of frontend asset use cases, S3 is the answer. It's what it's built for, it's what it does best, and your wallet will thank you.

Use EBS for what the server needs to run. Use EFS when you genuinely need file sharing across instances. But if you're serving files to users? S3 is your friend .

And whatever you do, don't use EBS to serve static assets. That's like using a Ferrari to deliver pizzas — technically possible, but wildly inefficient and expensive .

How AWS WAF Rules Stopped Bot Traffic to My Portfolio

Sohana Akbar — Fri, 03 Jul 2026 09:46:55 +0000

It started innocently enough—a spike in CloudWatch metrics that looked like success. More visitors than ever before? My portfolio was going viral!

Then I looked at the logs. The "visitors" weren't human. They were bots. Scrapers, crawlers, and automated scripts churning through my portfolio like it was an all-you-can-eat buffet. My API was getting hammered, costs were creeping up, and legitimate traffic was getting choked out.

Time to fight back. Here's how I used AWS WAF to reclaim my portfolio from the bots.

The Bot Problem
Bots aren't inherently evil—search engines and monitoring services are helpful. But scrapers and crawlers? They're digital parasites that:

Skew analytics (making you think your portfolio's a viral hit when it's just Python scripts)

Burn through resources (your AWS bill isn't as fun to look at as your portfolio)

Slow down real visitors (because your API's too busy serving bots)

I needed a way to separate the wheat from the chaff—legitimate visitors from automated pests.

Enter AWS WAF Bot Control
AWS WAF Bot Control is a managed rule group that detects and mitigates bot traffic with minimal configuration. The best part? It costs $10/month—well worth the peace of mind and resource savings.

Level 1: The Common Protection
The Common inspection level catches self-identifying bots using traditional detection techniques. It:

Detects web scraping frameworks, search engines, and automated browsers

Labels traffic from these bots

Blocks unverified bots by default

Think of it as the bouncer who checks ID at the door. Most bots aren't smart enough to fake it.

Level 2: The Targeted Protection
For more sophisticated bots that don't self-identify, I enabled the Targeted inspection level. This uses advanced techniques like:

Behavior-based detection

Browser interrogation

Machine learning analysis of traffic patterns

The ML rules analyze timestamps, browser characteristics, and other behavioral signals to spot coordinated bot activity.

My Custom Rule Configuration
Blocking Verified Bots
Some bots identify themselves honestly but aren't welcome. I added a label-matching rule that runs after the Bot Control rule group to block specific verified bots:

json
{
"Name": "match_rule",
"Statement": {
"LabelMatchStatement": {
"Scope": "LABEL",
"Key": "awswaf:managed:aws:bot-control:bot:verified"
}
},
"Action": {
"Block": {}
}
}
This blocks all verified bots in one shot. Want to block only specific ones? Match on the bot name label instead:

json
"LabelMatchStatement": {
"Scope": "LABEL",
"Key": "awswaf:managed:aws:bot-control:bot:name:bingbot"
}
Rate-Based Rules: The Silent Guardian
Sometimes bots aren't malicious—they're just... too much. I added rate-based rules to handle this gracefully.

A blanket rule protects against HTTP floods:

text
Limit: 500 requests per 5 minutes
Action: BLOCK
Then more targeted rules with stricter limits:

text
Scope-down: if uri_path starts_with '/api'
Limit: 100 requests per 5 minutes
Aggregation key: IP
This means if some scraper decides to hammer my API endpoint 500 times in a minute, it gets blocked while legitimate traffic flows freely.

Creating Exceptions for Good Bots
Not all bots are bad. I wanted search engines to index my portfolio. You can set specific rules to allow verified search bots while blocking others:

json
{
"Name": "allow-search-bots",
"Statement": {
"AndStatement": {
"Statements": [
{
"LabelMatchStatement": {
"Scope": "LABEL",
"Key": "awswaf:managed:aws:bot-control:bot:verified"
}
},
{
"NotStatement": {
"Statement": {
"ByteMatchStatement": {
"FieldToMatch": {
"SingleHeader": {
"Name": "user-agent"
}
},
"SearchString": "googlebot",
"PositionalConstraint": "CONTAINS"
}
}
}
}
]
}
},
"Action": {"Block": {}}
}
The Results
The impact was immediate:

API costs dropped by ~40% (fewer pointless requests)

CloudWatch metrics normalized (actual traffic! Humans!)

Response times improved (serving fewer bots = faster responses)

Analytics became useful again (I could actually see real user behavior)

Lessons Learned
Start with Common protection — It handles 80% of the bot problem with zero configuration

Layer your rules — Combine Bot Control with rate-based rules for defense in depth

Use scope-down statements — Only inspect what matters. Target API endpoints or dynamic content to save on inspection costs

Monitor the Bot Control dashboard — AWS provides pre-built dashboards showing bot activity levels. Use them to understand what you're dealing with

The Bottom Line
AWS WAF made protecting my portfolio from bots surprisingly painless. A few JSON rules, $10/month, and some dashboard monitoring—and my portfolio serves humans again.

The bots are still out there. They'll keep scraping. But now? They're hitting a wall. And I'm sleeping better knowing my AWS bill won't spike because some scraper decided to index my entire portfolio 50 times a day.

Your portfolio deserves better than being bot food. Time to give it the protection it deserves.

S3 Static Hosting with HTTP-Errors Redirects — Solved

Sohana Akbar — Wed, 01 Jul 2026 13:51:48 +0000

If you have ever deployed a Single Page Application (SPA) or a static site using Amazon S3, you might have encountered a frustratingly common issue: refresh errors. You navigate to yoursite.com/about, and everything works perfectly. But the moment you hit the refresh button—or share that link with a friend—you are greeted with a glaring 403 Forbidden or 404 Not Found error.

This is one of the most infamous pitfalls of static hosting. Here is why it happens and the definitive way to fix it.

The Root Cause
S3 is an object storage service, not a web server.

When you upload a React or Vue app, you usually have a single index.html that acts as your application shell. Your app uses client-side routing (like React Router) to handle navigation. However, S3 does not know about your routing logic. When you request /about, S3 looks for a literal file named about in the root directory. Since that file does not exist, S3 returns a 404 error.

To solve this, you need to instruct S3 to serve index.html for all requests, regardless of the path. This is usually done via the "Static website hosting" settings.

The "Old" Solution: S3 Redirection Rules
The standard advice is to use the S3 "Static website hosting" feature and set the "Error document" to index.html. This creates a redirection rule.

While this works, it has a significant downside: HTTP status codes.

When S3 returns index.html for a missing page, it often sends a 200 OK status. This is fine for the user interface, but it is a nightmare for SEO. Search engines cannot distinguish between a valid page and a missing page, and analytics tools fail to track 404s correctly.

The "Solved" Solution: CloudFront and Custom Error Responses
The most robust and professional solution involves CloudFront, AWS's Content Delivery Network (CDN). Instead of relying on S3's redirection, we use CloudFront's custom error responses to serve the index.html file while preserving the correct HTTP status.

Step-by-Step Implementation
Step 1: Set up the S3 Bucket
Upload your static files. Ensure the bucket is configured for static website hosting (or use the newer S3 website endpoint). For CloudFront, it is often better to use the REST endpoint to avoid redirect issues.

Step 2: Configure CloudFront Behavior
In your CloudFront distribution settings, find the "Error Pages" section.

Step 3: Create a Custom Error Response
You need to configure rules for specific HTTP error codes. Add a rule for both 403: Forbidden and 404: Not Found.

For each error, set the following:

Customize Error Response: Yes

Response Page Path: /index.html (or the root of your app)

HTTP Response Code: Set this to 200 only if you want to hide the error. However, the best practice for SEO is to set this to 404 if it is a real missing page, or leave it as 200 if you are using a SPA router.

The SPA Trick: For SPAs, you usually want the error response to be 200 (so the app loads and the router takes over). But, if you want to be precise, you can implement server-side logic to determine if the file exists. For most SPAs, the 200 override is the accepted standard.

The "S3 Redirects" Caveat
If you were using the S3 static website hosting endpoint (with s3-website-region.amazonaws.com), you might have been using RoutingRules to handle redirects. This approach has been largely superseded by CloudFront because:

HTTPS: S3 website endpoints do not support HTTPS natively. You must use CloudFront for SSL certificates.

Speed: CloudFront serves content from edge locations, drastically reducing latency.

Granularity: CloudFront allows you to handle errors without changing the URL in the browser, whereas S3 redirects often perform an explicit redirect (changing the URL).

The Ultimate Configuration
If you are using CloudFront + S3, your configuration should look like this:

S3: Just store the files. Do not rely on the "Static website hosting" redirection feature. Use the bucket's REST endpoint (not the website endpoint).

CloudFront Origin: Point to the S3 bucket REST endpoint.

Error Pages:

Error Code: 403

Response Page Path: /index.html

HTTP Response Code: 200

Error Code: 404

Response Page Path: /index.html

HTTP Response Code: 200

A Note on http-errors and Nginx
Sometimes, developers use the http-errors middleware in Node.js or Nginx configurations to serve the index.html file. The logic is identical: you are creating a "catch-all" route.

If you are using a reverse proxy like Nginx in front of your S3 bucket (via a proxy pass), the equivalent configuration is:

text
try_files $uri $uri/ /index.html;
This tells the server to check if the file exists ($uri), and if not, fall back to index.html.

Why This is "Solved"
By using this CloudFront-first approach, you get:

Perfect SPA Routing: Deep links and refreshes work flawlessly.

Global Speed: Edge caching.

Security: Full HTTPS support.

SEO Friendliness: You control exactly which status codes are returned.

So, ditch the S3 static hosting redirect rules and embrace CloudFront. It is the standard, production-grade method for hosting modern web applications on AWS.

A/B Testing at Warp Speed: How Cloudflare Workers Revolutionize HTML Experiments

Sohana Akbar — Tue, 30 Jun 2026 15:31:52 +0000

Let's be honest—traditional A/B testing is broken.

If you've ever implemented client-side testing, you know the drill. Your users load the page, wait for JavaScript to execute, and then—flicker—the content changes. It's jarring. It hurts your Core Web Vitals. And worst of all, your experiments might be measuring user frustration instead of genuine engagement.

But what if you could run A/B tests with zero flicker? What if you could modify your HTML before it even reaches the browser? That's exactly what Cloudflare Workers make possible .

The Server-Side Advantage
A/B testing at the edge means making decisions about which variant a user sees before any HTML is sent to their browser . Instead of:

Load the page

Execute JavaScript

Flicker

Apply the variant

Track the result

You get:

Decision made at the edge

Correct HTML streamed immediately

Zero flicker

Better performance

Companies like Ninetailed are already using Cloudflare Workers to achieve 2-3x cost savings compared to traditional serverless platforms, all while delivering personalized experiences with minimal latency .

How It Actually Works
The concept is surprisingly elegant. Your Cloudflare Worker intercepts incoming requests, checks for a cookie to maintain user consistency, and routes users to the appropriate variant .

Here's a simplified version that's production-ready:

javascript
const NAME = "myExampleWorkersABTest";

export default {
async fetch(req) {
const url = new URL(req.url);

// Determine which group this user is in
const cookie = req.headers.get("cookie");

if (cookie && cookie.includes(`${NAME}=control`)) {
  url.pathname = "/control" + url.pathname;
} else if (cookie && cookie.includes(`${NAME}=test`)) {
  url.pathname = "/test" + url.pathname;
} else {
  // New user—randomly assign them (50/50 split)
  const group = Math.random() < 0.5 ? "test" : "control";
  url.pathname = `/${group}` + url.pathname;

  // Fetch and modify the response to set a cookie
  let res = await fetch(url);
  res = new Response(res.body, res);
  res.headers.append("Set-Cookie", `${NAME}=${group}; path=/`);
  return res;
}

return fetch(url);

}
}
With this approach, your users stay in the same experiment group across sessions—no confusing inconsistencies .

Beyond Simple Routing: HTML Rewriting
The real magic happens when you combine Workers with HTMLRewriter. This powerful API lets you modify HTML as it streams through your Worker .

Need to change a headline, swap out a call-to-action button, or inject different meta tags? HTMLRewriter can do it all in real-time, without touching your origin server .

javascript
const transformer = new HTMLRewriter()
.on("h1", {
element(element) {
element.setInnerContent("Experience the future of testing");
}
})
.on("meta[name='description']", {
element(element) {
element.setAttribute("content", "Zero-flicker A/B testing at the edge");
}
});

return transformer.transform(originalResponse);
This approach is so powerful that Optimizely has built their Edge Delivery SDK specifically for this use case, leveraging Cloudflare's HTMLRewriter to execute web experiments .

Real-World Performance Impact
The numbers are compelling. By moving A/B testing logic to Cloudflare Workers:

60-70% faster context creation compared to client-only SDKs

Zero flicker—HTML is already modified when it reaches the browser

Global low latency—your tests run from Cloudflare's edge network

One developer who built a server-side A/B testing solution on Workers discovered an unexpected benefit: they could apply HTML patches for SEO tweaks without deploying new code. "Update meta tags, headings, or content structure without deploying new code"—that's a game-changer for teams with slow deployment cycles .

Production Considerations
When implementing A/B testing at scale, keep these patterns in mind:

Cookie-Based Sticky Sessions
Maintain user consistency by setting cookies. Users who see the "test" variant should keep seeing it . The SDK approach handles this automatically with built-in cookie management .

Configuration Management
Use Workers KV to store experiment configurations separately from code. This allows you to start, stop, or modify experiments without deploying new code .

Cache Strategy
Ensure your CDN caching respects variation logic. A common pattern: set Cache-Control: private or use cache keys that vary by the experiment cookie .

The Bottom Line
Cloudflare Workers aren't just making A/B testing faster—they're fundamentally changing how we think about experimentation. When you can modify HTML at the edge with zero performance penalty, you unlock possibilities that were previously impossible:

Run experiments without client-side flicker

Test SEO changes instantly

Personalize content based on real-time conditions

Save money while delivering better experiences

The next time someone tells you A/B testing is slowing down their site, show them what's possible at the edge. Zero flicker. Global reach. Complete control.

Ready to implement your own edge-powered experiments? Check out the Cloudflare Workers examples and start streaming HTML with confidence. Your users—and your conversion rates—will thank you.

Terraform for Frontend Hosting — 40 Lines to Prod

Sohana Akbar — Mon, 29 Jun 2026 09:26:12 +0000

Deploying a frontend application shouldn't require a PhD in DevOps. In this post, I'll show you how to get a production-ready static site online with just 40 lines of Terraform.

Why Terraform for Frontend?
Infrastructure as Code (IaC) isn't just for backend engineers. When you codify your frontend infrastructure, you get:

Repeatable deployments across environments

Version-controlled infrastructure alongside your code

Easy rollbacks (just revert the Terraform state)

No manual AWS console clicking (we all hate that)

The Setup
We'll deploy a static site to AWS S3 with CloudFront CDN and Route 53 DNS. All the essentials for a production-grade frontend.

Prerequisites
bash

Install Terraform

brew install terraform # macOS

or download from terraform.io

AWS CLI configured

aws configure
The 40 Lines
Here's the entire main.tf:

hcl
terraform {
required_providers {
aws = {
source = "hashicorp/aws"
version = "~> 5.0"
}
}
}

provider "aws" {
region = "us-east-1"
}

S3 Bucket for static hosting

resource "aws_s3_bucket" "site" {
bucket = var.domain_name
}

resource "aws_s3_bucket_website_configuration" "site" {
bucket = aws_s3_bucket.site.id
index_document {
suffix = "index.html"
}
error_document {
key = "404.html"
}
}

resource "aws_s3_bucket_public_access_block" "site" {
bucket = aws_s3_bucket.site.id
block_public_acls = false
block_public_policy = false
ignore_public_acls = false
restrict_public_buckets = false
}

resource "aws_s3_bucket_policy" "site" {
bucket = aws_s3_bucket.site.id
policy = jsonencode({
Version = "2012-10-17"
Statement = [
{
Sid = "PublicReadGetObject"
Effect = "Allow"
Principal = ""
Action = "s3:GetObject"
Resource = "${aws_s3_bucket.site.arn}/"
}
]
})
}

CloudFront CDN

resource "aws_cloudfront_distribution" "site" {
origin {
domain_name = aws_s3_bucket_website_configuration.site.website_endpoint
origin_id = var.domain_name

custom_origin_config {
  http_port              = 80
  https_port             = 443
  origin_protocol_policy = "http-only"
  origin_ssl_protocols   = ["TLSv1.2"]
}

}

enabled = true
default_root_object = "index.html"

default_cache_behavior {
allowed_methods = ["DELETE", "GET", "HEAD", "OPTIONS", "PATCH", "POST", "PUT"]
cached_methods = ["GET", "HEAD"]
target_origin_id = var.domain_name

forwarded_values {
  query_string = false
  cookies {
    forward = "none"
  }
}

viewer_protocol_policy = "redirect-to-https"
min_ttl                = 0
default_ttl            = 3600
max_ttl                = 86400

}

price_class = "PriceClass_100"

restrictions {
geo_restriction {
restriction_type = "none"
}
}

viewer_certificate {
cloudfront_default_certificate = true
}

aliases = [var.domain_name]

custom_error_response {
error_code = 404
response_page_path = "/404.html"
response_code = 404
}
}

Variables

variable "domain_name" {
description = "Your domain name (e.g., example.com)"
type = string
}

Outputs

output "website_url" {
value = "https://${var.domain_name}"
}

output "cloudfront_domain" {
value = aws_cloudfront_distribution.site.domain_name
}
That's it. 42 lines including whitespace.

Deployment Workflow

Initialize Terraform bash terraform init
Plan your infrastructure bash terraform plan -var="domain_name=yourdomain.com"
Apply the changes bash terraform apply -var="domain_name=yourdomain.com" -auto-approve
Deploy your frontend code bash aws s3 sync ./dist s3://yourdomain.com
Invalidate CloudFront cache (optional) bash aws cloudfront create-invalidation --distribution-id --paths "/*" CI/CD Integration Add this to your GitHub Actions workflow:

yaml
name: Deploy Frontend
on:
push:
branches: [main]

jobs:
deploy:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- uses: actions/setup-node@v3
with:
node-version: 18
- run: npm ci && npm run build
- uses: hashicorp/setup-terraform@v2
- run: terraform init
- run: terraform apply -auto-approve -var="domain_name=${{ secrets.DOMAIN }}"
- run: aws s3 sync ./dist s3://${{ secrets.DOMAIN }}
Pro Tips

Use Terraform State Backend Add this to store state remotely (essential for teams):

hcl
terraform {
backend "s3" {
bucket = "my-terraform-state-bucket"
key = "frontend/terraform.tfstate"
region = "us-east-1"
}
}

Environment Separation Use Terraform workspaces or separate terraform.tfvars files:

hcl

terraform.tfvars.prod

domain_name = "prod.example.com"

terraform.tfvars.staging

domain_name = "staging.example.com"

Add Custom Headers with CloudFront Functions hcl resource "aws_cloudfront_function" "security_headers" { name = "security-headers" runtime = "cloudfront-js-1.0" code = <<EOF function handler(event) { var response = event.response; response.headers['strict-transport-security'] = { value: 'max-age=63072000' }; response.headers['x-frame-options'] = { value: 'SAMEORIGIN' }; return response; } EOF } What About Other Cloud Providers? The same principle applies. Here's a GCP example:

hcl
resource "google_storage_bucket" "site" {
name = var.domain_name
location = "US"
website {
main_page_suffix = "index.html"
not_found_page = "404.html"
}
}

resource "google_storage_bucket_iam_binding" "public" {
bucket = google_storage_bucket.site.name
role = "roles/storage.objectViewer"
members = ["allUsers"]
}
Real-World Results
Using this approach, I've:

Reduced deployment time from 15 minutes to 2 minutes

Eliminated manual errors (no more "oops, I forgot to enable CDN")

Made rollbacks instant (terraform apply with a previous state)

Saved $50/month by automating resource cleanup with terraform destroy

The Big Picture
Infrastructure as Code for frontend isn't just about deploying faster—it's about treating your infrastructure with the same rigor as your application code. When your infrastructure is in version control, you can:

Review changes via PRs

Track who changed what and why

Reproduce environments exactly

Audit for security compliance

Next Steps
Add SSL certificates with AWS ACM

Implement custom error pages

Set up CloudFront Functions for A/B testing

Add monitoring with CloudWatch alarms

Implement Blue/Green deployments

Final Thoughts
Forty lines of Terraform replaced hours of manual AWS console clicking, created repeatable deployments, and gave me infrastructure that's actually maintainable. Your frontend deserves the same reliability as your backend.

Remember: The goal isn't to write the least lines of code—it's to create infrastructure that's simple, maintainable, and predictable. Forty lines just happens to be how simple it can be.

What's your experience with IaC for frontend? Drop a comment below!

AWS S3 + CloudFront + OAC: The Correct Way to Host a SPA

Sohana Akbar — Sat, 27 Jun 2026 13:21:47 +0000

So you've built a slick single-page application with React, Vue, or Angular. Now comes the crucial question—how do you host it securely on AWS without making your S3 bucket the wild west of the internet? Let's dive into what I consider the correct way: using S3 with CloudFront and Origin Access Control (OAC).

Why the Old Way Isn't Good Enough
I've seen countless tutorials that recommend enabling static website hosting on an S3 bucket and making it public. This always raises a red flag for me .

The problem? Public S3 buckets are security liabilities. Even if your bucket only contains static files today, exposing it directly to the internet creates risks. AWS themselves recommend blocking all public access . Plus, serving content directly from S3 means your users might experience higher latency, especially if they're far from your bucket's region .

The Three Pillars of Secure SPA Hosting

Keep Your S3 Bucket Private First things first—your S3 bucket should remain completely private with all public access blocked . This might seem counterintuitive for a website, but trust me, it's the foundation of a secure setup.

When creating your bucket, disable all public access and ensure your bucket policy doesn't allow public reads. This forces traffic to flow through CloudFront, which becomes your single entry point .

Use Origin Access Control (OAC) Here's where the magic happens. OAC is the modern way to let CloudFront securely access your private S3 bucket . It's the successor to the older Origin Access Identity (OAI) and provides better security with more granular permissions .

Configuring OAC:

In CloudFront, create a new OAC setting

Select "S3" as the origin type and keep the signing behavior as default

In your distribution, set the origin to use this OAC

Important: When configuring your S3 origin in CloudFront, use the REST API endpoint (e.g., your-bucket.s3.amazonaws.com), not the static website endpoint . The static website endpoint and OAC are incompatible .

Update Your Bucket Policy:

Your S3 bucket policy should look like this to allow CloudFront access:

json
{
"Version": "2012-10-17",
"Statement": {
"Sid": "AllowCloudFrontServicePrincipalReadOnly",
"Effect": "Allow",
"Principal": {
"Service": "cloudfront.amazonaws.com"
},
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::YOUR_BUCKET_NAME/*",
"Condition": {
"StringEquals": {
"AWS:SourceArn": "arn:aws:cloudfront::YOUR_ACCOUNT_ID:distribution/YOUR_DISTRIBUTION_ID"
}
}
}
}
Replace the placeholders with your actual bucket name, account ID, and distribution ID .

Handle SPA Routing Properly SPAs use client-side routing, meaning paths like /dashboard or /about are handled by JavaScript, not by the server. If a user refreshes the page or enters a deep link directly, CloudFront will look for a file that doesn't exist and return a 404.

The fix? Configure CloudFront's custom error responses to route 403 and 404 errors back to index.html with a 200 status code :

In your CloudFront distribution, go to the Error Pages tab

Create custom error responses for both 403: Forbidden and 404: Not Found

Set the response page path to /index.html and the response code to 200: OK

This tells CloudFront to serve index.html when a file isn't found, allowing your SPA router to take over and handle the navigation.

Alternative Approach: You can also use a CloudFront Function to rewrite requests:

javascript
function handler(event) {
const request = event.request;
const uri = request.uri;

if (uri.endsWith('/') || !uri.includes('.')) {
    request.uri = '/index.html';
}
return request;

}
This function rewrites requests without file extensions or trailing slashes to index.html .

Optimizing Performance with Caching
Cache Static Assets Aggressively
Your JavaScript and CSS files typically include unique hashes in their filenames (e.g., main-abc123.js), making them immutable. You can cache these aggressively with CloudFront .

Create a separate cache behavior for your static assets. For React, the pattern might be static/, while other frameworks might use assets/:

Go to your CloudFront distribution's Behaviors tab

Create a behavior with a path pattern matching your static assets

Use the managed CachingOptimized policy or create a custom one with long TTLs

You'll see the benefit immediately—CloudFront will serve cached assets with an x-cache: Hit from cloudfront header, dramatically reducing latency for returning visitors .

Don't Cache index.html
Your index.html should have a short cache duration or no caching at all. This ensures users get the latest version of your app without clearing their cache . Consider using max-age=60 with stale-while-revalidate for a balance of performance and freshness .

Custom Domain and SSL
Once your setup is working, you'll want to add a custom domain. You'll need to:

Request an SSL certificate through ACM (AWS Certificate Manager) in the us-east-1 region

Add your domain as an alternate domain name in CloudFront

Create a CNAME record in your DNS provider pointing to your CloudFront distribution domain name

CloudFront will handle SSL termination, providing HTTPS for your custom domain.

The Bottom Line
This architecture—private S3 bucket + CloudFront with OAC—gives you security, performance, and cost-effectiveness. Your S3 bucket stays private, your content gets delivered globally through CloudFront's edge network, and your SPA routes work flawlessly .

Skip the outdated tutorials that make your bucket public. Do it the right way with OAC, and your future self (and your users) will thank you.

SPA vs SSR Deployment: The Infrastructure Showdown

Sohana Akbar — Fri, 26 Jun 2026 14:13:05 +0000

Introduction
The age-old debate between Single Page Applications (SPA) and Server-Side Rendering (SSR) usually centers around user experience, performance, and developer productivity. But there's a critical aspect that often gets overlooked until it's too late: the infrastructure.

How you deploy and host your application fundamentally changes based on your rendering strategy. And trust me, learning this the hard way — like I did with my first production SSR app — is not fun.

Let's dive deep into the infrastructure differences between SPA and SSR deployments, and help you make the right choice for your next project.

The Short Answer
Aspect SPA SSR
Hosting Static file hosting (S3, CDN, Netlify) Dynamic server (Node.js, Python, etc.)
Compute Minimal (just serve files) Significant (render on every request)
Scale Easy (CDN caching) Complex (needs load balancing)
Cost Low Higher
Deployment Simple Complex
Cold Starts None Problematic
SPA Deployment: Static Simplicity
How It Works
A Single Page Application consists of static files:

index.html

JavaScript bundles

CSS files

Assets (images, fonts)

These files are served directly to the browser, where all rendering happens client-side.

Infrastructure Components
text
[CDN/Static Host] → [Browser]
Typical Setup:

Cloud storage (AWS S3, Google Cloud Storage)

CDN (CloudFront, Cloudflare, Fastly)

Optional: API Gateway + Backend services

Deployment Process
bash

Build your SPA

npm run build

Deploy to S3

aws s3 sync build/ s3://my-bucket/

Invalidate CloudFront cache

aws cloudfront create-invalidation --paths "/*"
The Good
✅ Incredibly simple — just copy files
✅ Cheap — storage and bandwidth only
✅ Easy scaling — CDN handles traffic spikes
✅ No server management — zero DevOps overhead
✅ Fast deployments — seconds to push updates

The Bad
❌ SEO challenges — need pre-rendering or dynamic rendering
❌ Initial load performance — must download all JavaScript
❌ Limited dynamic content — can't personalize per request

SSR Deployment: Dynamic Complexity
How It Works
Server-Side Rendering executes your application on the server for each request, generating complete HTML pages dynamically.

Infrastructure Components
text
[Load Balancer] → [Application Servers] → [Cache] → [Browser]
↓
[API Services]
Typical Setup:

Load balancer (ALB, Nginx)

Application servers (ECS, EC2, Kubernetes)

In-memory cache (Redis)

API layer

Database

Deployment Process
yaml

Simplified docker-compose for SSR

version: '3'
services:
app:
build: .
ports:
- "3000:3000"
environment:
- NODE_ENV=production
deploy:
replicas: 3
The Good
✅ SEO friendly — full HTML for crawlers
✅ Better perceived performance — content visible faster
✅ Personalization — per-request rendering
✅ Shared state — server can pre-fetch data

The Bad
❌ Complex infrastructure — servers, load balancers, caching
❌ Higher costs — compute resources for every request
❌ Cold start issues — especially with serverless
❌ Scaling challenges — stateful rendering
❌ More failure points — infrastructure can fail

Critical Infrastructure Decisions

Caching Strategy SPA:

text
Cache-Control: public, max-age=31536000, immutable
Versioned assets = infinite cache

HTML file = short cache or no cache

SSR:

text
Cache-Control: public, max-age=60
Dynamic caching with invalidation

Cache per user/region

Must handle cache stampedes

Scaling SPA Scaling:

Horizontal scaling is trivial

CDN handles 99% of traffic

SSR Scaling:

Need auto-scaling groups

Connection pooling

Database connection limits

Cold Starts SPA: None. Files are served instantly.

SSR:

javascript
// Serverless SSR cold start
exports.handler = async (event) => {
// This code runs on every cold start
const app = require('./app'); // Heavy!
return app.render(event);
};
Avoid serverless for SSR at high scale

Use always-on instances

Or implement warmup strategies

Real-World Performance Impact
Page Load Time Breakdown
SPA (First Visit):

text
📦 Download HTML: 50ms
📦 Download JavaScript: 800ms
⚡ Parse & Execute: 600ms
🎨 Render: 200ms
Total: ~1650ms to interactive
SSR (First Visit):

text
🖥️ Server Render: 200ms
📦 Download HTML: 150ms
📦 Download JavaScript (hydration): 400ms
🎨 Hydrate: 400ms
Total: ~1150ms to interactive
Cost Comparison (Monthly, 1M visits)
SPA:

Storage: ~$5

Bandwidth: ~$100

CDN: ~$20

Total: ~$125

SSR:

Servers (3 instances): ~$300

Load Balancer: ~$20

Cache (Redis): ~$50

Database: ~$100

Total: ~$470

Hybrid Approaches
Static Site Generation (SSG)
Build once, deploy everywhere

text
[Build Server] → [Static Files] → [CDN]
Best of both worlds

Perfect for content sites

Limited personalization

Incremental Static Regeneration
javascript
// Next.js ISR
export async function getStaticProps() {
return {
props: { data },
revalidate: 60 // Regenerate every 60 seconds
};
}
Edge Rendering
Render at the edge for speed:

javascript
// Cloudflare Workers
export default {
async fetch(request) {
const html = await renderPage(request);
return new Response(html, {
headers: { 'Content-Type': 'text/html' }
});
}
};
Making the Choice: Decision Framework
Choose SPA if:
You're building a dashboard/admin panel

SEO is not critical

You have a dedicated API layer

Budget is limited

Small team with no dedicated DevOps

Choose SSR if:
SEO is critical for your business

Personalization is required

You need fast initial paint

You have budget for infrastructure

Team has backend expertise

Choose SSG if:
Content is mostly static

Need good SEO

Want SPA-like hosting simplicity

Content changes infrequently

Migration Gotchas
Moving from SPA to SSR
API changes: Need to support server-side data fetching

Authentication: Session management on server

Environment variables: Can't use client-side env vars

Build process: Need Node.js compatibility

Moving from SSR to SPA
SEO strategy: Need pre-rendering solution

API exposure: More APIs become public

Performance: Need to optimize bundle sizes

State management: Must move state to client

Monitoring & Observability
SPA Monitoring
javascript
// Client-side monitoring
window.addEventListener('error', (e) => {
sendToAnalytics({
type: 'client_error',
message: e.message,
stack: e.error?.stack
});
});
SSR Monitoring
javascript
// Server-side monitoring
app.use((err, req, res, next) => {
logger.error({
message: err.message,
stack: err.stack,
requestId: req.id,
userId: req.user?.id
});
res.status(500).send('Server Error');
});
Key Metrics to Track:

SPA SSR
Bundle size Render time
Time to Interactive CPU usage
API response times Memory usage
Client errors Request queue length
CDN cache hit ratio Garbage collection pauses
Conclusion
The infrastructure differences between SPA and SSR are significant and should influence your decision early in the project lifecycle.

SPA offers simplicity, cost-effectiveness, and easy scaling at the expense of SEO and initial load performance.

SSR provides better SEO and perceived performance but demands more complex infrastructure and higher costs.

There's no "one size fits all" answer. Evaluate your specific requirements:

Does SEO matter for your business?

Can you afford the infrastructure costs?

Do you have the team expertise?

What are your performance requirements?

And remember — you're not locked in forever. Many teams start with one approach and migrate as needs evolve. Just plan for the transition if you think you might need it.

Resources
Tools Mentioned
Next.js - React framework with SSR/SSG

Vercel - Deployment platform

AWS Amplify - SPA hosting

Cloudflare Workers - Edge rendering

Further Reading
Next.js Deployment Documentation

AWS S3 Static Website Hosting

Vercel vs Netlify for SPAs

What's your experience with SPA vs SSR deployment? Have you migrated between the two? Share your stories in the comments below!

Serverless Frontends: When to Use Lambda@Edge

Sohana Akbar — Wed, 24 Jun 2026 15:17:15 +0000

Serverless is everywhere, and the frontend world has fully embraced it. We've got static sites on S3, APIs on Lambda, and everything managed by the cloud. But there's one piece of the puzzle that often gets overlooked: the edge.

Lambda@Edge is a powerful tool that lets you run serverless code at AWS's global edge locations, right where your users are. It can supercharge your frontend performance, but it's not always the right solution. Let's dive into when you should use Lambda@Edge for your serverless frontend—and when you should look elsewhere.

What Actually Is Lambda@Edge?
Lambda@Edge is an extension of AWS Lambda that runs your code in response to CloudFront events . Instead of your code executing in a single region, it runs across CloudFront's global network of edge locations, bringing compute power closer to your users .

The magic happens through four CloudFront events :

Viewer Request – When CloudFront receives a request from a user

Origin Request – Before CloudFront forwards the request to your origin

Origin Response – When CloudFront receives a response from your origin

Viewer Response – Before CloudFront returns the response to the user

This event-driven architecture lets you intercept and modify requests and responses at various points in the content delivery flow .

The Big Question: Lambda@Edge or CloudFront Functions?
Before we go further, there's a crucial decision you need to make. AWS offers two edge compute options: Lambda@Edge and CloudFront Functions. They're not interchangeable—each serves different purposes.

Here's the quick comparison :

Feature CloudFront Functions Lambda@Edge
Languages JavaScript (ES5.1) Node.js, Python
Events Viewer Request/Response only All four events
Execution time < 1ms 5s (viewer) / 30s (origin)
Memory 2 MB 128 MB – 10 GB
Code size 10 KB 1 MB (viewer) / 50 MB (origin)
Network access ❌ No ✅ Yes
Request body access ❌ No ✅ Yes
Scale Millions/sec 10,000/sec per region
Rule of thumb: Use CloudFront Functions for simple header manipulation, cache key normalization, or lightweight URL rewrites. Reach for Lambda@Edge when you need complex logic, network calls, or access to the request body .

When Lambda@Edge Shines for Frontends

Dynamic Content Personalization Your frontend might need to serve different content based on user location, device type, or preferences. Lambda@Edge can customize responses at the edge without going back to your origin .

javascript
// Example: Rewriting URLs based on user-agent
exports.handler = (event, context, callback) => {
const request = event.Records[0].cf.request;
const headers = request.headers;
const userAgent = headers['user-agent']?.[0]?.value || '';

if (userAgent.includes('Mobile')) {
    request.uri = '/mobile' + request.uri;
}

callback(null, request);

};

Server-Side Rendering (SSR) Without Servers One of the most compelling use cases is running SSR at the edge. Instead of spinning up servers or using API Gateway + Lambda (which adds latency), you can render pages directly at CloudFront edge locations .

For a Nuxt.js app, for instance, you can deploy the SSR logic to Lambda@Edge, with static assets served directly from S3. The result? Global scalability with significantly lower latency than traditional approaches .

Image Optimization on the Fly Modern frontends need responsive images for different devices. Lambda@Edge can resize, compress, or transform images in real-time based on device capabilities .

This offloads processing from your origin and reduces bandwidth costs. A viewer request trigger can detect the device type and request appropriately sized images from your origin or a transformation service.

A/B Testing and Feature Flags Want to test a new version of your frontend with 10% of users? Lambda@Edge can direct users to different versions based on cookies, headers, or even randomized logic .

The function runs at the edge, so the routing decision happens before the request reaches your origin. Your origin doesn't even need to know about the test.

Security at the Edge Protect your frontend by validating JWT tokens, adding security headers (HSTS, CSP), or blocking malicious bots before they reach your origin . This is especially valuable for SPAs or content-heavy applications where you want to prevent unauthorized access to your assets.

javascript
// Origin request trigger: Validate JWT before hitting origin
exports.handler = (event, context, callback) => {
const request = event.Records[0].cf.request;
const headers = request.headers;
const token = headers.authorization?.[0]?.value || '';

if (!isValidJWT(token)) {
    const response = {
        status: '401',
        statusDescription: 'Unauthorized',
        body: 'Invalid token'
    };
    callback(null, response);
} else {
    callback(null, request);
}

};
Real-World Impact: Performance Matters
A Japanese cloud blog recently tested Lambda@Edge performance and found remarkable results. Using Lambda@Edge without Origin Shield, they achieved consistent ~220ms response times from US, Japan, and Singapore locations .

The numbers tell a compelling story:

With Lambda@Edge: ~220ms from Singapore

Without Lambda@Edge (direct to Lambda URL): ~860ms from Singapore

That's nearly 4x faster—a massive win for user experience globally.

When You Should Think Twice
Lambda@Edge isn't a silver bullet. Here are scenarios where it might not be the right fit:

Simple HTTP Manipulations
If all you're doing is adding headers, normalizing cache keys, or simple URL redirects, CloudFront Functions are cheaper, faster to deploy, and easier to manage .
Heavy Computation or Long-Running Tasks
Lambda@Edge has strict limits:

Viewer triggers: 5 seconds max

Origin triggers: 30 seconds max

Complex operations or large file processing belong in a regular Lambda function, not at the edge.

When Edge Complexity Outweighs Benefit Just because you can move something to the edge doesn't mean you should. Edge compute will always be more constrained than a full AWS region. Consider:

State management is harder at the edge

Deployments take minutes (updates must propagate globally)

Debugging and logging are more complex

High-Frequency, Simple Logic at Massive Scale While Lambda@Edge scales to 10,000 requests/second per region, CloudFront Functions handle millions of requests/second at a fraction of the cost . For massive-scale header manipulation or cache key normalization, CloudFront Functions are the clear winner.

Best Practices for Lambda@Edge Frontends
Cache Everything You Can
Lambda@Edge costs money per request and execution time. Implement aggressive caching strategies to minimize invocations . CloudFront's cache can store 3XX redirects, API responses, and even dynamically generated content .

javascript
// In your response, set caching headers
response.headers['cache-control'] = [{
key: 'Cache-Control',
value: 'public, max-age=3600, stale-while-revalidate=300'
}];
Mind the 1MB Package Limit
Viewer-triggered Lambda@Edge functions have a 1 MB compressed package limit . If your code requires heavy dependencies:

Minimize dependencies

Use lightweight libraries

Offload heavy work to DynamoDB or S3

Split functions into smaller pieces

Watch for Cold Starts
Lambda@Edge can experience cold starts like regular Lambdas . For latency-sensitive frontends, implement warming strategies or keep your function's execution time as low as possible.

Consider Concurrency Limits
Your account has a default Lambda concurrency limit of 1,000 executions per region. For high-traffic frontends, you may need to request a limit increase . Calculate your needs:

text
Concurrency needed = (requests/second) × (function duration in seconds)
The Verdict
Lambda@Edge is a powerful tool for serverless frontends when you need:

Global performance – Run code where your users are

Dynamic content – Personalization, SSR, A/B testing

Security – Authentication and protection at the edge

Network access – Calls to databases, APIs, or other services

But don't reach for it by default. For simple operations, CloudFront Functions are faster, cheaper, and simpler to manage. And for heavy processing that doesn't need to run on every request, keep it in a regular Lambda in your region.

The edge is an incredible place to run code—but like any powerful tool, use it where it makes the most impact. For the right serverless frontend, Lambda@Edge can be the difference between good global performance and truly exceptional user experiences.