This guide shows how to automate this deployment using Pulumi and Docker.

What You'll Deploy

• Docker container with your agent code

• Amazon ECR to store the image

• Bedrock AgentCore Runtime to run your agent

The Setup

1. Your Agent Code

# agents/my_agent/api.py
from fastapi import FastAPI
from langchain_openai import ChatOpenAI
import uvicorn

app = FastAPI()

@app.post("/invoke")
def invoke(input_data: dict):
    llm = ChatOpenAI(model="gpt-4")
    response = llm.invoke(input_data["input"])
    return {"output": response.content}

if __name__ == "__main__":
    uvicorn.run(app, host="0.0.0.0", port=8080)

2. Test Locally

# Set your OpenAI API key
export OPENAI_API_KEY="sk-..."

# Run the agent
python agents/my_agent/api.py

Test with curl:

curl -X POST http://localhost:8080/invoke \
  -H "Content-Type: application/json" \
  -d '{"input": "Hello, what is AI?"}'

Example response:

{
  "output": "AI, or Artificial Intelligence, refers to..."
}

3. Dockerfile

FROM --platform=linux/arm64 ghcr.io/astral-sh/uv:python3.13-bookworm-slim

WORKDIR /app

# Copy dependencies
COPY pyproject.toml uv.lock
COPY agents ./agents

# Install dependencies
RUN uv sync --frozen --no-cache

EXPOSE 8080

# Start the agent API
CMD uv run uvicorn agents.my_agent.api:app --host 0.0.0.0 --port 8080

4. Build and Push

# Login to ECR
aws ecr get-login-password --region eu-west-1 | \
  docker login --username AWS --password-stdin <account>.dkr.ecr.eu-west-1.amazonaws.com

# Build for ARM64
docker buildx build \
  --platform linux/arm64 \
  -t <account>.dkr.ecr.eu-west-1.amazonaws.com/my-agents:my_agent_v1 \
  --load \
  .

# Push to ECR
docker push <account>.dkr.ecr.eu-west-1.amazonaws.com/my-agents:my_agent_v1

5. Deploy with Pulumi

# __main__.py
import pulumi
import pulumi_aws as aws

# Load config
config = pulumi.Config()
region = config.require("aws_region")
bedrock_role_arn = config.require("bedrock_role_arn")

# Get existing ECR repository
ecr_repo = aws.ecr.get_repository(name="my-agents")

# Build image URI
image_uri = f"{ecr_repo.repository_url}:my_agent_v1"

# Deploy to Bedrock AgentCore
runtime = aws.bedrock.AgentcoreAgentRuntime(
    "my_agent_runtime",
    agent_runtime_name="my_agent",
    agent_runtime_artifact={
        "artifact_type": "Docker",
        "docker_uri": image_uri,
    },
    role_arn=bedrock_role_arn,
    environment_variables=[
        {"name": "AWS_REGION", "value": region},
        {"name": "ENV", "value": "production"},
    ],
)

# Export outputs
pulumi.export("runtime_name", runtime.agent_runtime_name)
pulumi.export("runtime_arn", runtime.arn)

6. Configure and Deploy

# Set configuration
pulumi config set aws:region eu-west-1
pulumi config set aws_region eu-west-1
pulumi config set bedrock_role_arn arn:aws:iam::123456:role/AmazonBedrockExecutionRoleForAgents

# Deploy
pulumi up

Important Notes

ARM64 Required: Bedrock AgentCore only supports ARM64 architecture.

Always use --platform linux/arm64.

Runtime Naming Rules:

• Must start with a letter

• Only alphanumeric characters and underscores

• Max 48 characters

IAM Role Permissions:

The Bedrock role needs:

• ecr:GetAuthorizationToken

• ecr:BatchGetImage

• logs:CreateLogGroup, logs:CreateLogStream, logs:PutLogEvents

Viewing Your Agent

1. Go to AWS Console → Amazon Bedrock AgentCore

2. Navigate to Agent runtime

3. Find your runtime in the list

4. Choose Test endpoint to interact with it

This guide shows how to deploy AWS Bedrock Agents using Pulumi and TypeScript.

Prerequisites

• AWS Account with Bedrock access

• Node.js and npm installed

• Pulumi CLI installed

Project Setup

1. Generate Project with Pulumi
   pulumi new aws-typescript
cd bedrock-agent-project

This creates a complete TypeScript project with:

• package.json with all dependencies

• Pulumi.yaml configuration

• index.ts entry point

• TypeScript configuration

2. Project Structure

    bedrock-agent-project/
    ├── package.json
    ├── Pulumi.yaml
    ├── index.ts
    ├── tsconfig.json
    └── agent/
    ├── agent-deploy.ts
    └── instructions.txt
   

Pulumi Configuration

Complete the file Pulumi.yaml with the following content:

name: My first agent
description: "Stack used to deploy my agent"
config:
aws_region: us-east-1
aws_accountId: "123456789012"

Replace 123456789012 with your actual AWS account ID and the region by the one you want to use

agent/agent-deploy.ts
import  as pulumi from "@pulumi/pulumi";
import  as aws from "@pulumi/aws";

// Configuration
const config = new pulumi.Config();
const awsRegion = config.require("aws_region");
const accountId = config.require("aws_accountId");
const stack = pulumi.getStack();

// Create Bedrock Agent
const bedrockAgent = new aws.bedrock.AgentAgent(my-agent-${stack}, {
agentName: my-agent-${stack},
description: "A helpful AI assistant",
agentResourceRoleArn: "arn:aws:iam::YOUR_ACCOUNT_ID:role/YOUR_BEDROCK_EXECUTION_ROLE", // Replace with your IAM role ARN
idleSessionTtlInSeconds: 500,
foundationModel: arn:aws:bedrock:${awsRegion}:${accountId}:inference-profile/eu.claude-3-5-sonnet-20241022-v2:0,
instruction: "You are a helpful assistant"
});

export const agentId = bedrockAgent.id;
export const agentArn = bedrockAgent.agentArn;

