DEV Community: Benjamin Ajewole

Replacing Glue Lambdas with EventBridge Pipes

Benjamin Ajewole — Wed, 11 Mar 2026 21:41:00 +0000

Serverless architectures on AWS often rely on Lambda for more than business logic. In many systems, Lambda functions are used as intermediaries between event sources and downstream services, handling simple filtering, transformation, or event forwarding. Although this approach works, it can introduce unnecessary compute, more infrastructure to manage, and added complexity. EventBridge Pipes offers a more streamlined alternative by connecting sources and targets directly, reducing the need for intermediary Lambda functions.

The Traditional Pattern

A common approach starts with a source such as DynamoDB Streams capturing changes made to a table, after which a Lambda function consumes the stream record and forwards it to another AWS service such as SQS, EventBridge, or Step Functions. This design is flexible and familiar, but it often places Lambda in the middle of the flow even when the function is doing little more than forwarding records after light filtering or reshaping. In these cases, Lambda is being used more as infrastructure plumbing than as a true execution layer for application logic.

In the traditional design, a new order written to DynamoDB triggers a Lambda function through DynamoDB Streams. Lambda then filters, transforms, and forwards the event to SQS or Step Functions.

How EventBridge Pipes Simplifies the Architecture

EventBridge Pipes provides a more direct way to move events from a source to a target without placing a Lambda function in the middle. Instead of writing and maintaining code whose only job is to receive records from DynamoDB Streams and forward them elsewhere, you can connect the stream directly to supported targets such as EventBridge, SQS, or Step Functions. This moves filtering, transformation, and routing from custom code into a managed AWS integration, reducing the number of moving parts and making the event flow easier to understand.

In the EventBridge Pipes design, a new order written to DynamoDB flows from DynamoDB Streams into a pipe, which filters, transforms, and routes the event directly to SQS or Step Functions.

Advantages of Using EventBridge Pipes

Lower operational overhead and potential latency reduction With fewer Lambda functions in the middle, there are fewer deployments, permissions, logs, and runtime concerns to manage. In some cases, this can also improve end-to-end performance by removing an extra compute hop and avoiding Lambda cold starts.
Reduces intermediary Lambda functions EventBridge Pipes can replace Lambda functions that exist only to move events from a source to a target.
Built-in filtering and transformation Pipes can filter relevant events and reshape payloads before they reach the target, reducing the need for custom code.
Cleaner event flow By creating a more direct connection between source and target, EventBridge Pipes makes the architecture easier to understand, maintain, and evolve.

When to Use EventBridge Pipes Instead of Lambda

Use EventBridge Pipes instead of Lambda when your main goal is to move events from a supported source to a supported target with minimal custom processing. It is a strong fit when a Lambda function would otherwise exist only to forward, lightly filter, or reshape events, because Pipes already supports point-to-point routing, filtering, input transformation, and optional enrichment.

When Lambda Is Still the Better Choice

Lambda is still the better choice when the event requires complex business logic, external API calls, custom validation, enrichment logic that cannot be expressed cleanly through Pipes, or application-specific decision making. While EventBridge Pipes supports enrichment with services such as Lambda, API destinations, API Gateway, and Step Functions Express workflows, Pipes itself is best suited to managed integration rather than general-purpose compute.

Conclusion

EventBridge Pipes is most valuable when the problem is integration, not computation. If a Lambda function exists only to consume an event, discard some records, reshape others, and forward the rest, that function is often a candidate for replacement. By moving filtering, optional enrichment, and transformation into a managed source-to-target service, EventBridge Pipes can reduce infrastructure overhead and make event-driven architectures easier to reason about. Lambda still has a clear place when real application logic is required, but for simple routing flows, Pipes is often the cleaner design choice.

AWS Durable Functions vs Step Functions: Is Code-First Orchestration the New Standard?

Benjamin Ajewole — Sun, 21 Dec 2025 22:47:39 +0000

At the re:Invent 2025 keynote held in Las Vegas, AWS announced and launched Durable Functions for AWS Lambda, and for many serverless developers, this marked a major shift.

For the first time, AWS introduced a code-first approach to building long-running, stateful workflows directly inside Lambda, without requiring developers to define and manage Step Functions state machines.

As serverless applications grow more complex, workflows often need to:

Pause for minutes or hours
Wait for external events
Retry safely after failures
Resume without losing state

Until December 2025, AWS Step Functions were the primary solution. They are powerful and reliable, but they rely on JSON-based workflow definitions that feel disconnected from application code.

AWS Durable Functions change that model entirely.

This article explains:

What AWS Durable Functions are
How they work under the hood
How they compare to Step Functions
A full working example (handler + CDK)
Real execution screenshots
IAM and deployment configuration explained

What Are AWS Durable Functions?

AWS Durable Functions allow you to write long-running, stateful workflows directly inside a Lambda function using standard code (Node.js and Python for now).

Instead of defining workflows using Amazon States Language (ASL), you write normal async logic using a Durable Functions SDK.

Durable Functions are called durable because they:

Persist execution state automatically
Resume from the last completed step
Support long waits and external events
Survive Lambda restarts and failures

Think of it like writing a normal function, except AWS guarantees it will never forget where it left off.

Durable Function SDK: Core APIs

The Durable Execution SDK adds orchestration primitives to Lambda:

API	Purpose
`step(name, fn)`	Executes business logic with built-in retries and automatic checkpointing.
`wait(name, duration)`	Suspends execution for a specified duration (up to 1 year) without compute charges.
`waitForCallback(name)`	Pauses execution until an external event or human approval signal is received.
`createCallback()`	Creates a callback that external systems can complete
`waitForCondition(fn)`	Waits for a condition to be met by periodically checking state
`parallel(tasks)`	Executes multiple branches with durable operations in parallel with optional concurrency control
`invoke(name, payload)`	Invokes another durable or non-durable function with the specified input
`runInChildContext(name, fn)`	Runs a function in a child context with isolated state and execution tracking

How Durable Functions Work: The Replay Model

Durable Functions rely on a replay model.

Here’s what happens when your function pauses:

Your Lambda runs and reaches a wait()
AWS checkpoints the execution state
The Lambda invocation ends
Later, AWS replays the function from the beginning
Completed steps are skipped
Execution resumes from the pause point

This allows workflows to pause for minutes, hours, or days without consuming Lambda runtime.

Pro‑Tip: Determinism Is Critical

Because of replay, orchestration code must be deterministic:

No Math.random() during orchestration
No reading current time directly
No external API calls in orchestration logic

Cold Starts & Replay Performance

At first glance, replay sounds expensive, but AWS optimizes heavily:

Checkpoint state is cached in the execution environment
Previously completed steps are skipped, not re-executed
Cold starts only replay orchestration logic, not step bodies

In practice, replay overhead is milliseconds, even for multi-step workflows.

What Are AWS Step Functions?

AWS Step Functions are a fully managed workflow service where logic is defined using Amazon States Language (ASL).

They provide:

Visual workflow diagrams
Built-in retries and error handling
Native integration with 200+ AWS services

Step Functions are excellent for service-heavy orchestration, but they are configuration-first, not code-first.

Durable Functions vs Step Functions: Limits & Constraints

This is the key question readers ask: “Why would I still use Step Functions?”

Durable Functions: Constraints

State Size Limit: Durable execution checkpoint data is currently limited (≈256 KB). Large payloads should be stored externally (S3, DynamoDB).

Visibility: Durable Functions rely on logs and execution history, not a visual graph UI.

Extremely Long Sequences: Step Functions handle massive branching workflows (thousands of states) more efficiently than deep replay chains.

Step Functions: Tradeoffs

JSON‑heavy definitions
Harder to unit test
Workflow logic split from application code

Both tools remain valuable; it’s about choosing the right abstraction.

Testing Durable Functions (Huge Advantage)

