DEV Community: Jaya Ganesh

The Hidden Cost of AWS Lambda SnapStart for Python, and How I Fixed It with Durable Functions

Jaya Ganesh — Mon, 20 Apr 2026 13:32:50 +0000

Recently, I opened our AWS bill and found that thousands of dollars had been charged toward AWS Lambda. I was sure we did not have that much traffic. So I started digging through the bill, and that is when I found the real reason. It was Lambda SnapStart.

Lambda SnapStart is a great feature. For latency-sensitive applications, especially APIs, it can reduce cold start duration from seconds to sub-seconds by creating a snapshot of the initialized function and caching it. When invoked, Lambda restores the execution environment from that snapshot and resumes from that point to serve traffic. But there was one key detail we had missed. Every time we publish a Lambda version with SnapStart enabled, a new snapshot is created and cached. We pay for both cache and restore. AWS documents that caching is billed for as long as the version remains active, with a minimum of 3 hours, and the pricing page example for US East, N. Virginia shows cache at $0.0000015046 per GB-second and restore at $0.0001397998 per GB restored.

In our case, SnapStart itself was not the problem. Unused versions were.

We had enabled SnapStart for many Python APIs. Over time, repeated deployments created more and more published versions with SnapStart enabled. The older versions were not referenced anywhere and were not receiving traffic, but they were still sitting there and continuing to accumulate snapshot cache charges. AWS documents a 14-day inactive cleanup behavior for Java SnapStart versions, but that is not something we could rely on for our Python functions. That was the real bill shock.

So I built a cleanup workflow for it. Not a blind cleanup script. A controlled workflow with human approval. And this is where AWS Lambda Durable Functions turned out to be a perfect fit.

Why I used a Durable Function

At first, this looked like a simple cleanup script. List the old versions, check if they are unused, and delete them.

But I did not want a script that blindly deletes Lambda versions. Even if a version looks old, it could still be referenced by an alias or still be important for rollback. So I wanted this to be a workflow, not just a script.

That is why I used AWS Lambda Durable Functions.

With a durable orchestrator, I could break the process into clear steps: scan the SnapStart-enabled versions, filter the old and unused ones, generate a report, wait for approval, and only then delete them. The best part is that the approval step is part of the workflow itself. The function can pause, wait for a human decision, and then continue from the same point.

At a high level, the workflow looks like this:

How the workflow works

The workflow starts by listing all published Lambda versions with SnapStart enabled. Then it filters out versions that are newer than 14 days and also keeps the latest few versions as a safety measure. After that, it checks whether those versions are still being used by looking at invocation metrics and alias references. A version is considered a candidate only if it is old enough, not among the latest kept versions, not protected by an alias, and not showing recent usage.

If a version is old, not protected, and not used, it is added to the candidate list.

Once the list is ready, the workflow builds a report and sends an approval email. At this point, the durable function pauses and waits. If approved, it resumes and deletes the versions. If rejected, it simply exits without deleting anything. That is what made Durable Functions such a good fit for this use case.

It gave me a clean human-in-the-loop workflow instead of a risky cleanup script.

Approval flow

The approval flow is simple.

Once the candidate list is ready, the workflow uploads the report and sends an email with Approve and Reject links. Then the durable function pauses and waits for a callback.

One detail I liked here is that the link itself does not directly take action.

When the approver opens the link, it first shows a confirmation page. The actual approve or reject action happens only after clicking confirm. This is useful because email scanners and safe-link checkers often open links automatically, and I did not want them to accidentally approve a cleanup request.

Once the approver confirms, the callback is sent back to the durable workflow. If approved, the orchestrator resumes and deletes the selected versions. If rejected, it exits safely without deleting anything.

That made the whole process much safer and easier to trust.

Final thoughts

SnapStart is a really useful feature, especially for Python APIs where cold starts matter.

But like many good AWS features, it needs the right cleanup around it. In our case, the problem was not SnapStart itself. It was the old published versions that kept piling up and quietly adding to the bill.

That is why I built this workflow.

Not just to delete unused versions, but to do it in a safe and controlled way. The Durable Function gave me exactly that. It let me build a proper workflow with scanning, reporting, human approval, and deletion only after confirmation.

For me, this was the real value of the solution.

It solved the cost problem, and at the same time showed how useful Durable Functions can be when we need automation with a human in the loop.

