DEV Community: Rashwan Lazkani

Building an AI-Powered News App with AWS Bedrock and Strands Agents

Rashwan Lazkani — Sun, 15 Mar 2026 09:24:03 +0000

A fully serverless AI powered news app built with AWS Lambda, DynamoDB, Bedrock, and a SwiftUI client.

What if your news feed actually understood what you care about?

Not just broad categories like tech or sports, but specific interests like AI agents, Formula 1, or decentralized finance.

That question led me to build NewsAI, a fully serverless, AI powered personalized news application running entirely on AWS with a native iOS client built using SwiftUI.

In this article I walk through

The architecture
The AWS services involved
How the Strands Agents SDK connects everything to Claude on Amazon Bedrock

This project demonstrates how modern AI infrastructure can power real world developer applications with almost zero operational overhead.

Architecture Overview

Everything is serverless
No servers to manage
No containers to orchestrate

Just Lambda functions, DynamoDB, and Claude doing the reasoning through Amazon Bedrock.

AWS Services Used

Service	Purpose
AWS Lambda	Handles the application logic including news retrieval and personalization
Amazon API Gateway	Exposes the REST API endpoints
Amazon DynamoDB	Stores user topic preferences
Amazon Bedrock	Provides Claude models for AI reasoning
Strands Agents SDK	Simplifies building AI agents on top of Bedrock
IAM	Provides secure permissions between services

Infrastructure is deployed using Serverless Framework v3.

Personalization Pipeline

1. User Selects Interests

The iOS application presents topic categories:

When a user selects a topic, subinterest chips appear:

These preferences are sent to the backend and stored in DynamoDB.

The handler distinguishes between new and returning users. New users get a full record created, while returning users receive a partial update that only patches the fields they changed.

if (!existing) {
  const preferences = {
    userId,
    topics,
    interestDescription,
    language: "en",
    maxArticles: 10,
    updatedAt: new Date().toISOString(),
  }
  await putPreferences(preferences)
} else {
  await updatePreferences(userId, { topics, interestDescription })
}

When users select subinterests like LLMs or Agents under the AI topic, those selections are combined into an interestDescription field such as "Specifically interested in: LLMs, Agents". This description is later passed directly into the AI prompt and is what enables fine grained relevance scoring beyond broad topic matching.

2. Fetch Raw News

When the user opens the application the API endpoint /news is called.

The backend retrieves preferences and fetches news articles from the NewsAPI service using axios. Requests for each topic run in parallel using Promise.allSettled, which means a failure in one topic does not break the entire request.

const requests = preferences.topics.map(topic =>
  axios.get(`https://newsapi.org/v2/everything`, {
    params: { q: topic, language, pageSize, sortBy: "publishedAt", apiKey },
  })
)

const responses = await Promise.allSettled(requests)

3. AI Personalization Using Strands Agents

The raw articles are sent to an AI agent powered by Claude.

The agent performs three tasks:

Score each article from 0 to 100 based on relevance
Generate a one sentence summary
Match the article to the user topics

Example agent configuration:

import { Agent, BedrockModel } from "@strands-agents/sdk"

const agent = new Agent({
  model: new BedrockModel({
    modelId: "eu.anthropic.claude-sonnet-4-6",
    region: "eu-north-1",
    maxTokens: 4096,
  }),
  systemPrompt: `You are a news personalization engine. Given a user's topic
preferences, their specific interest description, and a list of news articles,
you score each article (0-100) on relevance to the user, write a one-sentence
summary, and identify which of the user's topics it matches.

When the user provides a detailed interest description, use it to score more
precisely. Articles that closely match their specific interests should score
much higher than articles that only match the broad topic category.`,
})

The user prompt includes both the broad topics and the specific interest description, which is what allows the agent to differentiate between a general AI article and one specifically about LLM agents.

User preferences:
  Topics of interest: technology, ai
  Specific interests: Specifically interested in: LLMs, Agents

Articles to evaluate (30 total):
[...]

Only include articles with relevanceScore >= 30.
Sort by relevanceScore descending.

The agent instance is cached at the module level, so warm Lambda invocations reuse the same agent without reinitializing the Bedrock connection.

4. Return Ranked Results

Articles scoring below 30 are filtered out
Remaining articles are sorted by relevance and returned to the mobile client
The SwiftUI interface displays them as a modern native news feed

Why Use the Strands Agents SDK

Many AI frameworks exist today. This project intentionally keeps the stack minimal.

Benefits include:

Native Bedrock integration
Automatic retry and streaming handling
Agent reuse across Lambda warm invocations
Very small API surface

In practice the actual model invocation is a single call:

const result = await agent.invoke(prompt)

The surrounding code handles prompt construction and response parsing, but the SDK abstracts away all Bedrock connection management, retries, and streaming.

Amazon Bedrock Inference Profiles

Claude models on Bedrock require inference profiles for scalable usage.

Instead of using the raw model identifier, a regional profile is used.

Example

eu.anthropic.claude-sonnet-4-6

This allows AWS to automatically route inference requests across European regions while keeping data within the EU.

This is important for compliance sensitive applications.

The SwiftUI Client

The client application is written using native SwiftUI and includes

Glass style interface using ultraThinMaterial
Interactive topic picker
Built in article reader using SafariViewController
Automatic dark mode support
Local preference persistence

Example SwiftUI interaction

ForEach(Topic.all) { topic in
    TopicCard(topic: topic) {
        toggleSelection(topic)
    }
}

Infrastructure as Code

The backend infrastructure is defined in a single Serverless configuration file.

service: news-ai
provider:
  name: aws
  runtime: nodejs20.x
  region: eu-north-1

Deployment requires only

sls deploy

For local development the project includes serverless-offline, which lets you run the full API locally without deploying.

sls offline start

This starts a local server at http://localhost:3000 with both endpoints available.

Lessons Learned

AI powered personalization benefits significantly from detailed interest signals
Broad categories such as AI are too vague
Subinterest signals such as LLMs or Agents dramatically improve relevance scoring because they flow directly into the agent prompt as a specific interest description
Warm Lambda reuse of agents also improves performance significantly

Future Improvements

Push notifications for breaking news
Tracking reading history
Additional sources such as RSS and Hacker News
Agent tools for contextual search and fact verification

Try It Yourself

Clone the repository: https://github.com/rashwanlazkani/news-ai
Set your NEWS_API_KEY environment variable which can be retrieved from https://newsapi.org
Run sls deploy
Enable Bedrock access from the AWS Console
Set the API_BASE_URL in the iOS project's Info.plist to your API Gateway URL
Build and run the iOS client

You now have a complete AI powered application running entirely on AWS.

Final Thoughts

Modern AI infrastructure has made it possible to build production ready intelligent applications with minimal infrastructure.

Combining:

AWS Lambda
Amazon DynamoDB
Amazon Bedrock
Strands Agents SDK

Creates an extremely powerful developer stack.

Add SwiftUI on the client side and you have a modern AI application architecture.

If you enjoyed this article and want to see more deep dives into serverless AI architectures, follow along for future projects.

Building Resilient Serverless Workloads with the Circuit Breaker Pattern

Rashwan Lazkani — Sun, 23 Nov 2025 20:16:40 +0000

Modern distributed systems rely on many external dependencies. Payments,
user verification, notifications, data enrichment and these often live
outside your control. When one of those services becomes unhealthy, your
architecture needs to protect itself.

In this article, we will look at how the Circuit Breaker pattern helps you prevent cascading failures, reduce wasted retries, and allow systems to recover gracefully. We will also walk through an AWS Lambda implementation using DynamoDB as the state store and see how the entire flow works in real serverless applications.

What the Circuit Breaker Pattern Helps You Achieve

Detects when a dependency becomes unhealthy
Stops sending requests that are likely to fail
Gives downstream systems time to recover
Performs periodic test calls to check if the service is healthy again
Works extremely well with a storage-first approach
Prevents cascading failures and wasted retries
Introduces a small amount of latency and state handling
Requires tuning of thresholds and cooldown settings

Retries are helpful only up to a point. Once a dependency is clearly
failing, additional retries simply increase the pressure on an already struggling service.

This is where the Circuit Breaker protects the rest of your architecture.

A Simple Way to Think About It

Think of it like an electrical circuit

Closed → electricity flows and everything works
Open → flow stops until it is safe again

When the path is closed, electricity flows freely and the system stays healthy.

When the circuit opens, the flow stops in order to prevent damage.

