Forem: Esin Saribudak

Build your own daily notification bot on AWS Free Tier

Esin Saribudak — Fri, 08 May 2026 02:04:13 +0000

A Lambda function checks the forecast, Bedrock tells you what to wear, and ntfy.sh pushes it to your phone before you get ready for the day, and it's all Free Tier eligible.

Last updated: May 7, 2026

Every morning before work, you open your weather app. It takes a few seconds to refresh. Then you scroll past the hourly breakdown, the radar map, the air quality index, the pollen count. All you need to know is: what's the high, what's the low, is it going to rain, and what should you wear?

If you're leaving your home for the office every day like I am, this time spent scrolling and thinking every morning adds up. Especially where I live, where it might be 55°F when I leave the house and 88°F by lunch. You need a jacket at 7 AM and regret wearing it by noon. The weather app gives you all the data but none of the interpretation.

This tutorial walks you through building a service that sends you a push notification every morning with the forecast and a clothing recommendation. You deploy it once, and it runs on a schedule. Instead of opening an app and parsing data yourself, the notification just shows up with what you need. It looks like this on your phone:

Austin, TX — Tuesday, May 6
Today: 88°F, Partly Sunny
Tonight: 73°F, Mostly Cloudy
Wind: 10 mph S | Rain: 20%

Light layers today. Short sleeves with a light
jacket for the morning, ditch it by lunch.
No umbrella needed.

Along the way, you'll wire together EventBridge, Lambda, and Bedrock into an app that streamlines a daily task. By the end, you'll have a working notification on your phone and hands-on experience with the same infrastructure that powers production applications. All the AWS services it uses are eligible for the AWS Free Tier.

If you followed the blog post view counter tutorial, this is a good next project. Same tools, different services, and you end up with something you'll use every day. If you haven't built that one, that's fine too — the prerequisites section covers what you need.

What you're building

Here's the application flow:

EventBridge triggers a Lambda function every morning on a cron schedule
Lambda calls the National Weather Service API with your coordinates to get the local forecast
Lambda sends that weather data to Amazon Bedrock (Nova Lite) and asks for a clothing recommendation
Lambda formats the forecast + recommendation into a short message
Lambda sends the message as a push notification to your phone via ntfy.sh, an open source pub/sub service

Three AWS services, two free external APIs, about 230 lines of TypeScript.

Outside the US? The NWS API only covers US locations. If you're elsewhere, swap in Open-Meteo as a drop-in replacement. It's free for non-commercial use, requires no API key, and covers the entire world.

Prerequisites

An AWS account. If you don't have one yet, the Creating an AWS account guide walks you through it. You'll need a credit card on file, but this project stays within Free Tier limits.
Node.js 24 or later
AWS CLI installed and configured
AWS CDK bootstrapped in your account. If you haven't used CDK before, it's an infrastructure-as-code tool. You write TypeScript that describes your AWS resources, and CDK turns it into CloudFormation and deploys it. The bootstrap command creates a staging bucket CDK needs to upload your code, and needs to be run the first time you use it.

npx cdk bootstrap aws://YOUR_ACCOUNT_ID/us-east-1

ntfy app installed on your phone. Download ntfy from the App Store or Google Play. Open it and add a topic name you'll remember (this acts as your private channel, so pick something not easily guessable, like weather-forecast-abc123).

What is ntfy.sh and why use it for notifications

ntfy.sh (pronounced "notify") is an open-source push notification service built on a simple pub/sub model. You subscribe to a topic in the app, and any HTTP POST to that topic's URL shows up as a push notification on your phone. No account required, no API key, no app store approval process.

Project setup

Create a new directory and initialize the project:

mkdir daily-notification-bot && cd daily-notification-bot
npm init -y
npm install aws-cdk-lib constructs @aws-sdk/client-bedrock-runtime
npm install -D aws-cdk tsx typescript @types/node

Create a cdk.json file in the project root:

{
  "app": "npx tsx cdk/app.ts"
}

And a tsconfig.json:

{
  "compilerOptions": {
    "target": "ES2022",
    "module": "NodeNext",
    "moduleResolution": "NodeNext",
    "lib": ["ES2022"],
    "outDir": "dist",
    "rootDir": ".",
    "strict": true,
    "types": ["node"],
    "esModuleInterop": true,
    "skipLibCheck": true,
    "declaration": true
  },
  "include": ["lambda/**/*", "cdk/**/*"]
}

Your project structure:

daily-notification-bot/
├── cdk/
│   ├── app.ts          # CDK entry point
│   └── stack.ts        # Infrastructure definition
├── lambda/
│   └── index.ts        # Lambda function code
├── cdk.json
├── package.json
└── tsconfig.json

Step 1: Define the infrastructure with CDK

Create cdk/stack.ts. This defines all the infrastructure:

import * as cdk from 'aws-cdk-lib';
import * as events from 'aws-cdk-lib/aws-events';
import * as targets from 'aws-cdk-lib/aws-events-targets';
import * as iam from 'aws-cdk-lib/aws-iam';
import { NodejsFunction } from 'aws-cdk-lib/aws-lambda-nodejs';
import { Runtime } from 'aws-cdk-lib/aws-lambda';
import * as path from 'path';
import { fileURLToPath } from 'url';
import { Construct } from 'constructs';

const __dirname = path.dirname(fileURLToPath(import.meta.url));