If you are using SnapStart for Python, it is worth checking how many old versions are still sitting there. You may find that the real cost is not in your traffic, but in the versions you forgot to clean up.

If you are interested in trying this approach or exploring the implementation in more detail, you can find the complete source code in my GitHub repository.

GitHub Repo: https://github.com/jayaganeshk/aws-lambda-snapstart-version-cleaner

A Practical Guide to Building Bidirectional Pagination in AWS DynamoDB

Jaya Ganesh — Tue, 24 Jun 2025 12:38:31 +0000

Pagination is the most common requirement for any API built. Usually, in the query parameter of the API, we will pass the required page number and the number of results to be present in the response.

But, in DynamoDB, we won’t be able to jump to a specific page. That’s a design approach taken to maintain the same millisecond response time from the database, even if it has millions of records.

So, how does Pagination work in DynamoDB? We can pass the number of items required in a response using Limit. And then we can request the next page and so on.

Unidirectional Pagination

Let us create a DynamoDB Table to store Invoice details. For now, we can keep the table simple with Invoice Number as the partition key and Invoice Date as the sort key. And, let's create a GSI with partition key as entityType, which will be set to “invoice”, and sort key as invoice date.

Now, let's use GSI to get invoices.

This query returns the first 10 invoices based on the ascending order of the invoice date. And, an interesting part in the response is the “Last Evaluated Key”. This key gives the primary key of the last element which was returned in the result. It is like an address, which you can use to fetch the next page.

Now, let's use this last evaluated key and get the next page.

If you observe the response of the second page, it is from the 11th invoice to the 20th invoice and has the last evaluated key value in the response for the next page.

Great, now we have achieved Unidirectional pagination, which allows us to go in the forward direction to get data in small chunks.

Bidirectional Pagination

We know how to utilise the limit and Exclusive Start key parameter to achieve pagination. Is it possible to go to the previous page?

The client can store the Last Evaluated Key on its side and get the previous page content. That looks simple, doesn't it? But, what if the number of pages is more, and it's complicated to store the keys for each page and maintain them? Instead, let's see how to handle it on the API side.

We have the last evaluated key for a given page, and it is passed as the exclusive start key. DynamoDB goes in ascending order of sort key to get the data for the next page. So the simple approach would be to ask DynamoDB to get the items from a specific item in descending order, so that we would be able to get the previous page data.

We are able to retrieve the previous page, but the results are not sorted in ascending order. We can just reverse the response list to get the data in the desired format.

If we observe carefully, the page 2 data doesn't have the 20th invoice in the response and also has the 10th invoice, which is supposed to be in 1st first. So, we can have a simple update done to get the response in the expected format.

Great, now we have achieved bidirectional pagination.

Complete Code:

import boto3

dynamodb = boto3.resource("dynamodb")
table = dynamodb.Table("invoice")

def get_invoices(pageSize=10, after=None, before=None):
    """Get invoices with pagination support."""
    query_params = {
        "IndexName": "entityType-invoiceDate-index",
        "KeyConditionExpression": "entityType = :entityType",
        "ExpressionAttributeValues": {
            ":entityType": "invoice",
        },
        "Limit": pageSize,
    }

    # if before is provided, we need to reduce the limit by 1 to account for the item that will be used as ExclusiveStartKey
    scanIndexForward = True

    if before:
        query_params["Limit"] = pageSize - 1
        scanIndexForward = False
        query_params["ExclusiveStartKey"] = before

    if after:
        query_params["ExclusiveStartKey"] = after

    query_params["ScanIndexForward"] = scanIndexForward

    response = table.query(**query_params)
    items = response.get("Items", [])
    last_evaluated_key = response.get("LastEvaluatedKey", None)

    # if before is provided, we need to get the complete item which is mentioned in ExclusiveStartKey
    if before:
        get_param = {
            "Key": {
                "invoiceDate": before["invoiceDate"],
                "invoiceNumber": before["invoiceNumber"],
            }
        }
        get_response = table.get_item(**get_param)
        item = get_response.get("Item", None)
        if item:
            items.reverse()
            items.append(item)

    # set the next cursor value to return in response   
    if scanIndexForward:
        next_cursor = last_evaluated_key if last_evaluated_key else None
        previous_cursor = after
    else:
        next_cursor =  {
            "invoiceNumber": items[-1]["invoiceNumber"],
            "invoiceDate": items[-1]["invoiceDate"],
            "entityType": "invoice"
        }
        previous_cursor = last_evaluated_key if last_evaluated_key else None       

    return {
        "items": items,
        "after":  next_cursor,
        "before": previous_cursor,
    }