Your architecture behaves the same way. If a downstream dependency fails too often, you open the circuit and stop sending calls for a while. After a cooldown period, you allow a few test calls in a half-open state to check if things recovered.

Architecture: Circuit Breaker with AWS Lambda, DynamoDB and an External API

OPEN State Diagram

Flow Description

A request enters through Amazon API Gateway which triggers the Lambda function
The Lambda function checks the circuit breaker status stored in DynamoDB
If the circuit is open, the Lambda function fails fast and returns the result
If the circuit is closed, the Lambda function calls the external dependency (Stripe in this example)
If the call fails, the failure counter is increased
If the failure counter crosses the configured threshold, the circuit opens and calls stop for a while
After the cooldown period, the system transitions into half-open state
A few test calls decide if the dependency recovered. If successful, the circuit closes again. If not, it reopens

Closed and Half-Open Flow

Description

A request enters through API Gateway
The Lambda function reads the current circuit status
Since it is in closed or half-open state, it makes a call to the external API
If the call fails, the failure count increments
An error is returned to the customer
If the call succeeds, the failure count is decreased or reset
The value is returned to the caller

Circuit Recovery Flow

When the number of failures exceed the threshold, the circuit opens
After a cooldown window, the system moves into half-open state
A few test calls determine if the dependency is healthy again
If successful, the circuit closes and traffic resumes
If failures continue, the circuit reopens and the cycle repeats

This makes the system self-healing without manual intervention.

Implementing a Circuit Breaker in AWS Lambda

Below is a simple TypeScript example showing how this pattern can be
implemented using Lambda and DynamoDB.

How the Code Works

Load circuit state from DynamoDB
- If no record exists, a new one is created with closed state
If the circuit is OPEN
- Check if the cooldown has passed
- If cooldown expired → move to HALF-OPEN
- Otherwise → fail fast without calling the dependency
Make the dependency call (e.g., Stripe)
- If successful:
  - If HALF-OPEN → close the circuit and reset the failure counter
  - If CLOSED → keep the circuit closed
- If failed:
  - Increment failure counter atomically
  - If threshold reached → open the circuit and set openedAt
Update DynamoDB with conditional writes
- Prevents concurrent Lambdas from overwriting each other

DynamoDB Table Structure

{
  "serviceName": "stripe",
  "state": "closed",
  "failureCount": 0,
  "openedAt": 0,
  "lastUpdated": 1732098200
}

Lambda Function (TypeScript)

import {
  DynamoDBClient,
  GetItemCommand,
  UpdateItemCommand,
} from "@aws-sdk/client-dynamodb";
import axios from "axios";

const TABLE = process.env.CIRCUIT_TABLE!;
const FAILURE_THRESHOLD = 5;
const COOLDOWN_SECONDS = 60;

const db = new DynamoDBClient({});

export async function handler(event: any) {
  const status = await getCircuitStatus("stripe");

  // OPEN → maybe move to HALF-OPEN
  if (status.state === "open") {
    const now = Math.floor(Date.now() / 1000);

    const elapsed = now - status.openedAt;

    if (elapsed >= COOLDOWN_SECONDS) {
      await setState("stripe", "half-open", status.failureCount, status.openedAt);
      status.state = "half-open";
    } else {
      return failFast("Circuit is open, failing fast");
    }
  }

  // Attempt dependency call
  try {
    const response = await axios.get(
      "https://api.stripe.com/health-check",
      { timeout: 3000 }
    );

    // HALF-OPEN success → CLOSE circuit
    if (status.state === "half-open") {
      await setState("stripe", "closed", 0, 0);
    }

    // CLOSED → remain closed (do not increase failures)
    return response.data;

  } catch (err) {
    // Failure: increment counter atomically
    const updatedCount = await incrementFailure("stripe");

    // Trip the circuit
    if (updatedCount >= FAILURE_THRESHOLD) {
      const now = Math.floor(Date.now() / 1000);
      await setState("stripe", "open", updatedCount, now);
    }

    throw new Error("Dependency call failed");
  }
}

// Load or initialize circuit state
async function getCircuitStatus(service: string) {
  const result = await db.send(new GetItemCommand({
    TableName: TABLE,
    Key: { serviceName: { S: service } },
  }));

  if (!result.Item) {
    // Initialize default state
    await setState(service, "closed", 0, 0);
    return {
      state: "closed",
      failureCount: 0,
      openedAt: 0,
      lastUpdated: 0
    };
  }

  return {
    state: result.Item.state.S,
    failureCount: Number(result.Item.failureCount.N),
    openedAt: Number(result.Item.openedAt.N),
    lastUpdated: Number(result.Item.lastUpdated.N)
  };
}

// Atomic increment of failureCount
async function incrementFailure(service: string) {
  const now = Math.floor(Date.now() / 1000);

  const result = await db.send(new UpdateItemCommand({
    TableName: TABLE,
    Key: { serviceName: { S: service } },
    UpdateExpression: "SET failureCount = failureCount + :inc, lastUpdated = :now",
    ExpressionAttributeValues: {
      ":inc": { N: "1" },
      ":now": { N: String(now) },
    },
    ReturnValues: "UPDATED_NEW",
  }));

  return Number(result.Attributes.failureCount.N);
}

// Controlled state changes (atomic write)
async function setState(
  service: string,
  state: string,
  failureCount: number,
  openedAt: number
) {
  const now = Math.floor(Date.now() / 1000);

  await db.send(new UpdateItemCommand({
    TableName: TABLE,
    Key: { serviceName: { S: service } },
    UpdateExpression:
      "SET #s = :s, failureCount = :fc, openedAt = :oa, lastUpdated = :now",
    ExpressionAttributeNames: {
      "#s": "state",
    },
    ExpressionAttributeValues: {
      ":s": { S: state },
      ":fc": { N: String(failureCount) },
      ":oa": { N: String(openedAt) },
      ":now": { N: String(now) },
    }
  }));
}

// Fast failure response
function failFast(message: string) {
  return {
    statusCode: 503,
    body: JSON.stringify({ message }),
  };
}

Final Thoughts

The Circuit Breaker pattern is one of the simplest ways to make your architecture more resilient, cost-efficient, and self-healing. Combined with storage-first ingestion, exponential backoff, and reasonable retry policies, it becomes a powerful tool in any distributed system.

If you are building production systems that depend on external services or shared infrastructure, this pattern deserves a place in your toolbox.

Preventing Breaking Changes in Event-Driven Systems with Contracts and Validation

Rashwan Lazkani — Sun, 02 Nov 2025 19:16:25 +0000

Event-driven systems are powerful, but they can also be fragile.
A small schema change in one service can silently break others down the line, the classic breaking change problem.

While no approach can completely eliminate breaking changes, contracts and validation can drastically reduce the risk and help you catch issues early before they ever reach production. If you’ve worked with event-driven systems long enough, you’ve probably seen this firsthand: a single schema tweak that silently breaks consumers down the line.

What makes this so tricky isn’t just that it happens; it’s that it’s often hard to detect until something fails in production.
A renamed field or missing property can lead to failed parsing, corrupted data, or silent business logic errors.

That’s why schema validation, contract testing, and automated checks in the pipeline matter. They provide a safety net that helps catch breaking changes before customers feel the impact.

How To Prevent Downstream Errors

There are many approaches. Here are two that work well in AWS-based event systems:

1. Use AWS EventBridge Schema Registry

EventBridge includes a schema registry that can auto-discover and store schemas (note: there are additional costs).
You can also build your own registry or keep schemas in version control.

A registry alone isn’t enough.

You also need versioning and notification: publishers must announce new versions and consumers need time to adapt.

Without a clear process, consumers risk breaking silently.

2. Version Your Contracts

If you introduce a breaking change, don’t overwrite the existing event.

Create a new version and let both exist in parallel for a while.

Communicate the change, give consumers time to migrate, and then decommission the old version.

Why Contracts Matter

Contracts make payloads explicit, verifiable, and testable.

They serve as a shared truth between publishers and consumers.

Without contracts:

You rely on implicit expectations
Breaking changes slip through unnoticed
Downstream failures become unpredictable

With contracts:

You can validate every incoming event against a defined schema
You can version safely (support v1 and v2 side by side)
You can catch errors early, for example through CI/CD validation

How Contract Validation Fits into the Architecture

Producers publish events to an SQS queue
A Lambda function consumes and validates each event against the expected contract version (v1, v2, etc.)
If validation fails, the event is retried and eventually sent to a DLQ for inspection (e.g., maxReceiveCount: 3)