One of the biggest benefits of Durable Functions is its testability.

Because workflows are just code, you can:

Unit test orchestration logic
Mock DurableContext
Use standard tools like Jest or Vitest

import { LocalDurableTestRunner } from "@aws/durable-execution-sdk-js-testing";
import { handler } from "../src/handlers/cartReminder";

describe("cartReminder handler", () => {
  beforeAll(async () => {
    await LocalDurableTestRunner.setupTestEnvironment({ skipTime: true });
  });

  afterAll(async () => {
    await LocalDurableTestRunner.teardownTestEnvironment();
  });

  it("sends a reminder after the wait when the cart is not checked out", async () => {
    const runner = new LocalDurableTestRunner({
      handlerFunction: handler,
    });

    const execution = await runner.run({
      payload: {
        userId: "user-123",
        cartId: "cart-456",
        email: "user@example.com",
      },
    });

    expect(execution.getStatus()).toBe("SUCCEEDED");
    expect(execution.getResult()).toMatchObject({
      userId: "user-123",
      cartId: "cart-456",
      email: "user@example.com",
      reminderSent: true,
      timestamp: expect.any(String),
    });
  });
});

Full Working Example: Order Workflow

This Durable Function:

Receives an event when a user adds an item to their cart
Waits 24 hours
Sends a reminder if the cart hasn't been checked out
Returns a summary of the action taken

Durable Function Handler (TypeScript)

import {
  DurableExecutionHandler,
  withDurableExecution,
} from "@aws/durable-execution-sdk-js";

type CartReminderInput = {
  userId: string;
  cartId: string;
  email: string;
};

type CartReminderResult = {
  cartId: string;
  userId: string;
  reminderSent: boolean;
  timestamp: string;
};

export const makeHandler = () => {
  const durableHandler: DurableExecutionHandler<
    CartReminderInput,
    CartReminderResult
  > = async (event, context) => {
    const { cartId, userId, email } = event;
    const startTime = new Date().toISOString();

    await context.step("cart-added", async () => {
      console.log(`User ${userId} added cart ${cartId} at ${startTime}`);
    });

    // Wait 24 hours before checking cart status
    await context.wait("wait-before-reminder", { hours: 24 });

    // Check if cart was already checked out (mocked logic)
    const cartCheckedOut = false; // Simulate lookup

    if (!cartCheckedOut) {
      await context.step("send-reminder", async (stepContext) => {
        stepContext.logger.info("Sending cart reminder", { userId, cartId, email });
      });

      return {
        cartId,
        userId,
        email,
        reminderSent: true,
        timestamp: new Date().toISOString(),
      };
    }

    return {
      cartId,
      userId,
      email,
      reminderSent: false,
      timestamp: new Date().toISOString(),
    };
  };

  return withDurableExecution(durableHandler);
};

Deploying with AWS CDK

You can deploy the Durable Function using AWS CDK with just a few steps.

const customRole = new iam.Role(this, "CustomRole", {
  assumedBy: new iam.ServicePrincipal("lambda.amazonaws.com"),
});

const cartReminderFn = new NodejsFunction(this, "CartReminderFn", {
  runtime: lambda.Runtime.NODEJS_LATEST,
  entry: "../src/handlers/cartReminder/index.ts",
  handler: "handler",
  durableConfig: {
    executionTimeout: Duration.hours(25),
    retentionPeriod: Duration.days(30),
  },
  role: customRole,
});

customRole.attachInlinePolicy(
  new iam.Policy(this, "DurablePolicy", {
    statements: [
      new iam.PolicyStatement({
        actions: [
          "lambda:CheckpointDurableExecution", // Save progress
          "lambda:GetDurableExecutionState", // Resume function state
        ],
        resources: [`${cartReminderFn.functionArn}:*`],
      }),
    ],
  })
);

executionTimeout: The amount of time that Lambda allows a durable function to run before stopping it, between a second and 366 days. If exceeded, the function will fail.

retentionPeriod: The duration for which AWS retains the execution history and state after the workflow completes. Useful for logs, audit, or manual retries. It must be between 1 and 90 days

For this article, I set it to 1 minute

Test execution

Durable configuration & Executions.

Durable Operations

Event History

When Should You Use Each?

Use Durable Functions when:

You prefer writing workflows in code
Logic is Lambda-based
You want clean unit tests and no extra state machines

Use Step Functions when:

You need visual debugging and monitoring
Your workflow spans many AWS services
You prefer declarative configuration (JSON/ASL)

Final Thoughts

The 2025 launch of AWS Durable Functions gives developers a new, elegant way to build workflows directly inside Lambda. No state machines. No JSON. Just code.

If you're building serverless apps and prefer async/await to YAML and JSON, Durable Functions are made for you.

Getting Started with Azure for AWS Professionals: A Quick Guide

Benjamin Ajewole — Thu, 03 Apr 2025 19:37:09 +0000

Introduction

When I started my current job, I had extensive experience with AWS but had never worked with Azure before. It wasn’t easy to get started, and I felt a bit lost navigating a new cloud platform. Mapping AWS services to their Azure equivalents helped me get up to speed. Once I saw the similarities and understood the key differences, I became more comfortable working with Azure.

This guide is designed to help you do the same, quickly grasp Azure by relating it to your existing AWS knowledge. We’ll cover the most commonly used services and map them directly to what you already know, highlighting key differences and practical tips to make your transition smoother.

1. Compute: From EC2 to Virtual Machines

In AWS, you probably use EC2 for virtual server instances. In Azure, the equivalent is Virtual Machines (VMs).

AWS (EC2)	Azure (Virtual Machines)	Key Differences
EC2 Instances	Virtual Machines (VMs)	Azure VMs do offer integrated support for Windows workloads, aligning with Microsoft's ecosystem.
AMI (Amazon Machine Image)	Azure Images	Images are created and managed differently.
Auto Scaling	Virtual Machine Scale Sets (VMSS)	VMSS is Azure’s native scaling service.

Quick Tip: Azure VMs require you to specify a Resource Group during creation.

AWS (Lambda)	Azure (Functions)	Key Differences
Lambda Functions	Azure Functions	Similar in concept, but Azure supports multiple triggers natively.
AWS Step Functions	Logic Apps	Step Functions focus on stateful orchestration, while Logic Apps are event-driven and connector-based.

Quick Tip: Logic Apps are more suited for business process automation and integrating with SaaS applications, while Step Functions excel at orchestrating microservices and serverless functions.

3. Containers and Orchestration: AWS Fargate for ECS, EKS to AKS, ACI

If you’ve worked with AWS Fargate or EKS, Azure offers AKS (Azure Kubernetes Service) and ACI (Azure Container Instances).

AWS (ECS/EKS)	Azure (AKS/ACI)	Key Differences
EKS (Elastic Kubernetes Service)	AKS (Azure Kubernetes Service)	AKS is fully managed and integrates with Azure AD for identity management.
AWS Fargate	ACI (Azure Container Instances)	Both are serverless container options. ACI is more suited for standalone containers, while Fargate works with ECS or EKS.

Quick Tip: Use Azure Container Registry (ACR), similar to Amazon ECR, for storing and managing container images.

4. Storage: From S3 to Blob Storage (Including Tiers)

Azure’s Blob Storage is similar to S3, but storage tiers differ slightly.

AWS (S3)	Azure (Blob Storage)	Key Differences
S3 Buckets	Blob Containers	Similar structure but different tiering.
Standard	Hot	Similar performance and cost for frequent access.
Intelligent-Tiering	Cool	Lower cost for infrequent access.
Glacier/Deep Archive	Archive	For long-term, rarely accessed data.

Quick Tip: Azure Blob Storage supports Immutable Blobs for data protection, similar to S3 Object Lock.

5. Identity and Secrets: From IAM, PCA, Secrets Manager to Azure AD, Key Vault

