For the last year, I've been deep in AI tools — coding agents, cloud agents, UX design agents, code review agents, you name it. Not evaluating them from a distance. Using them. Daily. On real projects.

I'm not an AI expert. I'm not building foundation models or writing research papers. But I am someone who has used these tools long enough to see their patterns — where they shine, where they break, and what they actually need to work well.

And here's my one take that I don't see enough people talking about:

The smarter AI gets, the more it needs humans. Not less.

Let me explain with an analogy that hit me as an engineer and as a father.

My Son Is Smarter Than I Was at His Age. He Still Needs Me.

This generation of kids is incredible. They have access to everything. They learn faster. They figure things out that took us years to understand.

But here's the thing — my son still gets stuck. Not because he's not smart. Because he doesn't have context. He doesn't know what he doesn't know. He walks into ambiguity and freezes. He makes confident decisions that are completely wrong because he's missing one piece of experience he hasn't lived yet.

Sound familiar?

That's exactly how AI agents behave.

They are fast. They are capable. They can write code, analyze data, generate plans, and execute tasks that would take me hours.

I've seen a coding agent refactor an entire module in minutes. I've watched a code review agent catch bugs I missed. I've used cloud agents to spin up infrastructure that would have taken me a full day to configure manually.

But they still need a parent.

What Does "Parenting AI" Actually Look Like?

When I say AI needs a parent, I don't mean babysitting. I mean the same things a good parent does:

Observation. You don't hover over your kid every second. But you watch. You notice patterns. You catch the moment something is going off track before it becomes a disaster. In production systems, we call this monitoring and observability. With AI agents, it's the same instinct — I've had coding agents confidently generate solutions that looked perfect on the surface but would have caused silent data loss in production. I caught it not because I read every line, but because something felt off. You set up the guardrails, you watch the outputs, you notice when something smells wrong.

Intervention at ambiguity. A smart kid will try to push through uncertainty on their own. Sometimes that works. Sometimes they go deep into a wrong direction and waste hours. A good parent steps in at the right moment — not too early, not too late — and says "have you considered this?" That's the human role with AI agents. The agent will execute confidently. It's your job to know when that confidence is misplaced.

Approval as a feature, not a bottleneck. In engineering, we have code reviews, deployment gates, approval workflows. Nobody calls those "bottlenecks" — they're checkpoints that prevent catastrophe. When an AI agent pauses and asks for human approval, that's not a failure of autonomy. That's good architecture.

Gut-level judgment. This is the one nobody wants to talk about. After 15 years of building and breaking systems, I've developed a sense for when something is about to go wrong. I can't always explain it. It's pattern recognition built from thousands of production incidents, late-night debugging sessions, and projects that failed in ways nobody predicted. AI doesn't have that. It has data. It has probabilities. But it doesn't have the scar tissue that tells you "this feels off, let's pause."

The Real Risk Isn't AI Going Rogue. It's Humans Checking Out.

Here's what actually worries me.

It's not that AI agents will become too powerful. It's that humans will get lazy. We'll see the agent handling things well for weeks, and we'll stop reviewing. We'll skip the approval step. We'll trust the output without reading it.

It's exactly like the parent who stops checking homework because the kid "always gets it right." And then one day, the kid turns in something completely wrong, and nobody caught it.

The most dangerous failure mode isn't an AI that makes mistakes. It's a human who assumes it won't.

Experience Is the Moat

Everyone is talking about AI replacing developers, replacing engineers, replacing knowledge workers.

But here's what I've learned from 15 years in this industry: the hardest part of building software was never writing the code. It was knowing what to build. Knowing when to ship. Knowing when to stop. Knowing when the "technically correct" solution is practically wrong.

That's experience. That's judgment. That's what a parent brings that a child — no matter how brilliant — doesn't have yet.

AI agents are going to get smarter every year. They'll write better code than me. They'll analyze data faster than me. They'll generate solutions I wouldn't have thought of.

And they'll still need someone who has been through enough production fires to know when to say: "Wait. Let's think about this before we proceed."

That someone is you. Don't automate yourself out of that role.

The Bottom Line

The future of AI isn't human vs. machine. It's human with machine — where the human is the experienced parent, and the AI is the brilliant kid who still needs guidance.

If you're a builder, an engineer, a product person — your experience isn't becoming obsolete. It's becoming the most critical layer in the stack.

The agents will do the work. You'll make sure it's the right work.

That's not a limitation of AI. That's how good systems have always worked.

I'm a full-stack developer and product engineer with 15 years of building, maintaining, observing, and debugging systems. For the past year, I've been using AI agents daily not as an expert, but as a parent.

