Forem: Ayman Aly Mahmoud

Demystifying API Gateway integration types

Ayman Aly Mahmoud — Wed, 14 Jan 2026 12:25:14 +0000

API gateway integrations connect the gateway to various backend services, such as Lambda functions, HTTP/S endpoints, or other cloud services. The specific integration types and configurations depend on the chosen API gateway provider and the target backend.
In this article I will explain the integration types and when to use each one.

I will divide them by 3 use cases:

The "Builder" tools (Lambda & Mock integrations) This one focuses on how to connect to serverless functions or create a fake backend for testing.
The "Connector" Tools (HTTP & Private) Here the focus is on how to talk to other public websites or secure services hidden inside a private network (VPC).
The "Power User" Tool (AWS Service) Focus on the advanced method of connecting directly to other AWS services (like DynamoDB) without writing any code.

Let's jump into the Builder Tools.
In this integration type we basically integrate with an "AWS Lambda" function, and sometimes we just use a "Mock Integration", when integrating with a lambda function, the code will execute the logic. talks to databases, or processes data. While in Mock Integration the API will just return static, hardcoded responses without actually running any backend code.

1. Lambda Integration
This is the most popular integration. When a user hits your API endpoint (e.g., GET /users), API Gateway triggers a specific AWS Lambda function.
The Crucial Decision is to choose between Proxy or Non-Proxy, this is the single most important setting to understand here.

Feature	Proxy Integration (The Pipe)	Non-Proxy Integration (The Prep Chef)
How it works	API Gateway passes the entire raw request (headers, body, query params) directly to your Lambda function.	API Gateway transforms the request before sending it. It can filter data, rename parameters, or change JSON to XML.
Who does the work?	Your Lambda code must parse the request and format the response perfectly.	API Gateway handles the messy parsing; your Lambda just receives clean data.
Best for...	Modern, standard APIs where you want full control in your code.	Legacy systems or when you need to clean up data before your code sees it.

2. Mock Integration (The Placeholder)
This is exactly what it sounds like. You configure the API to say: "If someone calls this endpoint, just send back this specific JSON."
Why would you use this?
The Mock will return fake data, so the frontend team keeps working while the backend code is still being developed.
You want to test how your app handles a "500 Server Error" without actually breaking your server.

The "Connector" Tools (HTTP & Private)
Now, let's look at how we connect to services that already exist somewhere else (not Lambda functions you just wrote).

3. HTTP Integration (The Messenger)
Think of this as a "pass-through." You already have a web application running somewhere else (like a legacy server or a third-party API like Google Maps). You want API Gateway to sit in front of it.
The API Gateway receives the request and forwards it straight to another URL.
Use this if you are migrating an old API to AWS. You can put API Gateway in front of your old server. To the user, it looks like a modern AWS API, but behind the scenes, it's still talking to the old server until you're ready to upgrade it.

4. Private Integration (The Secure Tunnel)
This is for when your backend is hidden and not accessible via the public internet.
You may have a database or service running on an EC2 instance inside an Amazon VPC. It is secure with no public IP address.
Since it's private, API Gateway can't normally reach it.
Private Integration uses a component called VPC Link to create a secure tunnel into your private network to talk to that hidden service.

The "Power User" Tool (AWS Service)
This is the final and often most misunderstood integration type.
Most people think: "If I want to save data to a database, I need a Lambda function to do it." AWS Service Integration says: "No, you don't."

5. AWS Service Integration (The Shortcut)
This allows API Gateway to talk directly to other AWS services like DynamoDB, SQS, SNS, or Kinesis; there is no need for a Lambda function.

How it works: API Gateway acts as the "client." When a request comes in, API Gateway translates it into the specific format that the AWS service (like DynamoDB) expects and sends it.
The "Cost": You have to set up Mapping Templates (using a language called VTL). You have to explicitly tell API Gateway: "Take the 'user_id' from the URL and put it into a DynamoDB PutItem command."

Why not just use Lambda?

You don't pay for Lambda execution time.
One less hop means lower latency.

A common use case is the "Contact Us" form, imagine a high-traffic "Contact Us" form on a website.

The Old Way: API GW - Lambda - SQS Queue.
The Better Way: API GW - SQS Queue.

Summary of the five integration types:

Integration Type	Best Use Case
Lambda	Running custom business logic or calculations.
HTTP	Proxying to existing web apps or 3rd party APIs.
Mock	Testing, unblocking front-end teams, or handling errors.
Private	Accessing internal/private resources inside a VPC.
AWS Service	High-performance, direct actions without code.

You have learned about all the API Gateway integration types, are you interested in specific further details to learn about API Gateway? Let me know in the comments!

Would Lambda Managed instance reduce your cost?

Ayman Aly Mahmoud — Thu, 08 Jan 2026 12:04:46 +0000

Since AWS pioneered Lambda, the decision between EC2 and Lambda was about a simple trade-off: Flexibility & Cost (EC2) vs. Simplicity & Speed (Lambda).
If you had a high-throughput, steady-state workload, you likely had to use containers or EC2 to save money, sacrificing the features of Lambda and the serverless architectures.
That era ends now. With the launch of AWS Lambda Managed Instances, AWS has given us the missing link: the ability to run Lambda functions on specific EC2 infrastructure that we select, but they manage.

What is Lambda Managed Instances?
This is a new deployment model where your function code runs on fleet instances that are provisioned for your account.

What has changed?

EC2 Pricing Models: You can apply Compute Savings Plans and Reserved Instances to your Lambda workloads, unlocking discounts of up to 72%.
No Duration Charges: You stop paying for "GB/seconds." instead, you pay for the underlying instance capacity + a management fee (15% premium on the EC2 on-demand instance price)
Multi-Concurrency: Unlike standard Lambda, where 1 Event = 1 invocation, Managed Instances support true multi-threading. A single instance can handle multiple concurrent requests, which maximize the CPU utilization.

Let’s look at a practical scenario where this feature can improve the cost while enjoying Lambda features.
You run a Real-Time Log Ingestion Service.

The traffic is steady stream of data, 24/7.
The volume is 50 Million requests per month.
I/O heavy worload (validating JSON, writing to Kinesis/DynamoDB).
The execution time: Average is 200ms.
The required memory is 1024 MB.

Option A: Standard AWS Lambda
In the standard model, you pay for every millisecond the code runs.

Requests: 50,000,000
Duration: 200ms @ 1024MB
Compute Cost: ~$166.00 (approx. based on standard x86 pricing)
Request Cost: $10.00
Total Monthly Cost: ~$176.00 While $176 isn't huge, imagine this at enterprise scale (500M or 5B requests). The linear scaling hurts.

Option B: Lambda Managed Instances
Now, let's switch to Managed Instances. Since the workload is I/O bound, we can leverage multi-concurrency. We don't need a new container for every request; we just need enough threads.
We choose 2x c7g.large (Graviton) instances to handle the baseline load with high availability.

Instance Cost: c7g.large (approx $0.07/hr On-Demand).
- $0.07 x 2 instances x 730 hours = $102.20
Management Fee: AWS charges a ~15% fee on the On-Demand instance price for managing the fleet.
- 15% of $102.20 = $15.33
Request Cost: Standard $0.20 per million.
- 50M x $0.20 = $10.00
Total Monthly Cost (On-Demand): $127.53

