Forem: Avinash Dalvi

MyRedBuddy: Helping Redditors Contribute Without the Fear of Bans

Avinash Dalvi — Fri, 27 Feb 2026 10:00:31 +0000

This is a submission for the DEV Weekend Challenge: Community

The Community

I built MyRedBuddy for the Reddit Community, specifically for new contributors, researchers, and indie hackers.

Reddit is an incredible place for knowledge, but for many, it can be intimidating. High entry barriers like "karma requirements" and strict, often invisible subreddit rules lead to many genuine users getting their posts removed or their accounts banned. I wanted to build a tool that acts as a "buddy" to help users understand how to contribute value without breaking community norms.

What I Built

MyRedBuddy is an open-source companion tool designed to help users contribute to Reddit more effectively.

Key features include:

Subreddit Insights: Analyzes subreddit rules and posting patterns to give users a "safety check" before they post.
Draft Management: A clean interface to prepare and refine contributions.
Ban Prevention: Guidance on community-specific etiquette to ensure your voice is heard rather than moderated.
Engagement Tracking: Helping users see where their contributions are making the most impact.

Demo

Check out the Live Demo here

Code

AvinashDalvi89 / myredbuddy-tool

Analyze your Reddit engagement and get AI-powered validator to write better posts and comments.

MyRedBuddy

Post with confidence. Get engagement, not banned.

MyRedBuddy is an action-oriented Reddit engagement tool that protects genuine users from bans, downvotes, and karma loss while helping them grow authentically.

Why MyRedBuddy?

Reddit is unforgiving. One wrong post can destroy your karma, get you shadowbanned, or kill your reputation in a community you care about. MyRedBuddy gives you a safety net:

No account required to start - Use Community Guide, Pre-Post Checker, and Reputation Shield with zero Reddit history
Pre-post protection - Check content BEFORE you post, not after
Learn from YOUR data - See what works for YOU specifically
Action-oriented - Every insight has an immediate action button
100% local - Your data never leaves your machine
Subreddit-specific - Each community is different

Features

Feature	What It Does	Needs Account?
Community Guide	Culture briefing for any subreddit — vibe, unwritten rules, what gets removed	No
Pre-Post Checker	Validate a

…

View on GitHub

How I Built It

As a Product Engineer, I focused on building something functional and user-centric over this weekend:

Framework: Next.js for a fast, SEO-friendly terminal-style interface.
Reddit Integration: Leveraging the Reddit API to fetch real-time community guidelines and activity.
AI Assistance: Used AI to help analyze complex subreddit wikis and summarize them into actionable "Dos and Don'ts."
Styling: Tailwind CSS for a clean, minimalist "developer-first

How I Replaced Prerender.io with My Own Serverless Renderer on AWS — For $0/Month

Avinash Dalvi — Fri, 27 Feb 2026 06:01:09 +0000

The Problem That Started It All

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 Lambda@EDGE

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)

Service	Pricing
Lambda invocations	First 1M/month free, then $0.20/1M
Lambda compute	First 400,000 GB-s/month free, then $0.0000167/GB-s
Lambda memory	2048MB = 2GB
Cache miss compute	2GB × 8s = 16 GB-s per render
Cache hit compute	2GB × 0.5s = 1 GB-s per request
API Gateway HTTP API	$1.00 per million requests
S3 GET	$0.00043 per 1,000 requests
S3 PUT	$0.0054 per 1,000 requests
Data transfer out	First 100GB/month free

Cost Comparison at Scale

Bot Requests/mo	Renders (cache miss)	Cache Hits	Lambda Compute	API Gateway	Our Cost	prerender.io $49
~100 (today)	~20	~80	400 GB-s ✓ free	$0.00	$0	$49
1,000	~200	~800	4,000 GB-s ✓ free	$0.001	~$0	$49
10,000	~1,000	~9,000	25,000 GB-s ✓ free	$0.01	~$0.01	$49
100,000	~3,000	~97,000	145,000 GB-s ✓ free	$0.10	~$0.10	$49
1,000,000	~7,230	~992,770	1.1M GB-s → $11.81	$1.00	~$13	$199+
5,000,000	~7,230	~4,992,770	5.1M GB-s → $78	$5.00	~$99	Enterprise

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 million.

My First AWS re:Invent Experience

Avinash Dalvi — Mon, 29 Dec 2025 11:08:00 +0000

Ten years.

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.