index.ts
Replace the default content with:
import { agentId, agentArn } from "./agent/agent-deploy";
export { agentId, agentArn };

Required IAM Role

Important: You must create the IAM role before deploying the agent, otherwise the deployment will fail.

Create IAM Role

1. Go to AWS IAM Console

2. Create a new role with these settings:

   • Trusted entity: AWS service

   • Service: Bedrock

   • Use case: Bedrock - Agents

3. Attach this policy to the role:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "bedrock:InvokeModel"
            ],
            "Resource": "*"
        }
    ]
}

4. Name your role (for example, MyBedrockAgentRole)

5. Update the agentResourceRoleArn in your code with the full ARN

Deployment

Deploy your Bedrock Agent using this command
pulumi up

Testing

After deployment:

1. Go to AWS Bedrock console

2. Navigate to Agents

3. Find your deployed agent

4. Test using the built-in chat interface

Cleaning

To clean up, don’t forget to run the command pulumi down

Conclusion

That’s it!
You now have a deployed Bedrock Agent that can have conversations with users. The agent uses the Claude 3.5 Sonnet model and follows the instructions you provided.

Useful link: https://www.pulumi.com/registry/packages/aws/api-docs/bedrock/agentagent/

I had a Raspberry Pi 4B sitting in a box, so I figured, why not jump in?

Discovering What’s on the Pi

I plugged it into my monitor to see what was on it. Turns out I had installed Ubuntu MATE desktop a few years ago. It worked… sort of. I connected to Wi-Fi and started downloading a few things, but every time I opened Firefox, the system froze. After several restarts and failed attempts, I decided Ubuntu MATE wasn’t the right fit—especially with only 2 GB of RAM.

Choosing the Right OS

To save resources, I went with Raspberry Pi OS Lite instead of the full desktop version. It boots incredibly fast and gives me a clean terminal-only environment—perfect for setting up a lightweight home server for experimentation.

Setting Up Remote Access (SSH)

Of course, I didn’t want to plug the Pi into a monitor every time I wanted to use it. Remote access via SSH is the way to go, and luckily, it’s very straightforward:

1. On your Raspberry Pi, open the terminal and run:

    sudo raspi-config
   

2. Go to Interfacing Options → SSH → Enable → OK → Finish.

3. Find your Pi’s IP address:

    hostname -I
   

4. From another computer, connect using:

    ssh <username>@<ip-address>
   

5. The first time you connect, you’ll get a security warning—type yes to proceed. Enter your password when prompted.

You should now see the Raspberry Pi prompt:

<username>@<hostname> ~ $

And that’s it—you’re now connected remotely and ready to start experimenting with your homelab!

Docker Compose profiles let you control which services run without modifying your docker-compose.yml. They’re useful for separating optional services (like monitoring tools or debugging containers) from your core stack.

From Docker documentation:
Profiles help you adjust your Compose application for different environments or use cases by selectively activating services. Services can be assigned to one or more profiles; unassigned services start/stop by default, while assigned ones only start/stop when their profile is active. This setup means specific services, like those for debugging or development, can be included in a single compose.yml file and activated only as needed.

How to use profiles in your docker-compose.yml

1. Add Profiles to Your Compose File

In your docker-compose.yml, specify the profiles key for optional services:

services:
  app:
    container_name: my-app
    image: myapp:latest
    ports:
      - "8080:8080"

  db:
    container_name: pg-database
    image: postgres:15

  adminer:
    container_name: adminer
    image: adminer
    ports:
      - "8081:8080"
    profiles:
            - debug

Here, adminer is tagged with the debug profile, while app and db always run.

2. Start Services with a Profile

Run only the default services:

docker compose up

Run services including the debug profile:

docker compose --profile debug up

That’s it !
You can now use profiles to load your local dev tools only when you need them.

An error occurred (dependencyFailedException) when calling the InvokeAgent operation: Dependency resource: received model timeout/error exception from Bedrock. Try the request again

I’m using Pulumi to deploy my agent like this:

const agent = new aws.bedrock.AgentAgent("pulumi-example-agent", {
    agentName: "pulumi-example-agent",
    description: "Pulumi example agent with Lambda integration",
    agentResourceRoleArn: `${roleArn}`,
    idleSessionTtlInSeconds: 500,
    foundationModel: "arn:aws:bedrock:eu-west-1:XXXXXXXXXXXXXXX:inference-profile/eu.amazon.nova-pro-v1:0",  
    instruction: `You are a helpful assistant that can answer questions and help with tasks.`,
})

I had no issue on the deployment using Github Actions.
But when i tried to chat with my agent, i got the error.
After trying many things, i decided to swap out the Nova model for a Mistral one.

const agent = new aws.bedrock.AgentAgent("pulumi-example-agent", {
    agentName: "pulumi-example-agent",
    description: "Pulumi example agent with Lambda integration",
    agentResourceRoleArn: `${roleArn}`,
    idleSessionTtlInSeconds: 500,
    foundationModel: "arn:aws:bedrock:eu-west-1:XXXXXXXXXXXXXXX:inference-profile/eu.mistral.pixtral-large-2502-v1:0",  
    instruction: `You are a helpful assistant that can answer questions and help with tasks.`,
})

Redeployed targeting the new model, and … it worked !
No more weird error !
So if you face that issue, just ditch the Amazon Nova model for another one !

See you in the next one ;)

I'm using this guide to prepare for the AWS Solutions Architect Associate certification. It covers common scenarios to help me understand which AWS services to use for different needs. By learning these, I’ll be better prepared to design secure and efficient solutions for the exam.

Compute

1. Run applications with minimal administration?
   Think AWS Lambda.

2. Need virtual servers in the cloud?
   Think Amazon EC2.

3. Automatically adjust compute capacity to match demand?
   Think Auto Scaling.

4. Run containerized applications?
   Think Amazon ECS/EKS (Elastic Container Service / Elastic Kubernetes Service).

5. Simplify container orchestration without managing servers?
   Think AWS Fargate.

Storage