A few months ago I published a post about using Prerender.io with Angular (https://www.internetkatta.com/how-i-fixed-seo-for-our-angular-spa-using-aws-amplify-prerenderio). The approach worked, but when I checked my bill I was paying ₹5,000/month ( $49) to Prerender.io for essentially zero usage.

My app is an Angular SPA hosted on AWS Amplify. Angular renders everything client-side using JavaScript. Social bots like WhatsApp, LinkedIn, Googlebot, and Telegram don't execute JavaScript. They crawl your URL, get a blank HTML shell, and your link preview shows nothing. No title. No image. No description.

Prerender.io solves this by running a headless browser on their servers, rendering your page, and returning the fully-rendered HTML to bots. It works well. But at ₹5,000/month, I was paying for a service that was essentially idling — my platform was still early stage, getting very little traffic while I worked on getting traction.

That's ₹5,000/month for almost zero usage. No scaling. No pay-per-use. Just a flat fee.

I started asking: can I build this myself on AWS and pay only for what I actually use?

Understanding the Existing Setup

Before building anything, I needed to understand exactly what prerender.io was doing for me. The architecture flow was: Regular users bypass all of this entirely and hit Amplify directly. The key insight: prerender.io was just a CloudFront origin. The Lambda@Edge was doing the bot detection and routing. prerender.io itself was a black box sitting at the end of that route. If I could replace that black box with my own renderer, I wouldn't need to touch the bot detection logic at all.

Designing the Replacement

So, the requirements were clear:

• Serverless — pay only when a bot actually hits a page

• No fixed monthly cost

• Same output as prerender.io — fully rendered HTML

• No changes to the Angular app

• Minimal changes to the bot detection logic in LambdaEDGE

The core idea was to replace this: Lambda@Edge origin-request → service.prerender.io to new flow Puppeteer

Why Puppeteer + networkidle0?

Prerender.io works without any changes to the Angular app. It uses a headless Chrome browser that waits until the page has no network activity for 500ms (networkidle0). This gives Angular enough time to finish fetching data and rendering the DOM. The same approach works in our own Lambda — no Angular code changes needed.

Why S3 for Caching?

A rendered page doesn't change every second. An article published today will have the same meta tags tomorrow. Caching the rendered HTML in S3 means:

• First bot request for a URL: Puppeteer renders it (5–10 seconds, acceptable for bots)

• Every subsequent bot request: S3 returns it in ~300ms

• Cache TTL: 24 hours (configurable)

This is how architecture look like.

The Code

Lambda@Edge — socialbots function

This runs at CloudFront edge. The key change from the original prerender.io version is the last 5 lines of the origin-request block. Bot detection logic is untouched.

'use strict';

const INTERNAL_TOKEN = 'your-secret-token'; // same value as renderer Lambda INTERNAL_TOKEN env var

exports.handler = (event, context, callback) => {
    const request = event.Records[0].cf.request;

    if (request.headers['x-prerender-token'] && request.headers['x-prerender-host']) {
        // ── ORIGIN-REQUEST: bot detected in viewer-request, now route to renderer ──

        if (request.headers['x-query-string']) {
            request.querystring = request.headers['x-query-string'][0].value;
        }

        // CRITICAL: When Lambda@Edge changes request.origin, CloudFront does NOT
        // automatically update the Host header. API Gateway rejects requests where
        // Host doesn't match its configured custom domain → ForbiddenException.
        // Must set Host explicitly before setting request.origin.
        request.headers['host'] = [{ key: 'Host', value: 'precache.myapp.com' }];

        request.origin = {
            custom: {
                domainName: 'precache.myapp.com', // ← was: service.prerender.io
                port: 443,
                protocol: 'https',
                readTimeout: 30,                           // ← was: 20 (Puppeteer needs up to 25s)
                keepaliveTimeout: 5,
                customHeaders: {
                    'x-prerender-token': [{                // auth token sent to renderer
                        key: 'X-Prerender-Token',
                        value: INTERNAL_TOKEN
                    }]
                },
                sslProtocols: ['TLSv1.2'],                 // ← was: TLSv1, TLSv1.1 (deprecated)
                path: ''                                   // ← was: '/https%3A%2F%2F' + host
            }
        };

    } else {
        // ── VIEWER-REQUEST: detect bots, set headers ── (completely unchanged)
        const headers = request.headers;
        const user_agent = headers['user-agent'];
        const host = headers['host'];

        if (user_agent && host) {
            var prerender = /googlebot|adsbot\-google|Feedfetcher\-Google|bingbot|yandex|
                baiduspider|Facebot|facebookexternalhit|twitterbot|rogerbot|linkedinbot|
                embedly|quora link preview|showyoubot|outbrain|pinterest|slackbot|vkShare|
                W3C_Validator|redditbot|applebot|whatsapp|flipboard|tumblr|bitlybot|
                skypeuripreview|nuzzel|discordbot|google page speed|qwantify|pinterestbot|
                bitrix link preview|xing\-contenttabreceiver|chrome\-lighthouse|telegrambot|
                Perplexity|OAI-SearchBot|ChatGPT|GPTBot|ClaudeBot|Amazonbot|
                integration-test/i.test(user_agent[0].value);

            prerender = prerender || /_escaped_fragment_/.test(request.querystring);
            prerender = prerender && !/\.(js|css|xml|less|png|jpg|jpeg|gif|pdf|doc|txt|
                ico|rss|zip|mp3|rar|exe|wmv|avi|ppt|mpg|mpeg|tif|wav|mov|psd|ai|xls|
                mp4|m4a|swf|dat|dmg|iso|flv|m4v|torrent|ttf|woff|svg|eot)$/i
                .test(request.uri);

            if (prerender) {
                console.log('Bot detected:', user_agent[0].value);
                headers['x-prerender-token'] = [{ key: 'X-Prerender-Token', value: INTERNAL_TOKEN }];
                headers['x-prerender-host'] = [{ key: 'X-Prerender-Host', value: host[0].value }];
                headers['x-prerender-cachebuster'] = [{ key: 'X-Prerender-Cachebuster', value: Date.now().toString() }];
                headers['x-query-string'] = [{ key: 'X-Query-String', value: request.querystring }];
            }
        }
    }

    callback(null, request);
};

Deploy note: Lambda@Edge must be in us-east-1. After publishing a new version, update both the viewer-request and origin-request ARNs in your CloudFront behaviour to point to the new version number (e.g. :12 → :13). CloudFront takes 5–10 minutes to propagate.

Renderer Lambda — index.js

This runs in ap-south-1 ( I choose Mumbai because my app run on this region) as a container image. Receives bot requests from API Gateway, checks S3 cache, renders with Puppeteer if needed.

'use strict';

const chromium = require('@sparticuz/chromium');
const puppeteer = require('puppeteer-core');
const { S3Client, GetObjectCommand, PutObjectCommand } = require('@aws-sdk/client-s3');

const s3 = new S3Client({});

const BUCKET         = process.env.CACHE_BUCKET;
const CACHE_TTL_MS   = parseInt(process.env.CACHE_TTL_HOURS || '24') * 3600 * 1000;
const INTERNAL_TOKEN = process.env.INTERNAL_TOKEN;
const SITE_URL       = process.env.SITE_URL || 'https://myapp.com';

// Reuse browser across warm Lambda invocations — saves 3-5s Chromium startup time
let browser = null;

async function getBrowser() {
    if (browser && browser.connected) return browser;
    browser = await puppeteer.launch({
        args: chromium.args,
        defaultViewport: { width: 1280, height: 800 },
        executablePath: await chromium.executablePath(),
        headless: true,
    });
    return browser;
}

function pathToS3Key(urlPath) {
    const clean = urlPath.replace(/^\/+|\/+$/g, '') || 'index';
    return `cache/${clean}.html`;
    // Examples:
    //   /article/my-slug  →  cache/article/my-slug.html
    //   /                 →  cache/index.html
}

exports.handler = async (event) => {
    const headers = event.headers || {};

    // Reject requests without the internal token
    // (prevents anyone who discovers the URL from triggering renders)
    if (INTERNAL_TOKEN) {
        const token = headers['x-prerender-token'] || headers['x-internal-token'];
        if (token !== INTERNAL_TOKEN) {
            console.log('Rejected: wrong or missing token');
            return { statusCode: 403, body: 'Forbidden' };
        }
    }

    const urlPath   = event.rawPath || '/';
    const host      = headers['x-prerender-host'] || new URL(SITE_URL).hostname;
    const targetUrl = `https://\({host}\){urlPath}`;
    const s3Key     = pathToS3Key(urlPath);

    // ── 1. Check S3 cache 
    try {
        const cached     = await s3.send(new GetObjectCommand({ Bucket: BUCKET, Key: s3Key }));
        const renderedAt = parseInt(cached.Metadata?.['rendered-at'] || '0');

        if ((Date.now() - renderedAt) < CACHE_TTL_MS) {
            const html = await cached.Body.transformToString('utf-8');
            console.log(`CACHE HIT [${urlPath}]`);
            return {
                statusCode: 200,
                headers: {
                    'content-type': 'text/html; charset=utf-8',
                    'x-prerender-cache': 'HIT',
                },
                body: html,
            };
        }
        console.log(`CACHE STALE [${urlPath}] — re-rendering`);
    } catch (err) {
        if (err.name !== 'NoSuchKey') console.error('S3 read error:', err.message);
        console.log(`CACHE MISS [${urlPath}]`);
    }

    // ── 2. Render with Puppeteer ──────────────────────────────────────────────
    console.log(`Rendering: ${targetUrl}`);

    let html;
    try {
        const b    = await getBrowser();
        const page = await b.newPage();

        // Block images, fonts, media — bots only need HTML + meta tags.
        // Blocking these cuts render time by 30-60%.
        await page.setRequestInterception(true);
        page.on('request', req =>
            ['image', 'font', 'media'].includes(req.resourceType())
                ? req.abort()
                : req.continue()
        );

        // networkidle0: wait until no network activity for 500ms.
        // This is how prerender.io works — Angular finishes data fetching and rendering.
        await page.goto(targetUrl, { waitUntil: 'networkidle0', timeout: 25000 });

        html = await page.content();
        await page.close();

    } catch (err) {
        console.error(`Render failed [${targetUrl}]:`, err.message);
        if (browser) {
            try { await browser.close(); } catch (_) {}
            browser = null; // force fresh browser on next invocation
        }
        return { statusCode: 500, body: 'Render error' };
    }

    // ── 3. Store in S3 cache ──────────────────────────────────────────────────
    try {
        await s3.send(new PutObjectCommand({
            Bucket: BUCKET,
            Key: s3Key,
            Body: html,
            ContentType: 'text/html; charset=utf-8',
            Metadata: {
                'rendered-at': Date.now().toString(),
                'source-url': targetUrl,
            },
        }));
        console.log(`Cached → ${s3Key}`);
    } catch (err) {
        console.error('S3 write error (non-fatal):', err.message);
    }

    return {
        statusCode: 200,
        headers: {
            'content-type': 'text/html; charset=utf-8',
            'x-prerender-cache': 'MISS',
        },
        body: html,
    };
};

Dockerfile

# AWS Lambda Node.js 20 base image (Amazon Linux 2023)
# @sparticuz/chromium v133+ is compatible with AL2023
FROM public.ecr.aws/lambda/nodejs:20

COPY package.json ./
RUN npm install --omit=dev

COPY index.js ./

CMD ["index.handler"]

package.json

{
  "name": "prerender-renderer",
  "version": "1.0.0",
  "dependencies": {
    "@aws-sdk/client-s3": "^3.741.0",
    "@sparticuz/chromium": "^133.0.0",
    "puppeteer-core": "^24.0.0"
  }
}

Build note: Always build with --platform linux/amd64 --provenance=false on Mac. The --provenance=false flag prevents Docker Desktop from creating an OCI manifest list, which Lambda doesn't support.

docker build --platform linux/amd64 --provenance=false -t renderer .

Problems We Hit Along the Way

Problem 1: Lambda Block Public Access (Account-Level)

The renderer Lambda needed an HTTP endpoint CloudFront could call as a custom origin. The natural choice was Lambda Function URL — no extra services, free, simple.

It returned 403 immediately.

AWS silently enabled Lambda Block Public Access at the account level in late 2024 (similar to S3's public access block). This blocks all Lambda Function URLs from public internet access, even with AuthType=NONE. The feature exists for good reasons but wasn't clearly communicated as a default.

Fix: Use API Gateway HTTP API instead. Same effective cost (< $1/month at any realistic scale for this use case), no public access restrictions.

Problem 2: The Host Header

This was the hardest bug to diagnose. Symptoms:

• Direct request to precache.myapp.com with token → 200 ✓

• Bot request through CloudFront → 403 from API Gateway

• Response had x-amzn-errortype: ForbiddenException and content-length: 0

The content-length: 0 was the clue. Our Lambda's 403 returns body "Forbidden" (8 bytes). Zero content means the request never reached our Lambda — API Gateway itself was rejecting it.

Root cause: when Lambda@Edge dynamically changes request.origin, CloudFront does not update the Host header to match the new origin domain. The request arrives at API Gateway with Host: myapp.com instead of Host: precache.myapp.com. API Gateway rejects it because that host isn't mapped to any API.

Confirmed with:

# Simulates what CloudFront sends without the fix
curl -H "Host: myapp.com" https://YOUR_API_ID.execute-api.ap-south-1.amazonaws.com/
# → 403 ForbiddenException

# Correct Host
curl -H "Host: precache.myapp.com" https://YOUR_API_ID.execute-api.ap-south-1.amazonaws.com/
# → 200 OK

Fix: One line in Lambda@Edge, before setting request.origin:

request.headers['host'] = [{ key: 'Host', value: 'precache.myapp.com' }];

This is not documented prominently in AWS guides but is a known gotcha with Lambda@Edge + API Gateway custom domains.

Scale Analysis and Cost Comparison

Renders vs Requests — The Critical Distinction

prerender.io charges per render — a render happens only when their headless Chrome actually runs (cache miss on their end). Repeated requests for the same URL within the cache window don't cost extra renders.

Our system works the same way:

• Cache miss = Puppeteer runs → slow (~8s), costs compute

• Cache hit = S3 returns cached HTML → fast (~300ms), costs almost nothing

Our cache is bounded by content, not traffic

With 241 content pages and a 24-hour TTL:

Maximum renders per month = 241 pages × 30 days = 7,230

No matter how many millions of requests arrive,
Puppeteer runs at most 7,230 times per month.

At 1,000,000 bot requests per month with a 99.3% cache hit rate, we still only render 7,230 times. This is the structural advantage of URL-level S3 caching.

AWS Pricing Used (ap-south-1)

Cost Comparison at Scale

prerender.io \(49 plan includes 25,000 renders/month. Extra renders cost \)2 per 1,000. Our system never exceeds 7,230 renders/month (bounded by content count), so we'd never hit their overage pricing either.

In INR (₹83 = $1 approx)

Today        → ₹0       vs ₹5,000/month   → saves ₹5,000/month
1K req/mo    → ₹0       vs ₹5,000/month   → saves ₹5,000/month
10K req/mo   → ₹1       vs ₹5,000/month   → saves ₹4,999/month
100K req/mo  → ₹10      vs ₹5,000/month   → saves ₹4,990/month
1M req/mo    → ₹1,100   vs ₹16,000+/month → saves ₹14,900+/month
5M req/mo    → ₹8,300   vs Enterprise      → saves significantly

When Does prerender.io Win?

At extreme scale (10M+ requests/month) and where geographic rendering matters — prerender.io has global PoPs, so renders happen near the requesting bot. Our renderer is in ap-south-1. For an Indian platform with Indian bots, this is fine. For a global platform, you'd want renderers in multiple regions.

Future Optimization: CloudFront-Level Caching

Currently every bot request invokes our Lambda (even cache hits, just for 0.5s). At 1M+ requests/month this adds up. The fix: enable CloudFront caching on the /prerender/* behavior with a 24-hour TTL.

First bot request for /article/xyz in 24h
    → Lambda invoked → Puppeteer renders → CloudFront caches response

Next 999 bot requests for same URL in same 24h window
    → CloudFront edge serves directly → Lambda never invoked
    → Cost: $0

This collapses 1M Lambda invocations to ~7,230 per month. At that point the 1M/month scenario costs under \(1 instead of \)13. Worth implementing when you approach that scale.

Trade-offs and Honest Assessment

Advantages

Pay-per-use with a hard ceiling: Renders are bounded by content count. 241 pages × 30 days = 7,230 renders max regardless of traffic. Costs can't spiral.

Full control: Cache TTL, bot detection rules, Puppeteer behaviour — all tunable. With prerender.io, you accept their defaults.

No vendor lock-in: One day prerender.io could shut down, change pricing, or have an outage. This infrastructure is yours and runs indefinitely.

Transparency: CloudWatch logs show exactly which bots crawl which pages, render durations, cache hit ratios.

Warm cache hits are fast: ~300ms, comparable to prerender.io's cached responses.

Honest Limitations

Cold start on cache miss: First bot request for a new URL takes 5–10 seconds. Lambda cold start + Chromium launch + Angular data fetching. Bots are patient, but it's not instant.

You own the Chromium version: If @sparticuz/chromium has a bug or Chrome updates break something, it's your problem. prerender.io handles this silently. Plan to update the package ~quarterly.

Lambda@Edge timeout risk: Lambda@Edge has a hard 30-second origin timeout. Complex pages that take longer than ~25 seconds to render will return a 504. Hasn't happened in practice, but it's a ceiling.

No geographic rendering: Our renderer Lambda is in ap-south-1. For a global platform, bots crawling from the US or Europe add ~150–200ms latency to the render. For an Indian platform with Indian bots, this doesn't matter.

One-time engineering cost: Setting up this system took a day of work and debugging. prerender.io takes 30 minutes. Factor this in if your time is expensive.

Final Results

# WhatsApp bot
HTTP 200 — 2.09s  (cache miss on first request — Puppeteer rendered)

# Googlebot (second request, cache hit)
HTTP 200 — 0.30s

# LinkedIn
HTTP 200 — 0.37s

# Regular user → Amplify, not renderer — no change
HTTP 200 — 0.18s

Rendered HTML for the article includes the correct title and meta tags:

<title>My Article Title | My App</title>
<meta property="og:title" content="..." />
<meta property="og:description" content="..." />
<meta property="og:image" content="..." />

Link previews on WhatsApp, LinkedIn, and Twitter work correctly. Googlebot indexes full content. The ₹5,000/month prerender.io subscription is cancelled.

Cost: ₹0/month today. ₹1,100/month at 1 million bot requests. ₹8,300/month at 5 millions.

That's how long I'd been waiting to attend re:Invent. Ten years of watching from afar, reading live tweets, consuming session recordings days later, imagining what it would feel like to be there in person.

This year, AWS launched a grant program for User Group Leaders. After a decade of being part of AWS community, attending, volunteering, contributing and organising meet-ups, answering questions at midnight, showing up week after week and I finally got the grant.

I was on cloud nine. The long-awaited dream was finally happening.

But here's what they don't tell you about dreams coming true: they rarely arrive smoothly. There are always ups and downs, tests you didn't prepare for, moments that ask you to prove how badly you really want it.

Mine came twenty-four hours before takeoff.

Most re:Invent stories start with excitement—the kind you share in Slack channels and LinkedIn posts. Mine started with a phone screen lighting up in a London airport terminal.

The Call That Changed Everything

Twenty-four hours earlier, my wife wasn't feeling well. Still, she looked at me with that determined expression I've come to recognise over the years and said, "You finally got this chance. Go. Don't miss it. I'll handle everything here."

The weight of that sentence was the trust, the sacrifice, the quiet strength and it doesn't leave you. It becomes part of the journey itself.

I boarded my first flight trying to convince myself everything would be fine. The nervous energy of a first-time re:Invent attendee mixed with the worry of leaving home when things weren't perfect. But we'd made the decision. I was going.

Then came the message.

Waiting for my connection at Heathrow, surrounded by the usual airport chaos, my phone buzzed. The hospital. My son had fallen. Two fractures. One dislocation. His arm.

I called home immediately. My wife picked up, her voice steady as she walked me through what happened, what the doctors said, what came next. In the background, I could hear the sounds of the emergency room. And as we spoke, trying to process it all, I saw the airline staff closing the aircraft door.

Ten hours in the air where there was no no network. I was waiting for update but can’t do anything.
Just the hum of engines and one thought playing on repeat: How is she managing all this alone, when she herself isn't well?

That flight became a masterclass in helplessness. In recognising that behind every conference badge, every community contribution, every public achievement, there are people at home carrying half your world, sometimes more and so you can chase the other half.

When Your Mind Finally Lands

The moment my plane touched down in Las Vegas, I didn't care about the Strip or the spectacle. I needed that first call home to work. It did. Things were stable. My son was being treated. My wife was managing with the kind of strength that makes you realise you married someone far braver than yourself.

That's when I finally arrived. That had been in Vegas for hours. But my mind. My presence. My ability to actually be at re:Invent.

And from that point forward, everything shifted.

Meeting the People Who Build the Things I Build On

I talk about ECS and Serverless constantly from product builder point of view. The service I return to, the one I recommend, the one I've built my mental models around.

This week, I got to meet the people who actually build that home.

I sat in Eric's session on ECS Managed Instances—the kind of talk where you're not just learning features, you're learning intent. Why this approach? What problem were they really solving? What trade-offs did they consider?

I heard the ECS Express Mode introduction straight from the product person and engineer who crafted it. Not through blog posts or documentation, but from the humans who debated, prototyped, and shipped it.

And here's what hit me: you can read docs. I've read AWS docs all year—they've been my reference point for everything. But talking to the people who think about these problems day and night? Who live inside the trade-offs and the edge cases? That changes how you understand a service, not just what you know about it.

We exchanged ideas. We nerded out about container orchestration. We talked about real problems and real solutions.

For me, that alone justified the entire trip.

The Sessions That Stayed With Me

If I'm being honest, I probably covered 20% of expo area it and that's generous.

Instead, I planted myself in technical sessions. ECS. Fargate. How teams think about scaling at impossible sizes. Every session fed directly into my "AWS for Product Builders" mindset—the lens I use to evaluate whether something works for startups and growing companies, not just enterprises.

I'll share the specific technical learnings in another post. But the meta-learning is this:

Hearing the intent behind the service is as valuable as learning the service itself.

When you understand why a team made certain decisions, you make better decisions yourself.

From Slack Avatars to Real Conversations

The Community Hub became my anchor during the chaos.

This was my first re:Invent, and I walked in carrying a kind of shyness I don't usually admit to. The hesitation to start conversations with new people. The imposter syndrome that whispers everyone here knows more than you. The Hub was full of heroes. Community Builders whose blogs I'd read for years. Leaders whose work I admired from afar. People I'd wanted to meet but never had the chance.

And I froze.

I'd see them across the room and think, "I should go say hello." But my feet wouldn't move. One step—that's all it would take. But that one step felt impossible in those moments.

I missed talking to people I'd dreamed of meeting. I let opportunities slip by.

But I also pushed myself. Tiny steps. One introduction. One conversation. Then another. And something magical happened.

I met AWS User Group Leaders I'd known online for five years—people who felt like old friends even though we'd never shared the same room before.

I encountered new faces who somehow felt instantly familiar—the kind of connection that reminds you why community work matters in the first place.

One highlight was the User Group meeting Maria organized. UG leaders shared the real problems they faced and the ones that don't make it into polished LinkedIn posts. How they kept their communities engaged when attendance dropped. How they found speakers. How they dealt with burnout while trying to inspire others.

At the APJC Community Awards, I met a leader from the Philippines who completely shifted my perspective. For them, community isn't just networking or professional development—it's a lifeline. They shared how incredibly difficult it is to get things done there. The lack of resources. The infrastructure challenges. The uphill battle to create opportunities where few exist.

Yet they keep showing up. They keep building. They keep creating spaces where people can learn, connect, and grow—because for many in their community, these meetups represent access they simply wouldn't have otherwise.

Listening to their story made me realize how privileged my own challenges are. It reminded me that community work looks different across the world, and the impact it creates can be measured in opportunities that never would have existed.

But there was another moment—one I didn't expect to witness, and one I'll never forget.

Jeff Barr. Twenty years of unwavering commitment to the AWS community. Two decades of blog posts, of showing up, of giving back. The room gathered to honor this milestone, and what happened next was pure, unfiltered emotion.

His son, Stephen, stood up to share another side of Jeff—the father behind the community legend. Stories from childhood. How Jeff balanced being a dad with being the voice of AWS. The late nights writing. The early mornings answering questions. The way he somehow made space for both family and this massive community he'd built.We all watched Jeff cry. Not the polished, composed tears you see at rehearsed events. Real tears. The kind that come when you realise the full weight of what you've built and who stood beside you while you built it.

The room was silent except for a few sniffles. Goosebumps. That rare moment when everyone present knows they're witnessing something genuine.

If someone asked me to name one moment from re:Invent that captured what community really means—the sacrifice, the longevity, the human cost, the profound impact—it would be this one.

Those stories stayed with me long after the session ended.

Community-building isn't just planning events and posting updates. It's resilience. It's creativity. It's learning to keep showing up even when you're tired, even when you wonder if it matters, even when the metrics don't move as fast as you'd like.

The Startup Conversation I Needed

At the Startup Amped event, I found myself in the kind of conversations that don't happen at traditional networking sessions.

Founders talking about the messy parts. The pivots that felt like failures until they weren't. The risks that kept them up at night. The moment they landed their first customer. The second-guessing. The breakthroughs.

I shared what we're building at NuShift Connect and our mission to reshape health conversations, awareness, and community in India. How we're trying to fill gaps that the traditional healthcare system leaves open.

These weren't pitches.
They were "we've been there too" conversations.
They were "here's what I learned the hard way" exchanges.

And then the conversations went deeper.

People opened up about their health struggles. Family health crises that happened while they were trying to build their startups. The nights they sat in hospital waiting rooms while their pitch decks sat untouched on their laptops. The impossible choice between being present for a sick parent or showing up for an investor meeting.

When I shared what had happened with my son just hours before my flight, I saw heads nodding around the room. Not with pity—with recognition. These were founders who understood that life doesn't pause for your business plan. That sometimes your greatest test isn't in the market—it's in the hospital corridor.

That room felt less like a networking event and more like a circle of people who understand what it really costs to build something from nothing while life happens all around you.

The Hard Truth About re:Invent: You Can't Be Everywhere

Here's something nobody tells you before your first re:Invent: the event will force you to make impossible choices.The Community Builder mixer was happening at the same time as the Startup Amped event. I chose Startup Amped. Which meant I missed connecting with fellow builders in a space specifically designed for us. Did I regret it? In the moment, yes. Absolutely. But here's what I learned: re:Invent isn't about attending everything. It's not about having a perfect schedule or checking every box. It's about choosing what matters most to you right now, in this season of your journey, and showing up fully for that.

I missed events. I missed conversations. I missed people.

But what I didn't miss was being present for the choices I did make.

And sometimes, that's enough.

Two Experiences I Never Planned For

The Pre-re:Invent Hike

Before re:Invent officially began, there was the hike. Around 40–50 of us gathered, dividing into two teams: one for the medium route, one for the long and tough route. I chose medium. Seemed reasonable after jet lag and hours of travel. Turns out, "medium" was a generous label. The trail was challenging—longer and steeper than any of us expected. Our team actually reached the end later than the "tough route" group, which became a running joke for the rest of the day. But here's what made it memorable: we didn't just hike. We stopped. We breathed. We talked. Someone pulled out food they'd brought from home—snacks from India, treats from different countries. We shared them on the trail like we'd known each other for years. We tried different paths to test which route worked better. A mental exercise wrapped in physical movement. Problem-solving while hiking. Very builder-like, when you think about it. And the strangest part? After jet lag and a transatlantic flight, I didn't feel tired. The opposite, actually. The mountain air, the movement, the conversations and it all felt energising. Within minutes of starting, strangers opened up about their journeys. Career pivots. Burnout stories. The "I almost quit but..." moments that never make it to LinkedIn. That hike wasn't about reaching the summit. It was about connection, genuine, unexpected, and rare. The kind you can only find when you remove the conference badge and just walk alongside other humans trying to figure things out

My First-Ever 5K Run

I'd signed up for the 5K run weeks earlier. But somewhere in the chaos of re:Invent, I got confused about the day. Was it Thursday or Wednesday? Then a message popped up in our India community group. The run was happening. Right now. My heart sank. I was going to miss it. Another opportunity slipping away. But something in me said: not this time. I rushed out, found the shuttle bus, my mind racing faster than I'd be running. When I finally reached the starting point, the run had already begun. People were already on the course, their figures disappearing into the early morning light and strong cold was slapping on face and ear. I could have turned back. Found an excuse. Told myself I tried. Instead, I joined them mid-run. My first 5K run. Started late. Arrived breathless. Nothing spectacular about my time. But I showed up. Even when it would have been easier not to. A reminder that even in a heavy week, health doesn't wait for perfect timing and neither should we.

A Nomination That Meant More Than Winning

Somewhere in the middle of all this, I found out I'd been nominated for the second year in a row for the AWS Community Builder of the Year award.

I didn't win.

And honestly? That didn't matter.

Seeing my name there again was enough. Because I know what it took to reach this point. The late nights answering questions in forums. The blog posts written when I was exhausted. The community events organised on weekends.

More importantly, I know who stood behind me so I could do any of it.

The nomination wasn't just about me. It was about everyone who made space for me to contribute.

What This Trip Really Taught Me

This wasn't a smooth trip.
It wasn't a relaxed conference experience.
It wasn't the postcard version of re:Invent you see in highlight reels.

It was real.
It was emotional.
It stretched me in ways I'm still processing.

And above everything, it crystallised three truths I already knew but needed to feel again:

Family makes the journey possible.
Without my wife's and son strength, I wouldn't have made it past the first airport. Every community contribution I make is built on her and his foundation of support.

Community makes the journey meaningful.
The technical knowledge matters. But the connections, the shared struggles, the moment you realise someone else has fought the same battles—that's what transforms information into wisdom.

Curiosity makes the journey worth continuing.
Even exhausted, even worried, even uncertain—asking questions, seeking understanding, wanting to know why and how—that's what keeps us moving forward.

What Comes Next

I'll be sharing more detailed technical learnings soon. The ECS insights. The Fargate patterns. The "AWS for Product Builders" framework I'm developing. The kind of content I'm excited to give back to the community that's given me so much.

But for now, I'm sitting with gratitude.

For my wife, who made an impossible choice to let me go.
For my son, who's recovering with the resilience only kids seem to have.
For the people I met in Vegas who reminded me why this work matters.
For the moments that tested me and, in testing me, changed me.

My first re:Invent wasn't perfect.

But it was mine.

And sometimes, that's exactly what you need.

Instead of our beautiful featured image and carefully crafted description, LinkedIn showed... nothing. Just a bland URL. No image. No description. Generic metadata.

"Did we forget to add the meta tags?"

We hadn't. They were there—dynamically generated by Angular. The problem? Social media bots don't execute JavaScript.

Understanding the Problem

Here's what was happening:

Regular Users: Browser loads our Angular app → JavaScript executes → Dynamic meta tags render → Perfect experience

Social Media Bots: Bot requests page → Gets bare HTML (no JavaScript execution) → Sees only static <title> tag → No rich preview

Facebook's crawler, LinkedIn's bot, Twitter's card validator—none of them waited for our Angular app to bootstrap and set those meta tags. They needed HTML, and they needed it immediately. I was aware of this limitation of Angular but while working on feature and other parts completely forgot main SEO friendliness.

The Research Rabbit Hole

I spent the next few days exploring every possible solution:

Option 1: Move to a Different Platform

"Maybe Netlify handles this better?" I thought. They do have prerendering built-in. ECS with server-side rendering was another option which we could run Angular Universal.

But here's the thing: AWS Amplify was perfect for everything else. The CI/CD pipeline, the preview branches, the authentication integration, the hosting performance—all excellent. Abandoning it felt like throwing the baby out with the bathwater.

Option 2: Angular Universal (SSR)

The "proper" solution, right? Server-side rendering would solve this elegantly. But it meant:

• Completely restructuring our application architecture

• Dealing with window/document undefined errors

• Managing a Node.js server

• Significantly more complexity for deployments

For a relatively simple SPA, this felt like overkill. We needed something lighter.

Option 3: Prerendering Services

This seemed promising. Services like Prerender.io could crawl our application and serve rendered HTML to bots. The architecture would be:

• Regular users → Direct to Amplify (fast!)

• Social media bots → Through prerender service → Get fully rendered HTML

The challenge? Amplify doesn't have built-in prerendering middleware. We'd need to set it up ourselves.

The Decision Framework: Why Prerender.io Made Sense

Before committing to any solution, I analysed the actual usage patterns and costs:

Understanding Our Traffic Pattern

Let's be realistic about when prerendering actually happens:

• Regular users browsing the site: 99%+ of traffic

• Social media bots crawling shared links: <1% of traffic

The key insight: Prerendering only happens when someone shares a link on social media. Not on every page load. Not for every user. Only when LinkedIn, Facebook, or Twitter bots crawl a URL.

Cost Analysis

The Math That Convinced Me

Scenario: 10,000 page views/month (9,900 users + 100 bot crawls)

Lambda@Edge Cost Breakdown

Pricing:

• Request charges: $0.60 per 1M requests

• Duration charges: $0.00005001 per GB-second

• Free tier: 1M requests/month (covers most small-medium sites)

Our usage:

• Viewer-request: 10,000/month (bot detection on all traffic)

• Origin-request: 100/month (redirect only bots)

• Memory: 128 MB | Execution: ~10ms

• Monthly cost: ~$0.007 (essentially free with free tier)

At scale:

Winner: Prerender.io + Lambda@Edge - 90% cost savings, 10x faster implementation, zero infrastructure overhead.

The Reality Check

I asked myself: "What am I actually trying to solve?"

• ✅ Social media previews when links are shared

• ❌ NOT trying to rank #1 on Google for competitive keywords

• ❌ NOT building a content-heavy blog that needs perfect SEO

• ❌ NOT dealing with thousands of bot crawls per day

For a SPA where social sharing matters but isn't the primary traffic driver, prerendering is the pragmatic choice.

When NOT to Choose Prerender.io

To be fair, Prerender.io isn't always the answer:

• Heavy SEO focus: If organic search is your primary channel, SSR is better

• Content-heavy sites: News sites, blogs with thousands of articles need full SSR

• High bot traffic: If bots are >10% of traffic, costs add up

• Real-time content: Stock prices, live scores need instant SSR

But for our use case—a business application where social sharing enhances discoverability—prerendering was perfect.

The challenge? Amplify doesn't have built-in prerendering middleware. We'd need to set it up ourselves.

The CloudFront Discovery

Then it clicked: Amplify uses CloudFront under the hood. And CloudFront has Lambda@Edge—functions that can intercept and modify requests at the edge.

This was our solution. We could:

1. Detect social media bots at the CloudFront level

2. Route bot traffic through Prerender.io

3. Keep regular user traffic going directly to Amplify

Best of both worlds: stay on Amplify, solve the bot problem.

Attempt 1: CloudFront Functions (Days of Frustration)

My first thought: "CloudFront Functions are faster and cheaper than Lambda@Edge. Let's use those!"

CloudFront Functions seemed perfect:

• Execute in microseconds

• Cost a fraction of Lambda@Edge

• Native CloudFront integration

• Perfect for request/response manipulation

I spent days trying to make them work. Here's what I built:

function handler(event) {
    var request = event.request;
    var userAgent = request.headers['user-agent'];

    // Bot detection works fine
    if (/facebookexternalhit|linkedinbot|twitterbot/.test(userAgent.value)) {
        // But now what? How do I redirect to prerender.io?
        // Can I change the origin? No.
        // Can I make an external call? No.
        // Can I modify the request to go elsewhere? No.
    }

    return request;
}

I tried multiple approaches:

• Modifying the request URI - CloudFront Functions can change URIs, but not the actual origin server

• Adding custom headers - Headers were added successfully, but no way to act on them at the origin level

• Request transformation tricks - Every creative workaround hit the same wall

The Hard Truth: CloudFront Functions are incredibly limited by design. They can:

• ✅ Modify headers

• ✅ Change URIs and query strings

• ✅ Validate and sanitize requests

• ❌ Cannot change origins (the actual server handling the request)

• ❌ Cannot make external API calls

• ❌ Cannot perform complex routing logic

They're designed for lightweight tasks like adding security headers or URL rewrites, not for dynamically routing traffic to different services based on conditions.

After days of testing, researching, and hitting dead ends, I realised: CloudFront Functions simply cannot solve this problem. I could detect bots perfectly, but I had no way to route them to Prerender.io.

Lesson learned: CloudFront Functions are blazing fast and cheap, but their limitations are real. For origin switching based on conditions, Lambda@Edge is the only option.

Time to learn Lambda@Edge.

Attempt 2: The 502 Bad Gateway Mystery

This time, the function ran but returned 502 errors. CloudWatch logs showed the function was executing, but CloudFront rejected the response.

The culprit? I was modifying the request structure incorrectly. Lambda@Edge has strict validation for the request/response objects you return. My custom origin configuration had:

• Missing required fields

• Incorrect URL encoding

• Wrong domain references (I was using the internal Amplify domain instead of the CloudFront domain)

Each iteration meant another 15-minute deployment wait. Testing edge functions is slow.

The Breakthrough: RTFM (Read The Fine Manual)

Frustrated, I finally dove into Prerender.io's official documentation. They had a CloudFormation template specifically for CloudFront integration: prerender-cloudfront.yaml. and thanks to Amazon Q developer CLI for debugging and fixing this issue.

The key insight I'd been missing: Use the same Lambda function for TWO different CloudFront events:

1. viewer-request: Detect bots and add special headers

2. origin-request: Check for those headers and redirect to Prerender.io

Here's the beautiful simplicity of the final solution:

'use strict';

exports.handler = (event, context, callback) => {
    const request = event.Records[0].cf.request;

    if (request.headers['x-prerender-token'] && request.headers['x-prerender-host']) {
        // This is the origin-request function - redirect to prerender.io
        console.log('Redirecting to prerender.io');

        if (request.headers['x-query-string']) {
            request.querystring = request.headers['x-query-string'][0].value;
        }

        request.origin = {
            custom: {
                domainName: 'service.prerender.io',
                port: 443,
                protocol: 'https',
                readTimeout: 20,
                keepaliveTimeout: 5,
                customHeaders: {},
                sslProtocols: ['TLSv1', 'TLSv1.1'],
                path: '/https%3A%2F%2F' + request.headers['x-prerender-host'][0].value
            }
        };
    } else {
        // This is the viewer-request function - detect bots and set headers
        const headers = request.headers;
        const user_agent = headers['user-agent'];
        const host = headers['host'];

        if (user_agent && host) {
            var prerender = /googlebot|adsbot\-google|Feedfetcher\-Google|bingbot|yandex|baiduspider|Facebot|facebookexternalhit|twitterbot|rogerbot|linkedinbot|embedly|quora link preview|showyoubot|outbrain|pinterest|slackbot|vkShare|W3C_Validator|redditbot|applebot|whatsapp|flipboard|tumblr|bitlybot|skypeuripreview|nuzzel|discordbot|google page speed|qwantify|pinterestbot|bitrix link preview|xing\-contenttabreceiver|chrome\-lighthouse|telegrambot|Perplexity|OAI-SearchBot|ChatGPT|GPTBot|ClaudeBot|Amazonbot|integration-test/i.test(user_agent[0].value);

            prerender = prerender || /_escaped_fragment_/.test(request.querystring);
            prerender = prerender && ! /\.(js|css|xml|less|png|jpg|jpeg|gif|pdf|doc|txt|ico|rss|zip|mp3|rar|exe|wmv|doc|avi|ppt|mpg|mpeg|tif|wav|mov|psd|ai|xls|mp4|m4a|swf|dat|dmg|iso|flv|m4v|torrent|ttf|woff|svg|eot)$/i.test(request.uri);

            if (prerender) {
                console.log('Bot detected:', user_agent[0].value);
                headers['x-prerender-token'] = [{ key: 'X-Prerender-Token', value: 'YOUR_PRERENDER_TOKEN'}];
                headers['x-prerender-host'] = [{ key: 'X-Prerender-Host', value: host[0].value}];
                headers['x-prerender-cachebuster'] = [{ key: 'X-Prerender-Cachebuster', value: Date.now().toString()}];
                headers['x-query-string'] = [{ key: 'X-Query-String', value: request.querystring}];
            } else {
                console.log('Regular user');
            }
        }
    }

    callback(null, request);
};

Why This Works (The Two-Stage Magic)

The genius of this approach is the two-stage processing:

Stage 1 - Viewer Request (Edge → Client):

• Lambda checks the user agent

• If it's a bot, adds special headers (x-prerender-token, x-prerender-host)

• Passes request along

Stage 2 - Origin Request (Edge → Origin):

• Same Lambda function checks for those special headers

• If present, redirects the request to Prerender.io instead of Amplify

• Prerender.io renders the Angular app and returns HTML

• If not present, request goes directly to Amplify (regular users)

This means:

• ✅ Regular users never touch the prerender service (fast!)

• ✅ Bots get fully rendered HTML with proper meta tags

• ✅ Zero changes to our Amplify hosting

• ✅ Cost-efficient—only pay for actual bot traffic (~1%)

Configuring CloudFront

In the CloudFront distribution settings, I associated the Lambda function with both events:

Associations:
  - EventType: viewer-request
    LambdaFunctionARN: arn:aws:lambda:us-east-1:xxx:function:socialbots:1
  - EventType: origin-request
    LambdaFunctionARN: arn:aws:lambda:us-east-1:xxx:function:socialbots:1

Same function, two different trigger points.

The Angular Side: Signaling Readiness

One more piece: Angular needed to tell Prerender.io when the page was fully rendered with all meta tags set.

In our article component:

ngOnInit() {
    const articleId = this.route.snapshot.paramMap.get('id');

    this.articleService.getArticle(articleId).subscribe(article => {
        // Update meta tags
        this.meta.updateTag({ property: 'og:title', content: article.title });
        this.meta.updateTag({ property: 'og:description', content: article.description });
        this.meta.updateTag({ property: 'og:image', content: article.imageUrl });
        this.meta.updateTag({ name: 'twitter:card', content: 'summary_large_image' });

        // Signal to Prerender.io that the page is ready
        (window as any).prerenderReady = true;
    });
}

Without prerenderReady = true, Prerender.io might snapshot the page before our API call completes and meta tags are set.

Testing and Debugging

Testing edge functions is painful because of deployment times. Here's what helped:

1. CloudWatch Logs Lambda@Edge logs go to CloudWatch in the region where the function executes (us-east-1 for me):

/aws/lambda/us-east-1.socialbots

2. Direct curl Testing

# Test bot detection
curl -A "facebookexternalhit/1.1" https://your-domain.com/article/123

# Test regular user
curl -A "Mozilla/5.0" https://your-domain.com/article/123

3. Cache Invalidation CloudFront caches everything. After changes, invalidate:

aws cloudfront create-invalidation --distribution-id YOUR_DIST_ID --paths "/*"

4. Prerender.io Direct Testing Check what Prerender.io sees:

https://service.prerender.io/https://your-domain.com/article/123

The Waiting Game

The hardest part? Patience. Every CloudFront distribution update takes 10-15 minutes to propagate. Every Lambda@Edge deployment requires replicating to all edge locations.

I learned to:

• Make changes in small batches

• Test thoroughly in CloudWatch before deploying

• Use Prerender.io's direct API for quick validation

• Keep a testing checklist to avoid forgetting edge cases

Key Lessons Learned

1. Don't abandon a great platform for one missing feature. Amplify is excellent—we just needed to extend it.

2. Lambda@Edge is powerful but picky. CommonJS only, strict validation, slow deployments. Plan accordingly.

3. Two-stage processing is elegant. Using the same function for both viewer-request and origin-request is cleaner than complex routing logic.

4. Follow official patterns. Prerender.io's CloudFormation template saved me hours of trial and error. When stuck, check the docs.

5. Cache management is critical. Both CloudFront and Prerender.io cache aggressively. Know how to clear both.

6. Testing takes time. Budget for 15-minute deployment cycles when working with edge functions.

Final Thoughts

What started as "our social links don't work" turned into a deep dive into CloudFront, Lambda@Edge, and edge computing. The journey had plenty of 502 errors, syntax mistakes, and waiting for deployments.

But the end result? Our Angular SPA on Amplify now provides beautiful social media previews while maintaining the performance and deployment simplicity we loved in the first place.

Sometimes the right solution isn't changing your infrastructure—it's extending what you already have.

Have you dealt with similar challenges in your SPA deployments? What solutions worked for you? Let me know in the comments!

References :

• https://github.com/AvinashDalvi89/cloudfront-lambda-edge-prerender-io-routing

• https://docs.prerender.io/docs/cloudfront

In the world of containerised deployments, small mistakes can have catastrophic consequences. What started as a routine morning API test in our development environment turned into a revelation about production resilience that fundamentally changed how we approach ECS Fargate deployments.

This is the story of how a simple port configuration error taught us the critical importance of ECS Deployment Circuit Breakers – and why every team running workloads on AWS Fargate should consider them essential infrastructure, not optional extras.

The best production incidents, as it turns out, are the ones that never happen.

The Setup

Our Flask API ran smoothly on ECS Fargate with a cost-optimized dev setup — tasks auto-started at 8 AM and stopped after hours using CloudWatch alarms.

We used an Application Load Balancer (ALB) targeting port 5001, with health checks and task definitions perfectly aligned:

# app.py - The way it had always been
if __name__ == '__main__':
    app.run(host='0.0.0.0', port=5001, debug=False)

ECS config:

• Container port: 5001

• Target group: 5001

• ALB health checks: 5001

Everything in harmony.

The Innocent Change

One of our backend developers, was working late on a new feature. They were running multiple services locally and kept hitting port conflicts. Port 5001 was already occupied by another service.

"Quick fix," developer thought, and made what seemed like the most logical change:

# app.py - The "harmless" local change
if __name__ == '__main__':
    app.run(host='0.0.0.0', port=5201, debug=False)  # Changed to avoid local conflict

The feature worked perfectly in her local environment. Tests passed. Code review looked good. The Docker build succeeded. Everything seemed normal.

But here's where the story takes a turn.

The 9 AM Discovery

The next morning, I arrived open my machine around 9 AM and decided to run some API tests before diving into feature work. Our automated CloudWatch alarm had dutifully started the ECS Fargate tasks at 8 AM, just as configured. But something was wrong.

Every API call returned the dreaded 502 Bad Gateway error.

I immediately checked the ECS console, and what I saw made me to think : Fargate tasks were in a continuous cycle of PENDING → RUNNING → STOPPED. They would start up, run for a few minutes, then get drained and terminated, only for ECS to immediately spin up new ones.

The root cause hit me like a lightning bolt: Our Flask application was now listening on port 5201, but everything else in our infrastructure was still configured for port 5001.

The Downward Spiral

What followed was a textbook example of how a small misconfiguration can cascade into a major incident:

1. Task Launch: ECS Fargate would start a new task

2. Health Check Failure: ALB couldn't reach the app on port 5001

3. Task Termination: ECS marked the task as unhealthy and terminated it

4. Replacement Attempt: ECS immediately launched a new Fargate task to maintain desired count

5. Infinite Loop: Steps 1-4 repeated endlessly

Our ECS Fargate cluster was stuck in what we later dubbed "the task death spiral." New Fargate tasks were being created and destroyed every few minutes, consuming compute resources while serving zero traffic.

The Circuit Breaker Revelation

During our post-incident analysis, then I realised something that would change our deployment strategy forever: "What if I told you this entire incident could have been prevented automatically?"

Enter the ECS Fargate Deployment Circuit Breaker.

This AWS feature acts like an intelligent safety net for ECS Fargate deployments. When enabled, it monitors your Fargate deployment and can automatically detect when something is going wrong, stopping the deployment and rolling back to the previous stable version.

How ECS Behaves in Different Rollback Scenarios

• Circuit breaker only works if a new task definition is registered.

• Desired count = 1 leads to slow failure detection, delaying rollback.

• ECS uses an internal failure threshold (usually 3 failed tasks).

How Circuit Breaker Would Have Saved Us

Let's replay our incident with ECS Fargate deployment circuit breaker enabled:

To better understand how ECS identifies and reacts to a bad deployment, here’s a simplified flow diagram based on our real incident:

1. Deployment Start: Mismatched port in new task definition

2. Monitoring Begins: ECS tracks task health and startup patterns

3. Failure Detected: Multiple ECS task failures trigger threshold

4. Automatic Rollback: ECS reverts to previous task definition

5. Service Restored: Traffic resumes via healthy version

Instead of 75 minutes of downtime, we would have had perhaps 5-10 minutes of degraded performance while the circuit breaker detected and resolved the issue.

How ECS Actually Triggers Rollbacks: Behind the Scenes

During our experiments, we noticed some undocumented behaviours:

• ECS doesn't rollback unless there's a new task definition — pushing a new image to latest doesn’t count.

• Desired count = 1 (common in off-hours cost optimisation) leads to much slower rollbacks due to staggered failures.

• ECS seems to use a dynamic failure threshold of 3 (confirmed visually in the console), meaning it waits for 3 failed task launches before triggering rollback. You cannot change either of the threshold values. It is mentioned in the ECS deployment circuit breaker

  ECS uses the following logic to determine rollback: Minimum threshold <= 0.5 * desired task count => maximum threshold

What this means in practice:
Even if circuit breaker is “enabled,” rollback won’t happen unless you structure your deployments correctly.

The Circuit Breaker Implementation

That afternoon, we made a decision that would prove to be one of our best infrastructure investments: enabling ECS Deployment Circuit Breaker across all our services, starting with our most critical production workloads.

The configuration was surprisingly straightforward:

{
  "deploymentCircuitBreaker": {
    "enable": true,
    "rollback": true
  }
}

What Happens When DesiredCount = 0? A Real Risk Pattern

Our incident happened in a development environment using off-hours scaling — every night, desiredCount = 0, and each morning ECS spins the tasks back up at 8 AM. This helps save cost during non-business hours.

But here’s the hidden danger we uncovered through real experiments:

In our real case, we pushed a new (and broken) image to flask-app:latest overnight.
However, we didn’t register a new task definition — the task definition was unchanged.
So when ECS scaled up in the morning, it pulled the broken image and launched new tasks.
Because ECS had no healthy task running and no “new deployment” to monitor, no rollback happened.

This subtle but critical issue means that:

• ECS had no baseline healthy task to compare against

• There was no new task definition, so ECS didn’t consider this a deployment

• Circuit breaker logic was never triggered

• ECS just kept retrying the same broken image silently

Even with circuit breaker enabled, rollback only works if ECS sees a new deployment (i.e., new task definition revision). In our case, since we reused flask-app:latest with the same task definition, ECS had nothing to roll back to.

Recommendations (Based on Real-World Failures)

These are not just best practices from the AWS documentation. These are hard-earned lessons from our own experiments and real incident recoveries.

1. Avoid using latest tag in ECS task definitions

ECS won't detect image changes if you're using flask-app:latest and don’t update the task definition. This can silently deploy broken images without triggering a rollback.

Do this instead:

• Use immutable image tags like v1.2.3, build-20250909, or a full SHA digest

• Always reference a new task definition revision tied to each deployment

2. Register a new task definition with every deployment

The deployment circuit breaker only activates when ECS detects a new deployment. If the task definition remains unchanged (even with a new image), ECS won’t treat it as a deployment, and rollback won’t occur.

Do this instead:

• Automate task definition registration in your CI/CD pipeline

• Even if using the same image tag, register a revision to trigger deployment detection

3. Use CloudWatch alarms to detect deployment failures early

ECS retries silently when tasks fail during deployment. In non-prod or low-desiredCount environments, this can go unnoticed.

Do this instead:

• Monitor UnhealthyHostCount (ALB) and ECS service deployment events

• Alert on unusual task exit reasons, STOPPED states, or drops in RunningTaskCount

4. Enforce Task Definition Updates in CI/CD

One common issue we saw: devs pushed new images to latest, but forgot to update task definitions. Result? No rollback, no detection, broken app silently running.

Do this instead:

• Add a CI/CD check: fail the pipeline if task definition revision isn't updated

• Maintain an audit log: map every deployment to a task definition revision

5. Use higher desiredCount during deployments for faster rollback

In our tests, when desiredCount was set to 1, rollback took over 20 minutes to trigger. With desiredCount set to 5, the circuit breaker detected the failure pattern faster and triggered rollback within 3–5 minutes.

What to do instead:

• Temporarily increase desiredCount during deployments (e.g., from 1 to 5).

• Alternatively, tune deploymentConfiguration to use maxPercent = 200 and minHealthyPercent = 50 to allow parallel task launches during updates.

Summary Table

Conclusion: The Safety Net We Proactively Built

Even small mistakes — like a port mismatch — can bring down containerized systems. That’s why we treat circuit breakers not as optional features, but as must-have infrastructure. They're not just for rollback — they build resilience into your deployment lifecycle.

That seemingly minor port change could’ve caused hours of downtime — but it didn’t. Because we caught it early, we had the chance to rethink our deployment safety.

We turned that morning’s incident into a proactive defense strategy by enabling ECS Deployment Circuit Breaker across all services. It now gives us confidence that even if a broken deployment slips through, ECS will detect the issue and roll back automatically — without us scrambling at 9 AM.

Our team now deploys with confidence, not caution. And the best part? The incident never reached users.

Sometimes the best production incidents are the ones that never happen.

👉 Have you faced something similar? Let’s talk in the comments.

References:

• https://aws.amazon.com/blogs/containers/announcing-amazon-ecs-deployment-circuit-breaker/

• https://docs.aws.amazon.com/AmazonECS/latest/developerguide/deployment-circuit-breaker.html

Every morning, after my usual routine, I scroll through Reddit. It’s part habit, part curiosity—a way to catch up on what’s happening in the world of AWS and product building.

But let me be clear: I’m not the kind of developer who jumps on every trendy new tool the moment it launches. Unless I see a clear reason it could help me in my real work, I usually wait and watch.

That’s because right now, I’m working under a strict timeline for GTM (Go-To-Market). I’m constantly evaluating anything that might help me ship faster without sacrificing quality.

I have Figma designs ready for most of our screens. Just last week, I built out an entire chat module—including both the UI and backend APIs—using ChatGPT to help speed up the process. Tools like that are no longer just experiments for me; they’re part of how I stay on track to deliver.

So when I saw AWS’s Reddit post about Kiro IDE, I wasn’t sure I’d even try it. Another AI tool? There’s been a flood of those lately.

But there was something different about how AWS positioned Kiro. They weren’t just talking about generating code. They were talking about helping developers go all the way from ideas and specs to production systems. That’s exactly where most AI tools fall short.

Given the tight timelines I’m working under, I figured: If this can help me move faster for real product work, it’s worth testing. So I decided to give it a shot—using a real feature I’m building for NuShift Connect.

At NuShift Connect, we’re building a health-focused social platform. Recently, I’ve been working on an additional feature: Groups. It’s a way for users to create dedicated communities around health topics—like cancer awareness, fitness journeys, or wellness discussions.

This Groups feature isn’t my entire product. It’s one of many pieces I’m layering onto an existing, fairly complex codebase. And that’s why I usually don’t rush into brand-new tools. I can’t afford to break my momentum or disrupt working systems.

But Kiro IDE made me curious because it seemed like it might help me structure my feature properly from the start, keep my thinking organised as I integrate with existing code, and speed up writing UI components in Angular.

I was at the GenAI Loft last week, where I attended a session on the AI Development Lifecycle (AIDLC) by Siddhesh Jog. He talked about how successful product development often requires moving through clear phases—from ideation and requirement gathering to building, testing, and deploying. As I explored Kiro, I could see that it’s built with that same philosophy in mind. It feels like a tool designed to guide product builders step by step through that lifecycle, rather than just spitting out random code

One thing that stood out right away was Kiro’s idea of Specs. Instead of just throwing random prompts at an AI, Kiro pushes you to define what you’re building—almost like writing requirements documentation but right inside your IDE.

For the Groups feature, I wrote out a spec something like this:

• Users can create new groups with a name, description, and cover image

• Groups can be public or private

• Each group has posts, comments, and member lists

• We already have user profiles and authentication in place

• My initial focus is designing the UI and Angular components—not backend APIs yet

The moment I saved this spec, Kiro started suggesting Angular component structures (Group List, Group Detail, Create Group form), folder organization ideas for modularity, and approaches for handling reactive forms and UI state.

Instead of dumping generic code snippets, Kiro was shaping its suggestions around my actual app structure and requirements.

This was the part that felt genuinely useful. I’ve used plenty of AI tools before—like when I built our chat module last week using ChatGPT to generate both frontend components and backend API scaffolding. That experience showed me how much time AI can save if used well.

Kiro felt similar, but with even more context awareness for Angular. It suggested splitting my UI into smart, modular components. It helped me outline reactive forms for group creation, including validation logic. It offered ways to connect state between components. It even reminded me to think about loading states and empty UI screens.

I haven’t wired up the backend yet—that’s the next step. But just for the Angular side, Kiro saved me hours of manual scaffolding and planning.

Another thing that impressed me was how Kiro handles Hooks and Steering.

Hooks are like background automations. For example, when I updated my spec, Kiro prompted me to adjust my component interfaces and possibly update tests. Small nudges, but useful.

Steering lets you guide how the AI writes code. I could tell Kiro to stick to Angular best practices, use TypeScript consistently, and avoid certain libraries we don’t use at NuShift. Instead of me manually rewriting AI code every time, Kiro started adapting to my way of working.

While exploring Kiro’s UI, I saw something called MCP Servers. From what I gather, this lets Kiro connect to real tools and data sources, like fetching live DynamoDB schemas, reading API specs, or integrating with CI/CD systems. I haven’t tested this yet, but the idea that Kiro could be aware of my real environment—not just write generic code—is intriguing for the future.

It’s Still Early, But It Feels Different

Like any new tool, Kiro isn’t perfect yet.

• Sometimes its suggestions were too generic, especially for UI styling details. Even when I gave it Figma screenshots, it didn’t always pick up the exact styles or color codes. I found myself needing to do more prompting to match our design system.

• To be fair, this is something I could solve better by using Kiro’s Specs feature upfront. You can define your product’s brand guidelines, color palettes, typography, and other design rules directly in specs. I simply hadn’t included those details in my initial prompts—but next time, I plan to try it.

• It occasionally misunderstood the relationships between my existing components. For example, our codebase has some duplicate components and modules left over from older versions, with similar names scattered in different folders. Instead of deleting unused modules, previous developers just added new ones alongside them. That created confusion for Kiro, which sometimes pulled from the wrong places.

• It’s a reminder that tools like Kiro work best if your codebase is clean—or at least if you set ground rules or do some upfront cleanup so the AI knows what’s current and what’s legacy.

• Even when there was an error running ng serve, Kiro didn’t automatically detect it or suggest fixes. I had to explicitly prompt it to run the command, read the error output, and help debug the issue.

• I was thinking it would be amazing if Kiro could automatically stop ng serve after making changes, rerun it, and check for errors. But I also realize that might get tricky. If the error doesn’t get fixed properly, it could send Kiro into an infinite loop of stopping, starting, and trying again—something I’ve definitely seen happen with ChatGPT during debugging.

I haven’t tested how well it handles full-stack API integrations yet.

That said, it’s worth remembering Kiro is brand new, and everyone—from developers to tech media—is still exploring what it can really do.

But even with those limitations, I came away feeling like this is not just another AI toy.

For the first time, I felt like an AI tool was working with me to build a real feature—not just generating isolated snippets of code.

Why Product Builders Should Pay Attention

I’m usually cautious about new tools, especially trendy ones. But Kiro felt different because it fits how product builders actually work.

We don’t just write code—we design systems and think about integration. We have existing codebases, not blank slates. We need speed—but also clarity and maintainability.

Kiro helped me think through my Groups feature in a structured way. It saved time on my Angular scaffolding. And it kept me focused on building something that fits into NuShift Connect—not just playing with isolated code.

I have a strict GTM timeline and a long list of features to deliver. Recently, AI tools like ChatGPT have helped me build faster—like with our new chat module. But Kiro feels like a step forward because it’s built for product builders, not just for writing isolated pieces of code.

If AWS keeps evolving it, Kiro could be one of the most useful developer tools they’ve launched since Lambda.

My Takeaway

My advice? If you’re curious, don’t just read blog posts (even this one). Pick a real feature you’re working on and try building it in Kiro IDE. That’s when you’ll see whether it’s just another AI experiment—or a glimpse of how we’ll build products in the future.

Next, I’m planning to see how Kiro handles backend integrations for Groups—especially how it manages API design and DynamoDB schemas. I’ll share those results once I’ve tested it further. Right now, Kiro IDE is free during its preview period. I’m not sure what pricing AWS will introduce later—but for now, it’s worth trying if you’re curious.

TL;DR: Kiro IDE isn’t just an AI code generator. It feels like a real partner helping me think through product features and ship faster under tight deadlines.

References Worth Exploring

If you’re curious to dig deeper into Kiro IDE, here are some good places to start:

Introducing Kiro: The Agentic AI IDE (AWS Blog)

Kiro IDE Official Site & Documentation

Kiro: The new Agentic AI IDE from AWS (DEV.to)

Kiro Agentic AI IDE — Beyond a coding assistant (DEV.to)

In this blog, we are going to learn about the real challenges, insights and mistakes behind migrating from EC2 to containers, based on my experience. So let’s start.

The Reality Check That Started It All

Here's the honest truth: Before NuShift, I had never migrated workloads from EC2 to containers. At previous jobs, we were either stuck in the EC2 era, had no real container strategy, or everything was already set up for containers, and my role was to focus on scaling and improving as a developer since the DevOps team handled it. I have been using containers for a long time and understood their benefits, but I never had the chance to lead that transformation..

When I joined NuShift, my first few months were spent doing the unglamorous work—cleaning up unused resources, right-sizing EC2 instances, and optimising our AWS bill. We managed to improve utilisation, but I knew this was just putting a band-aid on a deeper problem.

That's when I set a personal and team goal: move us toward containers. This wasn't about cost savings—it was about solving real operational headaches. We needed better resource utilisation, more structured deployments, and most importantly, the promise that "build once, run anywhere" that containers offered.

Like most developers, our instinct was simple: write code, host it quickly, pick the easiest option. That usually meant EC2. Even at NuShift, we initially launched everything on EC2 instances. We even started considering Graviton-based instances for better performance, but realised that would mean dealing with architecture changes and potential compatibility issues.

The real pain point? Environment consistency. What worked in development didn't always work in staging. Missing Python packages, different system libraries, manual patching cycles—these weren't just inconveniences, they were blocking us from moving fast as we prepared for our public launch.

That's when containers became part of my plan from day one. Not because of some dramatic failure, but because I could see the operational complexity we were heading toward if we didn't change course.

The Hidden Operational Pain of "Simple" EC2 Deployments

Launching a product is messy. You want the simplest path to get things running. That’s why EC2 becomes the go-to for most startup teams. At NuShift, our early backend stack—Flask APIs, WebSocket server, and MySQL—was each running on separate EC2 instances. No orchestration. Minimal automation. It worked... until it didn’t. Here's what nobody tells you about the EC2-first approach: it feels simple until you need consistency across environments.

The Development vs QA Nightmare

Our development setup worked perfectly. Local Flask app, local database, everything smooth. But when we moved to QA ( we are not on production yet)

• Missing Python packages that weren't in our requirements.txt

• Different system library versions causing unexpected behaviors

• Manual patching cycles that meant potential downtime

• "It works on my machine" became our team's unofficial motto

The worst part? Setting up a new environment meant hours of manual configuration, hoping we didn't miss any dependencies that existed on our other servers.

These challenges highlighted the need for a more consistent and reliable deployment process.

The Deployment gamble game (a.k.a. Jugaad)

Our deployment process was essentially gambling:

# Our "sophisticated" deployment process
ssh into qa-server
git pull
pip install -r requirements.txt  # hope nothing breaks or 
pip install library-xss #manually installed os level package
sudo systemctl restart app
# Check logs and pray

Every deployment felt like rolling the dice. Not because our code was bad—but because we could never guarantee the environment matched what we’d tested locally. A missing Python package here, a different system library version there—it was chaos waiting to happen.

Why This Matters Beyond Just Code

At first, we thought the problem was purely technical: missing packages, inconsistent environments, surprise crashes in staging. But underneath all that was a bigger issue:

We were trying to build modern applications on infrastructure we were too small to manage properly.

Deploying on EC2 meant we were responsible for:

• OS patching

• Library dependencies

• Security hardening

• Deployment orchestration

• Scaling and failover

For large teams with dedicated DevOps or platform engineers, this might be manageable. For us—a small team of developers—it wasn’t sustainable.

That’s when we realized:

Infrastructure decisions aren’t just about technology—they’re about your team’s strengths and capacity.

The Team Reality Check: Know Your Strengths

Here's the brutal truth most migration guides skip: your team composition matters more than technical specs.

Before choosing any path, ask yourself:

• Are you a developer who also handles infrastructure?

• Do you have dedicated DevOps/Platform engineers?

• How much time can you realistically spend on server maintenance?

At NuShift, we had 3 full-stack developers. Zero dedicated infrastructure people. This meant every hour spent patching EC2 instances, managing security updates, and troubleshooting server issues was an hour stolen from building features our users needed.

And here’s what that hidden cost actually looked like:

Reality Check:

• EC2 patching: 4 hours/month per instance

• Security updates: 2 hours/month

• Monitoring setup: 8 hours initially + ongoing maintenance

• Capacity planning: 3 hours/month

• Incident response: 6 hours/month average

Total: ~25 hours/month on infrastructure babysitting

If you're a startup with only developers, staying deep in the EC2 world means accepting that you'll spend significant time on environment management and system administration. That’s not why most of us became developers.

As we prepared for our public launch, this operational overhead became a real concern. We needed to move fast, deploy reliably, and focus on building features—not troubleshooting environment inconsistencies.

All these operational headaches forced us to step back and ask ourselves a bigger question.

The Moment Everything Clicked

The breakthrough came when I realised we were solving the wrong problem. We weren't trying to manage servers—we were trying to run applications.

That mental shift changed everything.

Instead of asking "which server will this run on?", we started asking "what does this service actually need?"

Why ECS Fargate Became Our Secret Weapon

We considered three paths:

1. ECS with EC2: More control, Spot instances, Graviton savings (but more operational overhead)

2. EKS: Full Kubernetes power and flexibility…but personally, as a developer, I find this path complex and better suited to teams with dedicated platform engineers. It felt like overkill for our small team

3. ECS Fargate: Serverless containers (perfect for developer-heavy teams)

For a team of 3 engineers with no dedicated infrastructure expertise, Fargate won because it eliminated the exact operational problems that were slowing us down:

Before: Environment Inconsistency

"This works fine in development, but staging has different Python versions."

"We need to manually install these system packages on every server."

"Production deployment failed because of a missing dependency."

After: Container Consistency

"Build the container once, run it everywhere.”

"All environments use the exact same container image.”

"Deployment is just pulling and running a container—no surprises."

It wasn’t just about technology. It was about giving our small team the freedom to build features without worrying about the plumbing underneath. For us, Fargate meant moving faster, deploying more reliably, and finally escaping the chaos of managing EC2 servers.

The Migration: What We Wish We'd Known

Even as someone deeply familiar with containers, these areas still tripped me up during migration. They’re easy to overlook—and that’s why I’m sharing them.

Victory #1: The IAM Maze (And How to Navigate It)

This tripped us up for days. ECS needs TWO different roles:

Task Role: What your application can do

{
  "Effect": "Allow",
  "Action": ["s3:GetObject", "s3:PutObject"],
  "Resource": "arn:aws:s3:::my-bucket/*"
}

Execution Role: What ECS can do to run your application

{
  "Effect": "Allow",
  "Action": [
    "ecr:GetDownloadUrlForLayer",
    "logs:CreateLogStream"
  ]
}

Pro tip: Create the execution role first, then focus on task permissions. Don't mix them up like we did. I have explained in one of Youtube Shorts video https://youtube.com/shorts/6-MxMB3E43U?si=FyfEr0_CLH8bJT0g

Victory #2: Goodbye SSH, Hello Observability

The hardest mental shift? No more SSH debugging. But this forced us to build better logging:

# Before: Debug by SSH and printf
def process_network_request():
    # hope nothing breaks
    return result

# After: Structured logging for containers
import structlog
logger = structlog.get_logger()

def process_network_request():
    logger.info("processing_network_request", user_id=user_id, network_count=len(networks))
    # proper error handling and metrics
    return result

Victory #3: The Security Groups Revelation

EC2 security groups felt simple—one instance, one set of rules. But Fargate tasks need precise networking:

Our mistake: Copying EC2 security group rules directly to Fargate tasks

The fix: Each ECS service gets its own security group with minimal required access:

• Flask API: Only needs outbound to RDS and inbound from ALB

• WebSocket: Needs different port ranges and longer timeouts

• Background jobs: Only outbound to external APIs

The Numbers That Matter

Six months post-migration:

But the real win? We stopped being environment troubleshooters and became product builders again. With our public launch approaching, this consistency became invaluable.

The Microservices Question: When to Split, When to Keep Together

Here's where most teams overthink it—and where your team structure should guide your decision.

Our Flask app was already modular:

• /networks/* routes → networks.py

• /profile/* routes → profile.py

• WebSocket handling → separate module

We could have split these into separate ECS services immediately. But we didn't.

Why we kept them together initially:

• Shared authentication logic

• Small team (3 engineers, no dedicated DevOps)

• Approaching public launch (needed stability over optimization)

• Limited operational bandwidth for managing multiple services

The key insight:

Containers gave us the flexibility to split later without the environment consistency problems we'd face with EC2.

And there’s another reason containers were the right choice for us—even if we started monolithic:

• With containers, you can right-size your compute per service as you grow.

• If one part of your app is lightweight, you can run it in a small container to save costs.

• If another part becomes resource-intensive, you can allocate more CPU, memory, or even switch to a larger container class—all without changing the rest of your system.

• This means you can optimise your AWS spend at a much more granular level than with monolithic EC2 instances.

That flexibility was a huge part of why we chose containers from day one. We knew we might not need microservices immediately—but when we did, we’d be ready to split workloads and optimize costs without rewriting everything from scratch.

The Team-Size Reality Check

If you have 1-3 developers doing everything:

• Start with containers, but keep services together

• Split only when you have clear performance bottlenecks

• Prioritize simplicity over "best practices"

If you have 5+ engineers or dedicated platform team:

• Consider splitting services earlier

• You have bandwidth to manage multiple deployment pipelines

• Microservices architecture becomes more viable

If you have dedicated DevOps/Platform engineers:

• ECS on EC2 might be worth considering for cost optimization

• You can handle the operational complexity of managing instances

• Kubernetes (EKS) becomes a viable option

Our Splitting Strategy (For Small Teams)

1. Start monolithic in containers (easier migration)

2. Monitor and measure actual bottlenecks

3. Split services when you have clear scaling needs AND team bandwidth

4. Grow your operational maturity alongside your architecture complexity

Signs it's time to split:

• One component consistently uses 80%+ CPU while others idle

• Different scaling patterns (API traffic vs background jobs)

• Team growth (multiple people working on same codebase)

The Unexpected Wins

1. Environment Parity That Actually Works

# Same container, different environments
development:
  cpu: 256
  memory: 512
staging:
  cpu: 512  
  memory: 1024
production:
  cpu: 1024
  memory: 2048

2. Feature Flags for Infrastructure

Need to test a new background job? Deploy it as a separate ECS service with minimal resources. No risk to existing services.

3. Cost Optimisation by Service

We discovered our podcast audio processing was using 60% of our compute budget. Easy to optimise when you can see it clearly.

What We'd Do Differently

Start with Monitoring Day One

Don't wait until after migration. Set up CloudWatch Container Insights and structured logging immediately.

Embrace Infrastructure as Code Earlier (It's Easier Than You Think)

We initially managed ECS through the console. Big mistake. CloudFormation templates made everything repeatable and reviewable.

But here's what changed the game: AI-powered infrastructure tools.

I wrote our entire CloudFormation stack using Amazon Q Developer CLI and ChatGPT. What used to require deep AWS expertise now takes basic prompting skills:

> q chat
# Amazon Q Developer CLI in action
> "Generate CloudFormation template for ECS Fargate with ALB, RDS, and auto-scaling"

# Review, modify, and iterate
>  "Add CloudWatch Container Insights and log retention policies"

# ChatGPT for fine-tuning
> "Fix this IAM policy - getting access denied on ECR pull"...

The result: 300+ lines of CloudFormation that would have taken me weeks to write manually, delivered in 2 hours.

The new reality: If you can describe your infrastructure in plain English, AI can write the CloudFormation. The barrier to Infrastructure as Code has practically disappeared.

Plan for Secrets Management

We moved secrets from EC2 environment variables to AWS Systems Manager Parameter Store. Should have done this from the start. We didn’t have any secrete which require rotation so choose simple option SSM parameter store.

Leverage AI Tools for Infrastructure as Code

Here's a game-changer: GenAI has eliminated the "I don't know CloudFormation" excuse.

I wrote our entire ECS infrastructure using Amazon Q Developer CLI. The process looked like this:

# Ask Amazon Q to generate CloudFormation template
> "Create CloudFormation template for ECS Fargate service with ALB and RDS"
> "Add CloudWatch log groups and auto-scaling policies to this template"

What used to take days now takes hours. The AI handles the boilerplate, you focus on the business logic.

Pro tip: Use AI tools as your pair programmer, not your replacement. They're incredible at generating infrastructure templates, but you still need to understand what you're deploying.

The Bottom Line

EC2 isn't wrong—it's just not optimised for modern application patterns or small development teams.

Choose Your Path Based on Your Team Reality:

Pure Developer Team (1-5 people, no DevOps):

• Fargate

• Managed databases (RDS, not self-hosted)

• Serverless where possible

• AI-generated Infrastructure as Code (Amazon Q, ChatGPT for CloudFormation)

• Avoid EC2 (unless you want to manage environments manually)

Mixed Team (Developers + DevOps/Platform Engineers):

• ECS on EC2 or EKS for more control

• Spot instances and Graviton for optimization

• More complex architectures become viable

• AI-assisted infrastructure optimization and troubleshooting

• Fargate still valid for rapid iteration

Large Team (10+ engineers, dedicated platform team):

• Full Kubernetes (EKS/GKE)

• Multi-cloud strategies

• Complex microservices architectures

• Advanced cost optimization techniques

If you're running a simple, monolithic app with predictable patterns and dedicated infrastructure expertise, EC2 might be perfect. But if you're building a product that needs to move fast, deploy reliably, and maintain consistency across environments while your developers focus on product development, containers will eventually become inevitable.

The question isn't whether to migrate—it's when, and what path matches your team's strengths and timeline.

Ready to Start Your Migration? (The AI-Powered Way)

The GenAI advantage: What used to require deep AWS expertise now needs basic prompting skills.

1. Audit your current EC2 usage (AWS Cost Explorer is your friend)

2. Identify your biggest pain points (deployment time? scaling? costs?)

3. Use AI to generate your infrastructure templates:

    # Amazon Q Developer CLI examples
    >  "Create ECS Fargate service template for my Flask app"
    > "Add Application Load Balancer with HTTPS certificate"
    >  "Configure auto-scaling based on CPU utilization"
   
    # ChatGPT for troubleshooting
    > "My ECS task is failing with this error: [paste logs]"
    > "Optimize this CloudFormation template for cost efficiency"
   

4. Start with one service (pick the most isolated one)

5. Measure everything (before and after metrics)

6. Iterate and expand (let AI handle the infrastructure complexity)

The old excuse: "I don't know CloudFormation well enough" The new reality: "I can describe what I want in plain English"

The best migration is the one you don't have to do twice—and AI ensures you get it right the first time.

My Container Migration Cheat Sheet

• Start with EC2 if you must—but design your code so you can migrate later.

• Know your team’s capacity. Small teams should prioritise simplicity and managed services.

• Fargate is perfect for dev-heavy teams without dedicated DevOps. It trades some control for massive operational relief.

• ECS on EC2 offers cost savings—but requires infra expertise.

• Containerisation solves environment drift. “It works on my machine” becomes a thing of the past.

• Don’t rush into Microservices. Keep services together initially if your team is small.

• Containers let you right-size resources per service. Small services can save money, while heavy services can scale independently.

• IAM roles in ECS are easy to confuse. Separate your task role from your execution role.

• Ditch SSH for observability. Logging and monitoring are non-negotiable in containerized workloads.

• Invest in Infrastructure as Code early. Use AI tools like Amazon Q or ChatGPT to help generate your templates.

• Measure everything before and after migration. You can’t improve what you can’t measure.

Want to discuss your EC2 to containers migration? I'd love to hear about your experience and challenges. Connect with me on LinkedIn/Twitter or drop a comment below.

You know those moments where everything compiles, no warnings pop up, the UI mostly works… but then something just quietly breaks?

This was one of those moments.

I wasn’t refactoring some ancient service or tweaking a low-level renderer. I was building a simple notification drawer — and somehow, Angular's NG02100 error made it feel like the app was haunted.

When “Just a Template Change” Isn’t

I was working on our notification drawer — a simple list showing who did what, when. The API was returning the usual data: message, title, timestamp. Nothing out of the ordinary.

In the template, I rendered the notification time like this:

<label class="notification-time">
  {{ notification?.cd | date: 'MMM d, y h:mm a' }}
</label>

It worked. I merged it. Life moved on.

Until it didn’t.

The Crash That Made No Sense

One morning, I refreshed the UI. The first few notifications loaded. Then — out of nowhere — Angular crashed.

Sometimes it broke after the third item, sometimes after the fifth. It wasn’t consistent. But the crash was real, and the console wasn’t much help:

 ERROR $e: NG02100
    at qn (http://localhost:4200/main.js:1:1782481)
    at Me.transform (http://localhost:4200/main.js:1:1784244)
    at H2 (http://localhost:4200/main.js:1:1923346)
    at Object.Y2 (http://localhost:4200/main.js:1:1924135)
    at pp (http://localhost:4200/main.js:1:556184)
    at L0 (http://localhost:4200/main.js:1:1865117)
    at ZC (http://localhost:4200/main.js:1:1875545)
    at X0 (http://localhost:4200/main.js:1:1876956)
    at Hb (http://localhost:4200/main.js:1:1876779)
    at Jm (http://localhost:4200/main.js:1:1876711)

No mention of the template line. No stack trace pointing to my component. Just NG02100.

I hadn’t seen this one before. And I write a lot of Angular.

Debugging the Wrong Places

Like most devs, I assumed something logical was broken. So I started removing things.

I tried:

• Wrapping fields in *ngIf

• Adding ?. everywhere

• Logging the API response

• Filtering out null and incomplete records

• Removing pipes, anchor tags, images, even entire rows

At one point I replaced the whole template with just:

{{ notification | json }}

Still crashing.

The error pointed to the line in my component where I assigned the response:

this.notifications = res.data;

And yet the first few notifications rendered fine. That made it worse — it felt like the problem was hiding somewhere deep in the data, waiting to ambush me at random.

The Breakthrough

After hours of slicing code, I dumped a single notification to the console and noticed this:

cd": "9 mins ago"

That used to be:

"cd": "2024-06-06T12:30:00Z"

So what changed?

The backend team had switched from sending ISO timestamps to human-readable time strings.

Totally reasonable — but my date pipe didn’t agree.

Angular was trying to parse "9 mins ago" with the date pipe. Naturally, it failed. But instead of throwing a descriptive error, it threw NG02100, which just means:

Something in the template broke during binding. Good luck finding it.

The Fix Was Simple (But Finding It Wasn't)

I removed the date pipe entirely:

<label class="notification-time">
  {{ notification?.cd }}
</label>

Just like that — everything worked again.

It took two hours to track down a single pipe that was assuming a valid date. A change that didn't cause TypeScript to fail. A runtime-only issue that crashed without context.

Lessons from the Trap

Looking back, this one line taught me more than I expected:

1. NG02100 is a template binding failure, not a logic error.

2. Pipes like date, currency, or async are easy to break if the data isn’t shaped exactly as expected.

3. When errors seem random in a loop (*ngFor), it’s usually one bad record in the list.

4. Defensive programming in templates is just as important as in your components.

What I’d Do Differently Now

• Validate data types before using them in the template.

• Guard pipes behind helper functions if the format can vary.

• Use conditional formatting:

• And finally, when I see NG02100 again, I’ll know where to look first — the template, not the logic

Final Thoughts

This wasn’t a tricky bug in hindsight. But it was just invisible enough, just misleading enough, to waste hours of time.

Sometimes the problem isn’t what changed — it’s what you assumed would never change.

If you ever see NG02100, don’t start with your TypeScript.

Start with your templates.

And then check your pipes.

That was the story every month-end in our GIS image processing app. A spike in usage from ops teams. Annotation tools slowing down. And the infamous error that no one wants to debug under pressure.

The ECS setup wasn’t new—built by the previous team—but now it was on us: developers and DevOps engineers trying to make sense of why scaling wasn’t saving us.

We did what most teams would do. We scaled the ECS service. Added more tasks. And for a while, it worked. Until it didn’t.

This blog isn’t just about what CAS is—there are plenty of docs for that. This is about why you might miss it, how we almost did, and what real-world capacity alignment actually looks like.

Most Builders Miss This: Task Scaling Isn’t Enough

When you configure ECS Service Auto Scaling (like scaling from 2 to 10 tasks based on CPU > 50%), ECS will try to place new tasks.

But here’s the catch:

If you’re using EC2 launch type, ECS needs available capacity on the cluster to actually place those tasks.

No CPU or memory available? The tasks stay stuck in PENDING. And it’s silent unless you're watching.

Here’s where ECS Cluster Auto Scaling (CAS) enters the story.

A Past Pain: Month-End GIS Workloads That Failed to Scale

In a previous role, we managed an internal image processing tool that rendered GIS data and allowed operations teams to annotate high-resolution maps. It wasn’t a real-time app — but it was heavy. And during critical windows like month-end or year-end closures, load would spike massively.

The app:

• Generated map tiles on the fly

• Handled concurrent uploads and annotations

• Involved CPU-heavy image processing

We assumed ECS auto scaling would “just work.” But then came 502s.

Naturally, we began by debugging the app:

• Checked RDS performance

• Tuned Apache settings

• Reproduced failures with same payloads

Nothing helped. The mystery deepened.

Until we noticed this: tasks were stuck in PENDING, but CPU and memory metrics looked fine.

That’s when we connected the dots. We had scaling at the task level, but the infrastructure wasn’t scaling with it.

It was like hiring more workers without giving them desks. We were adding more containers, but the underlying compute had no room to host them.

How to Estimate Capacity Like a Developer

Let’s say you're running a Flask or FastAPI app on ECS. The app handles:

• 10–12 API calls per user action

• Each API call does a DB lookup + image transform

• Spikes happen during end-of-day or batch usage

How do you estimate how many ECS tasks you need?

Here’s a developer-first method:

Step 1: Understand the API behaviour

• What is the average latency of a single API call? (e.g. 500ms)

• Are the calls CPU or memory bound? (CloudWatch / APM tools)

• What’s the max concurrency? (e.g. 100 users x 10 calls = 1,000)

If each ECS task can handle ~10 concurrent API calls → you need ~100 tasks

Step 2: Know Your Task Size

If task = 0.25 vCPU, 512 MB and EC2 = 2 vCPU, 8 GB → host ~8 tasks per EC2

➡️ 100 tasks → ~13 EC2s

Step 3: Monitor Key Metrics

• CPUReservation and MemoryReservation

• PendingTaskCount (cluster)

• ECS ManagedScaling logs

• App logs for 502s, slow endpoints, queuing behaviour

Step 4: Set Scaling Policies

• Task scaling: CPU > 50%

• CAS scaling: set targetCapacity = 80% for buffer

How ECS Cluster Auto Scaling Actually Works

It’s Not Magic — It’s Math

When ECS needs to launch new tasks but can't due to resource shortage, it uses a Capacity Provider with a formula like this:

desired = ceil((needed capacity) / (instance capacity)) * target capacity %

Let’s say you have:

• Pending Tasks: 4 tasks

• Each Task Needs: 0.5 vCPU and 1 GB RAM

• EC2 Type: t4g.medium (2 vCPU, 4 GB RAM)

• Target Capacity: 100% (binpack strategy)

Step-by-step:

1. Total Needed Capacity:

   • 2 vCPU (0.5 x 4)

   • 4 GB RAM (1 x 4)

2. Per Instance Capacity:

   • 2 vCPU and 4 GB RAM per t4g.medium

3. Divide & Ceil:

   • CPU: 2 / 2 = 1

   • Memory: 4 / 4 = 1

   • Take the max of the two = 1

4. Apply Target Capacity %:

   • At 100% target, no buffer → desired = 1 EC2 instance

So CAS would scale one t4g.medium to place those four tasks.

Target capacity lets you control buffer: set to 100% for binpack-style efficiency, or 80% for headroom.

Key Concepts from ECS CAS Internals

• ECS checks task placement every 15 seconds

• If it can’t place tasks, they go into the provisioning state (not failed)

• CAS calculates how many EC2s are needed based on task resource demand

• Up to 100 tasks can be in provisioning per cluster

• Provisioning timeout is 10–30 minutes before task is stopped

Daemon vs Non-Daemon Tasks: What Matters for Scaling

Daemon Task

• Scheduled to run on every EC2 instance

• Used for agents, log forwarders, metrics collectors

• ECS ignores these when calculating scale-out/scale-in

Non-Daemon Task

• Your real app workloads (Flask, Socket, Workers)

• These determine whether EC2s are needed or idle

How ECS Decides How Many EC2s to Run

Let’s say:

• N = current EC2s

• M = desired EC2s (CAS output)

ECS in Real Life: Before and After CAS

Once we added CAS:

• We linked services to a capacity provider

• Enabled managed scaling (target = 100%)

• Switched placement to binpack

Finally, tasks scaled. And so did the infra. No more 502s.

What If You're Launching a New App and Don’t Know the Load Yet?

Start lean. Scale for learnings.

When launching something new—like we are with NuShift—it’s often unclear what kind of user load or traffic patterns to expect. In such cases, make decisions based on expected concurrency, your framework’s behaviour, and instance characteristics.

Here are some tips to guide early capacity planning:

• Estimate concurrency: If you expect 50–100 concurrent users, and each user triggers multiple API calls, try to estimate peak call concurrency.

• Understand your app behaviour: Flask or FastAPI-based apps usually work well with 0.25 vCPU and 512MB, especially if I/O bound (e.g., API calls, DB reads). If your app does image processing or CPU-intensive work, start with 0.5 vCPU.

• Choose your EC2 wisely: We use t4g.medium (2 vCPU, 4GB RAM) for its cost-efficiency and support for multiple small tasks (6–8 per instance).

• Monitor early patterns: Let metrics shape your scaling curve—track CPUUtilisation, MemoryUtilisation, and task startup times.

Example initial config:

• Flask API: 1–3 tasks (0.25 vCPU, 512 MB)

• WebSocket: 1–2 tasks (depends on socket concurrency)

• EC2: t4g.medium in an ASG with ECS capacity provider

• CAS: enabled with 80% targetCapacity for buffer

Use New Relic, CloudWatch, or X-Ray to track CPU, memory, latency, and pending counts.

Final Thought

Scaling your application is easy to talk about. But infrastructure scaling is where things quietly break.

If you’re only watching task counts and CPU graphs, you might miss deeper issues:

• PENDING tasks with nowhere to run

• EC2s running agents, not apps

• Cold starts caused by infra lag

Auto scaling isn’t just about adding containers—it’s about giving them somewhere to live

References

• Deep Dive on Amazon ECS Cluster Auto Scaling (Official AWS Blog)

• ECS Task Placement Strategies

The lights were bright, the crowd buzzing, and everything looked perfect — but just hours before the show began, I stood still backstage, feeling a familiar knot in my stomach. Not out of fear, but from the weight of a moment that had been years — maybe a decade — in the making. I didn’t fully understand why it meant so much, not yet.

That clarity came later. Like all good stories — this one started with a spark, but the meaning would only unfold with time.

Great teams aren’t built on agreement — they’re built on shared purpose.”

That one line sums up our journey toward AWS Community Day Bengaluru 2025.

What started in December as a simple conversation soon turned into months of collaboration, debates, design chaos, speaker curation, and pure execution energy. We came in with diverse roles — some of us focusing on speakers, some on partnerships, others on content, marketing, logistics, or tech. We didn’t always agree, but we never lost sight of the goal: delivering a memorable experience for the community.

The Start: Vision to Action

The vision was simple — make this the most meaningful and elevated version of ACD Bengaluru yet. Bigger in scale, deeper in content, richer in community vibes. But turning that vision into action meant asking tough questions and making bold decisions.

We explored venue options, discussed format changes, and debated everything — from the layout of tracks to the type of workshops we wanted to host. It all started with a WhatsApp group and a few Google Meet calls. Weekend working sessions were filled with passionate arguments — and what's more magical is that the entire team never met in person, not even once. Yet, the synergy and symphony were real, because our goal was always clear and shared.

This was my first time organizing an event at such a large scale. Last year, I had organized Mautic Conference India in Pune — a proud moment with about 100 participants shared here. And I had volunteered for ACD BLR 2024, which was hosted at the Amazon office. But stepping up to co-lead the effort at a grand venue like Conrad Bengaluru was a completely different level. The stakes were higher, the pressure was real — but so was the passion.

That moment brought back an old, bittersweet memory. Back in engineering college, I had one dream: to become the CSR (Cultural Representative) — the person who would run the college fest, rally the teams, and own the spotlight. But college politics had other plans. I never got that role. That unfulfilled dream stayed tucked away — quietly lingering.

Yet, life has its own timeline. Organizing ACD BLR 2025, in front of hundreds of people, with a team I admire — it felt like that dream found its way back to me, not in the place I first imagined, but in a space where I was truly meant to lead, contribute, and shine. A heartfelt thanks to Bhuvana, Jones, and Ayyanar for trusting and believing in me with this opportunity — your confidence made all the difference.

Sometimes, you don’t get to live that dream in the place you imagined. But you get something better — a stage that truly values your intent, a platform where your efforts shine, and a team that believes in your vision. This was that moment for me.

The Build-Up: Decisions, Deadlines, and Dilemmas

As we moved into execution, the real challenges began. From finalising keynote speakers to rolling out creative ticket sale campaigns, each step required hustle, agility, and relentless problem-solving. We tested virtual photo booths, tweaked LinkedIn promos, crafted FOMO posts, created session posters, curated cue cards for emcees, and pulled off a social media blitz powered by our volunteers.

We also kickstarted two powerful community-led initiatives:

• Blogathon: A platform for community members to share their AWS learnings, stories, and hands-on experiments. It amplified new voices and celebrated the diverse experiences across our builder ecosystem.

• Voice of AWS UG Bengaluru: A new storytelling series where we spotlight the journeys, challenges, and achievements of our local AWS User Group members — giving a voice to the builders who power our community.

Two moments stood out for me as serendipitous reminders of how everything comes full circle:

The first was when my engineering college friend Sagar, who now runs an event management company called StudioB3, showed up at ACD. We hadn’t met in over 12 years. He’s been doing events for more than a decade — something I had completely forgotten. But someone once told me, "When your time comes, the right people will show up to help you." Reconnecting with Sagar at this moment felt like that kind of magic.

The second was when Talvinder Singh, founder of zop.dev, reached out via my official email regarding AWS cloud services. I could’ve replied formally, but instead, I sent him a message from my personal email — pitching the idea of sponsorship. And guess what? Talvinder turned out to be a former client from my time at Sodel Solutions. A full-circle moment, reminding me that when you build good relationships, people remember you.

Both moments reminded me that success is never solo — it's shaped by people, timing, and the relationships you nurture along the way.

It wasn’t perfect. And that’s what made it special.

A Moment to Recharge Before Show Time

Just before the final days of prep for ACD BLR 2025, a last-minute yet incredibly meaningful opportunity came our way — the inauguration of the first AWS Cloud Club in Bengaluru at Ramaiah Institute of Technology. The college had invited AWS UG leaders to attend the event alongside our keynote speaker Vivek Raja P S. Though Jason, Senior Program Manager of AWS Community Builders, couldn't join due to unforeseen reasons, his spirit was very much present.

Spending half a day there, celebrating the new generation of cloud enthusiasts, was a refreshing break — and a reminder of why we do this in the first place. Right after the ceremony, we were back in execution mode — refining ACD details, tying up loose ends, and getting ready to welcome hundreds of builders to Bengaluru.

The Day(s): Goosebumps, High-Fives, and Happy Faces

This time, I was doing something I’d never done before — speaking in front of the entire audience in the combined auditorium. Over the years, I’ve spoken in tracks and breakout rooms, but this was different. Bigger. A little scary. And deeply exciting. What made it even more special was sharing that stage with Vivek Raja P S, someone I deeply respect.

I wasn’t prepared the way I usually like to be — there were just too many moving parts in the days leading up to the event. But I reminded myself: I’ve been on stage more than 30 times. I knew I could pull through.

We tried something different — a conversational-style talk instead of a standard slide-heavy presentation. And to our surprise, many people came up to us afterward saying it helped them understand complex topics more easily. That made us smile. And just like that, the nervousness faded.

I didn’t know how the moment would unfold. Maybe we’d make mistakes. Maybe something wouldn’t go as planned. But I knew this for sure — we had built this event with heart.

• For every learner.

• Every builder.

• Every dreamer walking into ACD Bengaluru.

Walking into the venue, seeing everything come together — the tracks, booths, branding, swag, and smiles — was an emotional moment for many of us. The reactions from attendees, speakers, and sponsors reminded us that all the hard work had meaning.

Whether it was a packed Exhibition Lounge, a selfie with Jason (yes, that happened), or just the quiet moment of seeing a community member feel seen and celebrated — those were the wins we carried home.

What Made It Work?

• Diverse opinions, united by purpose

• Community-first thinking in every decision

• A willingness to do the grunt work

• Volunteers who went above and beyond, without expecting spotlight

Faces Behind the Magic

• Ansh, Isha, and Yashavi – The spotlight of the event as emcees. Their energy, clarity, and confidence brought the sessions to life and kept the momentum flowing throughout the day.

• Chetan's wife – A silent force of support who chipped in without hesitation and helped the team stay grounded.

• Yogesh and his friend - Our little and young champions who contributed like squirrel did in Ramayana.

• Mehnaz & Nabhanyua – Helped manage event-day logistics, always ready to lend a hand where needed. Their roles may have been short, but their impact was lasting.

• Bhuvana – The soul of AWS UG Bengaluru, her calm energy kept everything grounded. She’s the glue that held people and priorities together.

• Jones – The finance ministry and collaboration expert of our team. Always patient, always composed — he ensured everything behind the scenes ran with clarity and calm. Whether it was budget planning or community outreach, Jones brought structure, insight, and an unwavering willingness to help.

• Vivek Raja – The ML brain with a builder’s heart. Whether it was on-stage storytelling or behind-the-scenes mentoring, Vivek added thought leadership with humility.

• Srushith – The brain behind so many tactics that made this event impactful. From growth strategies to last-mile execution, his input often shaped the outcome — even when he stayed behind the curtain.

• Ayyanar – Deep tech wizard. His AI/ML depth and thoughtful insights shaped the content backbone of the event.

• Poobalan – He was always open to take up any challenge that came his way. From building the website — which was beautifully done — to managing social media seamlessly on event day, his openness and commitment truly stood out. A community strategist with a heart of gold and a can-do spirit.

• Logesh – A shadow for me in all things design, Logesh quietly helped shape the visual tone of the event. But on the event day, he stepped up and made sure everything ran smoothly on the ground — from handling AV to ensuring speaker content displayed right.

• Chetan – The quiet executor. If something needed doing, it was already done. No noise, just results.

• Harsha – Our perfectionist — always making sure our content and write-ups were polished and error-free. Unfortunately, he couldn’t be with us on event day due to a personal commitment, but his contributions in the lead-up were truly valuable and deeply appreciated. A silent force who made a loud impact. smile.

• Ramya – The swags master. From ideating to coordinating distribution, she ensured every attendee felt valued with thoughtful takeaways.

• Vijaya Nirmala – Supporting us from far away outside India, she showed that distance doesn’t matter when the intent is strong. Always present in spirit and helping wherever possible.

• Koti – The voice of calm in chaos. He’s a true community leader who brings in diverse insights from his experience running PyCon India — always calm in chaos. Whenever things went haywire, Koti was there with a plan and a laugh.

• Ayyanar & Srushith – The creative minds behind the AI speaker invention visuals that caught everyone’s attention. Their imaginative execution and attention to detail brought an extra layer of innovation to the event's design language.

Thanks also to the Konfhub team, especially Hari and Ganesh, for their incredible support in making this event a smooth experience — from handling ticketing operations seamlessly to sharing valuable insights whenever we hit a snag. Their behind-the-scenes help played a big part in the overall experience.

Life Behind the Curtain

They say,

"A smooth sea never made a skilled sailor."

And ACD BLR 2025 wasn’t just a journey of coordination — it was a test of balance, resilience, and purpose.

In the midst of all the planning and execution, life threw its own challenges. I was navigating some unexpected health issues — a gastrointestinal scare that pushed me to completely rethink my lifestyle and embrace fitness and clean eating. Just when I was finding a rhythm, my wife had to undergo a sudden surgery. Managing doctor visits, home responsibilities, a full-time job, and community commitments — it felt like everything hit at once.

But through it all, my family stood like a rock. They never once said, “Pause the community work.” They encouraged it. They believed in it. They believed in me. And that quiet support — the kind that doesn’t need applause — is what carried me through the chaos.

A Personal Note

As someone who’s been part of many community events, ACD BLR 2025 felt different. It was intense, emotional, and fulfilling. It proved once again that when builders, doers, and dreamers come together with clarity of purpose — magic happens.

To the Team:

Thank you. You weren’t just volunteers — you were visionaries, warriors, and glue that held it all together. This one’s for you.

https://youtube.com/shorts/i6WMuXA4wMM

References :

• AWS UG BLR meet up link to join - http://meetup.com/awsugblr

• AWS Community Day Bengaluru Blogathon awesome stories - https://acdblr-blogathon.devpost.com/project-gallery

• Konfhub - our ticketing platform

You know that moment when everything looks fine — no errors, no warnings — but the UI just... doesn’t do what it’s supposed to?
That’s how this story begins.

But let me add some background first...

🧳 Returning to Angular After 5 Years

I recently jumped back into Angular after almost five years away.

Things I used to know by heart?
Gone or evolved.

There’s standalone: true now. Modules are optional. Components feel more like islands.
It’s Angular — but... different.

So when I decided to build a simple standalone navbar component with a dropdown filter, I felt ready to dive in.

After all, how hard could *ngFor be?

Turns out, harder than I expected — if you're doing it blindly.

🚧 The Setup

I was building a home-navbar component — a simple filter with values like “Latest”, “Trending”, and “Following”.

In home-navbar.component.ts, I had:

filterOptions = ['latest', 'trending', 'following'];

And in the template:

<ul>
  <li *ngFor="let option of filterOptions">{{ option }}</li>
</ul>

So clean. So elegant.
So... not working.

😵‍💫 Debugging the Invisible

No errors. No warnings. Just an empty <ul>.
The kind of bug where Angular doesn’t even bother complaining — it just shrugs.

Here’s what I tried:

• ✅ console.log(filterOptions) — the array was there.

• ✅ {{ filterOptions }} in the template — rendered just fine.

• ❌ *ngFor — ignored. Like it didn’t exist.

I even replaced it with:

<li *ngFor="let item of ['a', 'b', 'c']">{{ item }}</li>

Still nothing.

Then I tried this:

<div *ngIf="true">Hello ngIf</div>

And when that didn’t render...
Something snapped.

💡 The Realization

After spiralling a bit, I checked the docs. Then it hit me:

This is a standalone component. It doesn’t inherit anything — not even Angular’s own core directives.

And that’s when I realised what I had missed all along:

import { CommonModule } from '@angular/common';

@Component({
  standalone: true,
  ...
  imports: [CommonModule, ...] // ← The missing piece
})

That one tiny line. That was the reason everything was failing — silently.

🔍 Why It Happens

In Angular:

• If you're using regular components inside an NgModule, importing CommonModule once covers all declared components.

• But if you're building standalone components, they’re completely self-contained.

• That means you must import CommonModule yourself, or you won’t get *ngIf, *ngFor, | date, | currency, etc.

🤦 Lesson from the Drama

I was so focused on building the UI and making things work that I forgot to stop and ask:

"Wait, where do structural directives even come from?"

This was a great reminder:
Even as someone experienced, it's easy to fall into habits — and overlook small things that matter.

The truth is, I wasn't "doing Angular" — I was doing muscle memory.

And Angular? It has changed.

✅ The Fix

This one line saved my sanity:

imports: [CommonModule]

Once I added that, *ngFor worked. *ngIf worked. Everything came back to life.

✨ Update: Angular 17+ Way Without CommonModule

Starting from Angular 17, there's an even cleaner way to handle loops without needing to import CommonModule at all!

✅ You can now use the new @for and @if syntax directly in your templates.

Example:

<ul>
  @for (option of filterOptions; track $index) {
    <li>{{ option }}</li>
  }
</ul>

or conditionally:

@if (filterOptions.length > 0) {
  <p>We have {{ filterOptions.length }} options!</p>
}

🏆 Best Practice

• For Angular 16 and below:
  Use CommonModule.

• For Angular 17 and above:
  Prefer @for and @if syntax.

• If you need to support older versions, stick to the *ngFor and *ngIf approach with CommonModule.

🔑 Takeaways

• Standalone components mean standalone responsibilities.
  Nothing is auto-included — you explicitly manage what your component needs.

• No CommonModule?
  Then no *ngFor, no *ngIf, no pipes — and no warnings either.
  Angular will silently skip them, leaving you scratching your head.

• Coming back to a framework after years?
  Don't assume things work like they used to.
  Even familiar tools evolve — often in small, silent ways.

• Tiny details break things quietly.
  Always slow down and verify the basics — they are the first place things go wrong.

• Bonus for Angular 17+:
  The new @for and @if syntax means even less boilerplate — no CommonModule needed at all!

🗯️ Have You Had “Silent Failures” Too?

Ever spent hours debugging only to realise one import was missing?
Or a component didn’t behave because of a silent Angular rule?

Share your moment.
Let’s normalise the messy middle part of learning and relearning.

Because sometimes, it’s not about knowing Angular.
It’s about knowing what to double check.

you might have heard about the recent release of Amazon Q Developer CLI.

I heard about it too, but like most tools, it sat on my radar until the moment I truly needed it - a real-time use case that made me glad I gave it a shot.

It started with a small request... and a potential disaster.

One of our developers was testing a machine learning model on an EC2 instance. A regular dev task, nothing fancy.

But a few hours in, he messaged me:

“Something’s off with the setup. I don’t want to break anything — can I get a clone of this machine to test on?”

Fair ask. But the instance he was using was one we also used for other internal dev workflows. Any changes could have unintended consequences.

My default plan? Console clicks and lots of waiting.

Cloning an EC2 isn’t rocket science — but it’s tedious:

1. Open AWS Console

2. Go to EC2

3. Find the instance

4. Create an AMI

5. Wait for the AMI to become available

6. Launch a new instance from it

7. Manually select the same instance type, security groups, IAM role...

8. Hope nothing breaks during this dance

It’s not hard, but I’ve done it too many times to count — and it always eats up 15–20 minutes, minimum.

This time, I tried something different. Amazon Q Developer CLI.

I had recently installed Amazon Q Developer CLI after reading about it.
A command-line assistant that understands natural language prompts and turns them into real AWS commands? I had to try it.

So instead of diving into the Console, I opened my terminal:

q chat

And typed:

“Create a new EC2 instance from the existing one named ml-base-server. Use the same security group and IAM role.”

That’s it. One sentence. No flags. No resource IDs.

What happened next blew me away.

Amazon Q Developer CLI:

• Identified the instance from its Name tag (ml-base-server)

• Generated an AMI creation command

• Waited for the AMI to become available

• Created a new EC2 instance using:

  • The same instance type

  • The same security group(s)

  • The same IAM role

• Even prompted me to confirm each step before executing

No scrolling. No searching. Just… done.

The result? My dev got a clean copy. Our base setup stayed untouched.

He could now run experiments safely.
No stress, no last-minute surprises, no Console hopping.

What would have taken 15+ minutes manually was done in under 3 — right from my terminal.

Why this matters

We often think of DevOps automation in terms of scripting or building pipelines.
But sometimes, what you really want is a conversation.

That’s what Amazon Q Developer CLI gives you:

• You say what you want in plain English

• It figures out how to do it

• You still keep control with confirmations

For small-but-important infra tasks like this, it’s a game-changer.

Try it yourself

If you haven’t used Amazon Q Developer CLI yet, get started here:
👉 Getting Started with Amazon Q Developer CLI – dev.to

Once installed, try this prompt:

q chat

“Create a new EC2 instance from the one named your-instance-name. Keep the same security group and IAM role.”

⚠️ Heads Up: A Few Post-Install Steps Are Missing from the Docs (macOS)

If you’re following the official Amazon Q CLI installation guide, you’ll notice it stops right after:

brew install amazon-q
q --version

But if you're on macOS, there are a few extra steps you must follow before things actually start working:

✅ Steps You Need to Complete After Installing via Brew

1. Open the Amazon Q desktop app
   After the brew install, you’ll find a new app called Amazon Q installed on your system (via Launchpad or Spotlight).

2. Grant Accessibility Permissions
   When you launch the app for the first time, it will prompt you to enable accessibility access.
   Go to:
   System Settings → Privacy & Security → Accessibility

   

   Then allow Amazon Q (CodeWhisperer) to control your system.

3. Login to AWS from the app
   You’ll be prompted to authenticate with your AWS account.

4. Enable Terminal Integration
   Go to the Integrations tab in the sidebar, and click “Enable” for your preferred terminal:

   • Terminal.app

   • iTerm2

   • Hyper

   • VS Code Terminal

     

5. Verify it’s active
   Open your terminal and try typing q chat — you should now see the CLI assistant activate in context.

Final Thoughts

Feel free to share what you are targeting to move from manual or script work to Amazon Q Developer CLI I’ve built EC2 clones hundreds of times the old way.
But this experience — using natural language to handle it — felt like the future.

Amazon Q Developer CLI didn’t just save time.
It let me focus on solving the actual problem, not navigating a UI maze.

And honestly?
I can’t wait to see what other repetitive tasks I can retire next.

References :

• https://dev.to/aws/getting-started-with-amazon-q-developer-cli-4dkd

• https://github.com/aws/amazon-q-developer-cli

• https://www.linkedin.com/posts/ricardosueiras_amazonqdevelopercli-aws-demoscene-activity-7312502995567431680-OocE/?utm_source=share&utm_medium=member_desktop&rcm=ACoAAAAycFYBiLynyePvMJ45ZRUDGVPqRgz4AJg

The reality is, these platforms evolved gradually. They started simple, observed system behaviour, and scaled incrementally based on real needs, not assumptions.

As engineers, we often fall into the trap of over-engineering too early. When building a new platform, there’s a natural temptation to implement event-driven architectures, message queues, caching layers, and microservices from day one. But do we really need all of that upfront? No one gets architecture perfect on the first try.

Instagram is a perfect example. When they started, they didn't have the complex, scalable infrastructure they do today. They also failed in the beginning, manually scaling their system—before weekends, they had to add more servers manually just to handle the expected load. It was a journey of learning and evolution. As a Staff Engineer building platforms at NuShift, I find myself asking similar questions:

• What will be my initial user base?

• Should I build everything for scale now, or should I start simple and evolve over time?

The answer is clear: implement what you need, observe, and then scale smartly.

Instagram’s Evolution: A Lesson in Scaling

Instagram’s infrastructure journey teaches us a lot about when and how to scale:

1. Start simple: Instagram began as a monolithic architecture. No microservices, no complex event-driven design—just a straightforward system.

2. Observe system behaviour: As their user base grew, they started experiencing bottlenecks in database queries, image processing, and request handling.

3. Scale where needed: Instead of redesigning everything from scratch, they incrementally added caching (Redis, Memcached), optimised databases (PostgreSQL sharding), and implemented asynchronous processing (Celery, Kafka).

4. Continuous Evolution: Over time, Instagram moved towards a service-oriented architecture, but only when it was necessary.

Had they over-engineered from day one, they would have slowed down feature development, introduced unnecessary complexity, and wasted engineering time solving problems they didn’t even have yet.

Building for Today vs. Tomorrow: My Approach at NuShift

At NuShift, I often face a similar challenge. I have to decide:

• Should I preemptively build for millions of users?

• Should I implement a full-scale event-driven system before the first release?

• Do I need queue-based processing, or is synchronous processing enough for now?

Here’s my approach:

✅ Start with the Basics: Get the core functionality working before adding complexity. Users will tell you where the pain points are.
✅ Observe and Measure: Use logging, monitoring, and metrics to track system behaviour. Performance bottlenecks will become clear over time.
✅ Scale Where Necessary: If database read operations are slow, introduce read replicas or caching. If too many background tasks pile up, introduce queues like SQS or Kafka.
✅ Avoid Premature Optimisation: Not everything needs microservices or Kubernetes from day one. Focus on solving real-world problems, not hypothetical ones.

Other Companies That Follow This Approach

Instagram isn’t the only one that scaled this way:

• Twitter: Started as a simple Rails app, later introduced queues, caching, and distributed storage as they grew.

• Airbnb: Began with a monolithic architecture, then adopted microservices when their scale demanded it.

• Netflix: Started with on-premise data centers, then moved to AWS cloud infrastructure as demand exploded.

None of these companies built their final, scaled architecture on day one. They scaled as needed, when needed.

Key Takeaways for Engineers

• No one architecture fits all. Start simple and evolve based on real-world demands.

• Scaling should be an iterative process. Monitor your system and fix what needs fixing, instead of blindly implementing every best practice.

• Premature optimisation can slow you down. Building for scale before you have users is an inefficient use of time and resources.

• Learn from real-world examples. Companies like Instagram, Twitter, and Netflix scaled over time, not overnight.

Final Thoughts

If you're building a new platform, don’t get caught up in trying to perfect everything from day one. Focus on building a solid foundation, listen to your system, and let real usage guide your scaling decisions. This is what Instagram did, what major tech giants did, and what we are doing at NuShift.

Scaling is a journey of learning and evolution. The best approach? Implement, observe, refine, repeat. 🚀

References :

https://blog.bytebytego.com/p/how-instagram-scaled-its-infrastructure?ref=dailydev

As a dedicated developer, I'm always on the lookout for more efficient ways to implement feature development. However, it's equally important to ensure that the features I build are genuinely beneficial for users. This is where A/B testing comes into play—it helps validate what truly resonates with users.

Previously, I was familiar with A/B testing using Google Analytics and custom logic to direct traffic to specific features. However, I sought a more seamless and scalable approach that didn't rely on additional infrastructure. As re:Invent approached, my focus wasn't solely on DevOps updates; I was actively searching for innovations that could simplify A/B testing and enhance feature development.

This led me to explore whether AWS had introduced any new capabilities to streamline this process. When I came across the recent update to Amazon CloudFront, allowing origin modifications using CloudFront Functions, I realised its potential in dynamically routing users based on key attributes like location or device type.

Amazon CloudFront recently introduced support for modifying the origin using CloudFront Functions, enabling developers to dynamically route requests to different origins based on user attributes such as country, device type, or other request headers. This feature unlocks new possibilities for global content delivery, including country-specific websites, A/B testing, and device-based content optimization.

This update immediately caught my attention as I was in the middle of preparing for the re:Cap event. It felt like the perfect opportunity to explore its real-world applications.

The Story Behind This Update

As part of AWS re:Invent preparations, AWS announced a Pre-re:Invent update on November 21, 2024, introducing new CloudFront capabilities. In preparation for the re:Cap event on January 6, 2025, I explored these new capabilities to showcase them in demos. When I came across this update, I decided to do a deep dive into CloudFront Functions and explore how it could be leveraged for dynamic origin selection. This led me to experiment with different use cases like country-based content delivery, A/B testing, and device-specific optimisations. Through this exploration, I realized how impactful this update could be for developers optimising global content distribution.

Why Modify CloudFront Origin Dynamically?

Traditionally, CloudFront distributions have a fixed origin (an S3 bucket, EC2 instance, or any HTTP endpoint). However, with CloudFront Functions, we can dynamically select the origin based on request attributes, such as:

• User’s country: Serve country-specific content from different S3 buckets or servers.

• A/B Testing: Route a percentage of traffic to different versions of a website or application.

• Device Type: Serve optimised content for mobile or desktop users.

How It Works

CloudFront Functions allow lightweight JavaScript-based logic to run at the viewer request stage, enabling modifications to the request before it reaches the origin. One key function is request.updateRequestOrigin(), which allows us to change the request origin dynamically.

Example: Changing Origin Based on User’s Country

For a country-specific website, we can use CloudFront-Viewer-Country header to decide which S3 bucket or server should serve the request.

Step 1: Create a CloudFront Function

You can create a CloudFront Function from the AWS Management Console or AWS CLI. Below is a sample function to modify the origin based on the user’s country.

Step 2: Deploy the CloudFront Function

1. Go to AWS CloudFront Console → Select CloudFront Functions

2. Create a new function and name it (e.g., ModifyOriginBasedOnCountry)

   You can choose any runtime but preferred one to use latest runtime.

   

3. Paste the JavaScript code and publish the function

    function handler(event) {
        var request = event.request;
        var headers = request.headers;
   
        // Extract country code from CloudFront-Viewer-Country header
        var country = headers['cloudfront-viewer-country'] ? headers['cloudfront-viewer-country'].value : 'US';
   
        // Define origin mapping based on country
        var origins = {
            'US': { domainName: 'us-content.example.com' },
            'IN': { domainName: 'in-content.example.com' },
            'UK': { domainName: 'uk-content.example.com' }
        };
   
        // Default to US if no specific origin is found
        var newOrigin = origins[country] || origins['US'];
   
        // Update the origin
        request.updateRequestOrigin(newOrigin);
        return request;
    }
   

   

4. Associate the function with the desired CloudFront distribution at the viewer request stage.

   

   

5. Make sure to publish function whenever make changes.

Step 3: Test the Function

To test country-specific content delivery, you can use any VPN-based proxy site like https://proxyium.com to browse the website from different locations. This will allow you to verify if the CloudFront function is correctly routing requests based on the user's country. Or Use curl to simulate requests from different countries by setting the CloudFront-Viewer-Country header.

curl -H "CloudFront-Viewer-Country: IN" https://your-cloudfront-domain.com

If implemented correctly, users from different regions will be routed to the appropriate origin. Same for can be tested for device specific using browser device testing under developer tool or test it on different physical devices.

Other Use Cases

1. A/B Testing

Modify the function to route a percentage of traffic to different origins for testing purposes.

var randomValue = Math.random();
if (randomValue < 0.5) {
    request.updateRequestOrigin({ domainName: 'experiment.example.com' });
}

2. Device-Based Content Routing

Use the User-Agent header to route requests based on mobile or desktop access.

var userAgent = headers['user-agent'].value.toLowerCase();
if (userAgent.includes('mobile')) {
    request.updateRequestOrigin({ domainName: 'mobile-content.example.com' });
}

Live demo

Summary

With the new updateRequestOrigin functionality in CloudFront Functions, developers can build highly customisable and dynamic content delivery strategies. Whether it's serving country-specific content, conducting A/B tests, or optimising content for different devices, this feature brings greater flexibility to AWS CloudFront.

🚀 Start leveraging CloudFront Functions today to optimise your content delivery!

I hope this blog helps you to learn. Feel free to reach out to me on my Twitter handle @AvinashDalvi_ or leave comment on the blog. Stay tuned for more learning.

References

• https://github.com/aws-samples/amazon-cloudfront-functions/tree/main/select-origin-based-on-country

As a developer, we always been in situation where the previous developer has long moved on, and you’re left with no documentation or answers. That was exactly the situation I found myself in when I started working on an Angular project that required deep linking for both iOS and Android. The previous developer wasn’t available, and I had to figure out how to make deep linking work in the existing codebase. Even after so many years of experience deep linking concept was new to me ( how it works ).

I’ll be honest — it wasn’t a smooth start. One of standup my team raised concern about this So I took this challenge to solve Though I good in Amplify hosting and Angular but how deep links work was exploration part. But with the help of Amazon Q Developer and a lot of trial and error, I eventually managed to set everything up. Amazon Q developer become best buddy to solve issue which I am not aware. I do use ChatGPT but for most of AWS related query used Amazon Q developer because expertise it has.

Understanding Deep Linking — The Social Media Analogy

Before diving into the technical steps, let’s take a moment to understand deep linking. You’ve probably seen it many times when using social media apps. For example, in Instagram, WhatsApp, or Facebook, when you want to share a post or a specific piece of content, you usually find a “Share” button or an option to "Copy Link." When you tap it, you're not just sharing a URL; you’re sharing a direct link to that specific content within the app.

This is exactly what deep linking does: it allows an app to open specific content directly through a URL, bypassing the homepage and landing you right where you want to be. So, whether it's sharing a Facebook post, sending a WhatsApp message, or viewing an Instagram story, deep links are everywhere — and they’re crucial for user experience in mobile apps.

For iOS, deep links are managed through the apple-app-site-association file, and for Android, it's handled by the assetlinks.json file. These files need to be hosted properly in the root of your web server, under a .well-known/ directory, and that’s where AWS Amplify comes into play if you are using Amplify hosting for Angular project.

Placing the apple-app-site-association File in Angular

Now that we understand what deep linking is and why it’s important, let’s get into the technical part. In an Angular project, the apple-app-site-association file should be placed inside the src/assets/.well-known/ directory. This allows Angular to copy the file into the build output, ensuring it gets served correctly when the app is deployed.

Here’s the folder structure you need to follow:

src/
  assets/
    .well-known/
      apple-app-site-association

And the contents of the apple-app-site-association file should look like this:

{
    "applinks": {
        "apps": [],
        "details": [
            {
                "appID": "TEAM_ID.BUNDLE_ID",
                "paths": ["*"]
            }
        ]
    }
}

This file essentially tells iOS which app should handle specific deep links and what paths are allowed. For instance, * means any path within the app can be opened via a deep link.

Updating angular.json to Copy the File During Build

At this point, the file is in the right location, but we need to make sure Angular knows to copy it to the build output when we run the build command. This can be done by modifying the angular.json file.

In the assets section of your angular.json file, you need to add an entry for the .well-known directory to ensure it’s copied during the build process:

{
  "architect": {
    "build": {
      "options": {
        "assets": [
          "src/favicon.ico",
          "src/assets",
          {
            "glob": "**/*",
            "input": "src/assets/.well-known",
            "output": "/.well-known/"
          }
        ]
      }
    }
  }
}