How I Fixed SEO for Our Angular SPA Using AWS Amplify + Prerender.io

Avinash Dalvi — Sat, 29 Nov 2025 13:58:03 +0000

I still remember the excitement of October 22nd, 2025. After months of development and anticipation, Nushift Connect was finally going live. Built with Angular and hosted on AWS Amplify, everything we'd worked so hard on was about to be in the hands of real users. The deployment was smooth. The app was working beautifully. Then I decided to share one of our articles on LinkedIn to celebrate the launch.

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:

Detect social media bots at the CloudFront level
Route bot traffic through Prerender.io
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:

viewer-request: Detect bots and add special headers
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

Don't abandon a great platform for one missing feature. Amplify is excellent—we just needed to extend it.
Lambda@Edge is powerful but picky. CommonJS only, strict validation, slow deployments. Plan accordingly.
Two-stage processing is elegant. Using the same function for both viewer-request and origin-request is cleaner than complex routing logic.
Follow official patterns. Prerender.io's CloudFormation template saved me hours of trial and error. When stuck, check the docs.
Cache management is critical. Both CloudFront and Prerender.io cache aggressively. Know how to clear both.
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 :

The 9 AM Discovery That Saved Our Production: An ECS Fargate Circuit Breaker Story

Avinash Dalvi — Thu, 18 Sep 2025 05:35:43 +0000

Hello Devs,

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:

Task Launch: ECS Fargate would start a new task
Health Check Failure: ALB couldn't reach the app on port 5001
Task Termination: ECS marked the task as unhealthy and terminated it
Replacement Attempt: ECS immediately launched a new Fargate task to maintain desired count
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

Scenario	Desired Count	Task Def Changed	Rollback Triggered	Rollback Time
Broken image pushed with `latest` only	1	❌ No	❌ No	❌ Never
Broken task def v3 (flask-app:v2)	1	✅ Yes	✅ Yes	⏱ ~10–20 min
Same failure with `desiredCount=5`	5	✅ Yes	✅ Yes	⏱ ~3–5 min

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:

Deployment Start: Mismatched port in new task definition
Monitoring Begins: ECS tracks task health and startup patterns
Failure Detected: Multiple ECS task failures trigger threshold
Automatic Rollback: ECS reverts to previous task definition
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

Problem	Recommendation
ECS didn’t rollback on broken image	Always register a new task definition
ECS used broken `latest` tag silently	Avoid `latest`, use immutable image tags
Slow rollback when desired count = 1	Use higher `desiredCount` during deploys
No alert when tasks failed	Add CloudWatch alarms for task health and service events
Deployment skipped task def update	Enforce task def registration in pipeline

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:

AWS Kiro IDE: Not Just Another AI Toy for Developers

Avinash Dalvi — Tue, 15 Jul 2025 04:40:56 +0000

Hello Devs,

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)

Migrating from EC2 to Containers: What Teams Miss

Avinash Dalvi — Thu, 10 Jul 2025 16:28:44 +0000

Hello Devs,

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:

ECS with EC2: More control, Spot instances, Graviton savings (but more operational overhead)
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
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:

Metric	Before (EC2)	After (Fargate)	Change
Environment setup time	4-6 hours	10 minutes	-95%
Deployment time	15 minutes	3 minutes	-80%
Deployment failures	1 in 5	1 in 50	-90%
"Works on my machine" incidents	3-4/month	0	-100%

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)

Start monolithic in containers (easier migration)
Monitor and measure actual bottlenecks
Split services when you have clear scaling needs AND team bandwidth
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.

Audit your current EC2 usage (AWS Cost Explorer is your friend)
Identify your biggest pain points (deployment time? scaling? costs?)

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"

Start with one service (pick the most isolated one)
Measure everything (before and after metrics)
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.

The Angular Error That Kept Scratching My Head: NG02100

Avinash Dalvi — Fri, 27 Jun 2025 01:12:29 +0000

Hello Devs,

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:

NG02100 is a template binding failure, not a logic error.
Pipes like date, currency, or async are easy to break if the data isn’t shaped exactly as expected.
When errors seem random in a loop (*ngFor), it’s usually one bad record in the list.
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.

Why your ECS tasks aren’t scaling

Avinash Dalvi — Sun, 15 Jun 2025 14:59:18 +0000

We had auto scaling set. Alarms configured. Metrics wired. And yet—502s.

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 behavior

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:

Total Needed Capacity:

* 2 vCPU (0.5 x 4)

* 4 GB RAM (1 x 4)

Per Instance Capacity:

* 2 vCPU and 4 GB RAM per `t4g.medium`

Divide & Ceil:

* CPU: 2 / 2 = 1

* Memory: 4 / 4 = 1

* Take the **max of the two** = 1

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)

Condition	Outcome
No pending tasks, all EC2s used	M = N
Pending tasks present	M > N (scale out)
Idle EC2s (only daemon tasks)	M < N (scale in)

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

Behind the Scenes of AWS Community Days Bengaluru 2025

Avinash Dalvi — Fri, 30 May 2025 02:01:49 +0000

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.

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

The Angular Standalone Component Gotcha I Didn’t See Coming

Avinash Dalvi — Mon, 28 Apr 2025 11:34:39 +0000

Hello Devs,

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.

Amazon Q Developer CLI Helped Me Clone EC2 in One Prompt - No Console, No YAML

Avinash Dalvi — Wed, 16 Apr 2025 03:00:43 +0000

Hello Devs,

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:

Open AWS Console
Go to EC2
Find the instance
Create an AMI
Wait for the AMI to become available
Launch a new instance from it
Manually select the same instance type, security groups, IAM role...
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

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).
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

Terminal.app
iTerm2
Hyper
VS Code Terminal

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

Login to AWS from the app

You’ll be prompted to authenticate with your AWS account.
Enable Terminal Integration

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

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.

Forem: Avinash Dalvi

MyRedBuddy: Helping Redditors Contribute Without the Fear of Bans

The Community

What I Built

Demo

Code

AvinashDalvi89 / myredbuddy-tool

Analyze your Reddit engagement and get AI-powered validator to write better posts and comments.

MyRedBuddy

Why MyRedBuddy?

Features

How I Built It

How I Replaced Prerender.io with My Own Serverless Renderer on AWS — For $0/Month

The Problem That Started It All

Understanding the Existing Setup

Designing the Replacement

Why Puppeteer + networkidle0?

Why S3 for Caching?

This is how architecture look like.

The Code

Lambda@Edge — socialbots function

Renderer Lambda — index.js

Dockerfile

package.json

Problems We Hit Along the Way

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

Problem 2: The Host Header

Scale Analysis and Cost Comparison

Renders vs Requests — The Critical Distinction

Our cache is bounded by content, not traffic

AWS Pricing Used (ap-south-1)

Cost Comparison at Scale

In INR (₹83 = $1 approx)

When Does prerender.io Win?

Future Optimization: CloudFront-Level Caching

Trade-offs and Honest Assessment

Advantages

Honest Limitations

Final Results

My First AWS re:Invent Experience

The Call That Changed Everything

When Your Mind Finally Lands

Meeting the People Who Build the Things I Build On

The Sessions That Stayed With Me

From Slack Avatars to Real Conversations

The Startup Conversation I Needed

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

Two Experiences I Never Planned For

A Nomination That Meant More Than Winning

What This Trip Really Taught Me

What Comes Next

How I Fixed SEO for Our Angular SPA Using AWS Amplify + Prerender.io

Understanding the Problem

The Research Rabbit Hole

Option 1: Move to a Different Platform

Option 2: Angular Universal (SSR)

Option 3: Prerendering Services

The Decision Framework: Why Prerender.io Made Sense

Understanding Our Traffic Pattern

Cost Analysis

The Math That Convinced Me

Lambda@Edge Cost Breakdown

The Reality Check

When NOT to Choose Prerender.io

The CloudFront Discovery

Attempt 1: CloudFront Functions (Days of Frustration)

Attempt 2: The 502 Bad Gateway Mystery

The Breakthrough: RTFM (Read The Fine Manual)

Why This Works (The Two-Stage Magic)

Configuring CloudFront

The Angular Side: Signaling Readiness

Testing and Debugging

The Waiting Game

Key Lessons Learned

Final Thoughts

References :

The 9 AM Discovery That Saved Our Production: An ECS Fargate Circuit Breaker Story

The Setup

The Innocent Change

The 9 AM Discovery

Why Puppeteer + `networkidle0`?

Lambda@Edge — `socialbots` function

Renderer Lambda — `index.js`

`package.json`

1. Avoid using `latest` tag in ECS task definitions

5. Use higher `desiredCount` during deployments for faster rollback