DEV Community: Ali Zgheib

AWS Community Builders Program 2026 – How and Why to apply

Ali Zgheib — Thu, 15 Jan 2026 10:30:58 +0000

There is a huge difference between building alone and building with a global network backing you up. That difference is the AWS Community Builders program.

The application window for the 2026 Cycle is officially open until January 21st, 2026. Quite simply: If you love AWS and love sharing what you learn, this program was designed for you.

Here is a breakdown of what the program really is, why you should apply, and how to get in.

What is the AWS Community Builders Program?

Most people believe the AWS Community Builders program is reserved for those who are highly skilled, heavily certified, or already well known in the public domain. This assumption alone discourages many strong candidates before they even consider applying.

In reality, AWS is not selecting experts. They are selecting Builders.

These are builders who learn continuously, share openly, and show up consistently. It is not about being the smartest person in the room. It is about having the curiosity to learn and the discipline to share that journey with others.

Why Apply? (The Benefits)

Beyond just being a "nice community," this program can fast-track your cloud career. Here are the four main benefits you unlock as a member:

1. Financial Support & Training

First, the resources backing your learning are substantial:

$500 in AWS credits: This allows you to experiment with advanced services and build complex demos without worrying about the bill.
Certification Voucher: You receive one voucher for an AWS certification exam of your choice.
Cloud Academy: A one-year subscription gives you access to their entire library of courses and hands-on labs to level up your skills.

2. Exclusive Access

You get an "insider edge" with the platform:

Direct Access: Join private sessions with AWS service teams to ask questions directly to the engineers building the tools.
Early Access & Insights: Get sneak peeks at upcoming AWS features under NDA, allowing you to experiment and shape new services with your feedback.

3. The Community Network

You join a private Slack community where you connect with like-minded people who are learning and sharing just like you. This is your chance to learn from experts, find mentors, and connect with other AWS Heroes.

4. Swag & Discounts

Finally, the fun stuff. You get a welcome kit filled with exclusive gear like backpacks, mugs, caps, and stickers. More importantly, you get a discount for AWS events like re:Invent, making attending cloud conferences much more affordable.

Who is Eligible? (Show Your Work)

You don't have to be an expert, but you do need to show that you are helping others learn. There are many ways to do this:

Blogging: Publishing deep-dive articles on Medium, Dev.to, or your personal blog.
Video: Creating YouTube tutorials, technical guides, or how-to videos about an existing or new AWS service.
Social Media: Sharing valuable AWS insights and tips on LinkedIn, Instagram, or TikTok to spark discussions.
Community Support: Answering questions in forums, Reddit, or AWS re:Post to help others get unblocked.
Speaking: Giving talks at cloud meetups or AWS events, whether remote or in-person.

The key is being consistent and genuine. If you are helping the community by sharing valuable content, you are eligible.

How to Apply

The application for the 2026 cycle is open until January 21, 2026.

You can submit your application here. To apply, you will need to log in with your free AWS Builder ID. Once you are in, fill out the form. It is short and asks for basic information about you and your content.

It's straightforward, but don't rush it. Take your time to gather your best links to your content before hitting submit.

Note: If you are reading this after January 21st, the application will be closed. However, you can use the same link to join the waitlist to be notified the moment the next cycle opens.

Conclusion

I’ve been building on my own for a while, but this year, I'm applying because I want to be part of this community.

If you decide to apply, drop a comment and let me know. I'm rooting for you. Good luck, and happy building!

🔥 This AWS Lambda Update Changes Everything (Durable Functions)

Ali Zgheib — Sat, 10 Jan 2026 17:36:42 +0000

TL;DR: In December 2025, AWS released Lambda Durable Functions. Your Lambda can now run for 366 days (not 15 minutes), automatically checkpoint progress, suspend during waits without charges, handle retries with built-in strategies, wait for external callbacks like human approvals, and process batches with concurrency control. All in a single Lambda function.

What Are Lambda Durable Functions?

Lambda Durable Functions extends Lambda to support long-running, stateful workflows that can pause, wait, and resume. Unlike standard Lambda functions (max 15 minutes), durable functions can run for up to 366 days through checkpoint-and-replay.

Key capabilities:

Automatic checkpointing after each operation
Zero-cost suspension during waits (Lambda suspends)
Built-in retry with configurable strategies
External callback support (human approvals, webhooks)
Batch processing with per-item checkpoints

Getting Started

This tutorial uses TypeScript and Serverless Framework for infrastructure-as-code. You can also use your favorite programming language, console, or any infrastructure-as-code tool like CDK, SAM, Terraform, etc.

Enable Durable Execution

Configure your Lambda function to support durable execution in serverless.yml:

functions:
  myFunction:
    handler: handler.main
    timeout: 900                      # Lambda execution timeout (seconds, max 900 = 15 min)
    durableConfig:
      executionTimeout: 86400         # Workflow timeout (seconds, max 31,622,400 = 366 days)
      retentionPeriodInDays: 7        # Keep execution history for 7 days

Parameter explanations:

timeout: Maximum time for a single Lambda invocation (max 15 minutes). Your function is replayed multiple times, and each replay must complete within this limit.
executionTimeout: Maximum time for the entire workflow across all replays (max 366 days). This is how long your durable function can run from start to finish, including all waits.
retentionPeriodInDays: How long AWS keeps your execution history and checkpoint logs after completion (1-90 days). Used for debugging and observability.

Example scenario: You have a workflow that processes a payment, waits 2 hours, then ships an order.

Set timeout: 60 because each individual Lambda execution (processing payment, then later shipping order) completes in under 60 seconds
Set executionTimeout: 7200 (2 hours) because the entire workflow from start to finish takes 2 hours (including the wait)

Set Up the Durable Execution SDK

Durable functions require the SDK - it's not optional. The SDK handles checkpoint-and-replay, manages execution state, and provides the durable operations you'll use in your code. Without it, you'd need to manually implement all state management, checkpoint tracking, and recovery logic yourself.

Available languages:

JavaScript
TypeScript
Python

AWS will add support for more languages over time.

Install:

npm install @aws/durable-execution-sdk-js

Wrap Your Handler

Wrap your Lambda handler with withDurableExecution to enable durable execution:

import { withDurableExecution, DurableContext } from '@aws/durable-execution-sdk-js';

export const handler = withDurableExecution(
  async (event: any, context: DurableContext) => {
    // Your durable workflow code here
    return { statusCode: 200 };
  }
);

The DurableContext gives you access to durable operations including step(), wait(), parallel(), map(), waitForCallback(), and several others for building long-running workflows.

How Durable Execution Works

Checkpoint and Replay

Durable functions run multiple times during their lifecycle. Each time Lambda invokes your function, it replays your code from the beginning - but skips completed operations by reading from the checkpoint log.

Example:

export const handler = withDurableExecution(async (event, context) => {
  // Step 1: Charge payment
  const charge = await context.step('charge', async () => {
    return processPayment(event.amount);
  });

  // Step 2: Wait 2 hours
  await context.wait({ seconds: 7200 });

  // Step 3: Ship order
  const shipment = await context.step('ship', async () => {
    return createShipment(charge.orderId);
  });

  return { shipment };
});

Execution timeline:

Invocation 1 (T+0):
┌─────────────────────────────────────────────────┐
│ [charge ✓] → checkpoint saved                   │
│ [wait 2h...] → Lambda suspends (no charges)     │
└─────────────────────────────────────────────────┘
                    ⏳ 2 hours pass...

Invocation 2 (T+2h):
┌─────────────────────────────────────────────────┐
│ [charge ⚡cached] ← reads from checkpoint       │
│ [wait ⚡skipped] ← already completed            │
│ [ship ✓] → checkpoint saved                     │
│ Return result ✓                                 │
└─────────────────────────────────────────────────┘

During the 2-hour wait, no Lambda runs. Zero charges.

Determinism Requirements

Replay depends on your code producing the same results every time it runs. Any code outside durable operations must be deterministic - meaning it returns the same output for the same input.

Non-deterministic operations must be wrapped:

// ❌ Wrong: Random value changes on each replay
const id = uuid();
await context.step('save', async () => saveWithId(id));

// ✅ Correct: Random value generated once, checkpointed
const id = await context.step('generate-id', async () => {
  return uuid();
});
await context.step('save', async () => saveWithId(id));

Wrap these in steps:

Random values (Math.random(), uuid(), uuidv4())
Timestamps (Date.now(), new Date())
External API calls
Database queries

Core Operations

The SDK provides several operations for building durable workflows. Each operation creates checkpoints automatically, ensuring your function can resume from any point.

context.step()

Executes business logic with automatic checkpointing and retry. Once a step succeeds, it never re-executes - the checkpointed result is used on replay.

const result = await context.step('process-payment', async () => {
  return await paymentService.charge(amount);
});

Use for: Database calls, API requests, any side-effecting operation.

context.wait()

Pauses execution for a specified duration. The SDK creates a checkpoint, terminates the function invocation, and schedules resumption. When the wait completes, Lambda invokes your function again.

await context.wait({ seconds: 3600 }); // Wait 1 hour

Use for: Delays between operations, rate limiting, scheduled actions.

context.parallel()

Executes multiple operations concurrently with optional concurrency control.

const results = await context.parallel([
  async (ctx) => ctx.step('task1', async () => processTask1()),
  async (ctx) => ctx.step('task2', async () => processTask2()),
  async (ctx) => ctx.step('task3', async () => processTask3())
]);

Use for: Independent operations that can run simultaneously.

context.map()

Concurrently executes an operation on each item in an array with optional concurrency control.

const results = await context.map(itemArray, async (ctx, item, index) =>
  ctx.step('task', async () => processItem(item, index))
);

Use for: Batch processing, parallel data transformation.

context.waitForCallback()

Suspends execution until an external system submits a callback. The SDK creates a callback, executes your submitter function with the callback ID, and waits for the result.

const result = await context.waitForCallback(
  'external-api',
  async (callbackId, ctx) => {
    await submitToExternalAPI(callbackId, requestData);
  },
  { timeout: { minutes: 30 } }
);

The external system receives the callbackId and sends the result back using the Lambda API (SendDurableExecutionCallbackSuccess or SendDurableExecutionCallbackFailure).

Use for: Human approvals, webhook integrations, external system coordination.

context.createCallback()

Creates a callback and returns both a promise and callback ID. You send the callback ID to an external system, which submits the result using the Lambda API (SendDurableExecutionCallbackSuccess or SendDurableExecutionCallbackFailure).

const [promise, callbackId] = await context.createCallback('approval', {
  timeout: { hours: 24 }
});
await sendApprovalRequest(callbackId, requestData);
const approval = await promise;

Use for: Advanced scenarios where you need the callback ID before suspending.

context.invoke()

Invokes another Lambda function and waits for its result.

const result = await context.invoke(
  'invoke-processor',
  'arn:aws:lambda:us-east-1:123456789012:function:processor',
  { data: inputData }
);

Use for: Function composition, workflow decomposition, calling other Lambda functions.

context.waitForCondition()

Polls for a condition with automatic checkpointing between attempts. The SDK executes your check function, creates a checkpoint with the result, waits according to your strategy, and repeats until the condition is met.

const result = await context.waitForCondition(
  async (state, ctx) => {
    const status = await checkJobStatus(state.jobId);
    return { ...state, status };
  },
  {
    initialState: { jobId: 'job-123', status: 'pending' },
    waitStrategy: (state) =>
      state.status === 'completed'
        ? { shouldContinue: false }
        : { shouldContinue: true, delay: { seconds: 30 } }
  }
);

Use for: Polling external systems, waiting for resources to be ready, implementing retry with backoff.

context.runInChildContext()

Creates an isolated execution context for grouping operations. Child contexts have their own checkpoint log and can contain multiple steps, waits, and other operations. The SDK treats the entire child context as a single unit for retry and recovery.

const result = await context.runInChildContext(
  'batch-processing',
  async (childCtx) => {
    return await processBatch(childCtx, items);
  }
);

Use for: Organizing complex workflows, implementing sub-workflows, isolating operations that should retry together.

Complete Example: Order Fulfillment Workflow

Here's a real-world example combining multiple operations:

import { withDurableExecution, DurableContext } from '@aws/durable-execution-sdk-js';