This ensures that when you build the app, the .well-known folder (and everything inside it) is copied into the root of the final build output.

Is it done ? No there few more steps are pending.

Configuring Rewrite Rules in AWS Amplify

Here’s where things got a bit tricky for me. AWS Amplify doesn’t automatically serve files like apple-app-site-association with the correct headers, and it also doesn’t automatically rewrite URLs to .json format when needed.

In my initial attempt, I added the rewrite rule for .well-known/apple-app-site-association to be rewritten to .well-known/apple-app-site-association.json. While this worked fine for that specific URL, the rest of the website went down for about two hours. It took me a while to realize that the order of the rewrite rules was causing the problem.

The Mistake

I had added the .well-known rule first, followed by other rules for the rest of the website. However, this sequence made the Amplify rewrite engine get stuck, causing an issue where the website would not load as expected. Although the .well-known URL was working fine, the other pages were not. It was a frustrating situation, and I realized that the sequence of the rewrite rules was the root cause of the issue.

The Solution

After some troubleshooting and a bit of trial and error, I figured out that the correct order of rewrite rules was essential for everything to work properly. I deleted all the previous rules and started fresh, ensuring the rewrite rules were correctly ordered.

Here’s how I corrected it:

1. I placed the .well-known rule first in the sequence.

2. Then, I added the rewrite rules to exclude .well-known and include other URLs for the rest of the website.

