Infrastructure observability is critical for maintaining uptime, optimizing cloud environments, and securing the cloud perimeter. Cloud environments generate observability data at massive scale. VPC Flow Logs, ELB Access Logs, CloudTrail and CloudWatch logs can easily reach hundreds of thousands of events per second. Dealing with scale like this is a complex problem all by itself.
Today, we introduce EDOT Cloud Forwarder, built on OTel Collector, it is the simplest, fastest, and possibly most boring way to connect your Cloud environment to Elastic Observability, and it is now Generally Available on AWS. With EDOT Cloud Forwarder you can get started in seconds, get observability across your entire cloud estate, and easily handle telemetry at any volume.
Deploying Cloud Forwarder from a District Line train
So, I got to work deploying EDOT Cloud Forwarder in my AWS account. I was doing it on the commute, using nothing more than a decent 4G signal and hoping that my 27% battery would be enough.
I hit deploy on the terraform template and waited. I started seeing events flowing into Elastic Observability.
As the train pulled into Putney Bridge, the flow of logs peaked, and one million events per second scrolled across my screen.
Once deployed, I got the best three zeros I could expect:
- Zero Intervention: I watched as traffic ramped up to a full 1M EPS. Lambda functions automatically scaled out from a few instances to the 60-65 concurrent executions needed. There were zero manual adjustments required. The scaling was instant and hands-free.
- Zero Data Loss: It achieved a consistent processing rate, with every single event indexed in Elasticsearch.
- Zero Idle Cost: When there are no events, Cloud Forwarder scales to zero - it has no fixed infrastructure cost. You only pay for the moment data is being processed, not for permanently over-provisioned servers sitting idle.
Right before the train came to a standstill, I looked at the total cost for running Cloud Forwarder for the two minutes between Parsons Green and Putney Bridge - we forwarded about 120GB of telemetry and the total cost was below £0.10. Well, unless you count the £2.50 train ticket!
Making Observability easy at any scale
Getting started observing your infrastructure is hard and once it's observable, deriving actionable value from it requires sifting and winnowing through massive volumes of telemetry data, sometimes millions of events per second.
The new EDOT Cloud Forwarder for AWS (also available in Preview for GCP and Azure) is easy to deploy, with just a Terraform template. To make sure that it was easy to get started with, we designed it to be as close to a single-click deployment as possible:
Just click the link below to launch the CloudFormation stack in your AWS account:
The best part? The fastest way to get started with Elastic Observability scales to any size workload! With EDOT Cloud Forwarder you have one solution which automatically scales down to zero and up to millions of events per second.
So, what is EDOT Cloud Forwarder?
EDOT Cloud Forwarder is a serverless OpenTelemetry Collector that, on AWS, runs as a Lambda function. In AWS, it is triggered by events and processes logs and metrics from services such as VPC Flow Logs, ELB Access Logs, CloudTrail, CloudWatch Logs and CloudWatch Metrics.
It has the following core capabilities:
- Collects observability and security data from Cloud Service Providers
- Parses data into native OpenTelemetry format
- Forwards data over OTLP
- Scales up and down based on traffic
ECF for AWS is a pure serverless solution, no VMs, containers, or Kubernetes control planes to manage.
Off the train, a more controlled scenario
For a more controlled testing scenario, we used synthetic VPC Flow Log data generated to show how easy EDOT Cloud Forwarder can sustain a million events per second reliably and without data loss.
For the configuration, we left all EDOT Cloud Forwarder configuration/settings at their defaults. In AWS, the Lambda max concurrency defaults to 5. If left to the default of 5, up to around 50k EPS could be expected. For our scenario, we bumped this to 100 to ensure we'd have plenty of headroom for our test.
We ran the scenario in 10 minute stages, with each stage resulting in a larger data volume. We held ingest flat during the stage to provide short-term steady state windows for us to grab metrics.
We experienced no errors across all stages of the scenarios, no retries outside expected behavior, no data loss across 5.4 billion ingested events.
Stats for Observability Nerds
Because we know you love them:
Incremental Load Stages
We tested EDOT Cloud Forwarder using incremental load stages, gradually increasing traffic from approximately 300,000 events per second to over 1 million events per second.
The graph below shows the Elasticsearch ingestion rate throughout the entire test duration. You can see the clear progression as we ramped up through six distinct stages, with each plateau representing a 10 minute stabilization period.
The system handled each traffic increase smoothly, culminating in sustained 1 million documents per second ingestion with no bottlenecks or data loss.
Lambda
As seen in CloudWatch metrics (no manual adjustments required). No errors and no throttles were seen during the full duration of the test.
Concurrent executions
60 to 65 instances running at the same time.
Average execution time per Lambda
Each execution is taking about 5 seconds.
Memory Usage
Memory use stabilized at around 450 MB, below the default limit of 512 MB.
Elasticsearch Indexing
Elasticsearch indexed one million documents per second, with events visible in Discover within seconds and no indexing delays or bottlenecks.
Efficient by design: Lambda at 1M EPS from S3
Running ECF for AWS at 1M EPS costs about $3.87 per hour. Around 66 percent ($2.57 per hour) is data transfer (same region), 34 percent ($1.32 per hour) is Lambda compute, and less than 1 percent is S3 requests.
This is fully serverless with no idle cost. You only pay while events are forwarded. With S3, data arrives pre-batched in large objects, which keeps Lambda invocations low and compute costs tightly controlled. At sustained throughput, Lambda costs are comparable to EKS—but without cluster management or idle capacity.
Other options: OTel Collector on EKS at 1M events per second
An OTel Collector on EKS sized for 1M EPS has a baseline cost of about $3.69 per hour. Roughly $0.33 per hour of this is compute related, EC2 nodes, EKS control plane, and EBS. The rest comes from data transfer and SQS, which scale with traffic and do not change with utilization.
Idle compute impact on EKS real costs
Considering EKS is typically provisioned for peak load, the real cost of the compute portion is affected by idle capacity. At 100 percent utilization, total cost is $3.69 per hour. At 50 percent utilization, a common baseline to absorb burstiness, total cost rises to about $4.02 per hour. At 30 percent utilization, it increases further to about $4.46 per hour.
Pay for Work vs Pay for Capacity
ECF for AWS delivers 1M EPS at a cost comparable to EKS at peak utilization, with no idle compute or capacity planning required. EKS can reach the same peak throughput, but total cost increases further as average utilization drops because compute capacity must be provisioned in advance.
Conclusion
The boring truth: to the EDOT Cloud Forwarder, a million events per second is no different from any other workload.
With no infrastructure to deploy, no idle cost and no manual scaling, I guess the best thing to do is to stop overthinking and start forwarding! It's like stepping onto the fastest train on the line: you just get on and you're instantly en route to your destination, effortlessly handling any distance or in this case, any volume.
So, we're shipping it. ECF for AWS is now Generally Available.
Get Started
- Deploy EDOT Cloud Forwarder via CloudFormation (below) or using the AWS Serverless Application Repository
- Create an Observability project using an Elastic Cloud free trial or deploy locally with start-local if you don't already have an Elastic project or deployment.
Visit EDOT Cloud Forwarder for AWS Documentation for more details.
Check out these other resources on OpenTelemetry at Elastic
Discover how Elastic is evolving data ingestion with OpenTelemetry
Learn how OpAMP enables centralized configuration of OpenTelemetry SDKs