export const handler = withDurableExecution(
  async (event: { orderId: string; items: string[] }, context: DurableContext) => {
    // Step 1: Process payment
    const payment = await context.step('process-payment', async () => {
      return await paymentService.charge(event.orderId);
    });

    // Step 2: Wait 1 hour for fraud check window
    await context.wait({ seconds: 3600 });

    // Step 3: Parallel operations - reserve inventory and calculate shipping
    const [inventory, shipping] = await context.parallel([
      async (ctx) => ctx.step('reserve-inventory', async () => 
        inventoryService.reserve(event.items)
      ),
      async (ctx) => ctx.step('calculate-shipping', async () => 
        shippingService.calculate(event.orderId)
      )
    ]);

    // Step 4: Wait for external approval
    const approval = await context.waitForCallback(
      'order-approval',
      async (callbackId, ctx) => {
        await notificationService.sendApprovalRequest(callbackId, event.orderId);
      },
      { timeout: { hours: 24 } }
    );

    if (!approval.approved) {
      return { status: 'rejected', orderId: event.orderId };
    }

    // Step 5: Process each item
    const shipments = await context.map(
      event.items,
      async (ctx, item, index) => 
        ctx.step('ship-item', async () => 
          shippingService.shipItem(item, shipping.address)
        )
    );

    // Step 6: Send confirmation
    await context.step('send-confirmation', async () => {
      return notificationService.sendConfirmation(event.orderId, shipments);
    });

    return { status: 'completed', orderId: event.orderId, shipments };
  }
);

This workflow demonstrates:

Sequential steps with automatic checkpointing (payment, confirmation)
Time-based waits for fraud checks (no charges during wait)
Parallel execution for independent operations (inventory + shipping)
External callbacks for order approval with 24-hour timeout
Batch processing with map() for shipping multiple items

The entire workflow runs for 25+ hours (1-hour fraud check + 24-hour approval window) while only consuming compute during active operations.

Resources

Have you tried Lambda Durable Functions yet? What workflows are you building with them? Share your experiences and questions in the comments below!

Stop Using AWS Access Keys in GitHub Actions: The OIDC Guide You Need

Ali Zgheib — Mon, 22 Dec 2025 22:24:16 +0000

Overview

OpenID Connect (OIDC) allows your GitHub Actions workflows to access resources in Amazon Web Services (AWS) without storing long-lived AWS credentials as GitHub secrets. Whether you're deploying Lambda functions, updating S3 buckets, managing EC2 instances, or using any AWS service, this guide shows you how to transition from using AWS access keys to OIDC authentication.

Why OIDC Instead of Access Keys?

Access Keys (Traditional Method):

❌ Long-lived credentials that never expire
❌ Must be rotated manually
❌ If leaked, remain valid until manually revoked
❌ Stored as GitHub secrets

OIDC (Modern Method):

✅ Short-lived tokens that expire automatically
✅ No credentials to rotate
✅ Tokens are automatically invalidated after use
✅ Fine-grained access control with trust policies

Prerequisites

Before proceeding, ensure you have:

An AWS account with IAM permissions
A GitHub repository
Basic understanding of IAM roles and policies

Step 1: Add GitHub OIDC Provider to AWS

Navigate to the IAM Console in AWS
Go to Identity providers → Add provider
Select OpenID Connect
Configure the provider:
- Provider URL: https://token.actions.githubusercontent.com
- Audience: sts.amazonaws.com
Click Add provider

Step 2: Create IAM Role with Trust Policy

Navigate to IAM → Roles → Create role to begin.

Step 1: Select Trusted Entity

Select Web identity as the trusted entity type
Configure the identity provider using the dropdowns:
- Identity provider: Select token.actions.githubusercontent.com from the dropdown
- Audience: Select sts.amazonaws.com from the dropdown
- GitHub organization: Enter your organization or personal username (e.g., AliZgheib)
- GitHub repository (optional): Enter * to allow all repositories, or specify a specific repo name
- GitHub branch (optional): Enter * to allow all branches, or specify a specific branch like main
Click Next

Tip: Using * for repository and branch gives you flexibility, but for better security, specify exact repository and branch names in production.

Step 2: Add Permissions

Attach the necessary permissions for your deployment based on what AWS services you're using:

Common AWS Services:

Lambda & API Gateway: AWSLambdaFullAccess, AmazonAPIGatewayAdministrator
S3: AmazonS3FullAccess
EC2: AmazonEC2FullAccess
ECS/Fargate: AmazonECS_FullAccess
CloudFormation/CDK/Terraform: CloudFormationFullAccess
General deployments: IAMFullAccess (or more restricted custom policy)

Note: In production, create a custom policy with least-privilege permissions specific to your needs.

Click Next to continue.

Step 3: Name, Review, and Create

Name the role: Enter a descriptive name (e.g., GitHubToAWSOIDC)
Description (optional): Add a description like "Role for GitHub Actions to deploy to AWS via OIDC"
Review:
- Step 1: Select trusted entities: Verify your GitHub org/repo settings
- Step 2: Add permissions: Verify the policies you attached
- Step 3: Add tags (optional): Add tags if needed for organization
Click Create role

Copy the Role ARN

After the role is created successfully, find and copy the Role ARN (e.g., arn:aws:iam::123456789012:role/GitHubToAWSOIDC). You'll need this for the next step.

Understanding the Trust Policy (Reference)

AWS automatically generates a trust policy based on your selections. Here's what it looks like:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "sts:AssumeRoleWithWebIdentity",
            "Principal": {
                "Federated": "arn:aws:iam::YOUR_ACCOUNT_ID:oidc-provider/token.actions.githubusercontent.com"
            },
            "Condition": {
                "StringEquals": {
                    "token.actions.githubusercontent.com:aud": [
                        "sts.amazonaws.com"
                    ]
                },
                "StringLike": {
                    "token.actions.githubusercontent.com:sub": [
                        "repo:YOUR_ORG/*"
                    ]
                }
            }
        }
    ]
}

Key elements:

token.actions.githubusercontent.com:aud: Ensures the token is intended for AWS STS
token.actions.githubusercontent.com:sub: Restricts access based on your GitHub org/repo/branch selections
- repo:YOUR_ORG/* means any repository under your organization, any branch

Note: For most use cases, the trust policy generated by AWS from the UI is sufficient. You can manually edit it later if you need more specific control (e.g., specific repository, branch, or environment restrictions).

Step 3: Add GitHub Repository Secret

Go to your GitHub repository
Navigate to Settings → Secrets and variables → Actions
Add a new repository secret:
- Name: AWS_ROLE_ARN
- Value: Your IAM role ARN (e.g., arn:aws:iam::123456789012:role/GitHubToAWSOIDC)

Step 4: Update GitHub Actions Workflow

Update your .github/workflows/deploy.yml to use OIDC instead of access keys:

Before (Access Keys):

jobs:
  deploy:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      - name: Configure AWS Credentials (Access Keys)
        uses: aws-actions/configure-aws-credentials@v4
        with:
          aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
          aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
          aws-region: us-east-1

After (OIDC):

jobs:
  deploy:
    runs-on: ubuntu-latest
    permissions:
      id-token: write   # Required for requesting the JWT
      contents: read    # Required for actions/checkout

    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      - name: Configure AWS Credentials (OIDC)
        uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: ${{ secrets.AWS_ROLE_ARN }}
          aws-region: us-east-1

Key Changes:

Added permissions block:
- id-token: write allows GitHub to create a JWT token
- contents: read allows checking out the repository
Replaced credentials:
- Removed aws-access-key-id and aws-secret-access-key
- Added role-to-assume with the IAM role ARN
Updated step name: Changed from "Access Keys" to "OIDC" for clarity

Step 5: Clean Up Old Secrets (Optional)

After confirming OIDC works successfully, remove the old access key secrets:

Go to Settings → Secrets and variables → Actions
Delete AWS_ACCESS_KEY_ID
Delete AWS_SECRET_ACCESS_KEY

Important: Delete these secrets only after verifying OIDC authentication works!

Complete Workflow Example

Here's a complete workflow example deploying to AWS (this example uses Serverless Framework, but the OIDC configuration works with any deployment tool):

name: Deploy Lambda to AWS

on:
  push:
    branches:
      - main
  workflow_dispatch:

jobs:
  deploy:
    runs-on: ubuntu-latest
    permissions:
      id-token: write
      contents: read

    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      - name: Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version: '22'

      - name: Configure AWS Credentials (OIDC)
        uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: ${{ secrets.AWS_ROLE_ARN }}
          aws-region: us-east-1

      - name: Install dependencies
        run: npm install

      - name: Deploy to AWS
        run: npx serverless deploy --verbose

Testing the Setup

Commit and push your changes to the main branch
Navigate to Actions tab in your GitHub repository
Monitor the workflow run
Verify the "Configure AWS Credentials (OIDC)" step succeeds

Troubleshooting

If your deployment fails, the most common issue is insufficient permissions. Ensure your IAM role has all the necessary permissions for the AWS services you're deploying to. If you're using granular (least-privilege) permissions instead of the full access policies, you may need to add specific permissions based on the error messages in your GitHub Actions logs.

Security Best Practices

Use specific conditions: Restrict the trust policy to specific branches or environments
Least privilege permissions: Attach only the minimum required permissions to the IAM role
Monitor usage: Enable AWS CloudTrail to audit role assumptions
Regular reviews: Periodically review and update trust policies
Use environments: For production deployments, use GitHub environments with protection rules

Comparison Summary

Feature	Access Keys	OIDC
Credential lifetime	Permanent	Temporary
Rotation required	Yes	No
Secrets to manage	2 per AWS account	1 per IAM role
Security risk if leaked	High	Low
Setup complexity	Simple	Moderate

Conclusion

By switching from AWS access keys to OIDC, you've improved your deployment security by:

Eliminating long-lived credentials
Reducing secret management overhead
Implementing fine-grained access control
Following AWS and GitHub security best practices

The initial setup requires more configuration, but the long-term security and maintenance benefits make OIDC the recommended approach for production deployments.

Additional Resources

Have you made the switch to OIDC? Share your experience in the comments below! 👇

🧠 Kiro: From Steering Docs to Specs to Hooks — An Agentic IDE Walkthrough

Ali Zgheib — Mon, 22 Dec 2025 16:14:34 +0000

Kiro is a new agentic IDE that brings structure and intent back into AI-assisted software development. Instead of generating isolated code snippets from prompts, Kiro introduces a workflow centered around persistent context, structured specifications, and event-driven automation.

This article walks through the three core building blocks of Kiro: Steering Docs, Specs, and Hooks, and how they work together to support spec-driven development.

📘 Steering Docs — Persistent Project Context

Steering docs allow Kiro to understand a project beyond the current prompt. They store long-lived knowledge such as architecture decisions, coding standards, naming conventions, and domain rules.

These documents are written in markdown and live alongside the codebase. Once defined, Kiro consistently uses them when generating code, reviewing changes, or performing automated tasks. This removes the need to repeatedly explain project context and helps ensure outputs match real-world team standards.

📐 Specs — Structured Development from Intent

Specs are the foundation of Kiro’s spec-driven workflow. Instead of jumping directly from a prompt to code, Kiro helps break features into structured documents:

Requirements — clear functional expectations and acceptance criteria

Design — technical architecture, data models, and implementation approach

Tasks — a sequenced list of actionable development steps

This approach makes complex features easier to reason about, review, and maintain, while keeping AI output aligned with the original intent.

⚙️ Hooks — Event-Driven Automation

Hooks enable automation based on IDE events such as file saves, file creation, or commits. When triggered, Kiro can run agent workflows or commands automatically.

Common use cases include:

Generating or updating tests when files change

Keeping documentation in sync with code

Enforcing project standards and best practices

Running checks before changes are committed

Hooks allow Kiro to operate continuously in the background, reducing manual overhead and improving consistency across the codebase.

🔁 How It All Fits Together

Steering docs provide long-term context

Specs provide structure and traceability

Hooks provide automation and enforcement

Together, they enable a workflow where AI assists with real engineering work, not just code generation.

🎥 Video Walkthrough

A full walkthrough of Kiro, covering steering docs, specs, and hooks in action:
https://www.youtube.com/watch?v=SPDziEBuWwY

Learn Serverless on AWS: Live Demo & Walkthrough – Wednesday, Aug 27

Ali Zgheib — Fri, 22 Aug 2025 14:02:05 +0000

Join us on Wednesday, August 27 for an engaging session on Serverless in Action: Building and Deploying APIs on AWS.
We’ll break down what serverless really means, why it matters, and where it shines (and doesn’t). Then, I’ll take you through a live walkthrough: designing, building, testing, deploying, and documenting an API step by step on AWS. This will be a demo-style session—you can watch the process end-to-end and leave with practical insights to apply later.

Details:

🗓️ Date: Wednesday, August 27
🕕 Time: 6:00 PM EEST / 7:00 PM GST
📍 Location: Online (Google Meet link shared after registration)
🔗 Register here: https://www.meetup.com/acc-mena/events/310519152/

Speaker: Ali Zgheib – Founding Engineer at CELITECH, AWS Certified (7x), and ACC community co-lead passionate about knowledge-sharing.

Whether you’re new to serverless or looking to sharpen your AWS skills, this walkthrough will help you see the concepts in action. Hope to see you there!

How I Built & Deployed 'DevMood' Developer App in 24 Hours with Pulumi & AWS 🔥

Ali Zgheib — Sun, 06 Apr 2025 19:57:45 +0000

This is a submission for the Pulumi Deploy and Document Challenge: Fast Static Website Deployment

What I Built

DevMood is a web application designed to enhance a developer's coding experience by offering dev jokes, coding music, and weather updates. The app is hosted on AWS and uses Pulumi for Infrastructure as Code (IaC), ensuring seamless deployment and scalability. The app includes:

Dev Jokes 💬: A collection of funny developer jokes.
Coding Music 🎶: Background music to help stay focused.
Weather Info 🌤️: Real-time weather updates based on your location.
Responsive Design 📱: Adapts to various screen sizes.

Live Demo Link

DevMood Live Demo

Project Repo

DevMood GitHub Repo

My Journey

When I decided to participate in the Pulumi Deploy and Document Challenge, my goal was to build a project that demonstrates Pulumi’s power in deploying cloud infrastructure on AWS. I had some experience with cloud deployments, but Pulumi provided the opportunity to dive deeper into Infrastructure as Code with a TypeScript-first approach.

Setting up the Project

The first step was to set up the project structure, including Next.js for the frontend and configuring the backend services on AWS with Pulumi. I used Tailwind CSS for styling to ensure the app was responsive and dynamic across devices. The frontend was a bit tricky in terms of layout, but once I got the hang of it, the combination of Next.js and Tailwind made it much smoother.

Frontend Setup

For the frontend, I used Next.js with Tailwind CSS for utility-first styling. Next.js allowed me to implement server-side rendering for better performance, while Tailwind CSS ensured a responsive layout. Here's a preview:

Infrastructure-1 (Static Website Hosting with S3)

For the basic version of DevMood, I used Amazon S3's static website hosting feature. It’s a cost-effective and scalable solution for hosting the frontend. The infrastructure is managed with Pulumi.

Key Components:

S3 Bucket: Stores the static website files (HTML, CSS, JS).
Static Website Hosting: Configured for the app to be served with an index and error document.
Bucket Policy: Ensures public access to the static assets.

Infrastructure-1 Preview

Infrastructure-2 (Static Website Hosting with S3, CloudFront, and OAC)

For the enhanced version of DevMood, I added CloudFront for content delivery and Origin Access Control (OAC) for security, ensuring that only CloudFront could access the S3 bucket. This optimized infrastructure is also managed by Pulumi.

Key Components:

S3 Bucket: Hosts static files but with public access restricted to CloudFront.
CloudFront CDN: Caches and delivers static content globally, improving performance.
OAC (Origin Access Control): Ensures that only CloudFront can securely access the S3 files.

Infrastructure-2 Preview

Continuous Integration (CI)

The CI pipeline ensures that code is continuously linted and checked for quality with each pull request. It lints the frontend, Infrastructure-1, and Infrastructure-2 code to ensure consistency and catch errors early in the process. Here's how it works:

Steps:

Code Checkout: Pulls the latest code from the repository.
Node.js Setup: Installs the latest version of Node.js (v18).
Linting: Runs the linting process to catch any coding errors or style violations before merging to the main branch.

Technologies Used:

GitHub Actions: Automates the linting process with pull request triggers.
ESLint: Used for linting the frontend and infrastructure code.

Continuous Deployment (CD)

The CD pipeline automates the deployment of the application whenever there is a push to the main branch. It deploys Infrastructure-1 (Static Website Hosting with S3) and Infrastructure-2 (Static Website Hosting with S3, CloudFront, and OAC). Here's how the process works:

Steps:

Code Checkout: Pulls the latest code from the repository.
Static Website Build: Builds the static website assets from the frontend.
AWS Credentials Configuration: Configures AWS access keys for secure deployment.
Deploy Infrastructure-1 via Pulumi: Deploys Infrastructure-1 by uploading the static website files to the S3 bucket.
Deploy Infrastructure-2 via Pulumi: Deploys Infrastructure-2 by uploading the static website files to the S3 bucket, while ensuring CloudFront and OAC are properly configured for enhanced security and performance.

Technologies Used:

GitHub Actions: Automates the deployment process.
Pulumi GitHub Action: Deploys infrastructure as code using Pulumi.
AWS GitHub Action: Manages AWS deployments and configurations.

Using Pulumi

I used Pulumi as my Infrastructure as Code (IaC) tool to deploy all the infrastructure, including S3 buckets, CloudFront distributions, and Origin Access Control (OAC) to secure the S3 bucket. Here's how Pulumi helped me:

Syntax

Having prior experience with AWS CDK and Serverless Framework, Pulumi’s TypeScript-first approach was both familiar and intuitive. The learning curve was steep at first, but the Pulumi documentation was super helpful in getting me up and running in less than 24 hours.

Multi-Stack Management

One of the more challenging aspects was managing the different stacks for the basic static hosting and the optimized version with CloudFront and OAC. Pulumi’s multi-stack management feature made it easy to handle the separation of concerns while keeping the infrastructure as code clean and manageable.

Pulumi Action

For the Continuous Deployment (CD) setup, I used Pulumi GitHub Action to automate the deployment of my infrastructure. It integrates seamlessly with GitHub Actions and was a perfect fit for managing the deployment pipeline. Pulumi’s action makes it easy to trigger the deployment process and manage the infrastructure via code, ensuring a smooth and reliable CD pipeline.

Check out the Pulumi GitHub Actions for more information.

Conclusion

In less than 24 hours, I successfully built and deployed DevMood using Pulumi and AWS. Despite some challenges with multi-stack management and initial syntax hurdles, Pulumi’s TypeScript-first approach made it easy to automate infrastructure deployment. If you’re looking to simplify your cloud deployments and enjoy the benefits of IaC, I highly recommend giving Pulumi a try.

Feel free to check out the repo and contribute!

Thanks for reading and thank you to Pulumi for creating such an amazing tool!

How to deploy a React application to AWS using AWS S3 & AWS CloudFront

Ali Zgheib — Sun, 09 Jul 2023 00:26:05 +0000

Hello everyone! I hope that you are doing great on this fine weekend😀

Previously, I built a face recognition tool for celebrities where I deployed its back-end to AWS using AWS CDK.

The link for the article can be found here: https://dev.to/alizgheib/build-a-face-recognition-tool-for-celebrities-using-react-aws-foo

Today, I'll be deploying the front-end part (React application) to Amazon Simple Storage Service (S3) while adding a caching solution using AWS CloudFront - So let's do it together!

I thought that it would be pretty useful to outline our process into steps so that it would be easier for you to follow along.

Build/Deployment Outline:

Fix a common issue with React applications (blank page)
Create a production build
Create an S3 Bucket on AWS and upload the content of the build folder
Create a CloudFront distribution
Enabled S3 public access to our bucket and allow access from our CloudFront distribution only (using OAC)
That should be it! Our application should be running now and available on over 400+ edge locations

Step By Step Guide:

If you would like to follow along, feel free to use the codebase available here: https://github.com/AliZgheib/celebrities-face-recognition/tree/main/front-end

Now let's start:

First of all, there's a small issue that I faced when accessing the deployed application (a blank page kept on showing)
To fix that, we just need to add "homepage": "." in the package.json file.

the package.json should look as follow:

{
  "name": "front-end",
  "version": "0.1.0",
  "private": true,
  "homepage": ".",
  "dependencies": {
    // project dependencies here
  },
  // other configurations
}

Now let's create a production build of the application

We cd into the project directory

cd front-end

We create a production build by running the NPM command below:

npm run build

After a successful run we should have a build folder similar to the one below:

Now let's login to the AWS Console and Navigate to the AWS S3 service page.

We click on the "Create bucket" button to create an S3 bucket that will host our React application code

We name our s3 bucket (ex: celebrities-face-recognition - it should be globally unique) and we click the "Create bucket" button at the bottom without the need to modify any other options.

We should see something similar to the image below:

Now let's upload the previously created production build to the S3 bucket.

We click on celebrities-face-recognition (the name of the bucket you created) and we click on “Upload”.

We upload the files (index.html, favicon.ico, asset-manifest.json, robots.txt) and the static folder separately and at the end, we should have something similar to the list below ready to be uploaded:

Now we click the "Upload" button at the bottom of the page and after waiting a couple of moments, our project should be successfully uploaded.

Great progress if you are still following along!

The setup for our S3 bucket is partially ready. We have to add a caching solution to our S3 bucket and expose our website to the web (via AWS CloudFront) and finally, we go back to S3 to update the permissions.

Let's navigate to the AWS CloudFront service and click on the "Create a CloudFront distribution" button to create a new distribution.

1- We pick celebrities-face-recognition.s3.us-east-1.amazonaws.com for the Origin domain option

2- Now for the Origin access option:

2.a- Let's change it from "Public" to "Origin access control settings (recommended)" - OAC is the newer and recommended approach to access your S3 bucket from AWS CloudFront.

b- Click "Create control setting"
c- Click "Create"

3- For the WAF option: pick whatever fits your needs. For my case, I'll go ahead and disable it

4- For the Default root object, we enter "index.html" as our
default object

5- We click "Create distribution" to create our distribution.

that's it for CloudFront, our distribution is now being deployed globally and you should see a screen similar to the one below:

You can see the distribution domain name: https://d3b1yxs153bxzh.cloudfront.net

However, if we try to access it, we will get an error because S3 is not allowing our CloudFront distribution to access it - let's change that!

Let's copy the new S3 bucket policy by clicking the "Copy Policy" button at the top right of the screen.

We navigate back to the AWS S3 service and we open the "permissions" section of our celebrities-face-recognition bucket.

1- Click the "Edit" button in the "Block public access (bucket settings)" section and make sure to untick all the options then click "Save changes".

2- Click the "Edit" button in the "Bucket policy" section and paste the previously copied CloudFront permissions here then click "Save changes".

Guess what? The distribution is working now 😀 and can be accessed globally at minimal latency - https://d3b1yxs153bxzh.cloudfront.net.

You can go a bit further and link the distribution URL to your domain (ex: https://www.example.com) using a DNS provider like GoDaddy, Name Cheap, Route 53, etc.. but that would be outside the scope of this article.

Please note that the distribution created is for education purposes only and it will be taken down before publishing the article. Use it as a guide to create and publish your distributions.

Thank you for sticking with me till the end and I would appreciate any feedback in the comments section below.

Build a face recognition tool for celebrities using React & AWS

Ali Zgheib — Thu, 06 Jul 2023 06:53:14 +0000

Hello everyone, This is my first tech blog on dev.to and in general. So I hope you hold tight while we go on this wild journey 😀

Today we will be building a tool that can detect the faces of celebrities in a specific photo. The tool will be built using React JS for the front-end and on the back-end we will be using AWS CDK to deploy our infrastructure (APIGateway & AWS Lambda). Our backend will be interacting with AWS Rekognition (Machine learning and face recognition service provided by AWS - https://aws.amazon.com/rekognition/ )

I thought that it would be fun to showcase the final results before diving into the implementation steps.

So let's say we have a celebrities photo as shown below:

We will upload the image to our application:

Finally, after submitting the form we will get the results below:

I hope you liked the idea of the app and the accuracy of the results.

Below is a simple architecture diagram created to showcase the final infrastructure and and how all service will be interacting with each other.

If that seems too complicated, no worries about it - we will be building it together step by step.

Let's start!!

First of all, we will start with our front-end (React application) and to do so we can create a basic typescript React project using the command below:

npx create-react-app front-end --template typescript

After giving it a couple of seconds/minutes, we should have a basic react application that we can use as a base for our application.

Let's start the application in development mode:

npm run start

Our application will be simple and will consist of only 1 page which contains the upload file form and a modal to display the results. We will also make use of React states and the Fetch API to be able to interact with our API on the backend (which we will deploy later)

Lets start with the code of the form:


  const [file, setFile] = React.useState<File | null>(null);
  const [isLoading, setIsLoading] = React.useState(false);
  const [error, setError] = React.useState<string | null>(null);

  const handleSubmit = async (e: React.FormEvent<HTMLFormElement>) => {
    // to be implemented later
  };

  const handleFileChange = (e: React.ChangeEvent<HTMLInputElement>) => {
    if (!e.target.files || e.target.files.length === 0) {
      return setFile(null);
    }

    setFile(e.target.files[0]);
    setError(null);
  };
  return (
    <div className="container">
      <div className="card">
        <h3>Detect celebrities through pictures</h3>
        <div className="drop_box">
          <h4>Upload File here</h4>
          <p>Files Supported: PNG & JPG</p>

          <form onSubmit={handleSubmit}>
            <div className="form">
              <input
                type="file"
                accept=".png,.jpg"
                id="fileID"
                disabled={isLoading}
                onChange={handleFileChange}
              />
              <h6 id="file-name"></h6>

              <p id="error">{error}</p>
              <button
                type="submit"
                className="btn"
                id="submit-btn"
                disabled={isLoading}
              >
                {isLoading ? "Loading..." : "Submit"}
              </button>
            </div>
          </form>
        </div>
      </div>
    </div>
  );

After the form element (div with class "card") we can add the modal as follow:

interface CelebtritiesData {
  celebrityFaces: any[];
  unrecognizedFaces: any[];
}

  const [showModal, setShowModal] = React.useState(false);
  const [celebritiesData, setCelebtritiesData] =
    React.useState<CelebtritiesData | null>(null);

  const handleModalClose = () => {
    setShowModal(false);
  };

  return (
    <div className="container">
      {/* upload file form here */}
      {showModal && (
        <div id="myModal" className="modal">
          <div className="modal-content">
            <span className="close" onClick={handleModalClose}>
              &times;
            </span>

            <div className="modal-actual-content">
              <h3>
                {`Number of recognized celebrities: ${celebritiesData?.celebrityFaces.length}`}
              </h3>
              <ul>
                {celebritiesData?.celebrityFaces.map((celebrityFace) => {
                  return <li>{celebrityFace.Name}</li>;
                })}
              </ul>

              {celebritiesData &&
                celebritiesData?.unrecognizedFaces.length > 0 && (
                  <h5>
                    {`we weren't able to recognize ${celebritiesData?.unrecognizedFaces.length} celebrities: `}
                  </h5>
                )}
            </div>
          </div>
        </div>
      )}
    </div>
  );