Get 1st Page:

Getting 2nd Page:

Let's get the previous page — 1st page — using the before key.

Magic and Logic behind fetching the previous page

When going to the previous page, DynamoDB doesn't give us a direct way. To achieve this, we have hacked a workaround.

We fetch pageSize - 1 records to skip the overlapping item between pages.
We fetch that skipped item separately (using get_item).
We reverse the list (since the query runs backwards) and add the skipped item back, giving us a proper previous page.

Key Terminology of DynamoDB Query.

Limit: While querying, we can pass a limit parameter, which decides the maximum number of items to be present in the response. If we don't pass a limit, DynamoDB will try to get as many items till the total response size reaches 1MB in size.

Last Evaluated Key: This gives the primary key of the last element which is present in the response for that given page.

Exclusive Start Key: We can ask DynamoDB to start getting items from a specific record instead of getting them from the beginning.

Scan Index forward: While getting the items from a specific item, if scan index forward is set to true, then DynamoDB fetches the item in ascending order based on sort key and in reverse when it is set to false.

Conclusion:

By using ExclusiveStartKey and playing with the sort direction, we can build clean, reliable B*idirectional pagination* on top of DynamoDB.

It’s fast and works well, though DynamoDB doesn’t support "go to page 10" style jumps (by design, to stay super fast). But for "next" and "previous" style UIs, this pattern works great.

The only thing to watch out for is if new items get added or removed, in between pages might shift a bit. But for most apps, this is perfectly fine.

BattleShip — Sink Enemy Ships — Game Rebuilt by Amazon Q CLI

Jaya Ganesh — Sat, 07 Jun 2025 09:32:39 +0000

In my school days, during summer season, I used to go to my friends home and play video games in his computer. There were many games I used to like; one such game was BattleShip.

Fast forward to the current summer, I got to rebuild the same game from scratch. I got introduced to Amazon Q. It is a generative AI-powered assistant which I used as my coding copilot. It helped me with code completion, saved me from writing boilerplate code, and accelerated my ability to write better code.

Then, I got introduced to Amazon Q CLI, an Agentic Assistant. Just give it a command and let it take care of the rest. Without writing a single line of code, we can create an entire application from scratch.

Setting Up

To install Amazon Q CLI in Windows, you must enable WSL (Windows Subsystem for Linux).

wsl --install

Once the Machine is restarted, you can access the WSL.

We can install Amazon Q CLI by downloading the ZIP file and installing.

curl --proto '=https' --tlsv1.2 -sSf "<https://desktop-release.q.us-east-1.amazonaws.com/latest/q-x86_64-linux.zip>" -o "q.zip"

Then, unzip it and run the installation.

unzip q.zip

./q/install.sh

Now, we can run q doctor to check the installation status.

You can login to Amazon Q CLI using q login.

Prompt To Generate the game:

You can select from the available models to help with the task. I selected Claude 4 Sonnet.

I used below prompt to generate the code.

Create a Complete Browser-Based Battleship Game

Technical Requirements:
• Use HTML, CSS, and vanilla JavaScript only (no frameworks or libraries)
• Implement as multiple project files for better maintainability
• Ensure responsive design that works on different screen sizes

Game Features:
• Single-player gameplay against a computer opponent
• 10x10 grid boards for both player and computer
• 5 ships of different sizes: Carrier (5), Battleship (4), Cruiser (3), Submarine (3), Destroyer (2)

Ship Placement Phase:

• Manual placement by clicking on cells
• Option to randomize ship positions
• Ability to rotate ships before and after placement
• Ability to move ships after placement but before game start
• Visual selection and highlighting of ships for editing
• No ships should touch (including diagonally)

Gameplay Mechanics:

• Turn-based gameplay where players alternate firing at opponent's grid
• Visual indication of hits and misses with animations
• Ship status tracking (active vs. sunk)
• Game over detection when all ships of either player are sunk
• Clear feedback messages throughout gameplay

Visual Elements:

• Detailed top-view representations for different ship types
• Visual differentiation between ship parts (bow, middle, stern)
• Ship legend showing all ship types and their current status
• Clear visual feedback for hits, misses, and selected ships
• Seamless ship appearance without gaps between cells
• Animation for ship blasts when hit
• Cross marker over ships when completely sunk
• Only the latest hit cell should animate/blink
• Clean, intuitive user interface with appropriate buttons and controls