Managing credentials and identity is crucial. Azure’s approach is slightly different but offers similar services.

AWS (IAM, PCA, Secrets Manager)	Azure (AD, Key Vault)	Key Differences
IAM (Identity and Access Management)	Azure AD (Active Directory)	Azure AD has built-in SSO and enterprise identity management.
Secrets Manager	Azure Key Vault	Both store secrets, but Key Vault also handles certificates.
Amazon Certificate Manager (ACM)	Azure Key Vault Certificates	Manages TLS/SSL certificates.
Private Certificate Authority (PCA)	Azure Key Vault Certificate Management	Key Vault supports issuing and managing private certificates.

Quick Tip: Use Managed Identities in Azure to avoid managing secrets directly, similar to IAM roles in AWS. Azure AD's functionalities extend beyond those of AWS IAM, encompassing broader identity management features.

6. Messaging and Event Handling: From SQS, SNS, EventBridge to Service Bus, Event Grid

Azure provides comparable services for messaging and event-driven architectures.

AWS (SQS, SNS, EventBridge)	Azure (Service Bus, Event Grid)	Key Differences
SQS (Simple Queue Service)	Service Bus Queues	Service Bus supports more advanced messaging patterns.
SNS (Simple Notification Service)	Service Bus Topics	Topics in Service Bus support subscriptions and filters.
EventBridge	Event Grid	Event Grid is more integrated with Azure services.

Quick Tip: Use Azure Logic Apps to build workflows that react to events, similar to AWS Step Functions.

7. API Gateway: From AWS API Gateway to Azure API Management (APIM)

AWS (API Gateway)	Azure (APIM)	Key Differences
API Gateway	API Management (APIM)	APIM supports versioning, throttling, and transformation out of the box.
Lambda Integration	Function App Integration	Similar serverless backend support.

Quick Tip: Azure’s APIM developer portal is more "built-in" and ready to use out of the box compared to AWS API Gateway, which requires manual deployment and configuration of a developer portal.

8. DNS and CDN: From Route 53 and CloudFront to Azure DNS and CDN

AWS (Route 53, CloudFront)	Azure (DNS, CDN)	Key Differences
Route 53	Azure DNS	Route 53 provides DNS name management and DNS-level traffic routing and failover services.
CloudFront	Azure CDN	CloudFront offers Lambda@Edge, while Azure CDN integrates with Front Door.

Quick Tip: Azure CDN supports integration with Azure Front Door for application acceleration and global load balancing. In Azure, Azure DNS provides domain and DNS management while Traffic Manager provides DNS-level traffic routing, load balancing, and failover capabilities.

9. AI and Machine Learning: From SageMaker to Azure Machine Learning

AWS (SageMaker)	Azure (Machine Learning)	Key Differences
SageMaker Notebooks	Azure Machine Learning Notebooks	Both provide Jupyter-based environments.
SageMaker Models	Azure Models	Azure ML integrates tightly with Azure DevOps for CI/CD.
Comprehend	Text Analytics	Similar NLP capabilities.
Rekognition	Computer Vision	Azure offers pre-trained and customizable models.

Quick Tip: Azure has a broader set of cognitive services for vision, speech, and language, similar to AWS AI services.

10. Database Services: From RDS, DynamoDB, Aurora to Azure SQL, Cosmos DB

AWS and Azure both offer a wide array of database services, but their approach and feature sets differ. AWS provides managed relational and NoSQL databases through services like RDS, DynamoDB, and Aurora. Azure offers similar capabilities through Azure SQL Database, Cosmos DB, and other data services.

AWS (RDS, DynamoDB, Aurora)	Azure (SQL Database, Cosmos DB)	Key Differences
RDS (Relational Database Service)	Azure SQL Database	RDS supports multiple engines, while Azure SQL focuses on SQL Server compatibility.
Aurora.	SQL Managed Instance.	Aurora offers MySQL and PostgreSQL compatibility, while SQL MI offers full SQL Server support.
DynamoDB.	Cosmos DB.	Cosmos DB provides multi-model support, including SQL, MongoDB, Cassandra, and Graph APIs.
Redshift	Azure Synapse Analytics	Redshift focuses on data warehousing, while Synapse integrates data lakes and big data processing.
ElastiCache	Azure Cache for Redis	Both provide in-memory caching but differ in their integration with other cloud services.

Quick Tip: Choose Cosmos DB for multi-region, globally distributed apps, and Azure SQL Database for SQL Server workloads that need high availability and scaling.

11. Networking: From VPC to VNet

Networking is a critical aspect of both AWS and Azure, providing foundational services for connecting and managing resources.

AWS (VPC)	Azure (VNet)	Key Differences
VPC (Virtual Private Cloud)	VNet (Virtual Network)	Both provide isolated networks, but VNet natively integrates with Azure services.
Direct Connect	ExpressRoute	Both provide private, high-speed connectivity, but pricing and integration vary.
Transit Gateway	Virtual WAN	Transit Gateway connects VPCs, while Virtual WAN provides a centralized networking hub.

Quick Tip: Use Azure Bastion for secure RDP and SSH connectivity to VMs without exposing them to the public internet.

Conclusion

Transitioning from AWS to Azure doesn’t have to be overwhelming. By understanding how key services map to each other, you can quickly become proficient with Azure. Focus on familiar concepts, explore the Azure Portal and CLI, and practice building simple setups to get hands-on experience. Whether it’s compute, storage, AI, or serverless, Azure has the tools to match your AWS expertise.

Would you like more deep dives into specific services or practical migration tips? Let me know!

Leveraging AWS API Destination to Trigger External APIs

Benjamin Ajewole — Thu, 27 Mar 2025 19:40:00 +0000

Introduction

Last year, while developing an AWS solution to integrate Salesforce and Microsoft Dynamics NAV, I was tasked with designing a system to capture DynamoDB stream updates and send them to both platforms. During this process, I discovered AWS API Destinations, which provided a seamless way to securely invoke external APIs, simplifying API call management and authentication.

AWS EventBridge API Destinations allow users to configure rules that securely send events to external APIs. They improve reliability by automatically retrying failed requests based on built-in retry policies. This article explores how to use API Destinations, referencing a high-level architecture diagram.

High-Level Architecture explanation

The architecture consists of the following components:

AWS DynamoDB: Acts as the primary data store.
Stream Handler (AWS Lambda): This listens for changes in the DynamoDB stream and sends updates to EventBridge.
EventBridge Event Bus: Routes events to API Destination.
CloudWatch Logs: Captures logs for monitoring and debugging.
API Destination: Acts as an intermediary to send requests to external APIs.
DLQ (Dead Letter Queue): Captures failed event deliveries for further analysis.
AWS Secret Manager: Manages credentials for secure API authentication.
Connection: Defines the authorization method, credentials, and network connectivity for EventBridge to communicate securely with the external webhook.
Webhook: The final external API endpoint that receives the triggered request.

Important AWS Considerations

Only Public APIs Supported: API Destinations support only public domain names with publicly trusted certificates for HTTPS endpoints. Private APIs that are not publicly resolvable and mutual TLS (mTLS) authentication are not supported.
Execution Timeout: Requests to API Destinations must complete within 5 seconds. If the target endpoint takes longer, EventBridge will time out the request and retry it according to the maximums set in the configured retry policy.

Use Cases for AWS API Destination

Third-party Service Integration: You can easily integrate AWS event-driven architectures with SaaS platforms like Salesforce, Slack, or Stripe.
Webhook-based Notifications: Automate event-driven notifications to external services.
Cross-Cloud Communications: Bridge AWS events with APIs hosted on other cloud providers.
Security and Compliance Monitoring: Send security logs to third-party SIEM tools for real-time analysis.
Automated Data Synchronization: Push updates from AWS services to external databases or applications.

Best Practices for Using API Destination