I added a rewrite rule to ensure that requests to /apple-app-site-association are correctly rewritten to .apple-app-site-association.json. This step was important because iOS expects the file to be in .json format, but users might request it without the extension.

I added the following rewrite rule to handle that:

{
  "source": "/.well-known/apple-app-site-association", 
  "target": "/.well-known/apple-app-site-association.json",
  "status": "200"
}

Additionally, I configured a default rewrite rule to handle non-asset URLs and redirect them to the main index.html for proper routing in the Angular app:

{
  "source": "/^(?!\.well-known/)(?!.*\.(css|js|jpg|jpeg|png|gif|svg|woff|ttf|eot|ico|mp4|mp3|json)$).*",
  "target": "/index.html",
  "status": "200"
}

This ensures that non-asset URLs are routed to the index.html page, which is typical for single-page applications (SPAs) built with Angular.

Deploying and Verifying

Once everything was set up, I deployed the application to AWS Amplify. After deployment, I tested the URL where the apple-app-site-association file should be served, and everything worked as expected:

https://your-amplify-app-url/.well-known/apple-app-site-association

I verified that the file was accessible and confirmed that it was being served with the correct content type and caching headers.

iOS Verification

To verify that the apple-app-site-association file is being served correctly, you can use Apple's verification tool:

https://app-site-association.cdn-apple.com/a/v1/yourdomain.com