export class MorningForecastStack extends cdk.Stack {
  constructor(scope: Construct, id: string) {
    super(scope, id);

    // Configuration — pass these at deploy time:
    //   npx cdk deploy -c latitude=30.27 -c longitude=-97.74 -c ntfyTopic=my-secret-weather-topic
    const latitude = this.node.tryGetContext('latitude');
    const longitude = this.node.tryGetContext('longitude');
    const ntfyTopic = this.node.tryGetContext('ntfyTopic');

    if (!latitude || !longitude || !ntfyTopic) {
      throw new Error(
        'Missing required context. Deploy with: npx cdk deploy ' +
        '-c latitude=30.27 -c longitude=-97.74 -c ntfyTopic=my-secret-weather-topic'
      );
    }

    // Lambda function — fetches weather, calls Bedrock, sends notification via ntfy
    const fn = new NodejsFunction(this, 'ForecastFunction', {
      runtime: Runtime.NODEJS_24_X,
      entry: path.join(__dirname, '../lambda/index.ts'),
      handler: 'handler',
      environment: {
        LATITUDE: latitude,
        LONGITUDE: longitude,
        NTFY_TOPIC: ntfyTopic,
      },
      timeout: cdk.Duration.seconds(30),
      memorySize: 256,
    });

    // Grant Lambda permission to invoke Bedrock
    fn.addToRolePolicy(new iam.PolicyStatement({
      actions: ['bedrock:InvokeModel'],
      resources: ['arn:aws:bedrock:*::foundation-model/amazon.nova-lite-v1:0'],
    }));

    // EventBridge rule — triggers every morning at 6:30 AM CT (11:30 UTC)
    // Adjust the cron to match your timezone and preferred time
    new events.Rule(this, 'MorningSchedule', {
      schedule: events.Schedule.cron({
        minute: '30',
        hour: '11',    // 11:30 UTC = 6:30 AM CT
        weekDay: 'MON-FRI',
      }),
      targets: [new targets.LambdaFunction(fn)],
    });

    // Output the function name for manual testing
    new cdk.CfnOutput(this, 'FunctionName', {
      value: fn.functionName,
      description: 'Lambda function name (for manual invocation)',
    });
  }
}

How to schedule a Lambda function with EventBridge

The EventBridge rule above is what makes this run every morning. A few things to notice:

Configuration via context. Your coordinates and ntfy topic are passed at deploy time with -c flags. This keeps configuration out of your source code and makes the project easy to share. To find your coordinates, right-click any location in Google Maps and the lat/long will appear at the top of the context menu.
Notifications go through ntfy.sh, which is just an HTTP POST from Lambda. There are no AWS messaging services to configure, no phone number verification steps, and no sandbox restrictions to deal with.
Weekdays only. The cron schedule runs Monday through Friday. If you want weekends too, change weekDay: 'MON-FRI' to remove that constraint, or set it to '*'.
UTC time. EventBridge cron expressions use UTC. Central Time is UTC-5 (or UTC-6 during standard time), so 6:30 AM CT is 11:30 UTC during CDT. You'll need to adjust this for your timezone.
30-second timeout. The Lambda makes three external calls (NWS points, NWS forecast, and Bedrock), so we give it more time than the default 3 seconds. In practice it finishes in 2-4 seconds.

Now create the entry point at cdk/app.ts:

#!/usr/bin/env node
import * as cdk from 'aws-cdk-lib';
import { MorningForecastStack } from './stack.js';

const app = new cdk.App();
new MorningForecastStack(app, 'MorningForecastNotificationApp');

Step 2: Fetch the forecast and generate a notification

Create lambda/index.ts. This is the code that runs every morning:

import { BedrockRuntimeClient, InvokeModelCommand } from '@aws-sdk/client-bedrock-runtime';

const bedrock = new BedrockRuntimeClient({});

const LATITUDE = process.env.LATITUDE!;
const LONGITUDE = process.env.LONGITUDE!;
const NTFY_TOPIC = process.env.NTFY_TOPIC!;

const NWS_USER_AGENT = 'daily-notification-bot (github.com/your-repo)';

// Type definitions
interface NwsPoint {
  forecastUrl: string;
  city: string;
  state: string;
}

interface ForecastPeriod {
  name: string;
  temperature: number;
  temperatureUnit: string;
  windSpeed: string;
  windDirection: string;
  shortForecast: string;
  probabilityOfPrecipitation: number;
  isDaytime: boolean;
}

interface WeatherData {
  city: string;
  state: string;
  daytime: ForecastPeriod;
  nighttime: ForecastPeriod;
}

// Step 1: Get the NWS grid point for our coordinates
async function getNwsPoint(): Promise<NwsPoint> {
  const url = `https://api.weather.gov/points/${LATITUDE},${LONGITUDE}`;
  const response = await fetch(url, {
    headers: { 'User-Agent': NWS_USER_AGENT },
  });

  if (!response.ok) {
    throw new Error(`NWS points API error: ${response.status}`);
  }

  const data: any = await response.json();
  return {
    forecastUrl: data.properties.forecast,
    city: data.properties.relativeLocation.properties.city,
    state: data.properties.relativeLocation.properties.state,
  };
}

// Step 2: Get the forecast from the NWS grid point
async function getForecast(point: NwsPoint): Promise<WeatherData> {
  const response = await fetch(point.forecastUrl, {
    headers: { 'User-Agent': NWS_USER_AGENT },
  });

  if (!response.ok) {
    throw new Error(`NWS forecast API error: ${response.status}`);
  }

  const data: any = await response.json();
  const periods = data.properties.periods;

  const daytime = periods.find((p: any) => p.isDaytime);
  const nighttime = periods.find((p: any) => !p.isDaytime);

  const toPeriod = (p: any): ForecastPeriod => ({
    name: p.name,
    temperature: p.temperature,
    temperatureUnit: p.temperatureUnit,
    windSpeed: p.windSpeed,
    windDirection: p.windDirection,
    shortForecast: p.shortForecast,
    probabilityOfPrecipitation: p.probabilityOfPrecipitation?.value ?? 0,
    isDaytime: p.isDaytime,
  });

  return {
    city: point.city,
    state: point.state,
    daytime: toPeriod(daytime),
    nighttime: toPeriod(nighttime),
  };
}