6. Store files and access them globally?
   Think Amazon S3.

7. Store infrequently accessed data but still need millisecond retrieval?
   Think S3 Standard-IA.

8. Archive data at the lowest cost?
   Think S3 Glacier or Glacier Deep Archive.

9. Shared file storage for EC2 instances?
   Think Amazon EFS (Elastic File System).

10. Block storage for EC2 instances?
    Think Amazon EBS (Elastic Block Store).

11. Transfer large datasets to AWS physically?
    Think AWS Snowball.

Databases

12. Managed relational database?
    Think Amazon RDS.

13. NoSQL key-value database?
    Think Amazon DynamoDB.

14. Low-latency caching layer for databases?
    Think Amazon ElastiCache.

15. Petabyte-scale data warehouse?
    Think Amazon Redshift.

16. Migrate databases with minimal downtime?
    Think AWS Database Migration Service (DMS).

Networking

17. Distribute traffic across multiple Availability Zones?
    Think Elastic Load Balancer (ELB).

18. Deliver content with low latency worldwide?
    Think Amazon CloudFront.

19. Privately connect services across VPCs?
    Think VPC Peering or AWS PrivateLink.

20. Allow private subnet instances to access the internet?
    Think NAT Gateway.

21. Securely connect your on-premises data center to AWS?
    Think AWS VPN or AWS Direct Connect.

22. Create isolated sections of your AWS environment for security?
    Think VPC (Virtual Private Cloud).

23. Host internal applications with a private DNS?
    Think Amazon Route 53 (Private Hosted Zones).

24. Automatically assign public IP addresses to resources?
    Think Elastic IP.

25. Extend private IP address space to handle more resources?
    Think VPC CIDR Blocks.

26. Secure traffic between services with encrypted endpoints?
    Think AWS PrivateLink.

27. Inspect and filter network traffic to secure your VPC?
    Think Network Access Control Lists (NACLs) or Security Groups.

28. Monitor and analyze network traffic patterns?
    Think VPC Flow Logs.

29. Implement high availability for DNS routing?
    Think Amazon Route 53 (Health Checks and Failover Routing).

30. Direct user traffic based on latency to endpoints worldwide?
    Think Amazon Route 53 Latency Routing.

31. Need a managed firewall solution for web traffic?
    Think AWS Network Firewall.

32. Accelerate data transfer between AWS regions?
    Think AWS Global Accelerator.

33. Secure your web application from threats?
    Think AWS WAF (Web Application Firewall).

34. Monitor and troubleshoot connectivity issues?
    Think Reachability Analyzer.

35. Create redundant connections between your data center and AWS?
    Think AWS Direct Connect + Direct Connect Gateway.

36. Automatically block malicious traffic at the network layer?
    Think AWS Shield Advanced.

Security

37. Monitor API calls across your AWS account?
    Think CloudTrail.

38. Monitor resource health and set alarms?
    Think CloudWatch.

39. Automate compliance and security checks?
    Think AWS Config.

40. Detect threats and suspicious activity?
    Think Amazon GuardDuty.

41. Centralized management of access across multiple accounts?
    Think AWS IAM Identity Center (formerly AWS SSO).

42. Protect against DDoS attacks?
    Think AWS Shield.

43. Inspect and secure application traffic?
    Think AWS WAF (Web Application Firewall).

44. Securely store and retrieve secrets?
    Think AWS Secrets Manager.

Migration & Hybrid

45. Quickly migrate virtual machines?
    Think AWS Server Migration Service.

46. Set up a hybrid cloud environment?
    Think AWS Outposts.

Analytics

47. Run big data processing jobs?
    Think Amazon EMR (Elastic MapReduce).

48. Real-time data streaming?
    Think Amazon Kinesis.

49. Search and analyze log data?
    Think Amazon OpenSearch Service (formerly Elasticsearch Service).

50. Managed business intelligence service?
    Think Amazon QuickSight.

Cost Management

51. Analyze and optimize costs?
    Think AWS Cost Explorer.

52. Receive alerts when costs exceed thresholds?
    Think AWS Budgets.

Machine Learning

53. Build and train machine learning models?
    Think Amazon SageMaker.

54. Translate text into other languages?
    Think Amazon Translate.

55. Convert text to speech?
    Think Amazon Polly.

56. Extract text and data from documents?
    Think Amazon Textract.

In performance benchmarks, io2 Block Express volumes consistently outperformed gp3 and io1 volumes across various database engines and configurations. They delivered higher performance with up to 66% lower disk latency compared to gp3, making io2 Block Express particularly suitable for workloads requiring high throughput and low latency.

Getting Started with io2 Block Express

To get started with io2 Block Express, you can create a new RDS instance or modify an existing one via the Amazon RDS console or the AWS CLI.

Creating a New RDS Instance with io2 Block Express:

aws rds create-db-instance \
    --db-instance-identifier mydbinstance \
    --db-instance-class db.m5.large \
    --engine mysql \
    --master-username admin \
    --master-user-password password \
    --allocated-storage 100 \
    --storage-type io2 \
    --iops 1000

Modifying an Existing RDS Instance:

aws rds modify-db-instance \
    --db-instance-identifier mydbinstance \
    --storage-type io2 \
    --iops 1000 \
    --apply-immediately

After modifying the instance, a storage optimization process begins, and further modifications are deferred until it completes. A progress indicator provides visibility into this process. It's recommended to evaluate performance and costs according to your application requirements and test any changes prior to production deployment.

Regional Availability

io2 Block Express volumes are available in multiple AWS Regions, including US East (N. Virginia, Ohio), US West (N. California, Oregon), Asia Pacific (Hong Kong, Mumbai, Seoul, Singapore, Sydney, Tokyo), Canada (Central), Europe (Frankfurt, Ireland, London, Stockholm), and Middle East (Bahrain).

For more detailed information, refer to the original AWS Database Blog post: Optimize Amazon RDS Performance with io2 Block Express Storage.

RDS Blue-Green Deployment offers a compelling alternative to traditional approaches, providing several key advantages:

1. Simplicity: This model simplifies the deployment process, reducing the likelihood of errors and streamlining operations.

2. Control and Flexibility: Blue-Green Deployment enhances control and flexibility, allowing for smoother management of releases with minimal disruption.

3. Reduced Downtime: A major benefit is the ability to minimize downtime by seamlessly shifting traffic between two identical environments.

Implementation of Blue-Green Deployment

After upgrading to a compatible PostgreSQL version, RDS Blue-Green Deployment was implemented through the following steps:

1. Setup of Blue-Green Deployment:

   • Initiated the creation of a Blue-Green Deployment using an existing PostgreSQL database as the starting point.

2. Topology and Configuration Replication:

   • RDS replicated the topology and configuration of the primary database to create the Green environment.

3. Data Replication:

   • Data from the Blue environment was synchronized to the Green environment, ensuring consistency between the two.

4. Major Version Upgrade on Green Environment:

   • Applied a major version upgrade to the Green environment, preparing it to handle production traffic.

5. Seamless Switchover:

   • Conducted a smooth transition of traffic from the Blue environment to the Green environment, minimizing disruption.

6. Minimized Downtime:

   • The switchover process was efficiently executed, resulting in minimal downtime while maintaining system availability.

7. Resource Optimization:

   • Once the switchover was complete, the Blue-Green Deployment was removed to free up resources.

Conclusion

RDS Blue-Green Deployment proved to be an effective and reliable strategy for minimizing downtime and ensuring a smooth transition during database upgrades. By leveraging this approach, we achieved greater control, flexibility, and simplicity in the deployment process. The seamless switchover and efficient resource utilization highlighted the value of this model, making it a robust solution for managing database transitions with minimal disruption to system availability.

You can create a new DB instance by restoring from a DB snapshot. You provide the name of the DB snapshot to restore from, and then provide a name for the new DB instance that is created from the restore.

You can't restore from a DB snapshot to an existing DB instance; a new DB instance is created when you restore.

Steps

To restore a DB instance from a DB snapshot

1. Sign in to the AWS Management Console and open the Amazon RDS console at https://console.aws.amazon.com/rds/.

2. In the navigation pane, choose Snapshots.

3. Choose the DB snapshot that you want to restore from.

4. For Actions, choose Restore snapshot.

5. On the Restore snapshot page, for DB instance identifier, enter the name for your restored DB instance.

6. Specify other settings, such as allocated storage size.

   For information about each setting, see Settings for DB instances.

7. Choose Restore DB instance.

Conclusion

Now you know how to restore a snapshot on RDS.
See you in the next one!

Prerequisites

Before we dive into using AWS DMS for a major version upgrade, ensure you have the following prerequisites in place:

1. Amazon Web Services Account: You need an AWS account with the necessary permissions to perform these operations.

2. Amazon RDS Instance: You should have an existing RDS instance that you want to upgrade.

Step-by-Step Guide

1. Create a Custom Parameter Group

Create a parameter group for the target DB with rds.logical_replication at 1 and rds.force_ssl at 0 (to allow the connection during the migration)

2. Create the target DB and associate the Parameter Group

In the RDS console, create a new RDS instance with the desired major version. Associate the custom parameter group you created in the previous step with your target DB.

3. Create a Replication Instance

A replication instance acts as the computing and memory resource for your migration task. You can create a new replication instance or use an existing one.

4. Configure Source and Target Endpoints

In the AWS DMS console, navigate to your DMS instance, and configure the source and target endpoints. The source endpoint should point to your existing RDS instance, and the target endpoint should point to your new RDS instance with the upgraded database engine.

5. Create a Migration Task

Create a new migration task in the AWS DMS console and associate it with the source and target endpoints you configured in the previous steps. Specify the migration type as 'Migrate existing data and replicate ongoing changes.'

6. Choose a Data Migration Method

AWS DMS offers various data migration methods, such as Full Load and CDC (Change Data Capture). For a major version upgrade, it's advisable to use the CDC method to minimize downtime.

7. Start the Migration Task

Once your migration task is configured, start it. AWS DMS will begin copying data and changes from your source RDS instance to the target RDS instance.

8. Monitor and Verify

Monitor the progress of your migration task using the DMS console. AWS DMS provides real-time status updates and logs to ensure the migration is proceeding as expected.

9. Test Your Applications

Before finalizing the upgrade, thoroughly test your applications against the new RDS instance to ensure everything works as expected. This step is crucial to identify any potential issues early.

10. Cutover to the New RDS Instance

When you are confident that the upgrade is successful and your applications are running smoothly on the new RDS instance, you can plan a cutover. This involves redirecting your applications to use the new RDS instance. This is typically a brief, controlled downtime.

11. Complete the Migration

After the cutover, you can stop your DMS migration task. The new RDS instance is now running the upgraded database engine, and you can decommission the old instance if necessary.

Best Practices

Here are some best practices to ensure a successful major version upgrade using AWS DMS:

• Backup and Snapshot: Always take a snapshot of your existing RDS instance before starting the upgrade process. This allows you to roll back in case of any issues.

• Test Thoroughly: Extensive testing is crucial to avoid post-upgrade problems. Test all aspects of your application to ensure compatibility with the new database engine version.

• Plan for Downtime: While AWS DMS minimizes downtime, there may still be some downtime during cutover. Plan for this and communicate it to your users.

• Monitor Performance: After the upgrade, closely monitor the performance of your new RDS instance to ensure it meets your requirements.

• Stay Informed: Keep an eye on AWS announcements for any new major versions, features, or security updates relevant to your database engine.

Conclusion

Upgrading the major version of your Amazon RDS instance is essential to maintain the security, performance, and features of your database. AWS DMS can help you streamline the process, minimize downtime, and reduce the risks associated with major version upgrades. By following the steps and best practices outlined in this article, you can ensure a smooth and successful upgrade for your RDS instance.

Scenario

I maintained a private repository that hosted the code for my application. Additionally, I created a separate private repository for a new library I developed. My objective was to use this library as a dependency in my primary project.