Optimize API Response Time: Since API Destination has a 5-second timeout, ensure that the external API is optimized for quick responses. Use caching or lightweight processing where possible.
Utilize Dead Letter Queues (DLQ): Configure DLQs to capture failed API calls for debugging and retrying later.
Monitor with CloudWatch Logs: Enable logging to track API calls, errors, and response times for troubleshooting and optimization.
Leverage AWS Secrets Manager: Store API keys and authentication credentials securely instead of hardcoding them in API Destination configurations.
Set Up Rate Limits: To prevent exceeding third-party API limits, use throttling mechanisms or request prioritization strategies.
Use Exponential Backoff for Retries: Configure EventBridge retry policies to use exponential backoff, reducing the likelihood of overloading external APIs.
Test with Mock APIs: Before integrating with a production API, use mock APIs to validate EventBridge configurations and request formatting.
Implement Security Best Practices: Restrict access to API Destinations by using IAM roles and policies to prevent unauthorized access.
Use Any HTTP Method Except CONNECT and TRACE: API Destination supports various HTTP methods, excluding CONNECT and TRACE.
Leverage Input Transformers: Customize event payloads to match the expected parameters of the external API endpoint, ensuring seamless integration.
Understand EventBridge Retry Behavior: Amazon EventBridge retries requests that receive HTTP error codes 401, 407, 409, 429, and any 5xx errors. It does not retry requests with 1xx, 2xx, 3xx, or most 4xx errors, except for the specified ones.

AWS CDK example

// Create a secret for client credentials
const clientSecret = new Secret(scope, 'SecretName', {
    secretName: 'secret-name',
});

// Create a secure connection for API authentication
const connection = new Connection(stack, 'ConnectionId', {
    connectionName: 'MyConnection',
    authorization: Authorization.oauth({
        authorizationEndpoint: "authorization-url",
        clientId: "client-id",
        clientSecret: clientSecret.secretValue,
        httpMethod: HttpMethod.POST,
        bodyParameters: {
            grant_type: "client_credentials",
        },
    }),
});

// Define the API Destination
const apiDestination = new ApiDestination(stack, 'ApiDestinationId', {
    apiDestinationName: 'ApiDestination',
    connection,
    endpoint: "endpoint-url",
    httpMethod: HttpMethod.POST,
    rateLimitPerSecond: 10,
});

// Create a Dead Letter Queue (DLQ) for failed events
const deadLetterQueue = new Queue(stack, 'DLQ');

// Define an EventBridge Rule
new Rule(stack, "EventBridgeRuleId", {
    ruleName: "EventBridgeRuleId",
    eventBus: new EventBus(stack, 'MyEventBus'),
    eventPattern: {
        source: ["eventSourceName"],
        detailType: ["eventDetailType"],
    },
    targets: [
        new ApiDestinationTarget(apiDestination, {
            deadLetterQueue,
            event: { detail: { key: "value" } },
            retryAttempts: 185,
            maxEventAge: Duration.hours(24),
        }),
    ],
});

Conclusion

AWS API Destination simplifies the process of securely triggering external APIs based on AWS events. Developers can build robust and scalable event-driven integrations with external services by leveraging managed authentication, retry policies, and monitoring capabilities. However, when designing solutions with API Destinations, it's essential to be mindful of execution time limits and supported API types.

Create Certificate Authority with AWS Private CA SDK

Benjamin Ajewole — Tue, 23 Apr 2024 21:00:00 +0000

In cybersecurity, the importance of secure communication cannot be overstated. Certificates are the bedrock for establishing encrypted and authenticated connections over networks, safeguarding data integrity, confidentiality, and authenticity. When managing certificates at scale within cloud environments like Amazon Web Services (AWS), leveraging tools like AWS Private Certificate Authority (acm-pca) SDK becomes indispensable. In this article, we'll explore the fundamentals of certificates, the significance of certificate authorities, and the practical steps involved in setting up a secure infrastructure.

What are Certificates?

Certificates are digital documents used to establish trust between parties in a communication exchange. These certificates contain vital information like the identity of the certificate holder, public keys, and cryptographic signatures.

What is the usefulness of certificates?

Certificates serve various purposes in ensuring the security of online transactions and communications, including:

Authentication: Certificates verify the identity of parties involved in a transaction.
Encryption: Certificates enable secure transmission of data by encrypting it.
Integrity: Certificates ensure the integrity of transmitted data, preventing tampering or unauthorized modifications.
Trust: Certificates establish trust between communicating parties, ensuring that sensitive information is shared only with trusted entities.

Components of a Certificate

A typical certificate comprises several components, including:

Subject: The entity to which the certificate is issued.
Issuer: The entity that issues the certificate.
Public Key: The cryptographic key used for encryption and verification.
Signature: A digital signature created by the issuer to validate the certificate's authenticity.
Validity Period: The duration for which the certificate remains valid.
Extensions: Additional information such as key usage, subject alternative names, etc.

Types of Certificates

There are various types of certificates tailored to specific use cases, including:

SSL/TLS Certificates: Used to secure websites and establish encrypted connections.
Code Signing Certificates(CSR): Ensures the authenticity and integrity of software.
Email Certificates: Secures email communications by encrypting and digitally signing messages.
Certificate Authority (CA) certificates: A Certificate Authority (CA) certificate is a digital certificate issued by a trusted Certificate Authority.

What is a certificate authority?

A Certificate Authority (CA) is a trusted entity responsible for issuing and managing digital certificates. It verifies the identity of entities requesting certificates and signs them to establish their authenticity.

What is a root certificate?

A Root Certificate is a self-signed certificate at the top of the certificate hierarchy. It represents the highest level of trust in a certificate chain and is used to sign other certificates, including intermediate certificates.

What is an intermediate certificate?

An Intermediate Certificate is a subordinate certificate issued by a root certificate. It sits between the root certificate and end-entity certificates. Intermediate certificates help in enhancing security by segregating certificate issuance and revocation processes.

Why do I need to create an intermediate certificate?

Creating an intermediate certificate offers several advantages:

Enhanced Security: Intermediate certificates provide an additional layer of security, reducing the risk associated with compromising a root certificate.
Scalability: Intermediate certificates allow for better management and delegation of certificate issuance responsibilities, particularly in large-scale environments.
Granular Control: By utilizing intermediate certificates, administrators can implement fine-grained access control and policy enforcement

Create a root and intermediate certificate with OpenSSL

Using OpenSSL, a widely-used open-source toolkit, one can generate root and intermediate certificates. Below are the OpenSSL commands to accomplish this:

# Generate a root private key
openssl genpkey -algorithm RSA -out root.key

# Generate a root certificate signing request
openssl req -new -key root.key -out root.csr

# Self-sign the root certificate
openssl x509 -req -in root.csr -signkey root.key -out root.crt

# Generate an intermediate private key
openssl genpkey -algorithm RSA -out intermediate.key

# Generate an intermediate certificate signing request
openssl req -new -key intermediate.key -out intermediate.csr

# Sign the intermediate certificate using the root certificate
openssl x509 -req -in intermediate.csr -CA root.crt -CAkey root.key -set-serial 01 -out intermediate.crt

Create a root and intermediate certificate with acm-pca

AWS Private CA enables the creation of private certificate authority (CA) hierarchies, including root and intermediate/subordinate CAs.
Using the AWS Certificate Manager Private Certificate Authority (acm-pca) SDK, you can automate the process of creating root and intermediate certificates. Here's how to achieve it using TypeScript:

import { ACMPCAClient, IssueCertificateCommand, CreateCertificateAuthorityCommand} from '@aws-sdk/client-acm-pca';

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