// Step 3: Ask Bedrock for a clothing recommendation
async function getClothingAdvice(weather: WeatherData): Promise<string> {
  const prompt = `Today's forecast for ${weather.city}, ${weather.state}:
- Daytime (${weather.daytime.name}): ${weather.daytime.temperature}°${weather.daytime.temperatureUnit}, ${weather.daytime.shortForecast}
- Wind: ${weather.daytime.windSpeed} ${weather.daytime.windDirection}
- Rain chance: ${weather.daytime.probabilityOfPrecipitation}%
- Tonight: ${weather.nighttime.temperature}°${weather.nighttime.temperatureUnit}, ${weather.nighttime.shortForecast}

What should I wear today? Give me a practical recommendation in one to two sentences. Be direct and specific. No preamble.`;

  const body = JSON.stringify({
    messages: [
      {
        role: 'user',
        content: [{ text: prompt }],
      },
    ],
    inferenceConfig: {
      maxTokens: 80,
    },
  });

  const command = new InvokeModelCommand({
    modelId: 'amazon.nova-lite-v1:0',
    contentType: 'application/json',
    accept: 'application/json',
    body: new TextEncoder().encode(body),
  });

  const response = await bedrock.send(command);
  const result = JSON.parse(new TextDecoder().decode(response.body));
  return result.output.message.content[0].text;
}

// Step 4: Format the notification message
function formatMessage(weather: WeatherData, advice: string): string {
  const today = new Date().toLocaleDateString('en-US', {
    weekday: 'long',
    month: 'short',
    day: 'numeric',
    timeZone: 'America/Chicago', // Adjust to your timezone
  });

  return [
    `${weather.city}, ${weather.state} — ${today}`,
    `${weather.daytime.name}: ${weather.daytime.temperature}°${weather.daytime.temperatureUnit}, ${weather.daytime.shortForecast}`,
    `Tonight: ${weather.nighttime.temperature}°${weather.nighttime.temperatureUnit}, ${weather.nighttime.shortForecast}`,
    `Wind: ${weather.daytime.windSpeed} ${weather.daytime.windDirection} | Rain: ${weather.daytime.probabilityOfPrecipitation}%`,
    '',
    advice,
  ].join('\n');
}

// Step 5: Send push notification via ntfy.sh
async function sendNotification(message: string): Promise<void> {
  const response = await fetch(`https://ntfy.sh/${NTFY_TOPIC}`, {
    method: 'POST',
    headers: {
      'Title': 'Morning Forecast',
    },
    body: message,
  });

  if (!response.ok) {
    throw new Error(`ntfy.sh error: ${response.status}`);
  }
}

// Main handler — EventBridge triggers this every morning
export const handler = async (): Promise<void> => {
  const point = await getNwsPoint();
  const weather = await getForecast(point);
  const advice = await getClothingAdvice(weather);
  const message = formatMessage(weather, advice);

  await sendNotification(message);

  console.log('Forecast sent:', message);
};

The function does four things in sequence:

Calling the NWS weather API from Lambda

The NWS API works in two steps. First you send your coordinates to /points/{lat},{lon}, which returns metadata about your location including the forecast URL and your city/state name. The NWS requires a User-Agent header for identification, but no API key.

The second call hits the forecast URL from step one. It returns forecast periods (today, tonight, tomorrow, etc.) with temperature, wind, precipitation probability, and a plain-English summary like "Partly Cloudy" or "Chance Showers."

Using Bedrock to generate clothing advice

We send the weather data to Amazon Nova Lite with a prompt that asks for practical clothing advice. The maxTokens: 80 keeps the response tight — one to two sentences, no filler. Nova Lite is Amazon's cheapest model and responds in under a second.

Sending push notifications with ntfy.sh

The city name, forecast summary, and clothing advice get combined into a notification message and sent to ntfy.sh with a single HTTP POST. The ntfy app on your phone picks it up instantly.

Step 3: Deploy and test your notification

Deploy with your coordinates and ntfy topic:

npx cdk deploy \
  -c latitude=YOUR_LATITUDE \
  -c longitude=YOUR_LONGITUDE \
  -c ntfyTopic=YOUR_NTFY_TOPIC

Replace the values with your own:

Latitude and longitude of your location. Right-click any spot in Google Maps and the coordinates appear at the top of the menu. For example, Austin, TX is 30.27,-97.74.
ntfy topic — the same topic name you subscribed to in the ntfy app. This is like a private channel, so pick something not easily guessable.

CDK will show you the resources it's creating and ask for confirmation. Type y.