Locally, everything functioned smoothly, primarily due to my SSH key setup. However, when it came to GitHub Actions, I ran into difficulties. The stumbling block was my use of a personal access token (PAT) from a machine user. Specifically, I encountered errors during the npm ci step, primarily stemming from permission issues.

Solution

This is how I have managed to install dependencies from private GitHub repositories.

package.json

 "dependencies": {
        ...
        "pg": "8.6.0",
        "myprivatelib": "orgName/myprivateRepo"
    },

# Github Action

- uses: actions/checkout@v3
   with:
       persist-credentials: false
- uses: actions/setup-node@v1
  with:
      node-version: 16.x
- run: git config --global url."https://${{ secrets.PAT }}@github.com/".insteadOf ssh://git@github.com/
- run: npm ci

It is important to disable persisted credentials on actions/checkout, otherwise they will override your PAT.

Your GitHub action should run without any issues now!

As a developer, you can use the local version of DynamoDB to simulate real-world scenarios and test the limits of your application. You can also use it to debug and troubleshoot issues in a controlled environment. By using the local version, you can speed up your development process and reduce your overall development costs.

Setup with Docker compose

A local version of Amazon DynamoDB is available as a Docker image.
For more information, see dynamodb-local.

To install and run DynamoDB locally with Docker compose (Docker must be installed):

Copy the following code to a file and save it as docker-compose.yml.

version: '3.8'
services:
  dynamodb-local:
    command: "-jar DynamoDBLocal.jar -sharedDb -dbPath ./data"
    image: "amazon/dynamodb-local:latest"
    container_name: dynamodb-local
    ports:
      - "8000:8000"
    volumes:
      - "./docker/dynamodb:/home/dynamodblocal/data"
    working_dir: /home/dynamodblocal

Run the following command:

docker-compose up

Your local DynamoDB is ready to be used.
You can use the AWS CLI to interact with your local DB using the --endpoint-url parameter

aws dynamodb list-tables --endpoint-url http://localhost:8000

You can also use dynamodb-admin to have a GUI to interact with your local database

https://www.npmjs.com/package/dynamodb-admin

Conclusion

That's it!

Don't hesitate to comment if you have any questions.

See you in the next one! 🤖🤖🤖

GitHub repository

1. Create a new repository on GitHub, or choose an existing repository that you want to set up the action for.

2. In the .github/workflows directory of your repository, create a new file for your action. You can name this file anything you like, but it should have the .yml file extension.

3. In the action file, define a new job with the name and on properties. The on property specifies when the job should be run, such as when a push event is made to some branch of the repository or when a pull request is made.

4. In the job, define a steps section that contains one or more steps. Each step is an individual task that the job should perform.

5. For the first step, use the uses property to specify an action. First, we are using an action named actions/checkout@v2. This is an action provided by GitHub that will check out your repository onto the runner, so that it can be built and tested.

6. Then, we are using another action named serverless/github-action@v3.1. This is an action provided by the Serverless team that wraps the Serverless Framework to enable common Serverless commands.

7. For subsequent steps, you can use the run property to run a command using the Serverless Framework. For example, you can use run: serverless deploy to deploy your serverless application to the cloud.

8. Set up any necessary environment variables that the Serverless Framework needs. For example, you may need to set the AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY environment variables to provide the action with access to your AWS account.

9. Commit and push your changes to the repository. This will trigger the GitHub Action to run.

Example file

Here is an example action file that demonstrates these steps:

Copy codename: Deploy Serverless Application

on:
  push:
    branches: [ main ]

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v3
    - name: Deploy Serverless Application
      uses: serverless/github-action@v3.1
      with:
        args: deploy
      env:
        AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
        AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}

This action will run when a push event is made to the main branch, and it will deploy the serverless application using the serverless deploy command.

I hope this helps! Let me know if you have any questions.

Definition

What is a Processor ?

Also known as Central Processing Units (CPUs), a processor is a small chip that act as brains for computers and smartphones. The CPU is responsible for calculations, caching critical information for quick access, and more.

Manufacturers vs Architecture

Intel and AMD are manufacturers, but ARM processors are a type of architecture, and therefore they do not have only one manufacturer, so it's not really the point to compare them.

Intel

Intel is the most popular and well-known maker of processors.
Manufacturers like Dell, Apple, Samsung and HP all use Intel processors in their computers.
Intel processors are the most stable and offer the best all-round performance.

AMD

AMD is Intel’s biggest competitor, offering processors that are similar to Intel’s, but at a cheaper price.

Both Intel and AMD produce what we call x86 processors.
So finally, the comparaison should be between the two architectures : x86 and ARM

Differences

X86 & ARM

X86

X86 is a family of complex instruction set computer (CISC) instruction set architectures[a] initially developed by Intel based on the Intel 8086 microprocessor.

ARM

ARM is a family of reduced instruction set computer (RISC) instruction set architectures for computer processors, configured for various environments.

Processors designed by different companies may adopt the same ISA(Instruction Set Architecture); for example, both AMD and Intel CPUs are based on the x86 architecture, which means any operating system or program that can run on an Intel CPU can also run on an AMD CPU.

CISC & RISC

CISC

The CISC Stands for Complex Instruction Set Computer, developed by the Intel. It has a large collection of complex instructions that range from simple to very complex and specialized in the assembly language level, which takes a long time to execute the instructions

RISC

RISC stands for Reduced Instruction Set Computer Processor, a microprocessor architecture with a simple collection and highly customized set of instructions. It is built to minimize the instruction execution time by optimizing and limiting the number of instructions.

*ISA : Instruction Set Architecture

ARM : smartphones and computers

Arm processors are incredibly energy-efficient and generate less heat. This is crucial for mobile devices such as smartphones, since battery life cannot be too limited, and the device must not get too hot! Arm CPUs are the leading smartphone processor IP on the market today. 95 percent of premium smartphones are powered by Arm.