Full code (including css) can be found here: https://github.com/AliZgheib/celebrities-face-recognition/tree/main/front-end

We still need to add the logic where we convert the image to base64 + send the results to our backend/API (which we will build soon)

So lets take a break from our react application and deploy our backend using AWS CDK (AWS API Gateway + AWS Lambda)

First of all there's a list of pre-requisite before we start working with AWS CDK - let's check it together:

1- Install the recommended version of NodeJS - https://nodejs.org/en

2- Install AWS CDK

npm install -g aws-cdk

3- Configure your AWS credentials

aws configure

4- Make sure to install typescript

npm install -g typescript

Now lets create our base AWS CDK project using typescript template

mkdir back-end
cd back-end
cdk init app --language typescript

After waiting a couple of seconds/minutes we should have our base AWS CDK project using typescript template.

An important step that we need to do when setting up AWS CDK on a new AWS account (or new region) is running the command below:

cdk bootstrap

That should be for the setup!! Now lets continue coding again.

If you are not familiar with AWS CDK or what it does. AWS CDK is basically a tool provided by AWS to help us provision infrastructure as code instead of via the console (clickops).

Infrastructure as code is the future. it will help us write a better code that is reusable, maintainable, and we can review it before deploying the updates to our production environment.

Now let's provision an API Gateway, a Lambda (which will act as an API endpoint) and add the necessary permissions for the Lambda to be able to interact with AWS Rekognition.