This setup ensures that only valid, contract-compliant messages are processed while invalid ones are isolated automatically.

Example: Versioned Contracts with Zod and TypeScript

Let’s start with a v1 contract and see how we can introduce a v2 version without breaking compatibility for existing producers.

`src/contracts/messageV1.ts`

This is our first version of the message contract. It defines the structure that all incoming events must follow, including required fields like id, type, and a payload with a valid timestamp.

import { z } from 'zod';

export const MessageV1 = z.object({
  id: z.string().uuid(),
  type: z.enum(['INFO', 'WARNING', 'ERROR']),
  payload: z.object({
    title: z.string().min(1),
    description: z.string().min(1),
    timestamp: z.string().refine((val) => !isNaN(Date.parse(val)), {
      message: 'Invalid timestamp format',
    }),
  }),
});

export type MessageV1Type = z.infer<typeof MessageV1>;

`src/contracts/messageV2.ts`

Version 2 extends the original contract by adding a version field and an optional userEmail field in the payload. This shows how to evolve an event schema without breaking existing producers.

import { z } from 'zod';
import { MessageV1 } from './messageV1';

export const MessageV2 = MessageV1.extend({
  version: z.literal('2'),
  payload: MessageV1.shape.payload.extend({
    userEmail: z.string().email().optional(),
  }),
});

export type MessageV2Type = z.infer<typeof MessageV2>;

src/contracts/messageSchema.ts (optional central registry)

A central registry combines all supported contract versions into one schema.
This allows you to validate messages dynamically, regardless of whether they’re version 1 or version 2.

import { z } from 'zod';
import { MessageV1 } from './messageV1';
import { MessageV2 } from './messageV2';

export const MessageSchema = z.union([MessageV1, MessageV2]);
export type MessageType = z.infer<typeof MessageSchema>;

src/handler.ts (detect version first, then validate)

The Lambda handler receives events from SQS, detects the contract version, and validates the message accordingly.
Each version can be processed differently while maintaining backward compatibility and clear validation boundaries.

import { SQSHandler } from 'aws-lambda';
import { MessageV1 } from './contracts/messageV1';
import { MessageV2 } from './contracts/messageV2';

export const processMessage: SQSHandler = async (event) => {
  for (const record of event.Records) {
    try {
      const body = JSON.parse(record.body);
      const isV2 = 'version' in body && body.version === '2';

      if (isV2) {
        const message = MessageV2.parse(body);
        console.log('Processing V2 message', {
          id: message.id,
          type: message.type,
          title: message.payload.title,
          email: message.payload.userEmail || '(no email)',
          timestamp: message.payload.timestamp,
        });
        // V2-specific logic here
      } else {
        const message = MessageV1.parse(body);
        console.log('Processing V1 message', {
          id: message.id,
          type: message.type,
          title: message.payload.title,
          timestamp: message.payload.timestamp,
        });
        // V1 logic continues unchanged
      }
    } catch (error: any) {
      console.error('Message failed validation or processing', {
        body: record.body,
        error: error.message,
      });
      throw error; // Let SQS retry and route to DLQ after threshold
    }
  }
};

Sample Messages

These examples show how valid and invalid messages look for each version of the contract.

Invalid messages will fail validation at runtime and be retried or sent to the DLQ, depending on your configuration.

Valid v1

A valid v1 message that includes all required fields: id, type, and a properly formatted payload.

{
  "id": "e7b1c37b-7b73-4d84-97a4-dc5a3e91c121",
  "type": "INFO",
  "payload": {
    "title": "Legacy Order Processed",
    "description": "Order completed successfully.",
    "timestamp": "2025-10-28T10:00:00Z"
  }
}

Invalid v1

This message is missing the description field inside payload and will fail validation.

{
  "id": "e7b1c37b-7b73-4d84-97a4-dc5a3e91c121",
  "type": "INFO",
  "payload": {
    "title": "Legacy Order Processed",
    "timestamp": "2025-10-28T10:00:00Z"
  }
}

Valid v2

A valid v2 message with the new version field and optional userEmail included.

{
  "version": "2",
  "id": "a8cb7c7f-93a0-4b24-b15d-63d9289ce9b1",
  "type": "INFO",
  "payload": {
    "title": "User Registered",
    "description": "New user created account.",
    "timestamp": "2025-10-28T10:10:00Z",
    "userEmail": "john@example.com"
  }
}

Invalid v2

This message fails validation because the userEmail field is not a valid email address and the timestamp format is invalid.

{
  "version": "2",
  "id": "a8cb7c7f-93a0-4b24-b15d-63d9289ce9b1",
  "type": "INFO",
  "payload": {
    "title": "User Registered",
    "description": "New user created account.",
    "timestamp": "not-a-date",
    "userEmail": "not-an-email"
  }
}

Why This Approach Works

Backward compatible: Existing v1 producers continue to work without changes
Forward ready: v2 producers can safely introduce new fields without breaking v1 consumers
Safe evolution: You can log and monitor usage across versions, then deprecate v1 once all consumers have migrated
Confidence: Every message is validated against a known contract, ensuring predictable and reliable behavior

Conclusion

In this post, we’ve explored how to prevent downstream errors caused by breaking changes in event-driven systems using contracts and validation.

By defining clear schemas, versioning events properly, and validating messages early, you can build systems that evolve safely without disrupting existing consumers.

The examples using Zod, TypeScript, and AWS services like Lambda and SQS showed how these principles can be applied in practice, giving you confidence that every message is well-structured, validated, and backward compatible.

All the source code used in this article is available on GitHub:

github.com/rashwanlazkani/aws-contract-testing

Here are the key takeaways to keep in mind:

Treat event schemas as public contracts. Design them with the same care as APIs since multiple services depend on them.
Use validation (for example, with Zod) and/or a schema registry to enforce structure and catch issues early.
Always version breaking changes instead of overwriting existing events and maintain backward compatibility during migration.
Validate early, fail fast, and communicate schema changes clearly across teams to prevent downstream failures.

Event-driven architectures thrive on autonomy and decoupling, but without clear contracts, that autonomy can quickly turn into chaos.

Contracts and validation keep your systems predictable, resilient, and future-proof.

How to Effectively Handle Caching in Your Application: Lazy Loading vs Write-Through

Rashwan Lazkani — Tue, 26 Nov 2024 22:01:41 +0000

Caching is a powerful technique for optimizing application performance, reducing database load, and ensuring faster response times for users. But choosing the right caching strategy is crucial to achieving these benefits without compromising on data consistency or resource usage. In this article, we’ll explore two popular caching strategies Lazy Loading and Write-Through and break down their workflows step by step to help you decide which approach suits your application's needs.

Lazy Loading

In the Lazy Loading caching strategy, data is loaded into the cache only when requested by the application. This ensures that only frequently accessed data resides in the cache, reducing unnecessary storage overhead. However, this approach might lead to cache misses during the first request for any data.

Steps in Lazy Loading:

Step 1 User Request: The user initiates a request for data. The application server, hosted on EC2, checks the cache (ElastiCache in this case) for the requested data.

Step 2 Cache Lookup: If the requested data is found in the cache (cache hit), it is returned to the EC2 instance immediately.

Step 3.1 Cache Miss: If the data is not found in the cache, a cache miss occurs. The application fetches the data from the database (Aurora).

Step 3.2 Data Fetching: The EC2 instance queries the Aurora database to retrieve the requested data.

Step 4 Cache Update: After fetching the data from the database, the EC2 instance writes it to the cache to make it available for future requests.

Step 5 Response Sent: Finally, the requested data is returned to the user.

Pros of Lazy Loading:

Reduces cache storage usage by only storing requested data.
Simple and efficient for read-heavy workloads.

Cons of Lazy Loading:

The first request for uncached data may experience higher latency (cache miss).
Cache might not reflect updates unless explicitly managed.

Write-Through

The Write-Through caching strategy ensures that the cache is always updated simultaneously with the database. Whenever data is written or updated in the database, the same operation is performed on the cache, making it consistent with the database at all times. This strategy eliminates cache misses for recently written or updated data.

Steps in Write-Through:

Step 1 User Request: The user sends a request to write or update data. The application server (EC2) processes this request.

Step 2.1 Database Update: The EC2 instance writes or updates the data in the primary database (Aurora).

Step 2.2 Cache Update: Simultaneously, the same write or update operation is performed on the cache (ElastiCache). This ensures that the cache stays synchronized with the database.