CDK asks because the stack creates IAM permissions (Lambda's execution role, Bedrock invoke access). This is standard for any stack that includes a Lambda function. Review the permissions if you want, then approve.

After about two minutes, you'll see output like this:

✅  MorningForecastNotificationApp

✨  Deployment time: 107.44s

Outputs:
MorningForecastNotificationApp.FunctionName = MorningForecastNotificationApp-ForecastFunctionBE622553-a1B2c3D4e5Fg

Stack ARN:
arn:aws:cloudformation:us-east-1:123456789012:stack/MorningForecastNotificationApp/67f1ff60-1234-5678-abcd-0affd8af3937

✨  Total time: 110s

Don't wait until tomorrow morning to test it. Invoke the function manually using the function name from the deploy output:

aws lambda invoke \
  --function-name MorningForecastNotificationApp-ForecastFunctionBE622553-a1B2c3D4e5Fg \
  --payload '{}' \
  output.json

Check your phone. You should have a push notification from the ntfy app with today's forecast and a clothing recommendation. 😎

Step 4: Customize the schedule, location, and AI prompt

Change your location

Update the coordinates in your deploy command. Right-click any location in Google Maps to get the
lat/long:

npx cdk deploy \
  -c latitude=YOUR_LATITUDE \
  -c longitude=YOUR_LONGITUDE \
  -c ntfyTopic=YOUR_NTFY_TOPIC

How to change the EventBridge cron schedule

The cron expression in stack.ts controls when you get your notification. A few examples:

// Every day at 7:00 AM ET (12:00 UTC during EDT)
schedule: events.Schedule.cron({ minute: '0', hour: '12' })

// Weekdays at 6:00 AM CT (11:00 UTC during CDT)
schedule: events.Schedule.cron({ minute: '0', hour: '11', weekDay: 'MON-FRI' })

// Every day at 6:30 AM PT (13:30 UTC during PDT)
schedule: events.Schedule.cron({ minute: '30', hour: '13' })

Remember: EventBridge uses UTC. Convert your local time accordingly.

Tweak the AI prompt

The Bedrock prompt in getClothingAdvice() is where you make this yours. The default asks for one to two direct sentences. Some ways to customize:

// If you bike to work:
"Assume I'm biking 3 miles to the office."

// If you run hot:
"I tend to run warm, so err on the side of lighter clothing."

// If you want outfit specifics:
"Suggest specific items: jacket type, shirt type, pants vs shorts, shoe type."

// If you want even less:
"Answer in one sentence only."

The prompt is just a string. Change it, redeploy, and your morning notification changes with it.

How the full flow works

Now that you've seen all the code, here's the complete flow, complete with approximate timestamps:

6:30 AM — EventBridge fires a scheduled event
6:30:01 — Lambda calls the NWS API with your coordinates, gets the forecast
6:30:02 — Lambda sends the weather data to Bedrock, gets back clothing advice
6:30:03 — Lambda formats the message and POSTs it to ntfy.sh
6:30:04 — Your phone buzzes with a push notification

Total execution time: 2-4 seconds. Total cost: covered by Free Tier.

How much this costs on AWS Free Tier

This project uses services eligible for the AWS Free Tier. Here's what each one costs:

Service	Free Tier allowance	Your usage
EventBridge	14M scheduled invocations/month	~30/month
Lambda	1M requests/month, 400K GB-seconds	~30 invocations/month
Bedrock (Nova Lite)	Free Tier credits	~$0.001/month
ntfy.sh	Free (open source)	~30 notifications/month
NWS API	Free (US government data)	~60 calls/month

EventBridge — 14 million scheduled invocations per month free. You're using around 30.

Lambda — You'll probably use around 30 invocations per month, each running for 2-4 seconds at 256 MB. That's well under the 1 million requests and 400,000 GB-seconds you get free.

Bedrock — Nova Lite costs fractions of a cent per invocation at this token volume. At 30 calls per month, it comes out of your Free Tier credits.

ntfy.sh — free, and doesn't require an account or API key for personal use.

NWS API — free US government public data, no key required.

I'd still recommend setting up a billing alarm at $5 as a safety net.

What you just learned

If you followed along, you now have hands-on experience with:

EventBridge: cron scheduling in UTC, weekday-only rules
Lambda: calling external APIs, environment variables, working with the Bedrock SDK
Bedrock: invoking a foundation model, prompt design, controlling output length
CDK: defining infrastructure in TypeScript, passing configuration via context, deploying with a single command
NWS API: the two-step points → forecast pattern for US weather data
ntfy.sh: push notifications via a simple HTTP POST

And you have something running that you'll actually use every morning.

A note on security

This project has a small attack surface. The Lambda has no public URL and can only be triggered by EventBridge within your account. There's no user input, no stored data, and the IAM permissions are scoped to a single Bedrock model.

The one thing to be aware of: your ntfy topic name is the only access control on your notifications. Anyone who knows the topic name can subscribe and read your messages. Since the content is just weather data, the risk is low, but pick a topic name that isn't easily guessable. If you want tighter control, ntfy supports token-based auth on their paid plan, or you can self-host.

Cleanup

If you want to tear everything down:

npx cdk destroy \
  -c latitude=YOUR_LATITUDE \
  -c longitude=YOUR_LONGITUDE \
  -c ntfyTopic=YOUR_NTFY_TOPIC

This deletes the Lambda, the EventBridge rule, and the IAM role. Your morning notifications will stop. Unsubscribe from the topic in the ntfy app if you want to clean that up too.

What to try next

Add a weekend mode with a later send time and more casual tone
Send a mid-day alert if rain probability spikes above 70%
Share the topic with your household so everyone gets the notification
Add a weekly summary on Sunday evenings for the week ahead
Swap the NWS API for Open-Meteo if you're outside the US (free for non-commercial use, covers the entire world)
Replace the weather API with something else you care about: stock prices, package tracking, your team's on-call schedule, a daily quote. The architecture will likely be similar regardless of what data you're fetching.

If you built the blog post view counter, you now have two working projects on AWS Free Tier: one that reacts to events (page views) and one that runs on a schedule (morning forecast). Between the two, you've used Lambda, DynamoDB, API Gateway, EventBridge, and Bedrock.

The source code for this project is on GitHub if you want to fork it and make it your own.

Build your own blog post view counter on AWS Free Tier

Esin Saribudak — Tue, 21 Apr 2026 19:35:19 +0000

Your blog deserves to know it's being read. A Lambda function counts the views, DynamoDB remembers them, and it's all eligible for the Free Tier.

Last updated: April 20, 2026

Most analytics tools require an account, a script tag, and a separate dashboard you have to check outside your infrastructure. If you're already on AWS, you can build a view counter that lives in your own account and stores data in a table you control. It takes about an hour, and all three services it uses are eligible for the AWS Free Tier.

This tutorial walks you through building that counter. You add one <script> tag to your blog, and every time someone reads a post, the count goes up in a DynamoDB table you own.

Along the way, you'll wire together Lambda, DynamoDB, and API Gateway into something that goes beyond "Hello World." By the end, you'll have working software on your blog and hands-on experience with the same services that power production applications.

If you've already set up your AWS account and deployed something to the cloud before, this is a good next project. If you haven't, start with a free AWS account and come back.

What you're building

Here's the application flow:

A visitor loads your blog post in a browser
A small script on your page sends a request to API Gateway
API Gateway invokes a Lambda function
Lambda checks DynamoDB to see if this visitor has already been counted today
If they're new, it increments the counter
API Gateway returns a 204 response to the client

Two serverless services for compute and storage, one API layer in front, about 100 lines of TypeScript.

The counter deduplicates by IP address (hashed, so you're not storing raw IPs) and auto-cleans old records with DynamoDB's TTL feature. You add it to your blog with a single <script> tag, and it automatically tracks every page.

Prerequisites

An AWS account. If you don't have one yet, the Creating an AWS account guide walks you through it. You'll need a credit card on file, but this project stays within Free Tier limits.
Node.js 24 or later
AWS CLI installed and configured. Follow the AWS CLI quickstart if this is your first time.
AWS CDK bootstrapped in your account:

npx cdk bootstrap aws://YOUR_ACCOUNT_ID/us-east-1

If you haven't used CDK before, it's an AWS infrastructure-as-code tool. You write TypeScript that describes your AWS resources, and CDK turns it into CloudFormation and deploys it. The bootstrap command creates a staging bucket CDK needs to upload your code. The CDK getting started guide has more information if you want it.

Project setup

Create a new directory and initialize the project:

mkdir blog-post-view-counter && cd blog-post-view-counter
npm init -y
npm install aws-cdk-lib constructs @aws-sdk/client-dynamodb @aws-sdk/lib-dynamodb
npm install -D aws-cdk tsx typescript @types/node

Create a cdk.json file in the project root. This tells CDK how to run your app:

{
  "app": "npx tsx cdk/app.ts"
}

And a tsconfig.json:

{
  "compilerOptions": {
    "target": "ES2022",
    "module": "NodeNext",
    "moduleResolution": "NodeNext",
    "lib": ["ES2022"],
    "outDir": "dist",
    "rootDir": ".",
    "strict": true,
    "types": ["node"],
    "esModuleInterop": true,
    "skipLibCheck": true,
    "declaration": true
  },
  "include": ["lambda/**/*", "cdk/**/*"]
}

Your project structure will look like this:

blog-post-view-counter/
├── cdk/
│   ├── app.ts          # CDK entry point
│   └── stack.ts        # Infrastructure definition
├── lambda/
│   └── index.ts        # Lambda function code
├── cdk.json
├── package.json
└── tsconfig.json

Step 1: The DynamoDB table

DynamoDB is a key-value database. You give it a key, it gives you back the data. No servers to manage, no connection strings to configure.

Our table stores two kinds of records using a composite key (pk + sk):

Counter records track views per page:

pk	sk	views
`/blog/my-first-post`	`counter`	42
`/about`	`counter`	17

Dedup records prevent the same person from being counted twice:

pk	sk	ttl
`/blog/my-first-post#a1b2c3d4...`	`dedup`	1745208000

The dedup key combines the page path with a hash of the visitor's IP. The ttl field is a Unix timestamp 24 hours in the future. DynamoDB automatically deletes expired records, so the same visitor gets counted again the next day.

Think of it like a filing cabinet. Each drawer is labeled with a page path. Inside, there's a counter folder with the view count, and temporary visitor sign-in sheets that get shredded after 24 hours.

Step 2: The Lambda function

Create lambda/index.ts. This is the code that runs every time someone visits your blog:

import { createHash } from 'node:crypto';
import { DynamoDBClient } from '@aws-sdk/client-dynamodb';
import { DynamoDBDocumentClient, GetCommand, PutCommand, UpdateCommand } from '@aws-sdk/lib-dynamodb';

// DynamoDB document client — lets us read/write JS objects instead of raw DynamoDB types
const client = DynamoDBDocumentClient.from(new DynamoDBClient({}));
const TABLE_NAME = process.env.TABLE_NAME!;
const DEDUP_HOURS = 24;

// These come from environment variables set in the CDK stack
const ALLOWED_ORIGIN = process.env.ALLOWED_ORIGIN || '*';
const ALLOWED_HOSTNAME = ALLOWED_ORIGIN !== '*' ? new URL(ALLOWED_ORIGIN).hostname : null;

// CORS headers — browsers require these when your blog (yourdomain.com)
// makes a fetch() to a different domain (your API Gateway URL)
const CORS_HEADERS = {
  'Access-Control-Allow-Origin': ALLOWED_ORIGIN,
  'Access-Control-Allow-Methods': 'GET,OPTIONS',
  'Access-Control-Allow-Headers': 'Content-Type',
};

// Only allow typical blog URL paths — letters, numbers, hyphens, slashes, dots
const VALID_PATH = /^\/[\w\-./]{0,199}$/;

// Hash an IP so we never store raw addresses in DynamoDB (GDPR-friendly)
function hashIp(ip: string): string {
  return createHash('sha256').update(ip).digest('hex').slice(0, 16);
}

export const handler = async (event: any) => {
  // Handle CORS preflight — browsers send this before the real request
  if (event.httpMethod === 'OPTIONS') {
    return { statusCode: 204, headers: CORS_HEADERS, body: '' };
  }

  const page = event.queryStringParameters?.page || '/';

  // Reject paths that don't look like blog URLs
  if (!VALID_PATH.test(page)) {
    return { statusCode: 400, headers: CORS_HEADERS, body: '' };
  }

  // If a Referer header exists, make sure it's from your site
  if (ALLOWED_HOSTNAME) {
    const referer = event.headers?.referer || event.headers?.Referer || '';
    if (referer && !referer.includes(ALLOWED_HOSTNAME)) {
      return { statusCode: 403, headers: CORS_HEADERS, body: '' };
    }
  }

  // Combine page path + hashed IP to create a unique dedup key
  const ip = event.requestContext?.identity?.sourceIp || 'unknown';
  const dedupKey = `${page}#${hashIp(ip)}`;
  const now = Math.floor(Date.now() / 1000);
  const ttl = now + DEDUP_HOURS * 3600; // DynamoDB TTL auto-deletes after 24h

  // Check if this visitor was already counted for this page today
  let isNewView = true;
  try {
    const existing = await client.send(new GetCommand({
      TableName: TABLE_NAME,
      Key: { pk: dedupKey, sk: 'dedup' },
    }));
    if (existing.Item) isNewView = false;
  } catch {
    // If lookup fails, count it as a new view
  }

  if (isNewView) {
    // Write a dedup record so this IP won't be counted again for 24h
    await client.send(new PutCommand({
      TableName: TABLE_NAME,
      Item: { pk: dedupKey, sk: 'dedup', ttl },
    }));

    // Increment the page's view counter (ADD creates the item if it doesn't exist)
    await client.send(new UpdateCommand({
      TableName: TABLE_NAME,
      Key: { pk: page, sk: 'counter' },
      UpdateExpression: 'ADD #v :inc',
      ExpressionAttributeNames: { '#v': 'views' },
      ExpressionAttributeValues: { ':inc': 1 },
    }));
  }

  // 204 No Content — the browser doesn't need a response body
  return { statusCode: 204, headers: CORS_HEADERS, body: '' };
};

The code comments cover the details, but here's the high-level flow: the function validates the incoming page path, checks the Referer header, then hashes the visitor's IP with SHA-256 so no raw addresses end up in your database. It looks up the hashed IP in DynamoDB to see if this visitor was already counted today. If not, it writes a dedup record (which DynamoDB auto-deletes after 24 hours via TTL) and atomically increments the page's view counter. The browser gets back a 204 No Content, meaning "got it, nothing to show you."

Step 3: The infrastructure

Create cdk/stack.ts. This defines all three AWS resources:

import * as cdk from 'aws-cdk-lib';
import * as dynamodb from 'aws-cdk-lib/aws-dynamodb';
import * as apigateway from 'aws-cdk-lib/aws-apigateway';
import { NodejsFunction } from 'aws-cdk-lib/aws-lambda-nodejs';
import { Runtime } from 'aws-cdk-lib/aws-lambda';
import * as path from 'path';
import { fileURLToPath } from 'url';
import { Construct } from 'constructs';

const __dirname = path.dirname(fileURLToPath(import.meta.url));

export class ViewCounterStack extends cdk.Stack {
  constructor(scope: Construct, id: string) {
    super(scope, id);

    // Read your blog's domain from the deploy command:
    //   npx cdk deploy -c blogOrigin=https://yourdomain.com
    const blogOrigin = this.node.tryGetContext('blogOrigin');
    if (!blogOrigin) {
      throw new Error('Missing required context: -c blogOrigin=https://yourdomain.com');
    }

    // DynamoDB table — stores page view counts and IP dedup records
    const table = new dynamodb.Table(this, 'ViewCounterTable', {
      partitionKey: { name: 'pk', type: dynamodb.AttributeType.STRING },
      sortKey: { name: 'sk', type: dynamodb.AttributeType.STRING },
      billingMode: dynamodb.BillingMode.PROVISIONED,
      readCapacity: 25,  // 25 RCU is within the always-free tier
      writeCapacity: 25, // 25 WCU is within the always-free tier
      timeToLiveAttribute: 'ttl', // Auto-delete dedup records after 24h
      removalPolicy: cdk.RemovalPolicy.DESTROY, // Clean up on `cdk destroy`
    });

    // Lambda function — NodejsFunction bundles TypeScript with esbuild automatically
    const fn = new NodejsFunction(this, 'CounterFunction', {
      runtime: Runtime.NODEJS_24_X,
      entry: path.join(__dirname, '../lambda/index.ts'),
      handler: 'handler',
      environment: {
        TABLE_NAME: table.tableName,
        ALLOWED_ORIGIN: blogOrigin, // Passed to Lambda for CORS and Referer checks
      },
      timeout: cdk.Duration.seconds(10),
      memorySize: 128,
    });

    // Give the Lambda read/write access to the DynamoDB table
    table.grantReadWriteData(fn);

    // API Gateway — public HTTPS endpoint that triggers the Lambda
    const api = new apigateway.RestApi(this, 'CounterApi', {
      restApiName: 'blog-post-view-counter',
      deployOptions: {
        throttlingRateLimit: 10,   // Max 10 requests/second sustained
        throttlingBurstLimit: 20,  // Allow short bursts up to 20/second
      },
    });

    const integration = new apigateway.LambdaIntegration(fn);

    // CORS — only allow requests from your blog domain
    const corsOptions: apigateway.CorsOptions = {
      allowOrigins: [blogOrigin],
      allowMethods: ['GET', 'OPTIONS'],
    };

    // GET /counter?page=/some-path — record a page view
    const counter = api.root.addResource('counter');
    counter.addMethod('GET', integration);
    counter.addCorsPreflight(corsOptions);

    // Print the tracking URL after deploy
    new cdk.CfnOutput(this, 'CounterUrl', {
      value: `${api.url}counter`,
      description: 'Tracking endpoint',
    });
  }
}

A few things to notice:

NodejsFunction instead of Function. You're writing TypeScript, but Lambda runs JavaScript. The regular lambda.Function construct would deploy your .ts files as-is, and Lambda wouldn't know what to do with them. NodejsFunction compiles your TypeScript to JavaScript with esbuild at deploy time. You write TypeScript, Lambda gets JavaScript, and you don't need a separate build step.
Provisioned capacity at 25/25. DynamoDB's always-free tier gives you 25 read capacity units and 25 write capacity units at no cost. That's 25 reads and 25 writes per second, which is way more than a personal blog needs. We're using provisioned mode instead of on-demand specifically to stay within this free allocation.
removalPolicy: DESTROY. By default, CDK protects your DynamoDB table from accidental deletion. Since this is a learning project, we set it to DESTROY so cdk destroy cleans everything up. For a production table, you'd leave the default.
Throttling. API Gateway is set to 10 requests per second with bursts up to 20. This caps how much traffic can hit your Lambda and DynamoDB, which limits your bill if someone discovers your endpoint and tries to hammer it.

Now create the CDK entry point at cdk/app.ts:

#!/usr/bin/env node
import * as cdk from 'aws-cdk-lib';
import { ViewCounterStack } from './stack.js';

const app = new cdk.App();
new ViewCounterStack(app, 'BlogPostViewCounterSampleForAws');

Step 4: Deploy

One command:

npx cdk deploy -c blogOrigin=https://yourdomain.com

Replace yourdomain.com with your actual blog domain. CDK will show you a summary of the resources it's about to create and ask for confirmation. Type y.

After about a minute, you'll see output that looks something like this:

Pay special attention to the Outputs section with the CounterUrl endpoint.

Outputs:
BlogPostViewCounterSampleForAws.CounterUrl = https://abc123.execute-api.us-east-1.amazonaws.com/prod/counter

That's your tracking endpoint. Save that URL.

Step 5: Add it to your blog

Add this script tag to your site's base layout. In Astro, that's your layout component. In Hugo, it's baseof.html. In plain HTML, put it before the closing </body> tag.

<script>
  fetch(`https://YOUR_COUNTER_URL?page=${encodeURIComponent(window.location.pathname)}`);
</script>

Replace YOUR_COUNTER_URL with the URL from the deploy output.

Here's what it looks like in an Astro blog layout, with the real endpoint URL:

<BaseLayout {title} {description} {image} type="article" {pubDate}>
  <script type="application/ld+json" set:html={JSON.stringify(schemaData)} slot="head" />

  <script>
    fetch(`https://u1sdf1bq66.execute-api.us-east-1.amazonaws.com/prod/counter?page=${encodeURIComponent(window.location.pathname)}`);
  </script>

  <a href="/blog" class="back-link">&larr; all posts</a>

  <article>
    <header class="post-header">
      <h1 class="post-header__title">{title}</h1>
      <p class="post-header__meta">
        <time datetime={pubDate.toISOString()}>{formattedDate}</time>
        {formattedUpdated && (
          <span> &middot; updated {formattedUpdated}</span>
        )}
      </p>
    </header>

    <div class="post-body">
      <slot />
    </div>
  </article>
</BaseLayout>

Now every page load fires a request to your API, which counts the view and returns a 204. The window.location.pathname part means it automatically sends the current page's path, so you don't need to configure anything per post.

Step 6: Check your view counts

Open the DynamoDB console, find your table, and click "Explore table items." If you have a lot of items, filter for items where sk equals counter. You'll see each page path and its view count.

You can also run this from the CLI:

aws dynamodb scan \
  --table-name YOUR_TABLE_NAME \
  --filter-expression "sk = :sk" \
  --expression-attribute-values '{":sk": {"S": "counter"}}'

How much does this cost?

This project uses services eligible for the AWS Free Tier. Depending on your usage and account status, charges may apply. Here's the breakdown:

DynamoDB provisioned at 25 WCU/25 RCU is within the always-free tier. No cost regardless of account age.
Lambda gives you 1 million requests per month free. Most personal blogs will stay within these limits.
API Gateway is the only service with a direct cost: $3.50 per million requests for REST APIs in us-east-1. A blog getting 10,000 views per month would cost about $0.035, which comes out of your Free Tier credits if you're a new customer.

I'd recommend setting up a billing alarm at $5 as a best practice in new sandbox accounts.

What you just learned

If you followed along, you now have hands-on experience with:

DynamoDB: composite keys, TTL for automatic cleanup, atomic counters with UpdateExpression
Lambda: handling HTTP events, environment variables, working with the AWS SDK
API Gateway: REST endpoints, CORS configuration, throttling
CDK: defining infrastructure in TypeScript, deploying with a single command

And you have something running on your blog that you built from scratch.

Cleanup

If you want to tear everything down:

npx cdk destroy -c blogOrigin=https://yourdomain.com

This deletes the Lambda, the DynamoDB table, and the API Gateway endpoint. All your view count data will be gone, so make sure you're done with it.

What to try next

Add a billing alarm so you get an email if your AWS charges go above $5
Build a small dashboard that reads from DynamoDB and displays your view counts
Track views over time by adding a date field to the counter records

The source code for this project is on GitHub if you want to fork it and make it your own. Let me know in the comments what you're building this week!

How I trained a computer vision model on the AWS Free Tier

Esin Saribudak — Fri, 27 Mar 2026 01:20:43 +0000

Last updated: March 26, 2026

Developers hide Easter eggs in code. Filmmakers hide them in scenes. I hid them in AI-generated images and asked Amazon Rekognition to find them.

If you've ever wondered whether AWS Free Tier gives you enough credits to build something cool, this post is for you. I built an Easter egg detector powered by Amazon Rekognition, tested its standard object detection API on 37 images, and trained a custom model, all with my AWS Free Tier credits.

(If you haven't set up a Free Tier account, check out this great guide!)

The idea

I wanted to build a simple and fun app where I can upload a photo and have the app tell me if there's an Easter egg in it. It sounds kind of silly, but the technical problem it maps to — locating a small, specific object in a complex scene — is a foundational one for the field of computer vision.

AWS has a lot of services for different AI/ML use cases, including Amazon Rekognition for computer vision. I learned that organizations like C-SPAN and the NFL use it to understand what's in their images and video. And Amazon Rekognition is available on the AWS Free Tier, which makes experimenting with it easier.

The service gives you different ways to figure out what's in images. The DetectLabels API works out of the box and recognizes thousands of common objects and concepts, everything from aircraft to zucchini to birthday parties. Custom Labels let you train your own computer vision model when the built-in labels fall short. With this project, I wanted to find out where the first one stops being useful and the other is needed.

What I built

The app I built to explore that question is a Streamlit app with two modes. Standard mode sends your image to the DetectLabels API and checks if it returns "Egg" or "Easter Egg" in the labels. Custom Labels mode uses a custom model I trained on my own images. Both draw bounding boxes around any eggs they find.

The application code is about 200 lines of Python, 100 lines of which is UI-related, and you can check it out at this GitHub repo. You upload an image, the app calls Rekognition using the AWS SDK for Python (Boto3), checks the response, and draws some boxes around any eggs that it finds.

Here’s an example of code that handles regular DetectLabels requests.

response = rekognition.detect_labels(
    Image={"Bytes": image_bytes},
    MaxLabels=30,
    MinConfidence=30.0,
)

Generating test images

I needed images with scenes where Easter eggs would be unexpected. I used an image generator to create 19 images: a messy desk with an egg tucked next to the monitor, a toy box with a painted Easter egg between two teddy bears, a picnic spread with a couple eggs in between the sandwiches.

Then I generated 18 images with no eggs at all, but similar to the other scenes. That gave me a relatively balanced dataset to start with.

Round 1: DetectLabels

I wrote a batch test script (also in the GitHub repo) that ran every image I had through DetectLabels and checked whether Rekognition found an egg.

The results at a 30% confidence threshold:

Metric	Score
Accuracy	75.70%
Precision	100%
Recall	52.60%

100% precision means it never hallucinated an egg where there wasn't one in the no-egg images. But 52.6% recall means it missed about half the eggs in the egg images. Imagine you're doing an Easter egg hunt, and there are 19 eggs hidden in the yard. A recall of 52.6% means you only found 10 of them.

At a stricter 70% confidence threshold, recall dropped to 36.8%, so you'd only find about 7 out of 19.

I added logging to see what objects Rekognition detected for the missed eggs. The logged objects were pretty accurate, which told me that Rekognition identified the gist of the images well but couldn't "see" the Easter eggs.

I realized the out-of-the-box API was great for detecting Easter eggs in more typical scenes, like this one.

Script output:

  ✅ 1774389521556_img.png eggs: Egg (99.9%), Easter Egg (99.1%)

DetectLabels had a harder time finding Easter eggs in less obvious scenarios or with more competing objects, like this one.

Script output:

❌ MISS 1774389716587_img.png eggs: none
↳ saw instead: Toy (98.7%), Teddy Bear (93.5%), Lego Set (69.8%), 
   Plush (53.7%), Doll (48.1%), Play Area (48.0%), Handicraft (47.7%), 
   Hedgehog (46.9%)

Round 2: Custom Labels

Custom Labels exist for situations where you need to detect specific objects in specific scenes that go beyond the capabilities of DetectLabels, like my Easter egg images. With Custom Labels, you can train a computer vision model on your own images. The model can learn to spot what you care about, even when the object is small, partially hidden, or surrounded by lots of visual noise. The benefit here is that rather than training a computer vision model from scratch on tens of thousands of images, you can build on existing capabilities by just uploading a relatively small set of training images. Then, Rekognition handles the model training and evaluation process for you.

I did this all directly in the Amazon Rekognition console, where I created a new project and uploaded my dataset of images. Rekognition automatically split my data 80/20 for training and testing.

I created my custom label of "Easter egg" and drew bounding boxes around the Easter eggs in my dataset images, then hit Train.

Training took around 30 minutes. When it finished, I got a model ARN and performance metrics. Here's how the custom model did on the test dataset compared to the standard DetectLabels API:

Metric	DetectLabels (30% threshold)	Custom Labels
Precision	100%	77.80%
Recall	52.60%	75%
F1 score	(not calculated)	0.764

Recall jumped from 52.6% to 75%. This meant that the custom model was finding eggs that DetectLabels missed entirely. Precision dropped from 100% to 77.8% (more false positives), meaning it occasionally saw an egg where there wasn’t one, but I think that's a reasonable trade-off for catching 22% more of the eggs.

The F1 score is a metric that shows how well the model balances precision and recall, indicating its overall accuracy. A score of 0.764 from a dataset of 37 images is a good starting point.

Going back to the Easter egg hunt analogy, DetectLabels was the careful egg hunter who only picked up real eggs but walked past half of them. The custom label found most of the eggs but also grabbed a few eggish-looking rocks along the way in the test dataset.

Considering the fact that I only had 37 total images in the dataset, these are promising results, but there's definitely room to improve. I'd expect the model's performance to climb if I added more training data. But this experiment was for learning and my own curiosity, and that F1 score worked for me. I plugged my custom model’s ARN into my Streamlit app, and uploaded a few images. The custom model did a pretty good job of detecting Easter eggs on new images that weren’t part of the training dataset.

It also was pretty good about not registering false positives, even with temptingly bright round objects in the image.

Cost

Everything in this project fits comfortably within the AWS Free Tier credits for new accounts. Here are some more details on the pricing for training and inferencing with a custom model in the us-east-1 region:

DetectLabels (Group 2 API)

74 images × $0.001/image = $0.074
- I had 37 images, but I ran the batch analysis script twice (first checking for egg presence, then again to log the labels that were found for false negatives).

Custom Labels training:

0.52 hours × $1/hour = $0.52
- The docs note that Amazon Rekognition may run multiple compute resources in parallel, so actual billed hours can be higher than elapsed time for model training.

Custom Labels inferencing:

1.41 hours x $4/hour = $5.71

If you build this in your own account, be sure to STOP the model when you’re done inferencing to avoid accumulating further charges. In total for this project, I was billed for 85.7 inference minutes and 31 training minutes, which amounted to $6.24. This amount was deducted from my Free Tier credits. (The charges for other services in the following cost breakdown image are related to other Free Tier projects.)

What I learned, and what I'd do differently

The jump from DetectLabels to Custom Labels was the most interesting part of this project for me. With Custom Labels, you get to label your own data, train a model, evaluate its performance, and iterate. That loop (data → train → evaluate → improve) is the same loop behind every ML system. Custom Labels just makes it accessible without needing to have ML experience or having to spin up your own dedicated hardware.

I also came away with a better sense of when to use what. You could send an image to one of the newer multimodal foundation models and ask, "Are there any Easter eggs in this picture?" It would probably give you a very good answer. But for a tightly-scoped detection task like this one, I think a purpose-built service is a better fit. A single API call returns predictable JSON with labels, confidence scores, and bounding box coordinates. No system prompt to write, no natural language to parse. And the whole project cost me $6.24 in Free Tier credits.

A couple things I'd change if I were starting over:

Create more images for the dataset. The docs say that most custom models need a few hundred images or less, but I only had 37. I'd aim for 50+ per class (Easter egg and no Easter egg). I'd also set up a script to generate text for image prompts and call an image generating API to quickly create a bunch of training and test images.
Test with real photos, not just AI-generated ones. Generated images have a certain look to them. Real phone photos with unexpected lighting and odd angles would be a tougher test.

Try it yourself

The full code and installation directions are on GitHub here.

If you want to skip the training and just play with DetectLabels, the standard mode works immediately. Upload a photo of your breakfast and see what happens. 🍳

If you want more ideas for Free Tier projects, let me know in the comments!