Wait, it gets better.
Because these are standard EC2 instances under the hood, we can apply a Compute Savings Plan (1-year, No Upfront). Graviton instances often see ~30-40% savings here.

Discounted Instance Cost: ~$65.00
Management Fee: Remains ~$15.33.
Request Cost: $10.00
Total Monthly Cost (Savings Plan): ~$90.33

The Result

Standard Lambda: $176.00
Managed Instances (Savings Plan): $90.33
Total Savings: ~48%

When to use which?

Feature	Standard Lambda	Lambda Managed Instances
Traffic Pattern	Spiky, Unpredictable, "Scale to Zero"	Steady-state, Predictable, High-Volume
Billing	Per Millisecond (Duration)	Per Instance Hour (Capacity)
Concurrency	1 Request per Execution Environment	Multi-threaded (Many requests per instance
Best For	APIs, Cron jobs, Event triggers	Data streams, High-throughput APIs, Batch processing

Summary
AWS Lambda Managed Instances is not a replacement for standard Lambda; it is an evolution for mature workloads. If the use case is suitable, It allows us to evolve our high-volume serverless functions to a more cost-effective model without rewriting them for containers.

Have you used Lambda Managed Instances, tell us in the comments if you find it cheaper for your workload!

Stop Building Chatbots: The Case for Infrastructure-Driven AI Agents

Ayman Aly Mahmoud — Mon, 05 Jan 2026 13:08:30 +0000

Everyone is building chatbots right now. They are the “Hello World” of the GenAI era. But in the real world applications, the real value of AI is not in conversation — it’s in execution.
Real business value comes from AI agents that take actions, make decisions for you when possible, integrate with tools and systems, and of course operate within strict governance and audit boundaries.
When people build AI agents they have two options:

To include the multi-step reasoning and decision logic inside the code.
Use agentic workflow with serverless services like AWS Step Functions and AWS Lambda The first option takes time and effort and eventually becomes a liability because of the following:

No clear audit trail
Limited observability
Fragile retries
Painful debugging
Hard-to-enforce human approval

In this post, I explain the agentic workflow. Instead of orchestrating AI in code, we move orchestration into infrastructure using:

AWS Step Functions for explicit control flow
Amazon Bedrock for multimodal and text reasoning
AWS Lambda for integration and validation

The result is an enterprise-grade AI orchestration pattern that is observable, auditable, secure, and production-ready.
I prefer to explain the concepts using hands-on and realistic use cases, so let's talk about a practical use case!

Automated Insurance Claim Processing

We are building an Automated Insurance Claim Processor that:

Analyzes an uploaded image of a car accident (multimodal AI).
Estimates repair cost and damage severity.
Retrieves the customer’s policy limits.
Decides whether to:
- Auto-approve the claim, or
- Pause for human review based on confidence and risk. This is not “just prompting.” It’s a multi-step decision workflow with financial and regulatory impact.

1. The Architecture:

Workflow Breakdown

1.Trigger (Image Upload): An S3 upload event initiates the Step Functions state machine.
2.Validate Input (AWS Lambda): Checks file integrity before invoking AI models.
3.AI Vision Analysis (Amazon Bedrock): Uses Claude 3.5 or Amazon Nova to analyze the damage.

- Pro-Tip: Native Structured Output: Bedrock now supports JSON Mode via the Converse API. By providing a schema, you guarantee valid JSON output, eliminating the need for "cleaning" or "validation" Lambdas.
To implement this, you define a schema that Bedrock uses to constrain its response. Here is the specific JSON Schema you can use:

{
  "type": "object",
  "properties": {
    "damage_type": { "type": "string" },
    "estimated_cost": { "type": "number" },
    "severity_score": { "type": "integer", "minimum": 1, "maximum": 5 },
    "confidence_score": { "type": "number", "minimum": 0, "maximum": 1 }
  },
  "required": ["damage_type", "estimated_cost", "severity_score", "confidence_score"]
}

4.Fetch Policy Data (AWS Lambda & DynamoDB): Retrieves coverage limits for comparison.
5.Choice State (Risk Assessment): Orchestrator compares AI estimates against policy data to decide between Auto-Approval or Human Review.
6.Final Update (DynamoDB): Records the outcome and full audit trail.

2. Human-in-the-loop with callback tasks

This is where Step Functions truly shines.
If the AI estimates that the cost is above policy auto-approval limits, or the confidence is below a defined threshold, then the workflow must not finalize the claim automatically.
Why do we use the Callback Pattern (.waitForTaskToken):

A Choice state detects high risk.
The workflow pauses execution and waits.
An SNS notification is sent to a human adjuster.

3. Context Checkpointing (Managing Token & Payload Limits)

Long-running agent workflows suffer from:

LLM context window limits
Exploding token costs
Step Functions payload size limits (256 KB)

We solve this with context checkpointing.
In this Checkpointing pattern we use DynamoDB to store summarized agent context, and S3 to store large artifacts like images.

How it works?

After a major reasoning step, the agent state is summarized.
A History Manager Lambda will use a smaller and cheaper model to produce a concise summary.
The summary is stored in DynamoDB.
The next step retrieves only the summary.

This ensures that:

Step Functions payloads is small
DynamoDB items is under the 400 KB limit
Bedrock token usage is predictable And we can use TTLs in DynamoDB to enforce data retention policies.

Why this wins over script-based agents?

As serverless builders, we prefer explicit orchestration over hidden loops.
Visibility
Failures are visible directly in the Step Functions console. You see which state failed and why, no log archaeology required.
Retries & Resilience
AI APIs fail. Networks glitch. Throttling happens.
Step Functions provides:

Built-in retries with exponential backoff
Explicit failure paths
Idempotent replays

Governance & Compliance
Human approval is auditable, secure, and enforceable. Not a while loop buried in a container.

Conclusion
The future of AI systems isn’t just better models, it’s better orchestration.
By treating AI prompts, decisions, and approvals as explicit infrastructure steps, we move from experimental demos to enterprise-grade autonomous systems.
The question is no longer: “How smart is the model?”
But: “Can we trust, observe, govern, and replay its decisions?”
Are you orchestrating your AI agents in code — or in infrastructure? Let’s discuss in the comments.

Simplifying Serverless Workflows with EventBridge Pipes

Ayman Aly Mahmoud — Mon, 10 Feb 2025 12:02:18 +0000

Introduction
Event-driven architectures (EDAs) are essential when creating scalable, decoupled systems. By allowing services to communicate asynchronously, they reduce bottlenecks and enable flexible scaling.
AWS offers many services for building EDAs, in this post I will focus on two different combinations:

The traditional SNS/SQS combo
The newer EventBridge Pipes.

We’ll explore how to build a serverless workflow using EventBridge Pipes (integrating SQS, DynamoDB Streams, and Lambda) and compare it to SNS/SQS setups.

What are eventBridge pipes?
EventBridge Pipes is a serverless integration service that connects AWS services like (SQS, DynamoDB Streams, and Lambda) without requiring intermediate code. It supports filtering, enrichment (we use Lambda to do it), and transformations, EventBridge Pipes simplifies creating event-driven workflows.

The diagram below illustrates the workflow of AWS EventBridge Pipes, which enables seamless integration between event sources and targets with optional processing steps.

Here's a breakdown of the components and their roles:

Event Source: This is the origin of events, such as AWS services (e.g., S3, DynamoDB, Kinesis), SaaS applications, or custom applications. Events are ingested into the pipe from here.
Filter: Events are evaluated against predefined criteria (e.g., JSON-based rules). Only events that match the filter conditions proceed to the next step, reducing unnecessary processing.
Enrichment: Optional step to enhance the event data. For example, you might invoke an AWS Lambda function to fetch additional information from a database or transform the event payload before sending it to the target.
Target: The final destination where processed events are delivered. Targets can be AWS services (e.g., Lambda, SNS, SQS, EventBridge event buses), HTTP endpoints, or other resources.

How it works together:

The event source generates events (e.g., an S3 bucket upload).
The filter pick up relevant events.
The enrichment step adds/modifies data.
The target receives the refined event for further action (e.g., triggering a Lambda function to process the file).

Comparing EventBridge Pipes with SNS/SQS

Now as we know how it works let's learn by looking at a use case of E-Commerce Order Fulfillment system
In this e-commerce platform every time a customer places an order, the order details are stored in a DynamoDB table. Changes in the table (e.g., new orders) are captured by DynamoDB Streams. Instead of writing custom integration code to filter and route these events, you can use EventBridge Pipes. With Pipes, you configure the following workflow:

DynamoDB Streams as the Source: When a new order is added to the DynamoDB table, the change event is captured.
EventBridge Pipes Filtering & Routing: The Pipe ingests events from DynamoDB Streams and applies a filter to select only orders with a status of "NEW." It then routes these filtered events directly to a Lambda function.
Lambda Function for Order Processing: The Lambda function processes the order (for example, updating inventory, initiating shipping, and sending notifications).

This approach is compared to the traditional setup where events are published to an SNS topic and then pushed to an SQS queue before being processed by a Lambda function.

Let's view both architectures and explain the advantages of each one, and when to use each one of them:

EventBridge Pipes approach

Diagram Explanation

Sources:
1. DynamoDB Streams: Capture changes from a table (for example, new or updated order records).
2. SQS Queue (if needed): Acts as an additional source that may buffer events from various systems.
EventBridge Pipes: Serves as the central hub that filters, transforms, and routes incoming events from both DynamoDB Streams and SQS.
Lambda Function: Consumes the refined events to process business logic (e.g., updating order status or triggering further workflows).

Traditional SNS-SQS approach

Diagram Explanation

SNS Topic: Typically used to broadcast events to multiple subscribers.
SQS Queue: Buffers messages and provides a pull-based delivery mechanism.
Lambda Function: Processes the events retrieved from the SQS queue.

Comparing EventBridge Pipes with SNS/SQS

EventBridge Pipes

Advantages:

Integrated Filtering & Transformation as you can set up rules directly within Pipes to process events without extra Lambda functions.
Simpler Configuration because it directly connects sources like DynamoDB Streams or SQS to Lambda with minimal configuration.
Reduced operational complexity by eliminating extra intermediary services.

When to Use:

When your workflow is relatively linear or requires simple filtering.
When you prefer a code-free, declarative integration between event sources and targets.
For pipelines where transformation and routing can be managed entirely within EventBridge Pipes.

Traditional SNS/SQS

Advantages:

Fan-Out Capabilities as SNS naturally supports broadcasting a single event to multiple subscribers.
Services reliability with fine-grained delivery and retry control.
Suitable for complex scenarios that require multiple consumer endpoints.

When to Use:

When your architecture needs to fan out events to multiple consumers.
If you require detailed control over message delivery policies and retry behaviors.
When your existing setup is already built around SNS/SQS patterns and migrating to Pipes isn’t practical.

Cost Components of Each Approach

EventBridge Pipes Approach

AWS Service	Cost Component
DynamoDB Streams	First 2.5M reads free per month, then $0.02 per 100,000 reads
EventBridge Pipes	$0.40 per 1M events processed
Lambda (Order Processing)	$0.20 per 1M requests + execution time cost (depends on memory & duration)

SNS/SQS Approach

AWS Service	Cost Component
DynamoDB Streams	$0.02 per 100,000 reads
SNS	$0.50 per 1M publishes
SQS (FIFO Queue)	$0.50 per 1M requests
Lambda (Order Processing)	$0.20 per 1M requests + execution time cost

Conclusion
EventBridge Pipes offer a modern, efficient way to build decoupled, event-driven workflows on AWS. By integrating sources like DynamoDB Streams and SQS directly with Lambda, you can streamline your architecture and reduce operational overhead. However, traditional SNS/SQS setups remain a good choice for scenarios that require broad event broadcasting and detailed control over message delivery.

The right choice depends on your specific use case: go for EventBridge Pipes when you seek simplicity and reduced code, or stick with SNS/SQS for more complex, fan-out scenarios. Either way, understanding these patterns is key to building scalable and resilient serverless applications.

Python Lambda function example:

Ayman Aly Mahmoud — Tue, 22 Oct 2024 16:16:00 +0000

Python Lambda function example:

import boto3
from PIL import Image
import io

s3 = boto3.client('s3')

def lambda_handler(event, context):
    # Get bucket and object key from the event
    bucket = event['Records'][0]['s3']['bucket']['name']
    key = event['Records'][0]['s3']['object']['key']

    # Download the image from S3
    response = s3.get_object(Bucket=bucket, Key=key)
    image = Image.open(io.BytesIO(response['Body'].read()))

    # Create a thumbnail
    image.thumbnail((100, 100))

    # Save the thumbnail to a new S3 key
    thumbnail_key = f"thumbnails/{key}"
    buffer = io.BytesIO()
    image.save(buffer, 'JPEG')
    buffer.seek(0)
    s3.put_object(Bucket=bucket, Key=thumbnail_key, Body=buffer, ContentType='image/jpeg')

    return {'statusCode': 200, 'body': f'Thumbnail saved to {thumbnail_key}'}

Explanation of Important Parts:

Imports (boto3 and PIL):
- boto3 is the AWS SDK for Python, allowing interaction with AWS services (S3 in this case).
- PIL (Pillow) is a library for image processing, used here to create a thumbnail.
AWS S3 Client (s3 = boto3.client('s3')):

Creates an S3 client to interact with Amazon S3.
Handler Function (lambda_handler):

The main entry point for the Lambda function, triggered by an S3 event when an image is uploaded to a bucket.
Extracting S3 Information (bucket and key):

The event contains information about the S3 bucket and the object (image) that triggered the Lambda function.
Download the Image (s3.get_object):

Downloads the image from the S3 bucket using the get_object method.
Image Processing (image.thumbnail):

Uses the Pillow library to create a thumbnail of the image with a maximum size of 100x100 pixels.
Upload the Thumbnail (s3.put_object):

Saves the thumbnail back to the S3 bucket under a new key (thumbnails/{key}).
Return Statement:

Returns a simple JSON response indicating where the thumbnail was saved.

Lambda layers

Without layers:

Two Lambda functions (function 1 and function 2) each with their own function code and dependencies. Function 1 also includes a custom run time.

With layers:

Lambda function 1 and Lambda function 2 include only function code.
Lambda function 1 uses Lambda layer 1 for its custom runtime and Lambda layer 2 for its code dependencies.
Lambda function 2 uses Lambda layer 2 for its code dependencies.

A Lambda layer is a .zip file archive that contains supplementary code or data. Layers usually contain library dependencies, a custom runtime, or configuration files. You can also package your own custom runtime in a Lambda layer if you prefer a different runtime from those provided by the Lambda service.

There are multiple reasons why you might consider using layers:

Reduce the size of your deployment packages: Instead of including all of your function dependencies along with your function code in your deployment package, put them in a layer. This keeps deployment packages small and organized.
Separate core function logic from dependencies: With layers, you can update your function dependencies independent of your function code, and vice versa. This promotes separation of concerns and helps you focus on your function logic.
Share dependencies across multiple functions: After you create a layer, you can apply it to any number of functions in your account. Without layers, you need to include the same dependencies in each individual deployment package.
Use the Lambda console code editor: The code editor is a useful tool for testing minor function code updates quickly. However, you can’t use the editor if your deployment package size is too large. Using layers reduces your package size and can unlock usage of the code editor.

Summary of what we learned in this series

AWS Lambda is a service to run code functions without provisioning or managing servers.
A Lambda function can run inside a VPC owned by the AWS Lambda service or as Lambda@Edge in an Amazon CloudFront regional cache.
A Lambda function can be configured to connect to your VPC to access AWS services inside the VPC.
A Lambda function can be invoked synchronously, asynchronously, and with event source mappings for queues and streams.
Use Lambda layers to package code dependencies or custom runtimes to be re-used by all Lambda functions in the Region.

Invoking a synchronous Lambda function

Ayman Aly Mahmoud — Sat, 19 Oct 2024 13:15:00 +0000

Invoking a synchronous Lambda function

When you invoke a function synchronously, the Lambda service runs the function and waits for a response. In this example, an API request is received from a browser client to Amazon API Gateway. API Gateway invokes the Lambda function by calling the AWS Lambda service. While the function runs, it can optionally call other AWS services. When the function completes, the Lambda service returns the response from the function's code with additional data, such as the version of the function that was invoked. If the function encounters an error, the error is returned as the response. The Lambda service returns the response to API Gateway which in turn sends the response to the browser client.

Another option for a synchronous call to Lambda is to use a function URL. A function URL is a dedicated HTTP(S) endpoint for your Lambda function. In the example above, the URL request is sent directly to the Lambda service from a browser client. The Lambda service invokes the Lambda function which returns a URL response. The response is returned to the browser client.

When you create a function URL, Lambda automatically generates a unique URL endpoint for you. After you create a function URL, its URL endpoint never changes. Lambda function URLs use resource-based policies for security and access control. Function URLs also support cross-origin resource sharing (CORS) configuration options. CORS defines a way for client web applications that are loaded in one domain to interact with resources in a different domain.

While function URLs are simple and easy to set up, the browser application will require an update if the URL changes. When a function changes behind Amazon API Gateway, no changes are required to the browser application.

Invoking an asynchronous Lambda function

When you invoke a function asynchronously, you don't wait for a response from the function code. You hand off the event to Lambda, and Lambda handles the rest. The Lambda service places the event in a queue and returns a success response without additional information. A separate process reads events from the queue and sends them to the function. You can configure how Lambda handles errors and can send invocation records to a downstream resource such as Amazon Simple Queue Service (Amazon SQS) or Amazon EventBridge to chain together components of your application.

Several AWS services, such as Amazon Simple Storage Service (Amazon S3) and Amazon Simple Notification Service (Amazon SNS), invoke functions asynchronously to process events. If scheduled events are required, you can use EventBridge as a scheduler to invoke Lambda functions. If an AWS service doesn’t have a direct integration with the Lambda service, EventBridge can serve as the event bus to route the request. An example of a scheduled event is daily reporting or any recurring process that should be activated.

Lambda event source mappings for queues and streams

An event source mapping is a Lambda resource that reads from an event source and invokes a Lambda function. You can use event source mappings to process items from a stream or queue in services that don't invoke Lambda functions directly. The Lambda service can poll AWS services like Amazon DynamoDB, Amazon Kinesis, Amazon SQS, and Amazon DocumentDB (with MongoDB compatibility).

In the above diagram, the target event source is a DynamoDB stream. When the Lambda service polls the DynamoDB stream for events, a number of events are returned to the Lambda service. The Lambda service batches records together in a single payload and invokes the Lambda function with the payload. You can configure the Lambda function to specify the maximum size of the batch window and the payload. The payload can’t exceed the Lambda function input limit of 6 MB.

An example scenario would be if a customer order changed status to delivery in progress in the DynamoDB orders table, then the Lambda function is invoked to send a notification to the customer and do some financial processing.

In the next article in this series we will have an example of a lambda functions, and will learns about lambda layers.

Building serverless architectures with AWS Lambda

Ayman Aly Mahmoud — Wed, 16 Oct 2024 12:10:24 +0000

AWS Lambda

AWS Lambda is a compute service that lets you run code without provisioning or managing servers. Lambda runs your code on a high-availability compute infrastructure and performs all of the administration of the compute resources, including server and operating system maintenance, capacity provisioning, automatic scaling, and logging.

You configure your Lambda function with the runtime language you prefer, the amount of memory that the function needs, and the maximum length of function timeout. The amount of memory determines the amount of virtual CPU and network bandwidth. Currently, the minimum and maximum amount of memory that can be allocated is 128MB and 10,240MB respectively. A Lambda function can’t exceed 15 minutes in duration, so 15 minutes is the maximum timeout setting. This is an AWS hard limit and can’t be changed.

You create code for the function and upload the code using a deployment package. Lambda supports two types of deployment packages: container images and .zip file archives. The Lambda service invokes the function when an event occurs. Lambda runs multiple instances of your function in parallel, governed by concurrency and scaling limits. You only pay for the compute time that you consume—there is no charge when your code isn’t running.

A Lambda function can run inside a VPC owned by the AWS Lambda service or in an Amazon CloudFront regional cache.

When you create a Lambda function, you deploy it to the AWS Region where you want your Lambda function to run. When a Lambda function is invoked, the Lambda service instantiates an isolated Firecracker virtual machine (VM) on an Amazon Elastic Compute Cloud (Amazon EC2) instance in the Lambda service VPC.

Lambda@Edge is an extension of AWS Lambda, a compute service that lets you run functions that customize the content that CloudFront delivers. You can author Node.js or Python functions in one Region, US East (N. Virginia), and then run them in AWS regional edge locations globally that are closer to the viewer. Processing requests at AWS locations closer to the viewer instead of on origin servers significantly reduces latency and improves the user experience.

An example of a Lambda@Edge use case is a retail website that sells bags. If you use cookies to indicate which color a user chose for a small bag, a Lambda function can change the request so that CloudFront returns the image of a bag in the selected color.

Lambda@edge

It is a serverless computing service that allows you to run AWS Lambda functions at AWS Edge locations. It integrates with Amazon CloudFront to run application code closer to your customers, to improve performance and reduce latency.

Key Features

Executing code closer to your customer reduces latency and improves performance.
You scale your application and be move available for customer around the globe.
You can modify request and response behavior for web applications in real-time, which make you able to customize content delivery
You can runs in a secure and isolated environment, supporting custom authentication and authorization, which is considered a secure execution for your code.

Use Cases

Dynamic Content Personalization: you can tailor content based on user attributes (like: language, location).
A/B Testing: serve different versions of content to different user groups for testing.
Access Control: you are able to implement custom authentication for web content.
SEO Optimization: you can modify URLs and headers for search engine optimization.

How It Works

Trigger Points: Runs in response to events generated by CloudFront, such as viewer request, viewer response, origin request, and origin response.
Deployment: Deploy code to AWS regions, and Lambda@Edge replicates it to edge locations globally.

Connecting a Lambda function to your VPC

Sometimes you might have a requirement to implement an architecture that has serverless components and components running in your own VPC. When designing this type of architecture, pay close attention to scaling as some components can cause a bottleneck.

By default, a Lambda function isn't connected to VPCs in your account. If your Lambda function needs to access the resources in your account VPC, you can configure the function to connect to your VPC. The Lambda service provides managed resources named Hyperplane elastic network interfaces (ENIs) which are created when the function is configured to connect to a VPC. When invoked, the Lambda function in the Lambda VPC connects to an ENI in your account VPC. Hyperplane ENIs provide NAT capabilities from the Lambda VPC to your account VPC using VPC-to-VPC NAT (V2N). V2N provides connectivity from the Lambda VPC to your account VPC, but it doesn’t in the other direction.

When you connect a function to a VPC in your account, the function can't access the internet unless your VPC provides access. To give your function access to the internet, route outbound traffic to a NAT gateway in a public subnet. The NAT gateway has a public IP address and can connect to the internet through the VPC's internet gateway.

In the example above, the database and the Amazon EC2 application instance can cause bottlenecks if the Lambda functions aggressively scale. Lambda functions 1 and 2 connect to an EC2 application instance and an Amazon Relational Database Service (Amazon RDS) proxy deployed in a private subnet in the customer’s VPC using the VPC-to-VPC NAT and the ENI. To scale the EC2 instance, deploy it behind an application load balancer in an Amazon EC2 Auto Scaling group.

To scale the database, you can use Amazon RDS proxy that manages a connection pool to the Amazon RDS database. Because Lambda functions can scale rapidly, the connections to an Amazon RDS database can be saturated. Lambda functions that rapidly open and close database connections can cause the database to fall behind. When no more connections are available the function will produce an error. When using MySQL and Aurora Amazon RDS databases, you can solve this challenge with RDS proxy. The Lambda functions connect to RDS proxy, which will have an open connection to the database ready to be used.

Here is a summary of what we discussed:

AWS Lambda is a serverless compute service that runs code without server management. It automatically scales, and you only pay for the compute time used. Functions can run in a VPC and are triggered by events.
Lambda@Edge extends Lambda to AWS edge locations for reduced latency, useful for content personalization and improving performance.
To access resources in your VPC, Lambda uses Hyperplane ENIs. For scaling, RDS Proxy helps manage database connections, preventing bottlenecks during rapid function scaling.

In the next article we will talk about "Identifying Lambda serverless scenarios" and "How to invoke lambda functions"

Image Labeling with Amazon Rekognition

Ayman Aly Mahmoud — Wed, 21 Feb 2024 11:46:34 +0000

Amazon Rekognition facilitates object and scene detection in images, offering a secure, stateless API that returns a list of related labels along with confidence levels.

In this tutorial, you'll build a serverless system to perform object detection upon image uploads to an Amazon S3 bucket. AWS Lambda will handle the processing logic, while Amazon DynamoDB will serve as the storage solution for the label detection results.

Object Detection Context and Limitations

Object and Scene Detection involves identifying objects and their context within an image. Object Detection locates specific instances of objects like humans, cars, buildings, etc. In Amazon Rekognition, Object Detection is akin to Image Labeling, extracting semantic labels from images. This approach also lends itself to scene detection, identifying both individual objects and overall scene attributes, such as "person" or "beach".

In AWS, Object Detection with Amazon Rekognition involves utilizing its DetectLabels API. You can input the image as either a binary string or an S3 Object reference. Submitting images as S3 Objects offers advantages such as avoiding redundant uploads and supporting images up to 15MB in size, compared to the 5MB limit.

The response typically follows a JSON structure similar to the following:

{
    "Labels": [
        {
            "Confidence": 97,
            "Name": "Person"
        },
        {
            "Confidence": 96,
            "Name": "Animal"
        },
        ...
    ]
}

The API provides an ordered list of labels, ranked by confidence level, starting from the highest.

The quantity of labels returned is determined by two parameters:

MaxLabels: This sets the maximum number of labels returned by the API.
MinConfidence: Labels with a confidence score below this threshold will not be included in the response.

It's crucial to note that setting low values for MaxLabels alongside high values for MinConfidence could result in empty responses.

Throughout the tutorial, we'll use an S3 bucket to store images, leveraging the API to extract labels from each newly uploaded image. We'll store each image-label pair in a DynamoDB table.

Let's start

1) create DynamoDB table named "images"