This URL should return the contents of the apple-app-site-association.json file and show that it's being served with the correct Content-Type (application/json). If it works, your iOS deep linking is correctly configured.

Android Deep Linking — A Similar Process

While this blog focuses on iOS deep linking with AWS Amplify, it’s worth mentioning that Android also requires a similar configuration. For Android, you’ll need to set up the assetlinks.json file in the same .well-known/ directory. The process is very similar to what we’ve done for iOS, and once set up, deep linking will work seamlessly across both platforms.

Conclusion: A Learning Experience

Setting up deep linking wasn’t easy, but it was incredibly rewarding. I learned how to handle iOS and Android deep linking in an Angular app, how to host the necessary files on AWS Amplify, and how to configure the right rewrite rules for proper routing. What seemed like a daunting task at first ended up being a great learning experience.

By following these steps, you should be able to set up deep linking for your Angular app hosted on AWS Amplify. I hope my journey helps you navigate this process more smoothly and efficiently!

Happy coding, and may your deep links always work perfectly!

References :

• https://dev.to/developeralamin/deep-linking-for-andriod-and-apple-in-reactjs-1hjc

• https://developer.android.com/training/app-links/deep-linking

• https://yeeply.com/en/blog/mobile-app-development/deep-linking-android-ios-apps/

“Data is the new oil,” they say, but in healthcare and finance, it’s more like nitroglycerin—immensely valuable, yet dangerously explosive if mishandled.”