Arm is also used in many Chromebook laptops, and Apple now offers a number of computers that use the Arm-based M1 chip (before they used Intel x86 chips).
Apple's new MacBook Pro systems, which use the chip, have set a new industry standard for laptop performance and battery life.
The Arm processor is also moving into the server market but more slowly.

Conclusion

Now you know that there are two different types of architectures, x86 and arm.
The way they work are different and the apps developed for one ISA cannot work on the other one. That's why, when you get a Macbook M1 (or a Chromebook), you have to adjust and download arm-compatible apps.
Don't hesitate to point out some mistakes i've made in the comments, i'm still digging the subject and i wanted to simplify a lot these concepts so maybe i took some shortcuts.

Container image support for AWS Lambda was announced back at AWS re:Invent 2020.
Okay, but what exactly is container image support ?

To understand that, you need to have some context about lambda. When you create a Lambda function, you package your function code into a deployment package. Before the container image support, the only way to deploy your lambda code was through a zip file.

Lambda with zip file

For example, you had to create the actual code of your lambda , let's say in Node.js

// index.js
exports.handler =  async function(event, context) {
  console.log("Hello world")
}

To be able to upload your code, you must create a zip file

zip function.zip index.js

Then upload your package using the update-function-code command

aws lambda update-function-code --function-name my-function --zip-file fileb://function.zip

Lambda with container image

If you use Container image to deploy your function, after creating your image, you can use the Docker CLI build it and push it to AWS ECR (Elastic Container Registry), and then after that create your function from that image.

Let's create an image from the code i showed you above

FROM public.ecr.aws/lambda/nodejs:16
COPY index.js  ./
CMD [ "app.handler" ]

Then build that image

docker build -t lambda-container-image .

And finally, push it to ECR

• Log in

  aws ecr get-login-password  --region <region> | docker login 
     --username AWS --password-stdin     
     <accountID>.dkr.ecr.<region>.amazonaws.com
  

• Create the Repository

  aws ecr create-repository 
     --repository-name lambda-container-image 
     --image-tag-mutability IMMUTABLE
     --image-scanning-configuration scanOnPush=true
  

• Tag the image

  docker tag lambda-container-image:v1 <accountID>.dkr.ecr.<region>.amazonaws.com/lambda-container-image:v1
  

• Push the image

  docker push <accountID>.dkr.ecr.<region>.amazonaws.com/lambda-container-image:v1
  

And then, create your function from that image

Conclusion

Now, you know the difference between the two types of deployment packages supported by Lambda.

If you want to know more, once again, check the Lambda Documentation

See you in the next one :)

Definition

A function URL is a dedicated HTTP(S) endpoint for your Lambda function.
The endpoints have the following format:

https://<url-id>.lambda-url.<region>.on.aws

Pricing

Function URLs are included in Lambda’s request and duration pricing.

Difference with API Gateway

Function URLs are best for use cases where you must implement a single-function microservice with a public endpoint that doesn’t require the advanced functionality of API Gateway, such as request validation, throttling, custom authorizers, custom domain names, usage plans, or caching.
For example, when you are implementing webhook handlers, form validators, static html file...
It is also the simplest way to invoke your Lambda functions during development without leaving the Lambda console or integrating additional services.

Create and deploy the lambda with CDK

Let's create a new project

mkdir lambda-url
cd lambda url
cdk init

lib/lambda-url-stack.ts

import { CfnOutput, Stack, StackProps } from 'aws-cdk-lib';
import { Construct } from 'constructs';
import * as lambda from 'aws-cdk-lib/aws-lambda';

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

    // The code that defines your stack goes here

    const myFunction= new lambda.Function(this, 'LambdaHandler', {
      runtime: lambda.Runtime.NODEJS_14_X,    // execution environment
      code: lambda.Code.fromAsset('lambda'),  // code loaded from "lambda" directory
      handler: 'index.handler'                // file is "index", function is "handler"
    });

    const fnUrl = myFunction.addFunctionUrl({  // your function url
      authType: lambda.FunctionUrlAuthType.NONE,
    });

    new CfnOutput(this, 'TheUrl', {
      value: fnUrl.url,
    });
  }
}

At the root of your project, (next to lib and bin), create a lambda folder and inside it, an index.js file

# at the root of your project
mkdir lambda
cd lambda
touch index.js

lambda/index.js (let's render some html ! )

exports.handler = async function(event) {
    console.log("request:", JSON.stringify(event, undefined, 2));
    const body = '<html><head><title>HTML from Lambda URL</title></head>' + 
    '<body><h1>Hello you ! This is served by a Lambda function URL</h1></body></html>'
    return {
      statusCode: 200,
      headers: { "Content-Type": "text/html" },
      body
    };
  };

Everything is ready ! Now let's deploy

❯ cdk deploy

✨  Synthesis time: 14.84s

LambdaUrlStack: deploying...
[0%] start: Publishing XXXXXXXXXXXXXXXXX:current_account-current_region
[0%] start: Publishing XXXXXXXXXXXXXXXXX:current_account-current_region
[50%] success: Published XXXXXXXXXXXXXXXXX:current_account-current_region
[100%] success: Published :XXXXXXXXXXXXXXXXXcurrent_account-current_region
LambdaUrlStack: creating CloudFormation changeset...

 ✅  LambdaUrlStack

✨  Deployment time: 45.96s

Outputs:
LambdaUrlStack.TheUrl = https://XXXXXXXXXXXXXXXXX.lambda-url.us-east-1.on.aws/
Stack ARN: XXXXXXXXX:stack/LambdaUrlStack/XXXXXXXX

✨  Total time: 60.79s

You can find the code on this repository

On the console

Go to Lambda , you should see the one you just created.

Click on it, and you should see your function URL (see capture)

Test our lambda

Copy the function URL and paste in your browser, hit enter and you should see this :

Conclusion

Congrats ! You know now how to use Function URLs for Lambda.

To go further : AWS Documentation

See you in the next one :)

Recently, i was working with a React application and i wanted to integrate a form that i created on Typeform.
This article is explaining how you can manage that using the React Embed Typeform library.