2) Create S3 bucket
Choose a unique name for the bucket, I will use the name "demo21-2"
Make sure to select ACLs Enabled:
Create a folder in the bucket and name it "images"

3) Create a Lambda function as follows:
Choose "Use a blueprint" when creating the function.
For the blueprint name, choose "Use Rekognition to detect faces"

You will need to give the lambda function permissions to access the following services:

"CloudWatch" to put logs
"DynamoDB" to put, update, describe item
"Rekognition" to detect labels and faces

So you will create a role with the following IAM policies, and assume the role by the lambda function.

Basic execution role

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "logs:CreateLogGroup",
                "logs:CreateLogStream",
                "logs:PutLogEvents"
            ],
            "Resource": "*"
        }
    ]
}

Lambda policy

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Action": [
                "dynamodb:PutItem",
                "dynamodb:UpdateItem",
                "dynamodb:DescribeStream",
                "dynamodb:GetRecords",
                "dynamodb:GetShardIterator",
                "dynamodb:ListStreams"
            ],
            "Resource": "arn:aws:dynamodb:us-west-2:909737842772:table/images",
            "Effect": "Allow"
        },
        {
            "Action": [
                "rekognition:DetectLabels",
                "rekognition:DetectFaces"
            ],
            "Resource": "*",
            "Effect": "Allow"
        },
        {
            "Action": [
                "s3:*"
            ],
            "Resource": "*",
            "Effect": "Allow"
        }
    ]
}