Additional Requirements:

• Include detailed comments in the code to explain implementation logic
• Ensure proper visual feedback when ships are hit or sunk
• Implement proper ship damage visualization
• Ensure no duplicate ships appear when sunk
• Make sure hit markers are clearly visible on ships

The game should provide an engaging and visually appealing experience while following classic Battleship rules.

After I entered the prompt, Amazon Q started doing its magic by “Thinking”.

And after a few minutes, it created the entire game with a proper folder structure.

Conclusion

I opened the index.html file that was created, and boom!

The game was ready to play!

You can experience the game from the URL below: https://jayaganeshk.github.io/battleship/

You can find the code that was generated in the repo below: https://github.com/jayaganeshk/battleship

Don’t log it... Just Trace it! OpenTelemetry in AWS Lambda - Part 3

Jaya Ganesh — Sun, 01 Jun 2025 07:52:50 +0000

In the Previous article, we have set up OpenTelemetry in an AWS Lambda function and saw the traces in Honeycomb. In this article, let's see how to customise the OTel data by sending custom application-related metadata.

Step 1: Update Lambda Code

We can add a few business logics to our Lambda and also make external API calls.

Update the lambda function with the below code. It makes an API call to get a list of products and returns.

💡For the requests to work, you need to add the requests package via lambda layers. You either package your function with requests, or you can get lambda layer ARNs from the below URL.

import json
import requests

def get_products():
    try:
        url = "https://fakerapi.it/api/v2/products?_quantity=1&_taxes=12&_categories_type=uuid"
        response = requests.get(url)
        response.raise_for_status()
        data = response.json()["data"]
        return data
    except Exception as e:
        print(e)
        return None

def lambda_handler(event, context):
    try:
        print(event)

        products = get_products()

        print(len(products))

        return {"statusCode": 200, "body": json.dumps(products)}
    except Exception as e:
        return {
            "statusCode": 500,
            "body": json.dumps({"message": "There was some error"}),
        }

Step 2: Invoke and see the trace

Load the URL in browser and we will be able to see the data.

In Honeycomb, open the trace and see it.

if you notice, we are able to see the GET call that was made, time taken and also few metadata like URL and status..

We achieved all of these without make any changes to code. By just adding few more lines of code we would be able to enrich the telemetry data.

💡You get this level of detail without writing any additional instrumentation code, thanks to OpenTelemetry’s auto-instrumentation!

Step 3: Create custom spans

In Trace, we are able to see the API call that was made, but we don't have info about what was the function name which invoked the GET call, get_products function.

And, we have added a print statement in lambda handler for the incoming event. But that is not visible in Trace.

Let’s update the lambda function with the code below to add Span Attributes and Span Events.

import json
import requests

from opentelemetry import trace
from opentelemetry.trace import Status, StatusCode

tracer = trace.get_tracer(__name__)

@tracer.start_as_current_span("get_products")
def get_products():
    try:
        url = "https://fakerapi.it/api/v2/products?_quantity=1&_taxes=12&_categories_type=uuid"
        response = requests.get(url)
        response.raise_for_status()
        data = response.json()["data"]
        return data
    except Exception as e:
        print(e)
        return None

def lambda_handler(event, context):
    with tracer.start_as_current_span("process_data") as span:
        try:
            span.add_event(
                "log",
                {"event": str(event)},
            )

            products = get_products()


            span.set_attribute("products length",  str(len(products)))

            return {"statusCode": 200, "body": json.dumps(products)}
        except Exception as e:

            span.record_exception(e)
            span.set_status(Status(StatusCode.ERROR))

            return {
                "statusCode": 500,
                "body": json.dumps({"message": "There was some error"}),
            }

After invoking the API again, head to Honeycomb and inspect the trace.

You would be able to see the span in a hierarchical format. We can see that the span event with the name log was added to the process_data span.

You should now see:

A custom span for get_products
A parent span named process_data
An event named log with the Lambda input event
A span attribute called products.length

We have also added a span attribute with the name “product length”. We can see it in the fields section.

Code Explanation:

Starting a new span

We can start a custom span in our code and wrap it around our function or part of a function which we want to track separately in OTel.

@tracer.start_as_current_span("get_products")