I recently shared on social media that I've joined the healthcare industry. This marks a shift from my background in both e-commerce and finance. During my time in finance, I dealt extensively with highly sensitive data like bank statements, KYC information, personal identification details, and other financial records. I vividly recall understanding that even a minor data handling error could have severe repercussions: breaches, fines, and, most importantly, a loss of public trust. This same level of data sensitivity exists in healthcare, where every piece of patient information is crucial and protected by regulations like GDPR and HIPAA. To comply with these regulations and similar ones worldwide, data masking has become essential. In this blog, I’ll break down what Powertools is, how it can be used for data masking in AWS Lambda, and why it’s critical for domains like finance and healthcare. Let's dive into Powertools for AWS Lambda.

What is Powertools for AWS Lambda?

Think of Powertools for AWS Lambda as a Swiss Army knife for serverless applications. It’s an open-source library that helps you write better, more secure, and more maintainable code. Instead of reinventing the wheel every time you need to mask data, log securely, or handle retries, Powertools provides ready-to-use utilities.

Key Features of Powertools for AWS Lambda

Powertools offers a robust set of features to simplify serverless development:

• Tracer

• Logger

• Metrics

• Event Handler

• Parameters

• Batch Processing

• Typing

• Validation

• Event Source Data Classes

• Parser (Pydantic)