We add the API Gateway to our CDK stack as follow:

import * as cdk from "aws-cdk-lib";
import { Construct } from "constructs";

import * as apigateway from "aws-cdk-lib/aws-apigateway";


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

    // The code that defines your stack goes here

    const api = new apigateway.RestApi(this, "my-api", {
      description: "api gateway",
      deployOptions: {
        stageName: "dev",
      },
      // 👇 enable CORS
      defaultCorsPreflightOptions: {
        allowHeaders: [
          "Content-Type",
          "X-Amz-Date",
          "Authorization",
          "X-Api-Key",
        ],
        allowMethods: ["OPTIONS", "GET", "POST", "PUT", "PATCH", "DELETE"],
        allowCredentials: true,
        allowOrigins: ["*"],
      },
    });

    // 👇 create an Output for the API URL
    new cdk.CfnOutput(this, "apiUrl", { value: api.url });
  }
}

Now lets add the Lambda function:

import * as path from "path";
import * as lambda from "aws-cdk-lib/aws-lambda";
import { Duration } from "aws-cdk-lib";

    // 👇 define the lambda function
    const rekognitionLambda = new lambda.Function(this, "rekognition-lambda", {
      runtime: lambda.Runtime.NODEJS_18_X,
      handler: "index.main",
      code: lambda.Code.fromAsset(path.join(__dirname, "/../src/rekognition")),
      timeout: Duration.seconds(10),
    });