// Create Root CA
  const rootCommand = new CreateCertificateAuthorityCommand({
    CertificateAuthorityType: "ROOT", // Specifies that this CA is a root CA  KeyAlgorithm: 'RSA_2048',
    CertificateAuthorityConfiguration: {
      Subject: {
        Country: "US",
        Organization: "Example Corp",
        OrganizationalUnit: "IT",
        State: "California",
        Locality: "San Francisco",
        CommonName: "Root CA",
        SerialNumber: "202401",
      },
      SigningAlgorithm: "SHA256WITHRSA",
      KeyAlgorithm: "RSA_2048",
    },
  });
const rootResponse = await client.send(rootCommand);
const rootArn = rootResponse.CertificateAuthorityArn;

// Create Intermediate CA
 const intermediateCommand = new IssueCertificateCommand({
    CertificateAuthorityArn: rootArn,
    Csr: new Uint8Array(Buffer.from(csrPem)),
    SigningAlgorithm: "SHA256WITHRSA",
    TemplateArn:
      "arn:aws:acm-pca:::template/SubordinateCACertificate_PathLen0/V1",
    Validity: {
      Value: 365,
      Type: "DAYS",
    },
  });

const intermediateResponse = await client.send(intermediateCommand);

AWS Private CA Templates

AWS Private CA offers predefined templates to streamline certificate issuance for various use cases. These templates encapsulate best practices and simplify the process of generating certificates for specific scenarios.

End Entity Certificate Template: For issuing certificates directly to end entities such as servers, clients, or IoT devices.
Subordinate CA Certificate Template: Simplifies the creation of intermediate CAs for delegating certificate issuance authority.
Root CA Certificate Template: Facilitates the creation of self-signed root certificates for establishing trust within the PKI.

Read more on AWS Templates

In conclusion, the AWS Private CA SDK provides a powerful toolkit for managing digital certificates, allowing organizations to establish robust security postures and ensure the integrity and confidentiality of their data. By leveraging AWS Private CA, developers can automate certificate management processes and focus on building secure and scalable applications.

Leveraging Custom Resources in AWS CloudFormation

Benjamin Ajewole — Sun, 03 Mar 2024 12:44:00 +0000

AWS CloudFormation is a powerful AWS infrastructure-as-code service, it enables you to define and provision AWS infrastructure resources in a declarative way using JSON or YAML templates. These templates describe the desired state of the AWS environment, including resources such as VPCs, EC2 instances, S3 buckets, Step Functions, Lambda functions, and more. CloudFormation automates the provisioning and management of these resources, making it easier to deploy and maintain complex AWS architectures.

Limitations of CloudFormation

While CloudFormation is an efficient tool for managing AWS resources, it does have some limitations. One major limitation is its inability to directly interact with external systems or perform actions beyond the scope of AWS services. This can be restrictive when needing to integrate with external APIs and databases or perform custom actions during stack creation or updates.

Introducing Custom Resource

To overcome the limitations of CloudFormation, AWS provides Custom Resources. Custom Resources allow you to extend CloudFormation's capabilities by incorporating custom logic or integrating with external systems during stack creation, update, or deletion. Essentially, Custom Resources enables you to define and manage AWS resources that are not natively supported by CloudFormation.

Other Use Cases of Custom Resource

Custom Resources can be utilized for various use cases, including:

Integration with External Systems: Execute custom logic or interact with external APIs, databases, or services during stack operations.
Dependency Management: Manage dependencies between AWS resources that are not directly supported by CloudFormation.
Configuration Management: Dynamically configure resources based on parameters or conditions not directly supported by CloudFormation.
Data Transformation: Perform data transformations or enrichments during resource creation or updates.

CloudFormation for Creating Custom Resource

Resources:
  MyCustomResource:
    Type: Custom::MyCustomResource
    Properties:
      ServiceToken: arn:aws:lambda:REGION:ACCOUNT_ID:function:MyCustomResourceFunction
      ResourceName: MyResource

CDK Code for Creating a Custom Resource

import * as cdk from '@aws-cdk/core';
import * as lambda from '@aws-cdk/aws-lambda';
import * as cr from '@aws-cdk/custom-resources';

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

    // Define the Lambda function for the Custom Resource
    const myLambdaFunction = new lambda.Function(this, 'MyCustomResourceHandler', {
      runtime: lambda.Runtime.NODEJS_20_X,
      handler: 'index.handler',
      code: lambda.Code.fromAsset('lambda'),
    });

    // Define the Custom Resource Provider
    const myProvider = new cr.Provider(this, 'MyCustomResourceProvider', {
      onEventHandler: myLambdaFunction,
    });

    // Create the Custom Resource
    new cdk.CustomResource(this, 'MyCustomResource', {
      serviceToken: myProvider.serviceToken,
      properties: {
        // Custom properties for the resource if needed
      },
    });
  }
}

When to Use AwsCustomResource and Provider

AWS CDK offers two primary mechanisms for implementing Custom Resources: AwsCustomResource and Provider.

AwsCustomResource: It provides a means to extend CloudFormation's capabilities by integrating custom AWS-specific logic seamlessly into the stack operations. You can use this when you have simple Custom Resource requirements and prefer a more streamlined, high-level abstraction. It's suitable for quick implementations and scenarios where simplicity outweighs advanced customization.

Provider: When the necessity arises to communicate with external systems or services beyond the AWS ecosystem, the Provider mechanism is utilized. It allows for the integration with external APIs or services through the use of Lambda functions or SDKs. With Providers, custom logic can be efficiently managed to orchestrate interactions with external systems as part of the CloudFormation stack operations.

Conclusion

Custom Resources offers a powerful way to extend the capabilities of AWS CloudFormation beyond its native functionalities. By leveraging Custom Resources, developers can integrate with external systems, perform custom actions, and manage dependencies more effectively within CloudFormation templates. Whether it's executing AWS API calls or interacting with external services, Custom Resources provides the flexibility needed to orchestrate complex AWS environments seamlessly.

https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.custom_resources.Provider.html

https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-cloudformation-customresource.html#cfn-cloudformation-customresource-servicetoken

Understanding Transactions in Amazon DynamoDB

Benjamin Ajewole — Mon, 12 Feb 2024 19:04:47 +0000

DynamoDB Transactions

Maintaining data consistency and integrity is crucial, particularly in applications managing large transaction volumes. Amazon DynamoDB, a fully managed NoSQL database service provided by Amazon Web Services (AWS), offers robust solutions for handling such scenarios through its transaction support.

What are Transactions?

Within the context of databases, a transaction is a unit of work that encapsulates one or more database operations, such as reads or writes, which should be executed as a single, indivisible unit. The ACID (Atomicity, Consistency, Isolation, Durability) properties define the essential characteristics of a transaction. These properties ensure that transactions are executed reliably, consistently, and with integrity, even amidst system failures or concurrent execution.

DynamoDB Transactions

Introduced in 2018, DynamoDB transactions allow developers to perform multiple operations on one or more items atomically. This ensures that either all operations in the transaction succeed, or none of them are applied. Adhering to the principles of ACID, DynamoDB transactions assure data consistency and integrity.

Features of DynamoDB Transactions

Atomicity: DynamoDB transactions are atomic, meaning that either all operations in the transaction succeed, or none of them is applied. This prevents partial updates or inconsistent states in the database.

Consistency: Transactions in DynamoDB maintain the consistency of data by ensuring that all reads and writes within a transaction are isolated from other operations. This prevents concurrent modifications from interfering with the transaction’s outcome.

Isolation: DynamoDB transactions provide isolation between concurrent transactions, ensuring that the effects of one transaction are not visible to others until it is committed. This prevents concurrency issues such as dirty reads, non-repeatable reads, and phantom reads.

Durability: Once a transaction is committed, the changes made to the database are durable and will persist even in the event of system failures or crashes.

Support for Conditional Writes: DynamoDB transactions support conditional writes, allowing developers to specify conditions that must be met for an operation to succeed. This feature is particularly useful for implementing business logic or enforcing data constraints within transactions.

Transactional APIs

DynamoDB offers two transactional APIs for performing transactions:

Transaction Write Actions: This API enables developers to perform multiple Put, Update, or Delete operations within a single transaction. You can optionally include a client token when you make a TransactWriteItems call to ensure that the request is idempotent.

Transaction Get Actions: This API allows developers to perform multiple Get operations within a single transaction, ensuring read consistency across multiple items. The Get actions are performed atomically so that either all of them succeed or all of them fail

TransactionCanceledException

This exception is thrown when working with DynamoDB transactions. This exception can be thrown for different reasons including:

Conditional check failed: One or more conditions specified in the transaction request were not met, causing the transaction to be cancelled.

Transaction conflict: Another transaction concurrently modified one or more items that are part of the transaction, causing a conflict and resulting in the transaction being cancelled. DynamoDB automatically retries the transaction if this exception occurs.

Item collection size exceeded: The total size of the items in the transaction exceeds the maximum allowed item collection size, leading to the transaction being cancelled.

Provisioned throughput limit exceeded: The transaction exceeded the provisioned throughput limits for the table or index, causing the transaction to be cancelled. This can happen if the transaction rate exceeds the provisioned capacity.

Use Cases

DynamoDB transactions are well-suited for various use cases where data consistency and integrity are critical:

E-commerce Platforms: Ensuring inventory updates, order processing, and payment transactions are executed atomically.

Financial Services: Handling financial transactions, account balances, and fund transfers securely.

Collaborative Editing Tools: Synchronizing concurrent edits to documents or collaborative projects without conflicts.

Best Practices

When working with DynamoDB transactions, it’s essential to adhere to best practices to maximize performance, scalability, and reliability:

Keep Transactions Short: Minimize the duration of transactions to reduce the likelihood of conflicts and improve throughput.

Batch Operations: Utilize batch operations whenever possible to reduce the number of round trips to the DynamoDB service.

Optimistic Concurrency Control: Use optimistic concurrency control to handle conflicts by detecting concurrent modifications and retrying transactions when necessary.

Monitor Performance: Monitor transaction throughput, latency, and error rates using Amazon CloudWatch metrics to identify and address performance bottlenecks.

Let’s incorporate examples using the SDK (Software Development Kit) for DynamoDB transactions.

Example 1:
We want to ensure that when a customer places an order, we deduct the purchased items from the inventory and record the order details atomically.

import { DynamoDBClient, TransactWriteItemsCommand } from "@aws-sdk/client-dynamodb";

// Create a DynamoDBClient instance
const client = new DynamoDBClient({
    region: 'eu-west-1'
});

// Define the parameters for the transaction
const params = {
  TransactItems: [
    {
      Update: {
        TableName: 'InventoryTable',
        Key: { productId: 'product1' },
        UpdateExpression: 'SET quantity = quantity - :quantity',
        ConditionExpression: 'quantity >= :quantity',
        ExpressionAttributeValues: { ':quantity': 1 },
        ReturnValuesOnConditionCheckFailure: 'ALL_OLD'
      }
    },
    {
      Put: {
        TableName: 'OrderTable',
        Item: {
          orderId: 'order123',
          productId: 'product1',
          quantity: 1,
          customerName: 'John Doe'
        },
      }
    }
  ]
};

try {
    const command = new TransactWriteItemsCommand(params);
    const data = await client.send(command);
    console.log('Transaction executed successfully:', data);
} catch (err) {
    console.error('Unable to execute transaction. Error:', err);
}

Example 2:
We want to implement a transaction that allows a user to like a post and update the corresponding user’s and post’s data atomically.

import { DynamoDBClient, TransactWriteItemsCommand } from "@aws-sdk/client-dynamodb";


const client = new DynamoDBClient({
    region: 'eu-west-1'
});

const params = {
    TransactItems: [
        {
            Update: {
                TableName: 'PostsTable',
                Key: { postId: 'post123'},
                UpdateExpression: 'SET likes = likes + :increment',
                ExpressionAttributeValues: { ':increment': 1 }
            }
        },
        {
            Update: {
                TableName: 'UsersTable',
                Key: { userId: 'user456' },
                UpdateExpression: 'ADD likedPosts :postIds',
                ExpressionAttributeValues: { ':postIds': ['post123'] }
            }
        },
        {
            Update: {
                TableName: 'PostsTable',
                Key: { postId: 'post123' },
                UpdateExpression: 'ADD likedBy :userIds',
                ExpressionAttributeValues: { ':userIds': ['user456'] }
            }
        }
    ]
};

try {
    const command = new TransactWriteItemsCommand(params);
    const data = await client.send(command);
    console.log('Transaction executed successfully:', data);
} catch (err) {
    console.error('Unable to execute transaction. Error:', err);
}

Conclusion

Amazon DynamoDB transactions provide developers with powerful tools for ensuring data consistency and integrity in high-throughput applications. By adhering to the principles of ACID and offering support for atomic, consistent, isolated, and durable transactions, DynamoDB equips developers to build robust and reliable systems capable of handling complex transactional workflows. Understanding and effectively leveraging DynamoDB transactions are essential for building scalable and resilient applications on AWS.

Prevent Lambda cold start using CDK

Benjamin Ajewole — Mon, 11 Sep 2023 22:10:36 +0000

A notable challenge within the realm of serverless architecture lies in the phenomenon known as "cold starts." A cold start occurs when a fresh instance of a function must be generated and initialized before processing an incoming request. While cold starts may not significantly impact applications that don't require an immediate response, such as background tasks or batch processes, they can pose substantial challenges when your AWS Lambda functions are integrated with API Gateway and are expected to deliver responses with minimal latency.
In scenarios where API Gateway and Lambda are closely coupled, cold starts can lead to delays in serving requests, affecting the overall responsiveness and user experience of your application.

There are different ways to prevent Lambda cold start

Provisioned concurrency
Cold start times are affected by the memory allocated to your Lambda function. Higher memory allocations come with more CPU power and network bandwidth.
Reducing the size of your deployment packages generally leads to quicker cold start times. Achieve this by eliminating superfluous dependencies, files, or libraries from your deployment bundle and opting for minimalistic runtime environments whenever feasible.
Create a specialized warm-up process, like a Lambda warm-up function, that triggers your Lambda function at regular intervals to ensure it remains in a warmed state. Another approach is to schedule recurring CloudWatch Events that invoke your function periodically, preventing it from experiencing full cold starts.

Provisioned Concurrency?

Provisioned concurrency initializes a requested number of execution environments so that they are prepared to respond immediately to your function's invocations. Note that configuring provisioned concurrency incurs charges to your AWS account.
With provisioned concurrency, you don't need to worry about cold starts because your Lambda functions will be in a warm state ready to respond immediately without initializations.

Lambda Warm State Setup with CDK

import * as cdk from 'aws-cdk-lib';
import * as lambda from 'aws-cdk-lib/aws-lambda';
import * as lambdaEventSources from 'aws-cdk-lib/aws-lambda-event-sources';

const myLambda = new lambda.Function(this, 'MyLambda', {
  runtime: lambda.Runtime.NODEJS_14_X,
  handler: 'index.handler',
  code: lambda.Code.fromAsset('path/to/lambda-code'),
  memorySize: 256,
});

const aliasOptions = {
  aliasName: 'MyAlias',
  version: myLambda.currentVersion,
  provisionedConcurrentExecutions: 2 //there will always be at least two Lambda functions running
};

new lambda.Alias(this, 'MyLambdaAlias', aliasOptions);

Conclusion

Apart from using provisioned concurrency, you can spend more time on making sure your Lambda function code is highly efficient by minimizing unnecessary initialization and resource allocation during function execution. You can also minimize the number of external dependencies your Lambda function relies on. Fewer dependencies mean less initialization work when the function starts.

Different ways to invoke AWS Lambda Functions

Benjamin Ajewole — Sun, 10 Sep 2023 22:36:07 +0000