Step 3 Response Sent: Finally, the requested data is returned to the user.

Pros of Write-Through:

Eliminates cache misses for updated data, ensuring consistency between the cache and database.
Suitable for write-heavy workloads where data consistency is critical.

Cons of Write-Through:

Higher latency for write operations due to dual writes (database + cache).
Increased cache storage usage since all data is cached regardless of access patterns.

Choosing the Right Strategy

The choice between Lazy Loading and Write-Through depends on the application requirements:

Lazy Loading is ideal for read-heavy applications where minimizing cache storage and handling occasional cache misses is acceptable.
Write-Through is suitable for write-heavy or consistency-critical applications where cache misses are not tolerable.

Both strategies can be used in tandem or modified to fit specific use cases, such as adding TTL (Time-to-Live) policies for expiring stale cache data.

Conclusion

Choosing the right caching strategy—whether it’s Lazy Loading or Write-Through—depends on your application’s workload and performance requirements. Lazy Loading is great for reducing cache storage and handling read-heavy operations, while Write-Through ensures consistency for write-heavy scenarios. Both have their advantages and trade-offs, so understanding your use case is key.

If you have any questions or insights about caching strategies, feel free to reach out or start a discussion in the comments!

Building an AI-Powered iOS Chat App with Amazon Bedrock and Swift

Rashwan Lazkani — Thu, 31 Oct 2024 00:37:45 +0000

This post will teach you to create a native iOS app using Amazon Bedrock to build AI-powered chat and image features in Swift. We’ll leverage Serverless resources, including AWS Lambda and API Gateway, for the backend.

The sample application includes the following:

A mobile application using Swift
An integration to Amazon Bedrock using the models amazon.titan-image-generator-v1 and ai21.j2-mid-v1
Serverless backend processing using AWS Lambda with TypeScript
Implementation of RESTful APIs using Amazon API Gateway for communication
Use Amazon CloudWatch Logs to monitor AWS Lambda functions and view their logs

The final result will be the following app:

Prerequisites

Before you get started, make sure you have the following installed:

An AWS account
Node.js v18 or later
Serverless Framework, AWS SAM or AWS CDK (depending on if you want to use Infrastructure as Code. I'll be using Serverless Framework)
Package manager, I'll be using yarn
Xcode version 15 or later

Architecture

Users access the application from their mobile devices and the app sends a request to Amazon API Gateway
API Gateway routes the request to either the ImageFunction or TextFunction Lambda
AWS Lambda communicates with an Amazon Bedrock model and retrieves the generated response in JSON format
The processed response is sent back to the app for display, enabling content or chat interaction

Accessing Amazon Bedrock begins with the following steps

Login to your AWS Console
Go to Amazon Bedrock
In the left navigation click on Model access
Request access – please note that the body may vary depending on the model you select. For the image I will be using the Titan Image Generator G1 model and for the text I will be using the ai21.j2-mid-v1 model

Serverless backend processing using AWS Lambda with TypeScript

You can choose your preferred tool for deploying Lambda functions, but I’ll provide the code necessary to create them:

Text Lambda

Please take note of a few important points below:

You need to import the client-bedrock-runtime package
You need to add the modelId
The prompt is the search text provided from your API

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

const client = new BedrockRuntimeClient({ region: 'us-east-1' });

export async function handler(event: any) {
  const prompt = JSON.parse(event.body).prompt;
  const input = {
    modelId: 'ai21.j2-mid-v1',
    contentType: 'application/json',
    accept: '*/*',
    headers: {
      'Access-Control-Allow-Headers': 'Content-Type',
      'Access-Control-Allow-Origin': '*',
      'Access-Control-Allow-Credentials': true,
      'Access-Control-Allow-Methods': 'POST'
    },
    body: JSON.stringify({
      prompt: prompt,
      maxTokens: 200,
      temperature: 0.7,
      topP: 1,
      stopSequences: [],
      countPenalty: { scale: 0 },
      presencePenalty: { scale: 0 },
      frequencyPenalty: { scale: 0 }
    })
  };

  try {
    const data = await client.send(new InvokeModelCommand(input));
    const jsonString = Buffer.from(data.body).toString('utf8');
    const parsedData = JSON.parse(jsonString);
    const text = parsedData.completions[0].data.text;
    return text;
  } catch (error) {
    console.error(error);
  }
}

Image Lambda

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

const client = new BedrockRuntimeClient({ region: 'us-east-1' });

export async function handler(event: any) {
  const prompt = JSON.parse(event.body).prompt;
  const input = {
    modelId: 'amazon.titan-image-generator-v1',
    contentType: 'application/json',
    accept: 'application/json',
    headers: {
      'Access-Control-Allow-Headers': 'Content-Type',
      'Access-Control-Allow-Origin': '*',
      'Access-Control-Allow-Credentials': true,
      'Access-Control-Allow-Methods': 'POST'
    },
    body: JSON.stringify({
      textToImageParams: {
        text: prompt
      },
      taskType: 'TEXT_IMAGE',
      imageGenerationConfig: {
        cfgScale: 10,
        seed: 0,
        width: 512,
        height: 512,
        numberOfImages: 1
      }
    })
  };

  try {
    const command = new InvokeModelCommand(input);
    const response = await client.send(command);

    const blobAdapter = response.body;

    const textDecoder = new TextDecoder('utf-8');
    const jsonString = textDecoder.decode(blobAdapter.buffer);

    try {
      const parsedData = JSON.parse(jsonString);
      return parsedData.images[0];
    } catch (error) {
      console.error('Error parsing JSON:', error);
      return 'TextError';
    }
  } catch (error) {
    console.error(error);
  }
}

Now deploy your Lambdas, if you're using Serverless Framework you can use the following configuration:

service: aws-bedrock-ts
frameworkVersion: '3'

provider:
  name: aws
  runtime: nodejs18.x
  timeout: 30
  iam:
    role:
      statements:
        - Effect: 'Allow'
          Action:
            - 'bedrock:InvokeModel'
          Resource: '*'

functions:
  bedrockText:
    handler: src/bedrock/text.handler
    name: 'aws-bedrock-text'
    events:
      - httpApi:
          path: /bedrock/text
          method: post
  bedrockImage:
    handler: src/bedrock/image.handler
    name: 'aws-bedrock-image'
    events:
      - httpApi:
          path: /bedrock/image
          method: post

You will now be granted the API endpoints to your Lambdas, save those.

Developing your iOS app

Setting Up the Project

Start by creating a new Swift project in Xcode.
Name the project according to your app (e.g., BedrockSwift).

ChatMessage Model

First, define a model to store your chat messages, which could either be text or images. I'll name my class ChatMessage.swift:

import UIKit

struct ChatMessage: Equatable {
    var text: String?
    var image: UIImage?
    var isImage: Bool
    var isUser: Bool
}

Service for Handling API Requests

This service is responsible for managing API interactions, including sending prompts to your Lambda functions and processing the responses. Make sure to update your endpoints to your Lambdas. I'll name my class APIService.swift:

import UIKit

class APIService: ObservableObject {

    @Published var messages: [ChatMessage] = []

    private func getEndpointURL(for type: String) -> URL? {
        let baseURL = "https://example.execute-api.region.amazonaws.com/bedrock"

        switch type {
        case "text":
            return URL(string: "\(baseURL)/text")
        case "image":
            return URL(string: "\(baseURL)/image")
        default:
            return nil
        }
    }

    func addUserPrompt(_ prompt: String) {
        messages.append(ChatMessage(text: prompt, image: nil, isImage: false, isUser: true))
    }

    func sendRequest(prompt: String, type: String, completion: @escaping () -> Void) {
        guard let url = getEndpointURL(for: type) else {
            print("Invalid URL for type: \(type)")
            return
        }

        var request = URLRequest(url: url)
        request.httpMethod = "POST"
        let parameters: [String: Any] = ["prompt": prompt]

        request.httpBody = try? JSONSerialization.data(withJSONObject: parameters)
        request.addValue("application/json", forHTTPHeaderField: "Content-Type")

        URLSession.shared.dataTask(with: request) { data, response, error in
            if let error = error {
                print("Error: \(error)")
                return
            }

            guard let data = data else { return }
            print(data)

            DispatchQueue.main.async {
                if type == "text" {
                    if let responseString = String(data: data, encoding: .utf8) {
                        let trimmedResponse = responseString.trimmingCharacters(in: .whitespacesAndNewlines)
                        self.messages.append(ChatMessage(text: trimmedResponse, image: nil, isImage: false, isUser: false))
                    }
                } else {
                    DispatchQueue.main.async {
                        if let base64String = String(data: data, encoding: .utf8),
                           let imageData = Data(base64Encoded: base64String, options: .ignoreUnknownCharacters),
                           let image = UIImage(data: imageData) {

                            DispatchQueue.main.async {
                                self.messages.append(ChatMessage(text: nil, image: image, isImage: true, isUser: false))
                            }
                        }
                    }
                }
                completion()
            }
        }.resume()
    }
}

View for Chat Interface

Now, create the main view that will handle the UI and display the chat messages. I'll name my file BedrockView.swift:

import SwiftUI

struct BedrockView: View {

    @StateObject var apiService = APIService()
    @State private var prompt: String = ""
    @State private var selectedType = 0
    @State private var isLoading = false

    var body: some View {
        VStack {
            ScrollViewReader { scrollViewProxy in
                ScrollView {
                    VStack {
                        ForEach(apiService.messages.indices, id: \.self) { index in
                            if apiService.messages[index].isImage, let image = apiService.messages[index].image {
                                HStack {
                                    Spacer()
                                    Image(uiImage: image)
                                        .resizable()
                                        .scaledToFit()
                                        .frame(height: 200)
                                        .frame(maxWidth: .infinity, alignment: .leading)
                                        .cornerRadius(10)
                                        .padding(.vertical, 5)
                                }
                            } else if let text = apiService.messages[index].text {
                                HStack {
                                    if apiService.messages[index].isUser {
                                        Spacer()
                                        Text(text)
                                            .padding(.vertical, 6)
                                            .padding(.horizontal, 12)
                                            .background(Color.blue.opacity(0.2))
                                            .cornerRadius(10)
                                            .frame(maxWidth: .infinity, alignment: .trailing)
                                    } else {
                                        Text(text)
                                            .padding(.vertical, 6)
                                            .padding(.horizontal, 12)
                                            .background(Color.gray.opacity(0.2))
                                            .cornerRadius(10)
                                            .frame(maxWidth: .infinity, alignment: .leading)
                                    }
                                }
                                .padding(.vertical, 1)
                            }
                        }
                        if isLoading {
                            ProgressView()
                                .padding(.vertical, 20)
                        }
                    }
                    .padding(.horizontal)
                    .id("BOTTOM")
                }
                .onChange(of: apiService.messages) { _ in
                    withAnimation {
                        scrollViewProxy.scrollTo("BOTTOM", anchor: .bottom)
                    }
                }
            }

            VStack {
                TextField("Enter prompt...", text: $prompt)
                    .textFieldStyle(.roundedBorder)
                    .padding(.horizontal)
                    .padding(.vertical, 10)

                HStack {
                    Picker(selection: $selectedType, label: Text("Type")) {
                        Text("Text").tag(0)
                        Text("Image").tag(1)
                    }
                    .pickerStyle(SegmentedPickerStyle())
                    .frame(maxWidth: .infinity)
                    .padding(.leading, 10)

                    Button(action: {
                        if prompt.isEmpty { return }
                        apiService.addUserPrompt(prompt)
                        let type = selectedType == 0 ? "text" : "image"
                        isLoading = true
                        apiService.sendRequest(prompt: prompt, type: type) {
                            isLoading = false
                        }
                        prompt = ""
                    }) {
                        Text("Send")
                            .frame(width: 100, height: 2)
                            .padding()
                            .background(Color.primary)
                            .foregroundColor(.white)
                            .cornerRadius(10)
                    }
                }
                .padding(.horizontal)
            }
            .padding()
        }
    }
}

struct ContentView_Previews: PreviewProvider {
    static var previews: some View {
        BedrockView()
    }
}

App Entry Point

Go to your file: YourAppNameApp.swift and update the default entry point created when you set up your SwiftUI project. Mine is called BedrockView as you saw above.

import SwiftUI

@main
struct BedrockSwiftApp: App {
    var body: some Scene {
        WindowGroup {
            BedrockView()
        }
    }
}

Running the App in Xcode

Now you're ready to run your app! Follow these steps to launch it in Xcode:

Select a Device: Choose a simulator or connected device from the toolbar.
Build and Run: Click the "Run" button (or press Cmd + R) to build and run the app.

This will launch the app on your selected device, allowing you to interact with Amazon Bedrock's chat and image generation features.

Note a couple of things

As this is a local app for testing, I've set the Access-Control-Allow-Origin to `*. Additionally, you may need to adjust the CORS settings in API Gateway..

Note that API calls may incur a small cost. For detailed pricing information, please refer to the Amazon Bedrock pricing model.

GitHub Repositories

The source code for this project is available on GitHub:

Backend: amazon-bedrock-back
iOS App: amazon-bedrock-app

Conclusion

In this post, I’ve walked you through building a simple AI-chat application for iOS, using native Swift alongside serverless AWS services. By integrating Amazon Bedrock's generative AI models with services like AWS Lambda and API Gateway, we’ve created a streamlined solution that leverages the power of AWS in a native mobile experience. Please note that I’ve aimed to use only native components in the app, though there are certainly areas for improvement. Additionally, securing your API with tokens is essential; I’ll cover this topic in detail in an upcoming post.

Securing Your REST API with JWT Authorizers and Amazon Cognito

Rashwan Lazkani — Thu, 31 Oct 2024 00:15:28 +0000

Most applications today expose an API to facilitate seamless interaction with their features and data. However, ensuring the security of your API is essential for various reasons:

Restrict Access to Authorized Users - Only authenticated users should have access to sensitive functions and data within your API, ensuring that internal information is protected from unauthorized exposure.
Control and Monitor Data Access - By enforcing authentication, you can prevent unauthorized access to data, allowing only verified users to make requests and interact with resources, which significantly reduces potential data leaks.
Protect Against Common Security Threats - Securing your API helps safeguard it from attacks like unauthorized data scraping, injection attacks, and brute force attacks, adding a critical layer of defense against malicious actors.
Ensure Data Integrity and Privacy - When users access your API, you want to ensure that their data remains secure and uncompromised. Proper security protocols help guarantee that data remains intact and private during transit.
Enable Scalability with Controlled Access - With secure API endpoints, you can scale your application more confidently, knowing that only authorized and authenticated users can access each part, reducing the risk of system overload due to malicious requests.

In this post, I’ll walk you through securing your API using JWT Authorizers and Amazon Cognito. But first, let’s clarify what a JWT is and why it’s crucial in securing APIs.

What is a JWT Token?

JSON Web Token - A standard format for securely transmitting information between parties as a JSON object.
Acts as a Secure Identifier for Authenticated Users - Think of it as a secure, encoded token that verifies the identity of authenticated users.
Contains a Verifiable Digital Signature - Each token has a digital signature that our API can validate, ensuring the token’s authenticity and integrity.
Provided by Authentication Services (e.g., AWS Cognito) - Services like AWS Cognito validate the user’s credentials at login and issue a token, which the user includes in every API request for continued access.

How to Set Up Authorization in AWS

Step 1: Create a Lambda Function

Start by creating a Lambda function in AWS. This function will handle your API requests.

Step 2: Set Up an API Gateway

Navigate to API Gateway in the AWS Console.
Create a new REST API.

Step 3: Connect Your Lambda to a GET Method

Select "Create Method" under your API.
Modify settings as highlighted below to connect your Lambda function to a GET method.

Step 4: Deploy Your API

Click on "Deploy API."
Create a new Stage if you don't already have one.

Step 5: Test Your API Endpoint

Copy the Invoke URL from your API.
Paste it into a browser to test the response from your Lambda function.

Adding Security to Your API

Step 6: Create a User Pool in Amazon Cognito

Go to Cognito in the AWS Console
Click Create user pool
For the Cognito user pool sign-in options, select Email
Click Next
For simplicity of this demo select No MFA
Click Next twice
For the Configure message delivery select Send email with Cognito
Click Next and give your user pool a name and also an app client name
Click Next and then Create user pool

Step 7: Create a test user

Click on your newly created user pool
Select Users and Create user
Create your user

Step 8: Set Up the App Integration

Click on your user pool that you just created
Click on App integration
Click on your app client that you created earlier
Click on Hosted UI
Add the following settings:
- Callback URL: https://localhost
- Sign-out URL: https://localhost
- Identity provider: Cognito user pool
- OAuth 2.0 grant types: Implicit grant
- OpenID Connect scopes: Select all options
Click Save changes

Step 9: Create a Domain for Your User Pool

Go back to your main user pool page
Click on Domain --> Actions --> Create Cognito domain
Add the desired domain and check if it's available
Create it

Testing and Parsing the JWT

Step 10: Test your login with the Hosted UI

Go back to your main user pool page
Scroll down to the bottom to the App client list
Click on your app client
Scroll down to Hosted UI
To the right click on View Hosted UI
Login with the credentials that you should have got in the email that you provided earlier
If the login is successful you should come to your callback URL which is https://localhost

Step 11: Parse our JWT

Let's parse our JWT now and explore it.

Go back to your main user pool page
Scroll down to the bottom to the App client list
Click on your app client
Scroll down to Hosted UI
Right click on View Hosted UI and copy the URL
Open Postman (or a similar tool)
Create a new request
Click on Authorization
Give the token a name
Grant type: Implicit 11: Auth URL: paste the URL that you copied from the hosted zone 12: Click on the button Get New Access Token 13: Login with your user 14: Copy the id_token

Step 12: Exploring the Contents of Your JWT

Go to jwt.io
Paste your id_token
On the right side you'll see your decoded payload data

Securing Your API with the JWT Authorizer

Step 13: Create an authorizer

Go to your API that you created
For your GET method you'll see that you don't have any authorization added
To add this click on Authorizers on the left pane
Click on Create authorizers
Add the settings you see below
Create authorizer
You can now click on your newly created authorizer and test it in the console directly

Step 14: Now let's update our method with our new authorizer

Go back to your GET method in your API
On the Method request settings select Edit
On the Authorization select your newly created authorizer
Click Save and the redeploy your API

Step 15: Let's test our new API endpoint with our authorizer

Go back to Postman to your request and use your GET method and click Send
You should now get:

{
    "message": "Unauthorized"
}

But let's generate a token and then add a new Header:
Key: Authorization
Value: Your id_token

Click send and you should now see:

"Hello from Lambda!"

Conclusion

Congratulations! You’ve successfully secured your API using JWT authorizers and Amazon Cognito. This setup provides robust authentication, ensuring only authorized users access your resources. With stateless JWTs, your API scales effortlessly without session management overhead. Plus, strong API security builds user trust and helps meet compliance standards.

With this foundation, your API is more secure, scalable, and ready to grow alongside your application’s needs.

How to set up AWS Budget Alerts to prevent surprises

Rashwan Lazkani — Fri, 15 Mar 2024 15:36:46 +0000

In this post, I'll explain how to set up an AWS Budget Alert and why it's important.

Why is it good to set up a budget alert?

You can use AWS Budgets to track and take action on your AWS costs and usage. You can use AWS Budgets to monitor your aggregate utilization and coverage metrics for your Reserved Instances (RIs), or Savings Plans.

You can monitor and receive notifications on your budgets free of charge. In addition to budget monitoring, you can add actions to your budgets to control IAM and Service Control Policy permissions as well as AWS resources when thresholds are exceeded (or forecasted to exceed).

How to set up AWS Budget Alerts

Begin by clicking on your logged-in name located in the top-right corner, then select "Billing and Cost Management" from the dropdown menu.

If you encounter an error message stating "You Need Permissions," it indicates that you are using an IAM user without access to the Billing and Cost Management dashboard.

To address this issue, follow these steps:

Login as the Root user
Click on you Root account on the top-right corner and select "My Account"
Scroll down to "IAM User and Role Access to Billing Information"
Click "Edit"
Check the "Activate IAM Access" checkbox
Click "Update"

Now you should be able to set up budgets using your IAM user. Follow these steps to set up a budget:

Go to the "Billing and Cost Management"
Click "Budgets" on the left pane
Click "Create a Budget"
Here select a budget type, I have selected a monthly budget of 100$

Monitor the created budget

You can always navigate to "Billing and Cost Management" > "Budgets" and select your budget to monitor it. And also:

Compare current spending to budgeted amount
Compare forecasted spending to budgeted amount (Month-to-date)
See your budget history
Change the budget period
Update the budgeted amount ($)
Set the budget scope by adding filtering and use advanced options to narrow the set of cost information tracked as part of this budget
Update the email recipients
Setup Amazon SNS alerts
Setup AWS Chatbot Alerts - AWS Chatbot lets you send budget alerts to the Amazon Chime, Slack or Microsoft Teams chat rooms of your choice which can by handy
Set alert thresholds - When should this alert be triggered? And how should this alert be triggered?

Conclusion

Setting up budget alerts is essential to avoid surprises. Additionally, I recommend configuring AWS Chatbot Alerts to receive notifications in your preferred channel. If you have any questions or thoughts, please feel free to comment!

Implement AWS Lambda Advanced Logging Controls using Infrastructure as Code

Rashwan Lazkani — Fri, 22 Dec 2023 16:50:59 +0000

Some time ago, AWS release advanced logging controls for AWS Lambda. This gives developers and operators greater control over how function logs are captured, processed, and consumed.

There are three new capabilities introduced:

You can capture Lambda function logs in JSON structured format without having to use your own logging libraries. JSON structured logs make it easier to search, filter, and analyze large volumes of log entries.
You can control the log level granularity of Lambda function logs without making any code changes, enabling more effective debugging and troubleshooting.
You can also set which Amazon CloudWatch log group Lambda sends logs to, making it easier to aggregate and manage logs at scale.

In this article I will show you how you can implement the Advanced Logging Controls using Infrastructure as Code. I will show you an example using Serverless Framework.

Why is this good to implement?

Imagine you have an application with multiple Lambdas, and now you have the capability to query logs from various sources simultaneously. This provides you with increased control over the capture, processing, and consumption of the logs of your Functions. For instance, you can seamlessly query this data in CloudWatch Log Insights by selecting your aggregated log group, encompassing all the Lambdas you've added for logging.

Let's implement this using Serverless Framework. For this we'll be using the serverless-logging-config plugin.

Three steps need to be completed:

Add the plugin:

plugins:
  - serverless-logging-config

Customize the settings for the plugin:

custom:
  serverless-logging-config:
    enableJson: true # [Optional] if enabled, set the LogFormat to JSON
    logGroupName: AggregatedLogGroup # [Optional] if set, all functions will send logs this log group
    applicationLogLevel: INFO # [Optional] valid values are DEBUG, ERROR, FATAL, INFO, TRACE and WARN
    systemLogLevel: INFO # [Optional] valid values are DEBUG, INFO and WARN
    useDefaultLogGroup: # [Optional] these functions would keep logging to their default log group
      - function1
      - function2

Note that everything under the useDefaultLogGroup will not be included in your aggregated log group.

Create the custom AggregatedLogGroup where your logs will be stored:

You final serverless.yml file should look something like this:

service: advanced-lambda-logging
frameworkVersion: '3'

plugins:
  - serverless-logging-config

provider:
  name: aws
  runtime: nodejs18.x

custom:
  serverless-logging-config:
    enableJson: true
    logGroupName: AggregatedLogGroup
    applicationLogLevel: INFO
    systemLogLevel: INFO

resources:
  Resources:
    AggregatedLogGroup:
      Type: 'AWS::Logs::LogGroup'
      Properties:
        LogGroupName: AggregatedLogGroup
        RetentionInDays: 90

functions:
  add:
    handler: src/todo/add.handler
    name: 'todo-app-add'
    events:
      - httpApi:
          path: /
          method: post
  fetch:
    handler: src/todo/fetch.handler
    name: 'todo-app-fetch'
    events:
      - httpApi:
          path: /todo/{id}
          method: get
  update:
    handler: src/todo/update.handler
    name: 'todo-app-update'
    events:
      - httpApi:
          path: /todo/{id}
          method: put
  remove:
    handler: src/todo/remove.handler
    name: 'todo-app-remove'
    events:
      - httpApi:
          path: /todo/{id}
          method: delete

Access the same Log Group from multiple Serverless files

A common practice is that you may have multiple Serverless files and sometimes you want to access the same Log Group in one or more of these Serverless files. This is how you can achieve that:

In one of your Serverless file, you create the Log Group:

resources:
  Resources:
    AggregatedLogGroup:
      Type: 'AWS::Logs::LogGroup'
      Properties:
        LogGroupName: AggregatedLogGroup
        RetentionInDays: 90

Then just reference this Log Group in your other Serverless files:

Note: just make sure the Log Group created and deployed before you reference it and that the name is exactly the same. In this case it's AggregatedLogGroup.

...

custom:
  serverless-logging-config:
    enableJson: true
    logGroupName: AggregatedLogGroup
    applicationLogLevel: INFO
    systemLogLevel: INFO

...

Conclusion

I have begun implementing advanced logging controls for AWS Lambda in my projects, and I've already observed a significant improvement in the quality of using our logs. This has positively impacted the processing efficiency and overall consumption of the logs. Have you tried this out? If so, what has been your experience with it?

Building an Amazon Bedrock App for Text and Image Retrieval

Rashwan Lazkani — Sat, 14 Oct 2023 06:38:01 +0000

Introducing Amazon Bedrock, a fully managed service, that provides a range of top-performing foundation models (FMs) from leading AI companies. It empowers you to effortlessly experiment with these FMs, customize them with your data through techniques like fine-tuning and retrieval augmented generation (RAG), and build managed agents for executing intricate business tasks and private projects.

Source Amazon.

As a fully managed service, it eliminates the need for server management or similar tasks. This means you won't have to worry about server provisioning, scaling, or maintenance.

In the context of serverless computing, services like AWS Lambda enable you to run code without managing servers. When you trigger a Lambda function, AWS automatically handles the infrastructure, scaling, and execution of your code. It's a pay-as-you-go model where you're only charged for the compute time your code actually uses, making it a cost-efficient and hassle-free option for running code in the cloud.

Tools that we'll be using:

Amazon Bedrock
AWS Lambda
Serverless Framework
TypeScript

Today, we'll be building two Lambda functions for text and image retrieval from Amazon Bedrock. We'll deploy these using Infrastructure as Code, make them accessible via API Gateway, and ensure everything remains Serverless.

You can use these functions to create applications similar to the ones I've showcased below:

Bedrock with Text

Bedrock with Images

Let's start!

Accessing BedRock begins with the following steps:

Login to your AWS Console
Go to Amazon Bedrock
In the left navigation click on Model access
Request access

Let's proceed to develop our Lambda functions:

You can choose which tool you want to use for deploying your Lambda functions by yourself but I'll provide the code for creating the Lambdas:

Text Lambda:

Please take note of a few important points below:

You need to import the client-bedrock-runtime package
You need to add the modelId
The prompt is the search text provided from your API

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

const client = new BedrockRuntimeClient({ region: 'us-east-1' });

export async function handler(event: any) {
  const prompt = JSON.parse(event.body).prompt;
  const input = {
    modelId: 'ai21.j2-mid-v1',
    contentType: 'application/json',
    accept: '*/*',
    headers: {
      'Access-Control-Allow-Headers': 'Content-Type',
      'Access-Control-Allow-Origin': '*',
      'Access-Control-Allow-Credentials': true,
      'Access-Control-Allow-Methods': 'POST'
    },
    body: JSON.stringify({
      prompt: prompt,
      maxTokens: 200,
      temperature: 0.7,
      topP: 1,
      stopSequences: [],
      countPenalty: { scale: 0 },
      presencePenalty: { scale: 0 },
      frequencyPenalty: { scale: 0 }
    })
  };

  try {
    const data = await client.send(new InvokeModelCommand(input));
    const jsonString = Buffer.from(data.body).toString('utf8');
    const parsedData = JSON.parse(jsonString);
    const text = parsedData.completions[0].data.text;
    return text;
  } catch (error) {
    console.error(error);
  }
}

Image Lambda

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

const client = new BedrockRuntimeClient({ region: 'us-east-1' });

export async function handler(event: any) {
  const prompt = JSON.parse(event.body).text_prompts;
  const input = {
    modelId: 'stability.stable-diffusion-xl-v0',
    contentType: 'application/json',
    accept: 'application/json',
    headers: {
      'Access-Control-Allow-Headers': 'Content-Type',
      'Access-Control-Allow-Origin': '*',
      'Access-Control-Allow-Credentials': true,
      'Access-Control-Allow-Methods': 'POST'
    },
    body: JSON.stringify({
      text_prompts: prompt,
      cfg_scale: 10,
      seed: 0,
      steps: 50
    })
  };

  try {
    const command = new InvokeModelCommand(input);
    const response = await client.send(command);

    const blobAdapter = response.body;

    const textDecoder = new TextDecoder('utf-8');
    const jsonString = textDecoder.decode(blobAdapter.buffer);

    try {
      const parsedData = JSON.parse(jsonString);
      return parsedData.artifacts[0].base64;
    } catch (error) {
      console.error('Error parsing JSON:', error);
      return 'TextError';
    }
  } catch (error) {
    console.error(error);
  }
}

Now deploy your Lambdas, if you're using Serverless Framework you can use the following configuration:

service: aws-bedrock-ts
frameworkVersion: '3'

provider:
  name: aws
  runtime: nodejs18.x
  iam:
    role:
      statements:
        - Effect: 'Allow'
          Action:
            - 'bedrock:InvokeModel'
          Resource: '*'

functions:
  bedrockText:
    handler: src/bedrock/text.handler
    name: 'aws-bedrock-text'
    events:
      - httpApi:
          path: /bedrock/text
          method: post
  bedrockImage:
    handler: src/bedrock/image.handler
    name: 'aws-bedrock-image'
    events:
      - httpApi:
          path: /bedrock/image
          method: post

Let's test our functions in Postman:

Text

Create a new POST request with the following data:

URL: add the URL to your newly created Text Lambda
Body: add the following body:

{
    "prompt": "Your search text"
}

Images

Create a new POST request with the following data:

URL: add the URL to your newly created Image Lambda
Body: add the following body:

{
    "text_prompts": [
        {
            "text": "Your search text"
        }
    ],
    "cfg_scale": 10,
    "seed": 0,
    "steps": 50
}

Now that your functions are prepared to be utilized with API Gateway, you can begin integrating them into your applications, much like the example I presented in the beginning of this article.

Note a couple of things

As this is a local app for testing, I've set the Access-Control-Allow-Origin to *. Additionally, you may need to adjust the CORS settings in API Gateway. Please be aware that there will be a small cost associated with your API calls. For detailed pricing information, refer to the Amazon Bedrock pricing model.

Conclusion

Amazon Bedrock provides a robust selection of high-performing foundation models from top AI companies. Integrating it into your application is straightforward and enhances its capabilities. If you haven't tried it yet, I highly recommend doing so!

Interested in the complete project? Feel free to let me know, and I'll create a part two that covers the UI aspect.

Mobile app with a serverless backend

Rashwan Lazkani — Mon, 21 Nov 2022 14:37:14 +0000

So you have you mobile application and do now realize that you need a backend service but you don't want to host any servers. How can you achieve this?

In this article I will show you how you easily with AWS can make use of several tools to handle this and without handling any servers (serverless).

Our architecture would looks something like this:

Let's go through each part below.

1. Amazon Cognito

We'll use Amazon Cognito for the login which will return User Pool tokens (note: with Amazon Cognito you can also use Amazon Cognito federates third party identity such as Facebook and Google).

2. Amazon API Gateway

With HTTPS request and the included Amazon Cognito tokens we'll make use of Amazon API Gateway to call the appropriate endpoint

3. AWS Lambda

Amazon API Gateway sends HTTPS requests to the appropriate Lambda based on the requested resource

4. Amazon DynamoDB

We'll use Amazon DynamoDB as a NoSQL database which our Lambdas will use to post/retrieve data

For this application we have used three different tiers.

Presentation - mobile application
Logic - Amazon API Gateway with AWS Lambda
Data - DynamoDB

Summary

That's it! A short summary of how you can use a serverless backend to your mobile applications.

Any comments, questions or discussions are always welcome!

Serverless - what should I have thought about?

Rashwan Lazkani — Fri, 18 Nov 2022 16:01:46 +0000

I have been working with serverless for about 2 years now and I really like it and can recommend it!

I can share two steps that I can recommend to you who want to start with serverless. I have mainly been using AWS Services which I will mention in this article.

So to start with quickly, what is serverless?

Serverless is a cloud-native development model that allows developers to build and run applications without having to manage servers meaning it essentially uses a cloud provider to completely manage your infrastructure.

Some benefits with serverless:

You only pay for when you use the service
You're moving away from servers and allowing developers to focus on code
You can build high scalability and reliability applications without managing servers
Offloading more responsibility to your cloud provider

Remember, you don't have to use serverless just because. There are cases where serverless might just not be the best solution.

Two stpes I can recommend you to think of when you're using serverless:

Start by using the AWS Console to play around

Firstly, I recommend you to create an AWS account.

When you have created your AWS account - play around, check the different settings, what happens when you change some setting, what options is available etc.

Let's take AWS Lambda functions for example, play around with it. Check how you invoke a Lambda, create a Lambda with the newly supported arm64 architecture. Figure out how you trace errors.

Next, create an Amazon DynamoDB. Create tables, checkout the Partition key and Sort key. Read about Read capacity unit (RCU) to get a better understanding about the costs. Use the Lambda you have created to add a row to the database.

When you have played around with Console and different services, then you proceed to the next step.

Start using Infrastructure as Code

After you have played around in the Console, have got a better understanding of the services I can really recommend you to use IaC for all your environments and not handle any changes from the Console.

This to understand what’s happening and to see the result of configuration changes. I can basically say, once you know what you are doing IaaC tools are really good and powerful!

Frameworks for serverless

Summary

A short summary of how I recommend you to get started with serverless. Don't rush into things, it's better to have a good understanding of the tools and services you are using. Good luck!

Any comments, questions or discussions are always welcome!

Amazon Athena query S3 data using SQL

Rashwan Lazkani — Wed, 16 Nov 2022 07:11:35 +0000

Amazon Athena is an interactive query service that makes it easy to analyze data in Amazon S3 using standard SQL. Athena is serverless, so there is no infrastructure to manage, and you pay only for the queries that you run.

It's easy to get started with and you'll get most of your results in seconds!

In this article I'll show you how you can get started with Amazon Athena and things that are good for you to think of when using this tool.

Create S3 buckets

For this we will create one S3 bucket and add a JSON file in it containing some sample data which will be used as the query source. We will also create one bucket where our query results will be stored in

So start by creating a S3 bucket which will contain our data and create a new file and add it into the bucket.

Note that your bucket name must be globally unique and must not contain spaces or uppercase letters.

When you have uploaded your file into the bucket, select the file and click on "Copy S3 URI", since this is needed to the next step.

You can copy the content below to the file if you want:

{"id": "aefb16a1-873e-4768-8b41-fed2169d6edc","isActive": true,"balance": "$3,945.61","age": 35,"registered": "2021-07-26T07:51:30 -02:00"}
{"id": "03ae00c4-0c0c-492f-8042-6769aa0ab1dd","isActive": false,"balance": "$32,405.72","age": 77,"registered": "2017-07-13T06:42:59 -02:00"}
{"id": "5c304a34-b9db-4bb5-b939-b399b99a01f7","isActive": true,"balance": "$11,117.00","age": 36,"registered": "2020-02-22T02:31:18 -01:00"}
{"id": "4a2a09c4-ce22-4397-8ac6-0b7175a67015","isActive": false,"balance": "$7,461.80","age": 23,"registered": "2022-01-09T08:18:47 -01:00"}
{"id": "aeee5d8c-8fdc-4c2a-bf69-996e2c167e93","isActive": false,"balance": "$37,321.59","age": 49,"registered": "2015-07-11T12:24:18 -02:00"}
{"id": "f005b41b-f8c2-4e44-8b91-01d3386d6523","isActive": false,"balance": "$10,240.07","age": 20,"registered": "2021-07-25T08:22:22 -02:00"}
{"id": "fd211f23-7890-49bf-8c5b-9a73f474fc88","isActive": true,"balance": "$36,729.80","age": 47,"registered": "2022-09-01T01:43:36 -02:00"}
{"id": "dd2e7598-5f87-432f-ae62-9734f955fb11","isActive": false,"balance": "$9,976.13","age": 80,"registered": "2014-11-10T11:05:54 -01:00"}
{"id": "d436143a-4796-4ee1-9435-379e90fcbe09","isActive": false,"balance": "$27,959.28","age": 28,"registered": "2017-09-01T09:14:55 -02:00"}
{"id": "c7c5cf84-4d4b-41d3-a421-0a3b9043d622","isActive": true,"balance": "$37,448.82","age": 54,"registered": "2020-02-06T10:08:52 -01:00"}
{"id": "e030033f-c266-41d5-a80e-1bcc899f96a2","isActive": false,"balance": "$10,377.82","age": 37,"registered": "2018-07-22T12:11:56 -02:00"}
{"id": "77a63add-51b0-4204-a6c5-36140742e221","isActive": false,"balance": "$5,119.16","age": 68,"registered": "2016-11-20T04:44:33 -01:00"}
{"id": "76ca5a7c-1aeb-4da3-b755-30ecf90fb678","isActive": true,"balance": "$39,777.44","age": 50,"registered": "2020-12-13T09:49:02 -01:00"}
{"id": "1a64b33e-ea3a-4d4c-95e7-dc8bc413e916","isActive": true,"balance": "$36,599.49","age": 23,"registered": "2022-04-11T03:38:24 -02:00"}
{"id": "d5c03b11-e5e9-4b28-ab01-9570152d06d7","isActive": true,"balance": "$8,772.33","age": 41,"registered": "2022-02-19T04:48:50 -01:00"}
{"id": "7e496708-2747-45b7-91d3-569c0864c775","isActive": true,"balance": "$36,996.72","age": 80,"registered": "2016-03-23T08:38:24 -01:00"}
{"id": "f71f8116-a1b1-44be-8541-c199832bd5a5","isActive": true,"balance": "$38,512.93","age": 30,"registered": "2022-09-29T04:50:38 -02:00"}
{"id": "956618ef-81ba-4eca-944f-7c56e26c2446","isActive": false,"balance": "$12,605.06","age": 22,"registered": "2016-09-15T09:55:42 -02:00"}
{"id": "1a6be308-162b-40bd-ab8c-2d50c5ea8d51","isActive": true,"balance": "$30,926.10","age": 30,"registered": "2020-03-17T10:12:31 -01:00"}
{"id": "fbda07e6-cb32-4512-a288-22d6d586ea5e","isActive": false,"balance": "$7,245.87","age": 35,"registered": "2019-04-21T01:45:16 -02:00"}

Now create another bucket which will contain the query results, in this bucket create a folder called "athena-results" or what you prefer.

You should now have the following:

One S3 bucket containing the data.json file
One S3 bucket and a folder in it which will store the Amazon Athena query results
You should also have copied the S3 URI to the first bucket

Setup Amazon Athena and AWS Glue

Now let's head over to Amazon Athena in AWS. In the main view click on "Explore the query editor" and you should now see this view:

Now click on "Edit settings" (highlighted in the image above). On the Location of query result option, click "Browse S3" and then select your results bucket and then select the results folder. Then click "Choose" and then "Save".

Now head back to the "Editor" tab. In the navigation pane, choose "Data sources". On the Data sources page, choose "Create data source". Next choose "S3 - AWS Glue Data Catalog".

Note that this option costs a bit extra (minor cost) but this will crawl your data and create a table with the columns based on your json data automatically. The other option is to create your table manually which is free. Click "Next" on the bottom right.

In the next step we want to select the "Create a crawler in AWS Glue" option. Now click "Create in AWS Glue".

AWS Glue is a serverless data integration service that makes it easier to discover, prepare, move, and integrate data from multiple sources for analytics, machine learning (ML), and application development.

You will now be redirected to a new tab to AWS Glue. Here click on "Crawlers" in the left navigation pane and then click on "Create crawler".

Add a name and click "Next"
Is your data already mapped to Glue tables? Select "Not yet"
In the "Data sources" click "Add a data source"
Next paste the S3 URI but remove the file extension name
Click "Add an S3 source"
Now go through the rest of the tutorial
When you have done all the steps in the tutorial, select your Crawler and click "Run crawler" (this can take a couple of minutes)

Query data in Amazon Athena

Now head back to Amazon Athena and click on "Explore the query editor"

You should now under tables see your table that was created through the Crawler:

If you expand the table you should see all the columns that the table have and these are based on the JSON file.

Now let's start and do some queries:

SELECT * FROM "default"."aws_athena_query_data_tutorial" where age > 50

Which will result in:

If you do check your results bucket in S3 you will also see that for each query there is .csv files automatically generated.

Cleanup

To cleanup what we just created you need to:

S3: remove the buckets you created (query and results)
AWS Glue: delete the Crawler and the database
Athena: delete the table

Summary

That's it! Hope you liked this and noticed how powerful this tool can be when you need to query data. Everything is serverless which means that you do not need to handle any servers.

Any comments, questions or discussions are always welcome!