As you can see above we specified the Node JS runtime of the Lambda to be v18 and we also passed the handler path to the "code" property.

We will add the Lambda Logic in a bit.

Now lets give our Lambda function the necessary IAM permissions to be able to interact with AWS Rekognition.

    // 👇 create a policy statement
    const rekognitionLambdaPolicy = new iam.PolicyStatement({
      actions: ["rekognition:RecognizeCelebrities"],
      resources: ["*"],
    });

    // 👇 add the policy to the Function's role
    rekognitionLambda.role?.attachInlinePolicy(
      new iam.Policy(this, "rekognition-lambda-policy", {
        statements: [rekognitionLambdaPolicy],
      })
    );

We will also create a POST /rekognition endpoint under the API and we will assign the Lambda as an integration/proxy which will allow it to read the base64 image in the POST request body -> call AWS Regkonition service and return the response.

    // 👇 add a /rekognition resource
    const rekognitionResource = api.root.addResource("rekognition");

    // 👇 integrate POST /rekognition with rekognitionLambda
    rekognitionResource.addMethod(
      "POST",
      new apigateway.LambdaIntegration(rekognitionLambda, { proxy: true })
    );

Now let's write the necessary logic for the Lambda function that will validate the "imageBase64" property in the body, forward it to AWS Regkognition service which will analyze the image and output a result. finally, the result will be formatted and returned to our front-end application.