AWS Lambda is a Serverless, event-driven compute service that lets you run code for virtually any type of application or backend service without provisioning or managing servers. You can trigger Lambda from over 200 AWS services and software-as-a-service (SaaS) applications and only pay for what you use.

Check out my previous posts on how to create a Lambda function and deploy it the CI/CD way.

AWS Lambda can be invoked in several ways which include through the Lambda console, a function URL HTTP(S) endpoint, the Lambda API, Amazon API Gateway, an AWS SDK, the AWS Command Line Interface (AWS CLI), and AWS toolkits. You can also configure other AWS services to invoke your function, or you can configure Lambda to read from a stream or queue and invoke your function.

In this tutorial, we will be covering how to invoke using the Lambda console, function URL, AWS SDK and the AWS Command Line Interface (AWS CLI).

Invoking your Lambda function through the Lambda console

Go to the Lambda function
Click on Test
Input an Event Name and click on Invoke, this will invoke the function

Invoking your Lambda function through the function URL

Function URLs are not supported in the following regions: Asia Pacific (Hyderabad) (ap-south-2), Asia Pacific (Melbourne) (ap-southeast-4), Europe (Spain) (eu-south-2), Europe (Zurich) (eu-central-2), Israel (Tel Aviv) (il-central-1), and Middle East (UAE) (me-central-1)

Follow these steps to create a function URL for your Lambda function

Go to the Lambda console
Click on the Configuration tab
Click on Function URL
Click on Create Function URL
Select None and click on Save
Open the link on your browser

Invoking your Lambda function using AWS SDK

import {InvokeCommand, LambdaClient} from "@aws-sdk/client-lambda";

const client = new LambdaClient({
region: "eu-west-1"
});

client.send(new InvokeCommand({
  FunctionName: "helloWord"
}))

Invoking your Lambda function using AWS CLI

# run this following commands

aws configure #configure aws cli

aws lambda invoke - function-name helloWorld response.json # invoke lambda function

cat response.json # read the response

Happy coding!!

Understanding AWS Fargate (Serverless Container or CaaS)

Benjamin Ajewole — Mon, 01 Aug 2022 12:20:55 +0000

AWS Fargate is a technology you can use with Amazon ECS to run containers without managing servers or clusters of Amazon EC2 instances. With Fargate, you no longer have to provision, configure, or scale clusters of virtual machines to run containers. This removes the need to choose server types, decide when to scale your clusters or optimize cluster packing. It's both compatible with AWS ECS and AWS EKS.

AWS Fargate is also referred to as Container as a Service (CaaS). Containers as a service (CaaS) is a cloud-based service that allows software developers and IT departments to upload, organize, run, scale, and manage containers by using container-based virtualization.

What are Containers?

Containers are packages of software that contain all of the necessary elements to run in any environment. In this way, containers virtualize the operating system and run anywhere, from a private data center to the public cloud or even on a developer's personal laptop.

With Amazon ECS, you can choose between two launch types: Fargate launch type (AWS managed) and Amazon EC2 launch type(User managed).

What difference between Fargate and EC2 launch types?

EC2 lets you create your own cluster, while Fargate allows you to simply deploy your containers to AWS' cluster, saving you the time and effort of managing your own machines and clusters.

Costs differ for EC2 and AWS Fargate. With EC2, billing is based on the cost of the EC2 instances used; AWS Fargate also charges for CPU cores and memory consumed.

What problems does AWS Fargate solve?

One of AWS Fargate's main advantages is a solution to the challenges of hosting, scaling and managing cloud infrastructure to run containerized applications. Amazon Fargate abstracts infrastructure operations, devoting more effort to creating containerized applications.

How AWS Fargate works?

The steps in the deployment cycle are:
1) Build a container image
2) Host your container image on AWS ECR or DockerHub
3) Choose an orchestration service: Amazon ECS or Amazon EKS
4) Create a Cluster taking the AWS Fargate option

Cons of AWS Fargate?

Less Customization: AWS Fargate is not well-suited for users or organisations that want to have greater control over their containers.
Not cost-effective for small workloads: If you have a ton of small services which are rarely used, it can be a lot cheaper to use EC2 instead.

Pros of AWS Fargate?

Reduce Complexity: AWS Fargate is a container as a service, so you don't need to worry about where and how to manage and scale your containers.

Better Security: AWS handles the security of your infrasctructure.

AWS Fargate pricing?

AWS Fargate pricing is calculated based on the vCPU, memory, Operating Systems, CPU Architecture, and storage resources used per second. Read more here: https://aws.amazon.com/fargate/pricing/
How to get started with AWS Fargate?
https://aws.amazon.com/fargate/getting-started/
https://docs.aws.amazon.com/eks/latest/userguide/fargate-getting-started.html

Setup CI/CD for your AWS Lambda with Serverless Framework and GitHub Actions

Benjamin Ajewole — Sat, 05 Feb 2022 11:36:49 +0000

Previously I wrote about how to Create a Serverless backend with AWS Lambda Function, Amazon API Gateway and Serverless Framework. In that tutorial, I showed you how to create, test and deploy your serverless app to AWS Lambda and Amazon API Gateway manually but in this tutorial, I'll be showing you how to deploy it using CI/CD.

What's CI/CD?

CI/CD stands for continuous integration, continuous deployment and continuous delivery. It's a process that alienates manual processes of doing things. It is the art of automating the process of building, testing, deployment and delivery of apps to your customers. There are different tools used for CI/CD, they include Jenkins, GitHub Actions, GitLab CI, CircleCI, Travis CI, Bitbucket Pipelines, AWS CodeBuild, AWS CodeDeploy, AWS CodePipeline and many more.

In this tutorial, I'll be using AWS, Serverless framework and GitHub Actions

GitHub Actions

GitHub Actions automate, customize, and execute your software development workflows right in your repository with GitHub Actions. You can discover, create, and share actions to perform any job you'd like, including CI/CD, and combine actions in a completely customized workflow.

Prerequisites to follow along:

Have a GitHub account
Fork and clone this repo (contains code from my previous tutorial)
Have an AWS account
Create an AWS IAM user that has the following permissions: IAMFullAccess, AmazonS3FullAccess, CloudWatchFullAccess, AWSCloudFormationFullAccess, AWSLambda_FullAccess and AmazonAPIGatewayInvokeFullAccess.
Store the AWS user API key and secret key (keep it safe)

Create a main.yml file to define the workflow configuration

After ticking all the prerequisites, create a file called main.yml in folder .github/workflows and paste this code

A workflow is a configurable automated process made up of one or more jobs.

Workflow syntax

name: the name of the workflow

on: the type of event that can run the workflow. Our workflow will only run when there's a git push to either the master or develop branch. Read more here

jobs: a workflow consists of one or more jobs. Jobs run in parallel unless a needs keyword is used. Each job runs in a runner environment specified by runs-on

steps: sequence of tasks to be carried out

uses: selects an action to run as part of a step in your job. An action is a reusable unit of code. Read more here

with: a map of input parameters

run: runs command-line programs

env: set the environment variables

Add API key and secret key to GitHub secret

Go to settings on the forked repo to add your API Key and Secret key. Click on Secrets on the left side nav and click on New repository secret to add your secrets. The API Key and Secret Key gives us programmatic access to your AWS environment.

Push changes to GitHub to start the workflow

You can now commit your changes locally and push it to GitHub. Navigate the repo on GitHub, click on the actions, you should be able to see your workflows.

Extra resources

You can see the full project here
Read the docs to know more about GitHub actions
Read more about Serverless framework here
Learn more about AWS here

Create a Serverless backend with AWS Lambda Function, Amazon API Gateway and Serverless framework

Benjamin Ajewole — Tue, 23 Nov 2021 22:30:28 +0000

Serverless backend may also be called Backend as a Service (Baas) and Function as a Service(Faas).