Create a Next.js application

Let's create a Next.js app

yarn create next-app

and start the server

yarn dev

We will edit the pages/index.js page this way.

import Head from 'next/head'
import Image from 'next/image'
import styles from '../styles/Home.module.css'

export default function Home() {
  return (
    <div className={styles.container}>
      <Head>
        <title>Create Next App</title>
        <meta name="description" content="Generated by create next app" />
        <link rel="icon" href="/favicon.ico" />
      </Head>

      <main className={styles.main}>
        <h1 className={styles.title}>
          Welcome to <a href="https://nextjs.org">Next.js!</a>
        </h1>

        <p className={styles.description}>
          Get started by editing{' '}
          <code className={styles.code}>pages/index.js</code>
        </p>

        <div className={styles.grid}>
          Your Typeform will be here
        </div>
      </main>

      <footer className={styles.footer}>
        <a
          href="https://vercel.com?utm_source=create-next-app&utm_medium=default-template&utm_campaign=create-next-app"
          target="_blank"
          rel="noopener noreferrer"
        >
          Powered by{' '}
          <span className={styles.logo}>
            <Image src="/vercel.svg" alt="Vercel Logo" width={72} height={16} />
          </span>
        </a>
      </footer>
    </div>
  )
}

You will see something like this in your browser :

Embed typeform

Typeform has an official React Embed Library

yarn add @typeform/embed-react

And use it inside your component like this

import { Widget } from '@typeform/embed-react'

const MyComponent = () => {
  return <Widget id="<form-id>" style={{ width: '50%' }} className="my-form" />
}

Integrate your form into your application

Let's add our form into our index page

The first thing you need is your form id :

You can find from the public URL of your form

form.typeform.com/to/<form-id>

Let's modify our index.js to add our Widget.

import { Widget } from '@typeform/embed-react'

export default function Home() {
  return (
    <div className={styles.container}>
      <Head>
        <title>Create Next App</title>
        <meta name="description" content="Generated by create next app" />
        <link rel="icon" href="/favicon.ico" />
      </Head>

      <main className={styles.main}>
        <h1 className={styles.title}>
          Welcome to <a href="https://nextjs.org">Next.js!</a>
        </h1>

        <p className={styles.description}>
          Get started by editing{' '}
          <code className={styles.code}>pages/index.js</code>
        </p>

        <div className={styles.grid}>
           // ------ here is your Widget ------------
          <Widget id="<form-id>" style={{ width: '500px', height: "400px" }} className="my-form" />
        </div>
      </main>
...

NB : don't forget to replace the with your form id !

You should see your Widget now in your application

You can also choose to display your Typeform with a Popover or a Slidertab if you like. Check the documentation to see all the display options.

Conclusion

As you can see, it's pretty easy ! If you have any questions, feel free to ask in the comments !

See you in the next one !

The Network Layer

On a local area network or LAN, nodes can communicate with each other through their physical MAC addresses. This works well on small scale because switches can quickly learn the MAC addresses connected to each other ports to forward transmissions appropriately. But MAC addressing isn't a scheme that scales well, every single network interface on the planet has a unique MAC address and they aren't ordered in any systematic way. There is no way of knowing where on the planet a certain MAC address might be at any one point in time, so it's not ideal for communicating across distances.

IP addresses

IP addresses are a 32 bit long numbers made up of four octets, and each octet is normally described in decimal numbers. This format is known as dotted decimal notation.

The important thing to know for now is that IP addresses are distributed in large sections to various organizations and companies instead of being determined by hardware vendors. For example IBM, which owns every single IP that has the number 9 as the first octet. At a very high level, this means that if an Internet router needs to figure out where to send a data packet intended for the IP address 9.0.0.1, that router only has to know to get it to one of IBMs routers.

You can find here the list of how ip adresses are distributed.

It's important to understand that IP addresses belong to the networks, not the devices attached to those networks. So your laptop will always have the same MAC address no matter where you use it, but it will have a different IP address assigned to it at your work than it would when you're at home.

IP address classes

IP addresses can be split into two sections, the network ID and the host ID.
Earlier we mentioned that IBM owns all IP addresses that have a nine as the value of the first octet in an IP address.
If we take an example IP address of 9.100.100.100, the network ID would be the first octet, and the host ID would be the second, third and fourth octets. The address class system is a way of defining how the global IP address space is split up.

Routers

Routers are networking devices operating at layer 3 or a network layer of the OSI model.
They are responsible for receiving, analyzing, and forwarding data packets among the connected computer networks.
When a data packet arrives, the router inspects the destination address, consults its routing tables to decide the optimal route and then transfers the packet along this route

ARP (address resolution protocol)

Address Resolution Protocol (ARP) is a protocol that connects an ever-changing Internet Protocol (IP) address to a fixed physical machine address, also known as a media access control (MAC) address, in a local-area network (LAN).

Conclusion

That's it !

Don't hesitate to comment to point out some mistakes or make some precisions.

As i said in the beginning, i am still studying these concepts :)

See you in the next one ! 🤖🤖🤖

To create the lambda and the SNS Topic to talk to the Bot, we are going to use CDK. To setup the ChatBot we'll do it on the console.

The Lambda

Let's create our project

mkdir chatBotLambda
cd chatBotLambda
npm init -y

Then install CDK and the packages we need

npm install -g aws-cdk
npm i @aws-cdk/aws-lambda
npm i @aws-cdk/aws-sns
npm i @aws-cdk/aws-sns-subscriptions
mkdir cdk-folder
cdk init app --language typescript

Open the file lib/cdk-folder-stack.ts

import * as cdk from '@aws-cdk/core';
import * as lambda from '@aws-cdk/aws-lambda';
import * as sns from '@aws-cdk/aws-sns';
import * as subs from '@aws-cdk/aws-sns-subscriptions';
import * as cloudwatch from '@aws-cdk/aws-cloudwatch';
import * as path from 'path';

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

    // sns topic
    const topic = new sns.Topic(this, 'my-lambda-notifications', {
      displayName: 'My SNS topic',
    });
    topic.addSubscription(new subscriptions.EmailSubscription("your-email@adress");

    // lambda function
    const myLambdaFunction = new lambda.Function(this, 'my-lambda', {
      runtime: lambda.Runtime.NODEJS_14_X,
      memorySize: 256,
      timeout: cdk.Duration.seconds(60),
      handler: 'index.main',
      code: lambda.Code.fromAsset(path.join(__dirname, '/../app/my-lambda/')),
    });
  }
}