Lets create a new directory "src/rekognition" in the root of our "back-end" project. Under the "rekognition" folder we will add an "index.ts" file which will contain the actual code of the Lambda function.

The content of the "index.ts" file should look as follow:

import {
  RekognitionClient,
  RecognizeCelebritiesCommand,
} from "@aws-sdk/client-rekognition";

const baseHandler = async (event: any) => {
  try {
    const { imageBase64 } = JSON.parse(event.body);

    console.log("imageBase64", imageBase64);

    if (!imageBase64) {
      return new Error("imageBase64 is a required");
    }
    const rekognitionClient = new RekognitionClient({});

    const { CelebrityFaces, UnrecognizedFaces } = await rekognitionClient.send(
      new RecognizeCelebritiesCommand({
        Image: { Bytes: Buffer.from(imageBase64, "base64") },
      })
    );
    return {
      celebrityFaces: CelebrityFaces ? CelebrityFaces : [],
      unrecognizedFaces: UnrecognizedFaces ? UnrecognizedFaces : [],
    };
  } catch (error: any) {
    console.log(error);

    return new Error("Something went wrong");
  }
};

const main = async (event: any) => {
  const response = await baseHandler(event);

  if (response instanceof Error) {
    return {
      headers: {
        "Access-Control-Allow-Origin": "*",
      },
      body: JSON.stringify({
        message: response.message,
      }),
      statusCode: 400,
    };
  }

  return {
    headers: {
      "Access-Control-Allow-Origin": "*",
    },
    body: JSON.stringify(response),
    statusCode: 200,
  };
};

module.exports = { main };

PS: "imageBase64" is the actual celebrities image that we will convert on the front-end to base64 and pass it in the request body.

If the code above is too complex, here's what we are doing in short:

1- We are parsing the request body using JSON.parse
2- We validating that the body contains "imageBase64" property
3- We are initializing the "RekognitionClient" Constructor
4- We are passing the "imageBase64" to Rekognition service and awaiting a response
4- We are destructuring the required data from the response
5- In the main handler we are returning a 200 response if all is good - otherwise, we would return a 400 with the error message.

The full back-end code can be found here: https://github.com/AliZgheib/celebrities-face-recognition/tree/main/back-end

Phew!! I believe thats it for the back-end code.

Now lets try to deploy our infrastructure/back-end to AWS by running the commands below:

npm run build

Now we deploy the code (follow the prompt - it should be pretty simple):

cdk deploy

After successfully deploying our API & Lambda, we should get the API URL in the output as follow:

https://XXX.execute-api.us-east-1.amazonaws.com/dev/

"XXX" is your actual API ID (yours should be different)

Based on the above, our API endpoint will be:

https://XXX.execute-api.us-east-1.amazonaws.com/dev/rekognition

That it for the backend!! Hope you made it through with me

Now let's go back to our React application to finalize our application.

In the same main page (or we can move it to a separate helper file for better files organization)

We add the following helper function that will read the uploaded file and convert it to base64

const convertFileToBase64 = async (file: any): Promise<any> => {
  return new Promise((res, rej) => {
    let reader = new FileReader();
    reader.readAsDataURL(file);
    reader.onload = function () {
      res(reader.result);
    };
    reader.onerror = function (error) {
      console.log("Error: ", error);
      rej(error);
    };
  });
};

Now we update the "handleSubmit" function that we previously left empty and add the necessary logic to call our POST /rekognition API endpoint:

  const handleSubmit = async (e: React.FormEvent<HTMLFormElement>) => {
    try {
      e.preventDefault();

      if (!file) {
        return setError("Image not found.");
      }
      setError(null)
      setIsLoading(true);
      const fileBase64 = await convertFileToBase64(file);

      const fileNameClean = fileBase64.split("base64,")[1];

      const rawResponse = await fetch(
        "https://XXX.execute-api.us-east-1.amazonaws.com/dev/rekognition",
        {
          method: "POST",
          headers: {
            Accept: "application/json",
            "Content-Type": "application/json",
          },
          body: JSON.stringify({ imageBase64: fileNameClean }),
        }
      );
      const content = await rawResponse.json();

      setCelebtritiesData(content);
      setShowModal(true);
    } catch (error) {
      setError("Image is invalid or too large.");
    } finally {
      setIsLoading(false);
    }
  };

PS: make sure to replace https://XXX.execute-api.us-east-1.amazonaws.com/dev/rekognition with your actual API endpoint

And that should be it!! Now you can try out the application and you should get very similar results to what I show cased at the start.

I hope you were able to follow along with me and that you enjoyed my article 😀

If you would like to take the React application to the next level and host it on AWS (using S3 and CloudFront as a caching solution) - Checkout the article that I recently wrote: https://dev.to/alizgheib/how-to-deploy-a-react-application-to-aws-using-aws-s3-aws-cloudfront-42km