According to Wikipedia, Serverless computing is a cloud computing execution model in which the cloud provider allocates machine resources on-demand, taking care of the servers on behalf of their customers.

Pros of a Serverless architecture

Serverless is inherently scalable, it will be able to handle an unusually high number of requests.
Low cost and more efficient because you only pay when your Serverless function is running
Easy to deploy and update
No server management is required

Cons of a Serverless architecture

Serverless is not built for long-running processing, it has a time frame. For instance, AWS Lambda timeout after 15 minutes.
It is difficult to debug because you will be dependent on your providers for debugging and monitoring tools
Long-running processing could be more costly on serverless compared to a dedicated server
It may take some time for your serverless backend to handle that first function request, so, you might need to keep it in a running state.

I will be creating a Serverless backend endpoint that returns information about the client’s OS information with the following tools:

Serverless framework — a more general-purpose tool for deploying and managing serverless application
AWS Lambda — a serverless compute service that lets you run code without provisioning or managing servers, creating workload-aware cluster scaling logic, maintaining event integrations, or managing runtimes
API Gateway — a fully managed service that makes it easy for developers to create, publish, maintain, monitor, and secure APIs at any scale
Nodejs — a JavaScript runtime built on Chrome’s V8 JavaScript engine

To get started:

You must already have Nodejs installed on your local machine,
you also have an AWS account,
you also have to create an IAM user with programmatic access but for the sake of this article, I’ll be using the root user,
copy the access key id and secret access key from your AWS console

Install Serverless framework globally using npm

npm install -g serverless

Configure serverless AWS credentials

serverless config credentials --provider aws --key AKJAPB7TR3*** --secret ****F4WA1JfG1sx9+7/+kKg/a

Replace the key and secret you copied from your AWS console. You can use serverless with different providers like Azure, AWS, GCP etc.

Create a serverless project using the Serverless AWS Nodejs template

serverless create --template aws-nodejs --path clientOs

The above command will create a folder called *clientOs *and inside this folder, you’ll see the following files/folders:

.serverless folder (This folder contains generated CloudFormation file and zipped bundle, the folder gets regenerated every time you run serverless deploy
.gitignore file
handler.js file
serverless.yml file ( This file contains serverless deployment configuration)

handler.js

'use strict';
const os = require('os');

module.exports.getOsInfo = async (event) => {
  return {
    statusCode: 200,
    body: JSON.stringify(
      {
        osName: os.hostname(),
        osPlatform: os.platform(),
        osCPU: os.cpus(),
        // 1mb = 1048576
        osMemory: os.totalmem() / 1048576,
      },
      null,
      2
    ),
  };
};

I updated the handler.js to get client’s operating system information. All I did was to import os from Nodejs library and call different methods like hostname(), platform() etc.

serverless.yml

service: clientos

provider:
  name: aws
  runtime: nodejs12.x

functions:
  getOsInfo:
    handler: handler.getOsInfo

I also updated the serverless.yml with the new function we just created. I added getOsInfo function.

Test the function locally

sls invoke local -f getOsInfo

Deploy the function to AWS

sls deploy

You can login into your AWS console, search for Lambda, under functions, you’ll see your newly deployed function

Amazon API Gateway

Amazon API Gateway is a fully managed service that makes it easy for developers to create, publish, maintain, monitor, and secure APIs at any scale. APIs act as the “front door” for applications to access data, business logic, or functionality from your backend services. Using API Gateway, you can create RESTful APIs and WebSocket APIs that enable real-time two-way communication applications. API Gateway supports containerized and serverless workloads, as well as web applications.

I am going to create an API endpoint for the getOsInfo function using AmazonAPI Gateway. It’s quite easy with serverless framework, all you need to do is to add some lines of code in serverless.yml and deploy

events:
  - http:
      path: client/os
      method: get

We add events with the type http, then the route and the API method which is get.

service: clientos

provider:
  name: aws
  runtime: nodejs12.x

functions:
  getOsInfo:
    handler: handler.getOsInfo
    events:
      - http:
         path: client/os
         method: get

Your updated serverless.yml should look like this.

Deploy the function to AWS

sls deploy

Check your console, you should see something like this

endpoints:
  GET - [https://shs8k2mrea.execute-api.us-east-1.amazonaws.com/dev/](https://shs8k2ryia.execute-api.us-east-1.amazonaws.com/dev/say/hello)client/os

You can copy the URL and test it on your browser or Postman or whichever tool you prefer.

Summary

We learnt the definition of Serverless computing
We learnt the pros and cons of Serverless
We learnt how to create a serverless backend with API using serverless framework, AWS Lambda, Amazon API Gateway and Nodjes
We learnt how to test functions locally
We learnt how to deploy functions

In my next article, I'll be showing you how to deploy your serverless applications using cloudFormation templates

DEV Community: Benjamin Ajewole

Replacing Glue Lambdas with EventBridge Pipes

The Traditional Pattern

How EventBridge Pipes Simplifies the Architecture

Advantages of Using EventBridge Pipes

When to Use EventBridge Pipes Instead of Lambda

When Lambda Is Still the Better Choice

Conclusion

AWS Durable Functions vs Step Functions: Is Code-First Orchestration the New Standard?

What Are AWS Durable Functions?

Durable Function SDK: Core APIs

How Durable Functions Work: The Replay Model

Pro‑Tip: Determinism Is Critical

Cold Starts & Replay Performance

What Are AWS Step Functions?

Durable Functions vs Step Functions: Limits & Constraints

Durable Functions: Constraints

Step Functions: Tradeoffs

Testing Durable Functions (Huge Advantage)

Full Working Example: Order Workflow

Deploying with AWS CDK

Test execution

Durable configuration & Executions.

Durable Operations

Event History

When Should You Use Each?

Use Durable Functions when:

Use Step Functions when:

Final Thoughts

Getting Started with Azure for AWS Professionals: A Quick Guide

Introduction

1. Compute: From EC2 to Virtual Machines

2. Serverless Computing: From Lambda to Azure Functions

3. Containers and Orchestration: AWS Fargate for ECS, EKS to AKS, ACI

4. Storage: From S3 to Blob Storage (Including Tiers)

5. Identity and Secrets: From IAM, PCA, Secrets Manager to Azure AD, Key Vault

6. Messaging and Event Handling: From SQS, SNS, EventBridge to Service Bus, Event Grid

7. API Gateway: From AWS API Gateway to Azure API Management (APIM)

8. DNS and CDN: From Route 53 and CloudFront to Azure DNS and CDN

9. AI and Machine Learning: From SageMaker to Azure Machine Learning

10. Database Services: From RDS, DynamoDB, Aurora to Azure SQL, Cosmos DB

11. Networking: From VPC to VNet

Conclusion

Leveraging AWS API Destination to Trigger External APIs

Introduction

High-Level Architecture explanation

Important AWS Considerations

Use Cases for AWS API Destination

Best Practices for Using API Destination

AWS CDK example

Conclusion

Create Certificate Authority with AWS Private CA SDK

What are Certificates?

What is the usefulness of certificates?

Components of a Certificate

Types of Certificates

What is a certificate authority?

What is a root certificate?

What is an intermediate certificate?

Why do I need to create an intermediate certificate?

Create a root and intermediate certificate with OpenSSL

Create a root and intermediate certificate with acm-pca

AWS Private CA Templates

Leveraging Custom Resources in AWS CloudFormation

Limitations of CloudFormation

Introducing Custom Resource

Other Use Cases of Custom Resource

CloudFormation for Creating Custom Resource

CDK Code for Creating a Custom Resource

When to Use AwsCustomResource and Provider

Conclusion

Understanding Transactions in Amazon DynamoDB

DynamoDB Transactions

What are Transactions?

DynamoDB Transactions

Features of DynamoDB Transactions

Transactional APIs

TransactionCanceledException

Use Cases

Best Practices