• Idempotency

• Data Masking (Focus of this blog)

• Feature Flags

• Streaming

• Middleware Factory

• JMESPath Functions

• CloudFormation Custom Resources

In this blog, we are going to explore Data Masking usage in detail. For data masking, Powertools ensures that only necessary data appears in your logs.

Image taken from official website.

Why is Data Masking Important in AWS Lambda?

When dealing with serverless functions, especially in industries like healthcare and finance:

• Logs are often sent to systems like CloudWatch.

• Sensitive information (like SSNs, credit card numbers, or medical IDs) can easily end up in plaintext logs.

• Compliance standards (HIPAA for healthcare, PCI-DSS for finance) strictly prohibit exposing such data.

This is where Powertools for AWS Lambda comes into play.

How to Use Powertools for AWS Lambda for Data Masking

Let’s break this down step by step. I am taking example of Python here because it widely used and I used this my day to day activities.

1. Install Powertools

pip install aws-lambda-powertools // use pip3 for Python3 
pip install jsonpath_ng // if you get issue for jsonpath_ng. This mostly require for below example
pip install ply // if you get issue for ply. This mostly require for below example

2. Use the Logger Utility for Masking ( erase, encrypt, decrypt).

In this example we are using erase method to mask data. Powertools for AWS Lambda offers three primary functions for data masking:

• erase: Removes sensitive data fields completely.

• encrypt: Encrypts sensitive data fields.

• decrypt: Decrypts previously encrypted fields.

from __future__ import annotations

from aws_lambda_powertools import Logger
from aws_lambda_powertools.utilities.data_masking import DataMasking
from aws_lambda_powertools.utilities.typing import LambdaContext

logger = Logger()
data_masker = DataMasking()


@logger.inject_lambda_context
def lambda_handler(event: dict, context: LambdaContext) -> dict:
    data: dict = event.get("body", {})

    logger.info("Erasing fields email, address.street, and company_address")

    erased = data_masker.erase(data, fields=["email", "address.street", "company_address", "aadhar", "diagnosis","blod_group"])  

    return erased

In this example, sensitive data like Aadhar, blood group, diagnosis is masked while still allowing logs to be useful for debugging.

Response:
{
  "id": 1,
  "name": "Avinash Dalvi",
  "age": 30,
  "email": "*****",
  "address": {
    "street": "*****",
    "city": "Bengaluru",
    "state": "KA",
    "zip": "211311"
  },
  "diagnosis": "*****",
  "blod_group": "*****",
  "aadhar": "*****",
  "company_address": "*****"
}

To use encrypt method refer this official documentation https://docs.powertools.aws.dev/lambda/python/latest/utilities/data_masking/#encrypting-data and for decrypt method use this https://docs.powertools.aws.dev/lambda/python/latest/utilities/data_masking/#decrypting-data

In this way we can validate compliance with Powertools and it is not only masks data but also helps with metrics and tracing to ensure compliance with industry standards like GDPR or HIPAA

Real-World Use Case: Healthcare Application Logs

Imagine a healthcare Lambda function that processes insurance claims. Without masking, logs might show:

INFO: Processing claim for Patient: Avinash Dalvi, Aadhar ID : 1233-2432-2233, Blood Group : O+

With Powertools:

INFO: Processing claim for Patient: Avinash Dalvi, Aadhar ID : *****, Blood Group : *****

A tiny change, but one that can save millions in potential fines and, more importantly, protect lives.

How It Impacts Healthcare and Finance

• Healthcare: Ensures compliance with HIPAA by preventing PHI (Protected Health Information) leaks.

• Finance: Aligns with PCI-DSS guidelines to prevent exposure of payment details.

• Audit Readiness: Masked logs are audit-friendly while maintaining transparency for debugging.

In fast growing world of Serverless architectures, Powertools for AWS Lambda isn’t just tool - it’s a shield which protect us and make it compliant. Whether you are handling medical records, financial transactions or personal user data integrating Powertools ensures you are not just compliant but also responsible.

As I continue building solutions in the healthcare space, Powertools has become my go-to companion, making critical use cases easier, safer, and scalable.

Have you faced similar challenges in your Serverless journey? Share your thoughts below, and let’s keep building secure and responsible applications together.

I hope this blog helps you to learn. Feel free to reach out to me on my Twitter handle @AvinashDalvi_ or leave a comment on the blog. Stay tuned for more learning for data masking using Powertools.

References:

• https://docs.powertools.aws.dev/lambda/python/latest/utilities/data_masking/

• https://github.com/aws-powertools/powertools-lambda-python

I nurtured these thoughts daily, visualizing them as already achieved, allowing them to guide my actions and intentions. Alongside this, I began preparing myself for the role of a Staff Engineer. Little did I know, the universe was already listening. By the end of 2024, I found myself not just as a Staff Engineer, but as a Senior Staff Engineer at NuShift.

This journey wasn't without its challenges, but every step was purposeful, every setback was a lesson, and every small victory was a milestone on the path I had envisioned. This year wasn't just about professional achievements; it was about believing in the unseen, trusting the process, and showing up every single day with intention and resilience.

The Staff Engineer Dream: A Road Paved with Failures and Growth

One of my key aspirations for 2024 was to transition into a Staff Engineer role. But the journey wasn't linear. I faced multiple rejections during interviews, and each one felt like a heavy blow to my confidence. I remember sitting quietly after one particularly tough rejection, questioning whether I was truly cut out for this path. But amidst those moments of doubt, I reminded myself why I started—to grow, to learn, and to contribute at a higher level.

To ensure I was prepared, I went through countless blogs from people who had walked this path before me. I read The Staff Engineer's Path and immersed myself in videos, interviews, and success stories. I wanted to understand not just the technical expectations but the mindset, leadership qualities, and the varying interpretations of the role across different companies. I didn't want to step into the role unprepared; I wanted to do justice to it.

Slowly, I began treating each rejection not as a failure, but as feedback. I revisited my preparation, identified weak spots, and sought guidance from mentors who had walked this path before me. Every setback became a stepping stone, every doubt became a question to answer, and every small improvement became a reason to keep going. The road was tough, but it shaped me in ways success never could. I leaned on my experiences, sought mentorship, and slowly started building a roadmap for myself, not just professionally but emotionally. The road is still being paved, but the lessons from those moments will forever remain etched in my journey.

Breaking the Habit of Context Switching: The Power of Deep Work

For years, I had a habit of multitasking and frequently switching contexts. While it seemed productive on the surface, it often left me exhausted, overwhelmed, and surrounded by unfinished tasks. But in 2024, I stumbled upon the book Deep Work by Cal Newport, and it completely changed my perspective.

The book taught me the value of focus and uninterrupted work sessions. I'm not saying I've perfected this habit, but something has shifted. I've started noticing improvements in how I manage my tasks, focus on one thing at a time, and make meaningful progress without feeling perpetually drained.

In 2025, I aim to deepen this habit even further—to strike a better balance between my professional and community contributions, and to ensure every effort counts.

Mentorship and Judging: 0x.Day Hackathon, Pondicherry

On December 29th and 30th, I had the incredible opportunity to be a mentor and a final panel judge at the prestigious 0x.Day Hackathon in Pondicherry. With over 500 participants and 130 teams, the energy was electric. Personally evaluating 27 teams was no small feat, but it was equally rewarding.

During the hackathon, I was amazed by several projects focused on social and community impact. One team worked on creating sign language translations from YouTube or any video content, breaking barriers for hearing-impaired individuals. Another team built a voice-hearing application for people who can't listen, offering them a new way to interact with the world. A third project aimed to create an inclusive healthcare ecosystem, ensuring accessibility and care for underprivileged communities. There was even an innovative idea that focused on transforming negative or unclear speech into positive, meaningful communication.

Each of these projects left a lasting impression on me, not just because of their technical ingenuity, but because of the compassion and purpose driving their creators. It reminded me that technology isn't just about innovation; it's about creating meaningful change in people's lives. These young minds showed courage, creativity, and a deep sense of responsibility, and I felt incredibly proud to have been a part of their journey.

In moments like these, I was reminded why events like hackathons matter. It's not just about flawless execution; it's about courage, creativity, and the willingness to try. I felt proud to contribute to nurturing the next generation of builders, one team at a time.

International Talks: A Dream Realised (Almost)

2024 also marked a significant milestone: my first international talk at FOSS Asia. Standing on an international stage, sharing knowledge, and interacting with a global audience was an experience unlike any other. Out of 26 talk submissions this year, three were accepted internationally. However, I could only attend one. The missed opportunities weighed on me initially, but I reminded myself that sometimes, the universe has other plans.

On the brighter side, I successfully delivered four impactful talks at conferences, each one carefully crafted with a storytelling approach to ensure every attendee left with not just insights but inspiration.

Community Building: Amplify, Mautic, and Beyond

This year was also deeply rooted in community contributions. I played a significant role in organizing the first-ever Mautic Conference in India, an event that brought together 100+ attendees to share ideas, best practices, and future possibilities for open-source marketing automation.

In parallel, I served as a supporting organizer for the 30 Days of Amplify event, hosted by AWS User Group India. Coordinating sessions, engaging participants, and ensuring seamless execution reaffirmed my love for community building and the ripple effect it creates.

I also stepped into the Mautic community supporting lead role, a position I was both excited and anxious about. Despite my best intentions, I often felt that I couldn't give the role the justice it deserved. There were moments when I considered stepping away entirely, but I reminded myself why I took on the responsibility in the first place. I continued to contribute in whatever capacity I could, even if it felt small at times. In 2025, I am determined to show up better, contribute more meaningfully, and truly justify the trust placed in me by the community.

Fitness and Well-being: Small Habits, Big Changes

This year, I also focused on staying active and maintaining my well-being. Whether it was playing cricket, hitting the gym, walking, or enjoying a quick game of table tennis, these activities didn't just keep me fit—they kept me happy. They became moments of pause in an otherwise busy schedule, reminding me that while work is important, keeping the mind relaxed is even more essential.

I also implemented a few small but impactful habits: setting a consistent bedtime, reading before sleep, and ensuring my mobile internet was off by 9:30 PM. Although there were occasional exceptions, I mostly stuck to these habits, and they made a significant difference.

This focus on fitness and mental well-being stems from a deeply personal realization. After being admitted to the ICU during the COVID-19 pandemic, I promised myself that I would prioritize my health. Over the past few years, these small initiatives have helped me stay active, reduce stress, and bring a better version of myself to both my professional and personal life.

In 2025, I aim to continue these habits and refine them further to maintain a balance between physical health, mental well-being, and professional excellence.

YouTube Journey: Consistency and Growth

In 2024, I focused on building consistency on my YouTube channel - Learn with Avinash Dalvi. I committed to uploading videos every Tuesday and Saturday, and this routine brought both discipline and growth to my channel.

📊 2024 YouTube Milestones:

• 1,054 New Subscribers

• 82K Views

• 101 Uploads

• 2,272 Likes

• 58 Comments

• 546 Shares

This journey wasn't just about numbers; it was about showing up consistently, sharing knowledge, and building a connection with the audience. In 2025, I plan to keep this momentum going and continue delivering valuable content.

AWS re:Invent Nominations: A Moment of Pride