For the S3 trigger section enter the following:

You are now ready to test the function to see if it's successfully been triggered and called AWS Rekognition
Upload a picture to the folder "images" in your bucket
Go check the CloudWatch log group for your functions, you should see a log similar to this one below:

Implementing the Object Detection Logic
In the Code source section, double-click the lambda_function.py file, and replace the code with the following:

import boto3, urllib.parse

rekognition = boto3.client('rekognition', 'us-west-2')
table = boto3.resource('dynamodb').Table('images')

def detect_labels(bucket, key):
    response = rekognition.detect_labels(
        Image={"S3Object": {"Bucket": bucket, "Name": key}},
        MaxLabels=10,
        MinConfidence=80,
    )

    labels = [label_prediction['Name'] for label_prediction in response['Labels']]

    table.put_item(Item={
        'PK': key,
        'Labels': labels,
    })

    return response


def lambda_handler(event, context):
    data = event['Records'][0]['s3']
    bucket = data['bucket']['name']
    key = urllib.parse.unquote_plus(data['object']['key'])
    try:
        response = detect_labels(bucket, key)
        print(response)
        return response
    except Exception as e:
        print(e)
        raise e

The code outlined above facilitates the following functionalities:

Each image uploaded triggers the creation of a new DynamoDB item, with the S3 Object Key serving as the primary key.
The item includes a list of corresponding labels retrieved from Amazon Rekognition, stored as a set of strings in DynamoDB.
Storing labels in DynamoDB enables repeated retrieval without additional queries to Amazon Rekognition.
Labels can be retrieved either by their primary key or by scanning the DynamoDB table and filtering for specific labels using a CONTAINS DynamoDB filter.