with tracer.start_as_current_span("process_data") as span:

Add custom span attribute

We can add our custom data in a key-value pair to Span as a span attribute, which would help us in querying the data efficiently and know the system status better

span.set_attribute("products length", str(len(products)))

Add Span Events

Use events to log contextual information like errors or input payloads:

span.add_event("log", {"event": str(event)})

Conclusion:

In this article, we learned how to:

Create custom spans in AWS Lambda
Add span events to track log-like info
Enrich spans with custom attributes

These enhancements help us better understand our application's behaviour, performance, and internal state using distributed tracing tools like Honeycomb.

Don't log it… Just Trace it! OpenTelemetry in AWS Lambda - Part 2

Jaya Ganesh — Sun, 25 May 2025 07:07:14 +0000

In the previous article, we were introduced to OpenTelemetry and AWS Distro for OpenTelemetry. In this article, we will set up OpenTelemetry in AWS Lambda for Python and observe it in Honeycomb, an observability tool.

Prerequisites:

AWS Lambda: A serverless Function as a service provided by AWS where we can execute our application code without thinking about Servers
Amazon API Gateway: A fully managed API solution that lets us create and publish REST and HTTP APIs.
ADOT Lambda Layer: An AWS-supported distribution of the OpenTelemetry project that includes SDKs, agents, and collectors.

Setting up AWS Lambda Function and API Gateway:

Create an AWS Lambda Python Function in the AWS Console.

Now, let's create an API gateway.

Let's add a GET method to the API and attach the Lambda which was created in step 1.

Now, deploy it and test it from a browser.

We have got the response from Lambda. We can go to the AWS Lambda console and look into the Logs. We can see the event from the API Gateway from the print statement in the logs.

Setting up ADOT in AWS Lambda

We have successfully created an API Endpoint and saw the logs in CloudWatch. Now let us set up AWS Distro for OpenTelemetry on this lambda and export the telemetry data to Honeycomb.

Add AWS Lambda Layer:

You can get the latest Lambda Layer ARN from ADOT documentation and add attached it to our lambda function.

Lambda Layer format (arn:aws:lambda::901920570463:layer:aws-otel-python--ver-1-29-0:1)

Configure Lambda Environment Variables:

Add the below environment variables to our Lambda function

AWS_LAMBDA_EXEC_WRAPPER /opt/otel-instrument

OTEL_PROPAGATORS tracecontext,xray

OTEL_SERVICE_NAME learn-adot
Create a Custom OTel Collector config file with below data and replace your Honeycomb API Key.

AWS_LAMBDA_EXEC_WRAPPER	/opt/otel-instrument
OTEL_PROPAGATORS	tracecontext,xray
OTEL_SERVICE_NAME	learn-adot

#collector.yaml in the root directory
#Set an environemnt variable 'OPENTELEMETRY_COLLECTOR_CONFIG_FILE' to '/var/task/collector.yaml'
receivers:
  otlp:
    protocols:
      grpc: # port 4317
      http: # port 4318

exporters:
  # Data sources: traces, metrics, logs
  # NOTE: Prior to v0.86.0 use `logging` instead of `debug`
  # logging:
  #   verbosity: detailed
  otlp:
    endpoint: "api.honeycomb.io:443"
    headers:
      "x-honeycomb-team": <HONEYCOMB API KEY>

service:
  pipelines:
    logs:
      receivers: [otlp]
      exporters: [otlp]
    traces:
      receivers: [otlp]
      exporters: [otlp]
    metrics:
      receivers: [otlp]
      exporters: [otlp]

You can get a Honeycomb API Key using steps below:

Click on Manage Data
Select environments
And click API Keys and generate an Ingest Key.

We can add this config YAML file to the AWS Lambda code directly. In production scenarios, we can upload it to an S3 Bucket and add its URI to the Lambda environment variable. For this, we need to add get S3 Permission to the Lambda.

Add below environment variable to Lambda:

OPENTELEMETRY_COLLECTOR_CONFIG_URI: s3://.s3..amazonaws.com/collector_config.yaml

Now our AWS Lambda environment variables look like this.

Now Let's invoke the same API again and see the Magic happen.

We can see a few more logs in our CloudWatch Logs indicating that our collector has started.

In the Honeycomb console, we can see our incoming requests.

Click on the graph and select view trace.

In the Trace, we can see the Span Fields and other meta data.

Conclusion