Lambda part Now the lambda code

mkdir app
cd app
mkdir my-lambda
cd my-lambda
npm init -y 
touch index.js

Very simple code for the lambda :

exports.main = async (event) => {
        console.log('Hello ChatBot');
};

Bootstrap and deploy

cdk bootstrap
⏳  Bootstrapping environment aws://XXXXXXXXXXXXX/us-east-1...
 ✅  Environment aws://XXXXXXXXXXXXXX/us-east-1 bootstrapped (no changes).

cdk deploy

Now we have our lambda, next step, the ChatBot

The ChatBot

Open the AWS Chatbot console.

Under Configure a Chat client choose Slack, and then choose Configure.

In the upper right corner, choose the dropdown list, and then choose the Slack workspace that you want to use with AWS Chatbot and choose Allow.

Choose Configure new channel.

Under Configuration details, for Name, enter AWSChatBot.

Under Channel type, choose Private.

Navigate to Slack and create a private channel by choosing the + button to the right of Channels.

Choose Create a channel.

Name the channel AWSChatBot and make it private then hit create.

When prompted to add people, choose x.

Navigate back to the AWS Chatbot console and enter the private channel ID.

Define the IAM permissions that the chatbot uses for messaging your Slack chat room:

For Role name, enter AWSChatBotRole.

For Policy Templates, select Read-only command permissions and Lambda-invoke command permissions.

In the SNS topics section, choose the appropriate AWS Region under Region.

Under Topics, select the AWSChatBotNotifications topic.

Choose Configure.

Your ChatBot is ready !

Make them work together

Invite yout AWS Chatbot to your channel by doing the following in Slack :

@AWS

hit enter and choose invite to the channel.

Enter the following command in Slack

@aws lambda invoke --function-name <your-function-name> --region <your region>

The output should be :

Congrats ! You can now invoke your lambda from Slack ! Pretty convenient to test out some stuff !

Clean up

To destroy the lambda and the SNS topic :

cdk destroy

To delete the chatbot :

• Open the AWS Chatbot console.

• Choose Slack.

• Choose the radio button next to the channel you created and then choose Delete.

I will show how to use the CDK assertions (aws-cdk-lib/assertions) library to write unit tests about your stacks. The library (aws-cdk-lib/assertions) contains several helper functions for writing unit and integration tests.

Create a project

mkdir unitTestCdk
cd unitTestCdk
cdk init app --language typescript
yarn add @aws-cdk/assert

The command generates an empty stack.

Go to lib/unit_test_cdk-stack.ts

import { Stack, StackProps } from 'aws-cdk-lib';
import { Construct } from 'constructs';

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

    // The code that defines your stack goes here
       👇👇👇👇👇👇👇👇

  }
}

Let's write a test for that.

Go to test/unit_test_cdk.test.ts, you will already have the structure to write your first test. Let's write our test :

import * as cdk from 'aws-cdk-lib';
import '@aws-cdk/assert/jest';
import * as UnitTestCdk from '../lib/unit_test_cdk-stack';

test('Empty stack', () => {
    const app = new cdk.App();

    const stack = new UnitTestCdk.UnitTestCdkStack(app, 'MyTestStack');

    expect(stack).not.toHaveResource('AWS::SQS::Queue');
});

Let's run our test

yarn test

$ jest
 PASS  test/unit_test_cdk.test.ts (7.442 s)
  ✓ Empty stack (25 ms)

Test Suites: 1 passed, 1 total
Tests:       1 passed, 1 total
Snapshots:   0 total
Time:        7.488 s
Ran all test suites.
✨  Done in 8.23s.

Great ! Now let's add a resource , and update our test

With a SQS queue

import { Stack, StackProps } from 'aws-cdk-lib';
import { Construct } from 'constructs';
import * as sqs from 'aws-cdk-lib/aws-sqs';

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

    // The code that defines your stack goes here

    // example resource
    const queue = new sqs.Queue(this, 'UnitTestCdkQueue', {
      queueName: "sqs-test"
    });
  }
}

Let's update our test now

import * as cdk from 'aws-cdk-lib';
import '@aws-cdk/assert/jest';
import * as UnitTestCdk from '../lib/unit_test_cdk-stack';

test('stack with SQS queue', () => {
    const app = new cdk.App();

    const stack = new UnitTestCdk.UnitTestCdkStack(app, 'MyTestStack');

    expect(stack).toHaveResource('AWS::SQS::Queue');
});

And run the test

yarn test

 PASS  test/unit_test_cdk.test.ts (10.276 s)
  ✓ stack with SQS queue (29 ms)

Test Suites: 1 passed, 1 total
Tests:       1 passed, 1 total
Snapshots:   0 total
Time:        10.346 s
Ran all test suites.
✨  Done in 11.81s.

We can even test check the queue name :

import * as cdk from 'aws-cdk-lib';
import '@aws-cdk/assert/jest';
import * as UnitTestCdk from '../lib/unit_test_cdk-stack';

test('stack with SQS queue', () => {
    const app = new cdk.App();

    const stack = new UnitTestCdk.UnitTestCdkStack(app, 'MyTestStack');

    expect(stack).toHaveResource('AWS::SQS::Queue', {
        QueueName: 'sqs-test'
     });
});

You can look further in the AWS Documentation to find helpers to test your stack the way you need it.

Conclusion

Now, you know how to unit test your infrastructure created with AWS CDK !

If you have any questions, feel free to ask in the comments, i'll do my best to answer !

See you next in the next one ! 🤖