You can now test the function by uploading one or more images to the "images" folder in your bucket

Go to the DynamoDB table and click on Explore items from the left pane, you will find the items returned with the labels that are recognized by AWS Rekognitions

Conclusion
In this tutorial, you set up an Amazon S3 bucket and configured an AWS Lambda function to trigger when images are uploaded to the bucket. You implemented the Lambda function to call the Amazon Rekognition API, label the images, and store the results in Amazon DynamoDB. Finally, you demonstrated how to search DynamoDB for image labels.

This serverless setup offers flexibility, allowing for customization of the Lambda function to address more complex scenarios with minimal effort.

Configuring Lambda functions properly

Ayman Aly Mahmoud — Tue, 06 Feb 2024 12:17:22 +0000

When developing and evaluating a function, it's essential to define three key configuration parameters: memory allocation, timeout duration, and concurrency level. These settings play a crucial role in measuring the performance of the function. Determining the optimal configuration for memory, timeout, and concurrency involves testing in real-world scenarios and under peak loads. Continuously monitoring your functions allows for adjustments to be made to optimize costs and maintain the desired customer experience within your application.

First, let's talk about how important it is to configure your memory and timeout values. Following that, we'll discuss the billing considerations associated with these values then exploring concurrency and strategies for optimizing it.

Memory:

Lambda functions allow for allocating up to 10 GB of memory. Lambda allocates CPU and other resources in direct proportion to the amount of memory configured. Scaling up the memory size results in a corresponding increase in available CPU resources for your function. To determine the optimal memory configuration for your functions, consider utilizing the AWS Lambda Power Tuning tool.

AWS Lambda Power Tuning, is a state machine powered by AWS Step Functions, optimizes Lambda functions for cost and performance. It's language agnostic and suggests the best power configuration for your function, based on multiple invocations across various memory settings (128MB to 10GB), aiming to minimize costs or maximize performance.

Since Lambda charges are directly proportional to the configured memory and function duration (measured in GB-seconds), the additional costs incurred by using more memory might be balanced out by reduced duration.

Timeout:

The AWS Lambda timeout value specifies the duration a function can run before Lambda terminates it. Currently capped at 900 seconds, this limit means a Lambda function invocation cannot exceed 15 minutes.

Set the timeout to the maximum only after thorough function testing. Many scenarios require quick failure rather than waiting for the full timeout.

Analyzing function duration aids in identifying issues causing invocations to surpass expected lengths. Load testing helps determine the optimal timeout value.

Billing for Lambda functions is based on runtime in 1-ms increments. Avoid lengthy timeouts to prevent billing for idle time during timeouts.

Lambda Billing:

AWS Lambda charges are based on usage, including the number of requests and duration. Each time your code runs in response to an event or an invoke call counts as a request. Duration is rounded up to the nearest 1 ms, and pricing depends on memory allocation, not actual usage, if you allocate 4 GB but only use 1 GB, you'll be charged for the full 4 GB. That is another reason why testing with various memory allocations is crucial to optimize both function performance and budget.

Increasing memory allocates proportional CPU power and resources. The AWS Lambda Free Tier includes 1 million free requests per month and 400,000 GB-seconds of compute time monthly. Access AWS pricing details and calculators for more information.
For more visibility about the cost please refer to https://calculator.aws/

Concurrency and Scaling:

Concurrency is a crucial configuration that affects your function's performance and scalability. It refers to the number of invocations your function can handle simultaneously. When invoked, Lambda launches an instance to process the event, and upon completion, it can handle additional requests. If new invocations occur while previous ones are still processing, Lambda allocates additional instances, leading to concurrent invocations.

Concurrent Invocations:

Consider a bus's capacity is 50 passengers. Only 50 passengers can occupy seats at any given time. Passengers who arrive when the bus is full must wait until a seat becomes available. With a reservation system, if a group reserves 10 seats, only 40 of the 50 seats remain available for other passengers. Similarly, Lambda functions have a concurrency limit comparable to the bus's capacity, and a reservation system can allocate runtime for specific instances.

Concurrency types

Unreserved concurrency
The amount of concurrency that is not reserved for specific functions. A minimum of 100 unreserved concurrency is guaranteed, ensuring functions without provisioned concurrency can still execute. If all concurrency is provisioned for one or two functions, none remains for others. Maintaining at least 100 available concurrency ensures all functions can run upon invocation.

Reservred concurrency
Reserved concurrency guarantees the maximum number of concurrent instances for a function. Once reserved, this concurrency is exclusively allocated to that function, preventing other functions from utilizing it. There is no charge for configuring reserved concurrency for a function.

Provisioned concurrency
Provisioned concurrency initializes a specified number of runtime environments, ensuring they are ready to promptly respond to your function's invocations. This option is ideal for achieving high performance and low latency.
You're charged for the provisioned concurrency amount and the duration it's configured. For instance, you may elevate provisioned concurrency in anticipation of a traffic surge. To avoid paying for unused warm environments, you can scale back down once the event subsides.

Testing Concurrency:

Ensuring your concurrency, memory, and timeout settings are optimal requires thorough testing against real-world scenarios. Here are some recommendations:

Conduct performance tests mimicking peak invocation levels, monitor metrics to view throttling occurrences during performance peaks.
Assess whether your backend can handle the incoming request velocity.
Test comprehensively; if interfacing with Amazon RDS, verify that your function's concurrency levels align with the database's processing capabilities.
Validate error handling functionality; include tests to push the application beyond concurrency limits to confirm proper error management.

In conclusion, we talked about optimizing AWS Lambda functions for performance, cost-efficiency, and scalability. We've explored key configuration settings such as memory allocation, timeout values, concurrency, and provisioned concurrency.
Additionally, we've discussed strategies for testing concurrency and ensuring that our functions perform effectively under real-world conditions. By implementing these best practices, we aim to enhance the reliability and efficiency of our serverless applications on AWS.

AWS Lambda Function Permissions

Ayman Aly Mahmoud — Tue, 26 Dec 2023 09:19:52 +0000