In this tutorial, we've successfully implemented basic OpenTelemetry observability in an AWS Lambda function using ADOT, transforming standard CloudWatch logs into rich, context-aware telemetry visible in Honeycomb.

While this setup already provides significant advantages—including end-to-end request visibility, automatic AWS metadata collection, and cross-service tracing capabilities—we've only scratched the surface of what's possible.

In the next article, we'll enhance our observability by adding custom instrumentation with span attributes and events to capture business-relevant context, measure specific operations, and correlate traces across services, enabling you to answer critical questions about your application's performance and behaviour.

Don’t log it… Just Trace it! OpenTelemetry in AWS — Part 1

Jaya Ganesh — Sun, 25 May 2025 07:01:33 +0000

Traditionally, we rely on print or log statements in our code to debug or understand the system’s current status. But does that really solve the problem?

AWS offers tools like CloudWatch Insights, dashboards, and alarms to meet basic monitoring needs. However, it doesn’t allow us to visualise the time taken for a particular part of the function or where there are bottlenecks. We could use AWS X-Ray. But what if your application interacts with services owned by other teams — possibly in different AWS accounts or entirely different environments?

What if you could see the entire path (or trace) of events that happened when a user clicked on a website, to all the backend services that were triggered as part of it? This is where OpenTelemetry comes to the rescue, ushering in the concept of observability.

Observability is the ability to see the current state or context of the system using the data it generates. We would be able to see all the incoming and outgoing requests in our application.

What is OpenTelemetry (OTel)?

OpenTelemetry is an open-source observability framework for instrumenting, gathering and exporting telemetry data like traces, metrics and logs from our application.

OTel is a vendor-agnostic framework, which means that we can export the logs to various observability tools like Honeycomb, New Relic, Grafana, Datadog, etc.

OpenTelemetry is a CNCF (Cloud Native Computing Foundation) project and is the result of a merger of two projects, OpenCensus and OpenTracing, unified to create a global standard for telemetry

AWS Distro For OpenTelemetry (ADOT)

ADOT is a secure, production-ready, AWS-supported distribution for OTel provided by AWS. It abstracts the manual instrumentation required for OpenTelemetry. Using Auto instrumentation in ADOT, without writing any extra lines of code, we can publish basic telemetry data to any Observability tool. It also collects and includes metadata from our AWS Lambda like function name and version.

In AWS Lambda, we can just add an ADOT Lambda Layer to our function and just by adding a few environment variables, we would be able to collect telemetry data and export it to any observability tool.

Now let’s understand more about OpenTelemetry and its core concepts.

Core Concepts of OpenTelemetry

Traces

Traces provide end-to-end visibility into request flows across our systems. Think of a trace as the journey of a single request as it travels through your application ecosystem. Each step taken by it is called a Span.

Trace Contains Unique identifiers known as trace ID, and each Span also has a unique ID known as Span ID.

A Span contains metadata like timestamp, status, faas (Function As a Service) name and versions.
Key Moments, like exceptions in a span, are captured as Events.
We can add custom Key-Value Pairs to span, which are application-related, and it is called span attributes.
If any external calls are made, this Trace ID is propagated across systems, and this is called as context propagation.

Metrics

Metrics are numerical measurements collected to monitor the system. Counter is the most common type of metric. For example, you can have a metric for the number of users who clicked on a button or the number of products that were purchased.

Logs

Logging mechanisms are available in all programming languages. OpenTelemetry helps us to correlate logs with Traces and Metrics. And, a centralised location to observe logs from various systems.

Instrumentation

It is the process of adding observability to our application code. There are two types available one is Manual instrumentation and another is Auto Instrumentation.

In Auto Instrumentation, minimal code changes are required, and it enables us to easily set up observability for our application, whereas in manual instrumentation, we need to write custom code to set up collection and transportation of telemetry data.

OpenTelemetry Collectors

OpenTelmetry collectors can be run as an agent (sidecar) alongside our application or as a standalone service.

Receiver: Ingests data from sources
Processor: Transforms, filters telemetry data
Exporters: Send data to various Observability tools like AWS X-Ray, Honeycomb, New Relic, Etc.
In AWS Lambda, this can be run as a Lambda extension just by adding the ADOT Lambda Layer.

Now that we’ve covered the basics of OpenTelemetry, the next part will walk through implementing it in AWS Lambda and exporting telemetry data to an observability tool.

Until then, Happy Learning!