One of the proudest moments of 2024 was being nominated in two categories at the AWS re:Invent APJ Community Awards Night—'Invent & Simplify' and 'Deliver Results.' While I couldn't personally attend the event and didn't win the award, the nomination itself felt like a significant achievement.

Being recognized at such a prestigious platform reassured me that my contributions are making an impact. It felt like a signal to keep going, to keep contributing, and to continue sharing knowledge with the community. This nomination wasn't just an accolade; it was a reminder that consistency and dedication never go unnoticed.

Reflections: The Emotional Side of the Journey

Beyond the technical accomplishments, this year was also about embracing my vulnerabilities. I realized the power of pauses while speaking, the importance of balancing ambition with self-care, and the humility in acknowledging limitations.

There were moments of self-doubt, burnout, and disappointment. But every time I felt stuck, I reminded myself of why I started—to build, to share, to contribute, and to inspire.

A Special Thanks to My Strong Pillars: Trupti and Advit

None of this would have been possible without the unwavering support of my wife, Trupti, and my child, Advit. They are my strongest pillars, my motivation, and the reason I can step out into the world with confidence and purpose. Their encouragement, sacrifices, and love have been the silent force behind every achievement this year.

Looking Ahead: A Vision for 2025

As I step into 2025, I carry with me the lessons, the wins, and even the scars from 2024. I look forward to growing deeper into my technical expertise and continuing to give back to the community. I am also excited to explore unexplored areas like AI/ML, Big Data, and Blockchain. These fields demand more learning, experimentation, and sharing, and I am ready to embrace that challenge.

Stay tuned to my blog and YouTube channel for updates as we continue to Learn Together, Grow Together. There are also a few initiatives I'm quietly working on, but I'll reveal them when the time is right.

If there's one takeaway from this year, it's this:

"Success isn't always about the applause at the end; it's about showing up, day after day, even when no one's watching."

Thank you, 2024, for being everything I didn't expect but everything I needed.

Here's to 2025—another year of growth, impact, and storytelling.

Whats your reflection ? share in comment would like read about your story too. Every person has story to tell.

As we approach the 10th anniversary of AWS Lambda and Amazon Elastic Container Service (ECS) on 14th November 2024, I find myself reflecting on how these two revolutionary services have not only transformed cloud computing but have also profoundly shaped my career and passion for sharing knowledge. This milestone feels like the perfect moment to express my gratitude for the journey these services have enabled me to embark on, evolving from curious exploration to becoming an advocate within the AWS community.

Discovering AWS Lambda: From Curiosity to Clarity

It all began in 2016 when I arrived in Bangalore, excited but unsure of where my tech journey would lead. Coming from a traditional background of managing servers with EC2, the concept of Serverless was completely new. Then came Lambda—a name I initially associated with math, not with revolutionising my approach to development.

Lambda was introduced to me as "the way forward" for an upcoming project in one of project meeting when I was in KNAB finance. I remember feeling puzzled—how could we run code without managing servers? But as I dove into Lambda, my confusion turned to clarity. Lambda’s ability to handle massive traffic loads, scale automatically, and only charge for what was used completely changed the way I viewed application development. Suddenly, infrastructure was no longer a limiting factor; instead, it was an enabler, allowing me to focus solely on creating, experimenting, and scaling.

Lambda didn’t just simplify architecture; it shifted my perspective on innovation. This new approach empowered me to experiment with microservices, scaling applications effortlessly. I found myself fascinated by its flexibility and cost-efficiency, and soon enough, I became a regular speaker on Lambda, sharing this newfound knowledge with other developers via blogs. Each session deepened my connection with the AWS community and inspired me to continue exploring what Serverless could do. So Lambda become become my go to service for any research.

Embracing ECS and the Power of Containers

While Lambda laid the foundation for Serverless architecture, my journey with containers began in 2021 with ECS When I joined Eagleview. ECS introduced me to container orchestration and allowed me to deploy applications with more control and customisation. Through Fargate, AWS made it possible to run containers without managing servers, aligning with my passion for Serverless solutions.

I began experimenting with ECS for real-world applications, diving deep into concepts like debugging, hosting WordPress, and lazy-loading container images. These experiences led to articles like Debugging AWS ECS Task Containers, Hosting WordPress on ECS Fargate, and OCI Lazy Loading with ECS and Fargate. These pieces connected with readers worldwide, and my YouTube video on WordPress on ECS Fargate reached nearly 4,000 views, reinforcing the power of ECS to solve complex challenges simply and effectively.

One of my most memorable sessions at Serverless Days Bengaluru 2024, Serverless Sherlock, showcased ECS Fargate’s Serverless capabilities, allowing me to discuss advanced debugging techniques and troubleshooting strategies with the community. Building on this experience, I am eager to explore further innovations and share more insights on how these technologies can be leveraged to solve complex challenges efficiently.

Building, Sharing, and Giving Back to the Community

As my knowledge of Lambda and ECS expanded, so did my commitment to share it. In 2021, I became an AWS Community Builder, a role that has allowed me to share my expertise more widely and connect with other developers and learners. From blogs to Stack Overflow answers, talks, and webinars, I’ve tried to make these technologies more accessible and relatable. My blog post on using AWS Secrets Manager with Lambda gathered over 65,000+ views.

AWS has not only been a set of services—it’s been a supportive community, a source of endless learning, and a platform for growth. The journey has been inspiring, and every new feature or capability AWS releases is an opportunity to learn, share, and give back. With the community's encouragement, my writing took off, and articles like Navigating Docker Container Deployment on AWS resonated with developers looking to simplify their AWS journeys.

A Heartfelt Thanks to Lambda, ECS, and AWS

To AWS Lambda and ECS: thank you. You have not only simplified complex challenges but have also opened the doors to innovation, allowing me to think bigger and build smarter. Your flexibility, scalability, and the freedom you offer have been instrumental in shaping my career and my commitment to the AWS community.

Here’s to Lambda, ECS, and the endless possibilities they represent. Thank you for being a vital part of my journey and for inspiring countless developers to build, innovate, and share. Here's to the next decade of AWS—and the transformative power it brings to us all.

Your Turn to Share

As we celebrate a decade of AWS Lambda and ECS, I invite you to reflect on your own journey with these transformative technologies. Here are a few questions to ponder:

• How has AWS Lambda or ECS impacted your development process?

• What challenges have you faced, and how did you overcome them?

• What features do you find most beneficial, and why?

I would like to know from you too. I encourage you to share your thoughts and experiences in the comments below or on social media using the hashtag #MyAWSJourney. Your insights could inspire others and contribute to our growing community of AWS enthusiasts.

What next ?

Looking ahead, what do you think the future holds for serverless computing and container orchestration? Share your predictions and let's discuss how these technologies might evolve in the next decade.

References :

• https://aws.amazon.com/serverless/10th-anniversary/

Generative AI is rapidly gaining traction, with companies eager to integrate it into their workflows and drive product innovation. As its popularity soars, numerous LLM models and Generative AI companies are emerging. However, this surge in interest brings its own set of challenges. Companies face difficulties in managing large models on their infrastructure, caching results, handling credentials, and dealing with new-age queries (prompts). Most critically, they struggle with managing a diverse array of AI models, each with its unique structure and communication format. This complexity makes it challenging to establish failover mechanisms and efficiently switch between models, leading to significant time and resource investments.

Introducing Portkey open-source AI Gateway:

Portkey AI Gateway offers an open-source AI Gateway that simplifies managing generative AI workflows. This powerful tool supports working with multiple large language models (LLMs) from various providers, along with different data formats (multimodal). By acting as a central hub, Portkey streamlines communication and simplifies integration, improving your application's reliability, cost-effectiveness, and accuracy.

Getting Started with PortKey AI Gateway

Getting started with PortKey AI Gateway involves very simple steps.

1. Open this https://github.com/Portkey-AI/gateway and follow instructions or run the below command in your terminal. Make sure your NodeJs is installed in your machine.

2. Hit http://localhost:8787 in the browser.

3. That’s it! This server is up, the next step is to test out a Large Language Model (LLM). You can pick up any LLM from the list

In this blog, I will explain how to use Google PaLM and Gemini model as an example to use with PortKey gateway.

Google PaLM and Gemini with Portkey AI Gateway

If you already know how to get the API key then skip these steps.

1. Sign up using google account here https://aistudio.google.com. And click on “Create new key” on the left navigation menu.

2. You can choose any AI model from here

To call PortKey Gateway you need two things:

• Your AI model API key or secret key ( Google AI Studio API key )

• Model name which you would like to test.

PortKey currently supports AI model API hardcoded versions like Google gemini version supported is v1beta and Google Palm supported is v1beta3. A feature request is under process. So you need to find a model which is supported under those API versions, otherwise it will throw an error “Model doesn’t support under API version”.

As per this reference document https://ai.google.dev/tutorials/rest_quickstart Google gemini model supported for generateContent is gemini-pro. We will test our /generateContent AI API model. This standard example is to call a CURL request to PortKey Gateway.

curl '127.0.0.1:8787/v1/chat/completions' \
  -H 'x-portkey-provider: openai' \
  -H "Authorization: Bearer $OPENAI_KEY" \
  -H 'Content-Type: application/json' \
  -d '{"messages": [{"role": "user","content": "Say this is test."}], "max_tokens": 20, "model": "gpt-4"}'

Here is an API request for Google Gemini AI model : Replace $GOOGLE_KEY with your actual key.

curl --location '127.0.0.1:8787/v1/chat/completions' \
--header 'x-portkey-provider: google' \
--header 'Authorization: Bearer $GOOGLE_KEY' \
--header 'Content-Type: application/json' \
--data '{
    "messages": [
        {
            "role": "user",
            "content": "Write a story about a magic backpack."
        }
    ],
    "model": "gemini-pro"
}'

Exactly similarly you can use other AI models like OpenAI, Ollama etc with just model name and AI API key.

Now you have understood how to use this PortKey Gateway API with different AI models. Lets checkout how you can developed resilient GenAI pipeline with PortKey AI Gateway

I will cover major features of PortKey support to make your GenAI pipeline resilient.

Build failover mechanism with PortKey AI Gateway

As we saw early in blog fallback is one feature of PortKey gateway which supports adding a list of AI Model API if incase any one of them or primary API fails. In this list you can add numbers of AI model AI.

In the same REST call under header against x-portkey-config you can add these params to add a list of LLM models API along their API keys so that if the primary key fails it will take the second one. Here's a quick example of a config to fallback to Anthropic's claude-v1 if Gemini’s “gemini-pro” fails.

{
  "strategy": {
      "mode": "fallback",
  },
  "targets": [
    {
      "virtual_key": "google-virtual-key",
    },
    {
      "virtual_key": "anthropic-virtual-key",
      "override_params": {
          "model": "claude-1"
      }
    }
  ]
}

Here is example CURL request to PortKey AI Gateway with config params :

curl --location '127.0.0.1:8787/v1/chat/completions' \
--header 'x-portkey-provider: google' \
--header 'Authorization: Bearer $GOOGLE_KEY' \
--header 'Content-Type: application/json' \
--header 'x-portkey-config: {"strategy":{"mode":"fallback"},"targets":[{"provider":"google","api_key":"$GOOGLE_KEY"},{"provider":"openai","api_key":"sk-***"}]}' \
--data '{
    "messages": [
        {
            "role": "user",
            "content": "Write a story about a magic backpack."
        }
    ],
    "model": "gemini-pro"
}'

This way you can have a fallback mechanism in your AI pipeline. In this config you set on which status code of failing API should have fallback by just adding under “strategy”

"strategy": {
    "mode": "fallback",
    "on_status_codes": [ 429 ]
  }

Note : You need to ensure while using this fallback mechanism that the LLMs in your fallback list are compatible with your use case. Not all LLMs offer the same capabilities.

Similarly you can have more capabilities to make sure your GenAI pipeline is resilient and stable. Like adding auto retry mechanism, caching and load balancing. Same can be configured under “config” parameters. More details given here.

This way PortKey AI gateway simplifies managing generative AI workflows by offering multi-model support and easy integration. This translates to improved app performance through features like automatic failover and efficient model switching.

So give it a try with PortKey AI gateway and make your GenAI pipeline resilient. Let us know if you have any query.

References

• More details about feature and how to use : https://docs.Portkey AI Gateway/docs/product/ai-gateway-streamline-llm-integrations

• https://github.com/Portkey-AI/gateway/blob/27a6ebbc9ddd972ef1a716176fc17d0b2671c366/src/providers/google/api.ts#L4C22-L4C70

• https://github.com/Portkey-AI/gateway/blob/27a6ebbc9ddd972ef1a716176fc17d0b2671c366/src/providers/palm/api.ts#L4C64-L4C71

• PortKey Config : https://docs.Portkey AI Gateway/docs/api-reference/config-object

• https://docs.portkey.ai/docs/product/ai-gateway-streamline-llm-integrations/fallbacks

• How to add JSON object in header Postman API: https://community.postman.com/t/get-custom-header-value-as-object-json-stringify/16172

I was recently assigned the task of migrating alert notifications from Slack to Microsoft Teams. However, I encountered challenges testing these alerts in a live environment, especially the inability to delete ECS clusters or tasks without impacting production systems. To address this issue, I looked for a way to simulate the alerting process locally. This search led me to discover LocalStack, a powerful tool that enables you to test AWS services on your local machine. In this blog, I will guide you through setting up LocalStack to test ElastAlert rules, ensuring a smooth alert migration without the risk of disrupting live services.

1. Install Prerequisites

Before getting started, ensure you have the following installed:

• Python: Download and install Python (3.7 or above) from python.org.

• AWS CLI: Install the AWS CLI to manage LocalStack resources easily. Follow the AWS CLI installation guide.

• Docker: Install Docker, as it is required for running LocalStack.

2. Set Up LocalStack

Using the LocalStack Desktop App

1. Download the LocalStack Desktop app from the LocalStack website.

2. Install the app by following the provided instructions for your operating system.

3. Open the LocalStack Desktop app and start the LocalStack service. This will create a LocalStack environment where you can run your AWS services locally.

Using Docker Desktop LocalStack Extension

1. If you prefer using Docker, open Docker Desktop.

2. Navigate to the Extensions section and search for LocalStack.

3. Install the LocalStack extension directly from Docker Desktop.

4. Once installed, you can start LocalStack by selecting it from the extensions list.

3. Create LocalStack Elasticsearch Instance

After installing LocalStack (either through the Desktop app or Docker extension), create an Elasticsearch domain. It may take a few minutes for the service to start.

Run the following command to create a LocalStack Elasticsearch domain: —domain-name can use any word I just used “testinglocally”

aws es create-elasticsearch-domain --domain-name testinglocally --endpoint=http://localhost:4566

Once you run this command it will show host value. copy that host value will require while doing step 4.

{
    "DomainStatus": {
        "DomainId": "000000000000/testinglocally",
        "DomainName": "locales",
        "ARN": "arn:aws:es:us-east-2:000000000000:domain/testinglocally",
        "Created": true,
        "Deleted": false,
        "Endpoint": "testinglocally.us-east-2.es.localhost.localstack.cloud:4566",
        "Processing": true,
        "UpgradeProcessing": false,
        "ElasticsearchVersion": "7.10",
        "ElasticsearchClusterConfig": {
            "InstanceType": "m3.medium.elasticsearch",
            "InstanceCount": 1,
            "DedicatedMasterEnabled": true,
            "ZoneAwarenessEnabled": false,
            "DedicatedMasterType": "m3.medium.elasticsearch",
            "DedicatedMasterCount": 1
        }
    }
}

Verify the instance by listing the domains:

aws es describe-elasticsearch-domain --domain-name testinglocally --endpoint-url=http://localhost:4566

4. Clone ElastAlert

Clone the ElastAlert repository from GitHub:

git clone https://github.com/jertel/elastalert2
cd elastalert2

Create Configuration File

Copy the example configuration file and create a new config.yaml:

cp config.yaml.example config.yaml

You can place this file in the root directory or, if you prefer a structured approach, keep it in an example folder. If you do this, remember to specify the path when running ElastAlert rules. elastalert-test-rule --config <path-to-config-file> example_rules/example_frequency.yaml

5. Install ElastAlert Dependencies

Install the required Python packages by running:

pip install -r requirements.txt
python setup.py install

6. Create an ElastAlert Rule

Navigate to the example/rules folder in the ElastAlert repository. You can either select an existing example rule or create a new one for testing. Here’s an example structure for a new rule:

name: login page
include: ["@timestamp", "monitor.name", "monitor.status", "ev.application.name"]
type: frequency
# We want to alert if we have been down for 5 minutes
# Heartbeat runs every 60s, so we need 6 failures in 330s to trigger an alert
# timeframe = (num_events - 1) * 60s + 60s / 2
num_events: 1
timeframe:
  minutes: 10
index: heartbeat-*
filter:
- query:
    query_string:
      query: 'monitor.name: "login page" AND monitor.status: "down"'
alert:
  - ms_power_automate
ms_power_automate_webhook_url: "https://webhook.site/e3f965f6-4087-4aad-a1db-7e46db55ae1d"

7. Create an Index and Sample Data

Create the index that your rule will use, such as heartbeat or filebeat: You can use http://localhost:4566 or locales.us-east-2.es.localhost.localstack.cloud:4566.

curl -X PUT "http://localhost:4566/filebeat-1"

Insert Sample Data

Use the following PUT request to add sample data:

Note : use UTC timing for testing if you want to know what is your machine UTC timing then run this command date -u it will display like this Mon Sep 30 11:01:57 UTC 2024 take out of timing and use in below CURL request.

curl -X PUT "http://localhost:4566/filebeat-1/_doc/1" -H 'Content-Type: application/json' -d '{
    "message": "Test log entry",
    "@timestamp": "2024-09-30T14:40:00Z",
    "monitor": {
        "name": "Test Monitor",
        "status": "down"
    }
}'

8. Test the ElastAlert Rule

Run the ElastAlert test command:

elastalert-test-rule examples/rules/example_error.yaml --alert --config examples/config.yaml

This command will simulate the alert based on the created rule and the data in your Elasticsearch instance.

9. Troubleshooting and Triage

After running the test, you may want to perform some maintenance and triage tasks or while testing alerts locally, you may encounter some common errors. Here are some triaging steps you can follow:

Deleting an Index

To delete an index, run: Whichever index you have created use that to delete example if you have created hearbeat-1 or filebeat-1 then used accordingly.

curl -X DELETE "http://localhost:4566/filebeat-1"

Refreshing the Index

You can refresh the index to ensure that all operations are performed:

curl -X POST "http://localhost:4566/filebeat-1/_refresh"

Searching the Index

You can search the index to verify data:

curl -X GET "http://localhost:4566/filebeat-1/_search"

Searching with Filters

Apply filters to your search for more specific queries:

curl -X GET "http://localhost:4566/filebeat-1/_search?q=monitor.status:down"

Check Indexes:

Run the following command to verify the indices in Elasticsearch

curl -X GET 'http://localhost:4566/_cat/indices?v'

Ensure Correct Timing:

Alerts are often time-sensitive. Make sure the @timestamp field in your sample data falls within the range of the query in your rule. If your rule looks at data from a specific time range, ensure that your sample data aligns with this range.

Verbose Mode:

If the alerts aren't triggering, run ElastAlert in verbose mode to get more detailed output**.** So that can see what going wrong. In case my case i created one index with filebeat and testing alert with heartbeat and this issue able to found because of verbose flag.

elastalert-test-rule examples/rules/example_error.yaml --alert --verbose

Error Resolution:

Common errors like index_not_found_exception can be resolved by creating the index first or ensuring the correct configuration file paths.

Conclusion

By following these steps, you can effectively test ElastAlert locally using LocalStack and simulate web hook alerts. This setup is ideal for development and testing environments where you can validate your alerting rules before deploying them to production.

Happy testing! 🚀

I hope this blog helps you learn. Feel free to reach out to me on my Twitter handle @AvinashDalvi_ leave a comment on the blog.

References:

• ElastAlert Documentation

• LocalStack Documentation

• https://docs.localstack.cloud/user-guide/aws/elasticsearch/

• https://hub.docker.com/r/localstack/localstack#installing

• https://docs.aws.amazon.com/cli/latest/reference/es/describe-elasticsearch-domain.html