In this article we will explore the permissions and connection capabilities that allow AWS Lambda and other AWS services to connect to each other.

Lambda functions involve two aspects that determine the required permissions:
Execution Permission: Authorization for the Lambda function to interact with other services.
Invoking Permission: Granting permission to invoke the function, it is controlled using an IAM resource-based policy.

Let's break it down

Execution role

The execution role gives your function permissions to interact with other services. You provide this role when you create a function, and Lambda assumes the role when your function is invoked.

Execution role definitions
Let's assume you have an S3 bucket that your Lambda function needs to read from and write to. Your execution role would look like this:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:PutObject"
      ],
      "Resource": "arn:aws:s3:::your-bucket-name/*"
    },
    {
      "Effect": "Allow",
      "Action": [
        "logs:CreateLogGroup",
        "logs:CreateLogStream",
        "logs:PutLogEvents"
      ],
      "Resource": "arn:aws:logs:*:*:*"
    }
  ]
}

The trust policy defines who (or what) can assume the role. In the case of AWS Lambda, the principal is the Lambda service, and it's given permission to assume the role using the AWS STS AssumeRole action. Here's an example trust policy:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "lambda.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

This policy explicitly states that the AWS Lambda service (identified by the service principal "lambda.amazonaws.com") is allowed to assume the role by calling the sts:AssumeRole action.
When you create an IAM role for your Lambda function, you would attach this trust policy to the role. It ensures that the Lambda service has the necessary permissions to assume the role and execute the Lambda function on behalf of your AWS account.

Here is a screenshot showing where to configure both the function "Execution Role" (or Permission), and the "Trust policy"

Resource-based policy
A resource policy (also called a function policy) tells the Lambda service which principals have permission to invoke the Lambda function. An AWS principal may be a user, role, another AWS service, or another AWS account.

Here is an example of a Resource-based policy

{
    "Version": "2012-10-17",
    "Id": "default",
    "Statement": [
        {
            "Sid": "lambda-allow-s3-my-function",
            "Effect": "Allow",
            "Principal": {
              "Service": "s3.amazonaws.com"
            },
            "Action": "lambda:InvokeFunction",
            "Resource":  "arn:aws:lambda:us-east-2:123456789012:function:my-function",
            "Condition": {
              "StringEquals": {
                "AWS:SourceAccount": "123456789012"
              },
              "ArnLike": {
                "AWS:SourceArn": "arn:aws:s3:::my-bucket"
              }
            }
        }
     ]
}

Read more about Resource-based policy from AWS documentation

What if I need a function to connect to AWS resource in a VPC like EC2 or RDS instance?
And is it possible to call the function from an EC2 instance in a private subnet?

Accessing resources in a VPC
Enabling your Lambda function to access resources inside your VPC requires additional VPC-specific configuration information, such as VPC subnet IDs and security group IDs. This functionality allows Lambda to access resources in the VPC. It does not change how the function is secured. You also need an execution role with permissions to create, describe, and delete elastic network interfaces. Lambda provides a permissions policy for this purpose named "AWSLambdaVPCAccessExecutionRole".

learn more about attaching your Lambda functions to a VPC, in the AWS Lambda Developer Guide.

Lambda and AWS PrivateLink
AWS Lambda supports AWS PrivateLink, enabling you to securely create, manage, and invoke Lambda functions within your VPC or on-premises data centers without exposing traffic to the public Internet.
For a private link between your VPC and Lambda, set up an interface VPC endpoint. This utilizes AWS PrivateLink, allowing private access to Lambda APIs without the need for an internet gateway, NAT device, VPN, or AWS Direct Connect. No public IP addresses are required for instances in your VPC to communicate with Lambda APIs, ensuring that traffic between your VPC and Lambda stays within the AWS network.

learn more about AWS PrivateLink and AWS Lambda, in the AWS Lambda Developer Guide.

Conclusion
In this article we covered the permissions to control who can do what in regard to AWS Lambda and other AWS services.
And then we talked about the ability to of AWS Lambda to connect to AWS services in a VPC, and a resource in private VPC that needs to call Lambda functions privately.

Unleashing the Power of Serverless: A Journey into Event-Driven Architectures with AWS

Ayman Aly Mahmoud — Mon, 18 Dec 2023 13:19:14 +0000

Welcome, everyone! are you ready to improve your approach for application development?
In this series I will cover how to use serverless and event driven architecture in your applications.
I will explain the concept and how to use AWS services in this architecture, and I will add hand-on guides if you are like me love to learn by doing.

Let’s start by some concepts first:
Serverless advantages
Cloud computing main advantage is removing the need to manage data center components by yourself and leaving this to the cloud provider.
In a serverless environment you don't even manage servers, of course there are servers that run your applications, but you don't need to manage and maintain those servers, and AWS will take care of it, allowing you to focus on your code which reflects on your client's experience.

AWS Lambda
AWS Lambda is a serverless compute service that lets you run your code without the need to manage servers. It runs on a highly available infrastructure, and it handles scaling, code monitoring, and logging.

To cut short we can say that lambda has the following Benefits

Serverless operation
Event-triggered functions
Automatic scaling
Integrated monitoring and logging

If you are new to AWS Lambda, and you need to learn by doing, then please read my previous post on how to use AWS Lambda

Event-driven architectures
Event-driven is an architecture where your application is decoupled to many services and these services communicate events to each other and services can make use of events and run code in the context of the event.
but what is an event?
An event reflects some change, user request, or update, like adding an item to a shopping cart on an e-commerce site. Once an event happens, the data is sent to be used by other services. In this architecture, the main way to exchange information between different services is by sending those events.

Producers, pathways, consumers
There are many AWS services that produce events, which we can call an event sources for AWS Lambda. In response to events, Lambda executes the code, which is crafted to handle those events, and when executed, Lambda functions can trigger additional actions or subsequent events.

The following diagram illustrates how services work together in a serverless architecture

Notice: An event is a state change in what you're monitoring, such as an updated shopping cart or a new file uploaded to Amazon S3.

After covering the fundamentals of serverless architecture and AWS Lambda, let's dive into the details of how AWS Lambda operates through event sources and triggers.

How AWS Lambda Works?
To understand event driven architectures and services like AWS Lambda, you need to understand the events themselves. This section dives into how events trigger Lambda functions.

Invocation models for running Lambda functions
Event sources can trigger lambda functions with three different invocation models, and each model suits specific requirement.
We have 3 invocation models:

Synchronous invocation
Asynchronous invocation
Polling invocation

Now let’s learn about each invocation model

Synchronous invocation
In this model you wait for the function to process the event and return a response. when the function completes, Lambda returns the response from the function's code with additional data.

The following diagram illustrates clients invoking a Lambda function synchronously. Events go directly to the function, and the function response returns directly to the invoker.

The following AWS services invoke Lambda synchronously:

Amazon API Gateway
Amazon Cognito
AWS CloudFormation
Amazon Alexa
Amazon Lex
Amazon CloudFront

More information about Synchronous invocation in the AWS Lambda Developer Guide.

Asynchronous invocation
Several AWS services, such as S3 and Amazon SNS, invoke functions asynchronously to process events. When you invoke a function asynchronously, you don't wait for a response from the function code. You hand off the event to Lambda and Lambda handles the rest. You can configure how Lambda handles errors, and can send invocation records to a downstream resource such as Amazon SQS or EventBridge to chain together components of your application. More about destinations is coming below.

The following diagram illustrates clients invoking a Lambda function asynchronously. Events are queued before being sent to the function.

Destinations
Destinations sends records of asynchronous invocations to other services. You can setup separate destinations for events that fail processing and events that succeed.
Destinations provide a way to handle errors and successes without requiring additional code.
More information about Configuring destinations for asynchronous invocation in the AWS Lambda Developer Guide.

The following diagram shows a function handling asynchronous invocation. If the function responds successfully or exits without errors, Lambda sends an invocation record to an EventBridge event bus. In case of repeated processing failures, Lambda forwards an invocation record to an Amazon Simple Queue Service (Amazon SQS) queue.

Asynchronous AWS service integration
The following AWS services invoke Lambda asynchronously:

Amazon SNS
Amazon S3
Amazon EventBridge

More information about Asynchronous invocation in the AWS Lambda Developer Guide.

And one last type of invocations:
Polling invocation
This invocation model is designed to allow you to integrate with AWS Stream and Queue based services with no code or server management. Lambda will poll the following services on your behalf, retrieve records, and invoke your functions.
The following are supported services:

Amazon Kinesis
Amazon SQS
Amazon DynamoDB Streams

With this type of integration, AWS will manage the poller on your behalf and perform Synchronous invokes of your function with this type of integration. The retry behavior for this model is based on data expiration in the data source. For example, Kinesis Data streams store records for 24 hours by default (up to 168 hours).

Event source mapping
The configuration of services as event triggers is known as event source mapping. This occurs when you configure event sources to launch your Lambda functions and then grant these sources IAM permissions to access the Lambda function.

Lambda reads events from the following services:

Amazon DynamoDB
Amazon Kinesis
Amazon MQ
Amazon Managed Streaming for Apache Kafka (MSK)
self-managed Apache Kafka
Amazon SQS
Amazon DocumentDB

More information about Lambda event source mappings in the AWS Lambda Developer Guide.

In conclusion, we've explored the principles of serverless architecture and dived into the how to use lambda in such architecture, we explored its functionality through event sources and triggers.
By understanding the different invocation models, such as synchronous and asynchronous approaches, and the seamless integration with AWS streaming and queuing services using polling, you're ready to get in and start using serverless computing.
AWS Lambda's ability to abstract infrastructure layer, and with its diverse invocation options, it helps developers to focus on crafting code that drives unique and innovative business solutions.
Stay tuned to the upcoming articles in this series for more fun with serverless!

Introduction to AWS Fargate

Ayman Aly Mahmoud — Thu, 16 Mar 2023 08:58:16 +0000

What is AWS Fargate?

As described by AWS, AWS Fargate is a technology that you can use with Amazon ECS to run containers without having to manage 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.

That means you focus more on developing your applications, and your business value, and spare the time to manage and maintain the underlying infrastructure.

Components

Cluster
With AWS ECS we use cluster to group tasks or services together, and to isolate applications.

Task definitions
A task definition is a text file that describes a container ot containers that form your application. it is a JSON file and for task definition it can be use to describe up to ten containers.
The file contains information like which port to open for the application.

Task
A Task is created when you run a Task directly, which launches container(s) defined in the task definition.

Service
A Service is responsible for creating Tasks. it guarantee that you always have some number of tasks running all the time, if a Task's container fails due to an error or something, or the EC2 instance fails, ECS service will replace it by launching another instance based on your task definition

What do we mean by managing apps and services at the container level?
To better understands this, Here is a simple architecture of Fargate in AWS ECS stack.

As illustrated above, with ECS and Fargate it starts with a "Task Definition", you as a customer use the task definition to define the container, CPU, memory, image, along with other details that tells the container how it should run.
Then a "Task" represents one or more containers that make up the application.
To run the task, you simply use the start task API and choose the launch type, either in EC2 instance you manage, or using managed environment by Fargate.

You can use AWS Fargate from AWS Console, AWS CLI, and Amazon ECS CLI.

Networking with Fargate
AWS Fargate runs in your VPC, you select the VPC, subnets, and Security groups the you need to attach to the instances that runs your containerized applications

Fargate supports Application Load Balancers "ALB", and Network Load Balancers "NLP".

Security with Fargate
No SSH access, as you offload the management of the infrastructure to AWS, there is no need to have SSH access, so it is secure.
And you have cluster-level isolation of your containers.

Fargate use cases

Long running services
Highly available workloads
Monolithic applications
Microservices applications

When should not you use Fargate?
You should go for EC2 mode if you have reserved instances running your applications.
As Fargate charges you on seconds of CPU and memory consumed, there is no way to translate that to reserved instances saving plan.

Notice: Before 2019 Spot instance plan was not supported, then at AWS re:Invent 2019 AWS announced AWS Fargate Spot. Fargate Spot is a new capability on AWS Fargate that can run interruption tolerant Amazon ECS Tasks at up to a 70% discount off the Fargate price.

Container services on AWS
If you are new to containers and want to make use of Fargate it is recommended to understand more about container services on AWS, and there is no better way than reading about them on AWS documentations. So here are what you need to read.

Amazon ECS
Amazon EKS
Amazon ECR

Tutorial "How to use AWS Fargate"
Now you understand the basics and want to explore some hands on experience, I will walk you through this tutorial on how to deploy a sample container using AWS Fargate. Let's jump in.

1- Sign in to the console and search for AWS ECS, then click in "Get Started"
The first component to create is the cluster that will contain a group of tasks together.
2- Click on "Create Cluster"
Enter the cluster name and choose the VPC and subnets your want to create the cluster in.

In the infrastructure section, you will find AWS Fargate is selected for you.

Click "Create"

3- Click on the cluster name to open its page, and then from the service tap, click create, to create a new service.

4- Select the "Launch Type" Fargate.

5- Scroll down to "Deployment configuration" section, and click on "Task definitions"

This will open another browser tap to create the "Task definitions"

6- Click on "Create new task definition"
Enter "Task definition family" name.
In the container details section enter the container name, and the Image URI.
If you don't have an image in AWS ECR, please get one first.

7- Review the "Port mappings", then click "Next"

8- In the "Environment" section make sure AWS Fargate is selected and choose the CPU and Memory that works for you.

9- Accept all the default settings and scroll down, then click "Next"

10- In the "Review and create" page, review every thing and click Create

11- Now back to the "Create service" page, you will need to refresh the page to load the task definition you just created and select it, then enter a "Service name".

12- Review the Networking and Load Balance sections if needed, and finally click "Create"

13- Click on the Service to open its page, and review the health

14- Click on "Configuration and task"

15- Scroll down, and check that the task is running, then click on it is name

16- Click on open address, to confirm that your service is running.

You will need to add a rule to the security group to allow traffic to port 80, in order to be able to connect like in step 16

That will be all.
Make sure you delete the container and clean all the resources to avoid unexpected costs in your bill.

I hope this has been beneficial to you, and I would like to thank you for reading.

Follow me for more articles and tutorials in serverless.