Serverless vs Containers: Data Transfer Costs

When it comes to cloud architecture, data transfer costs can quietly become a major expense, often outweighing compute charges. The choice between serverless and containers significantly impacts these costs due to differences in how data is handled and billed.

Here’s the key takeaway:

• Serverless (e.g., AWS Lambda): Charges for data egress range from £0.06–£0.09 per GB, with added NAT Gateway fees (£0.034/GB) for private VPC traffic. Data transfer can make up 40–70% of your bill, especially for high-traffic workloads.
• Containers (e.g., AWS ECS/EKS): Internal traffic within the same Availability Zone is free, but cross-AZ transfers cost around £0.008/GB. Containers avoid NAT Gateway fees by using VPC endpoints, reducing networking expenses for data-heavy operations.

Quick Facts:

• Serverless is cost-efficient for low-traffic, event-driven workloads, but costs rise sharply with frequent data transfers.
• Containers are better suited for steady, high-throughput workloads, offering more control over networking and lower data transfer costs.

Quick Comparison:

Understanding these costs is essential for optimising your cloud spend. Serverless shines for unpredictable traffic, while containers offer better value for sustained, high-volume applications.

::: @figure {Serverless vs Containers Data Transfer Cost Comparison} :::

Data Transfer Costs in Serverless

How Serverless Platforms Price Data Transfer

When it comes to serverless platforms, data transfer costs are billed separately from compute charges. Here's how it works: data ingress - the flow of information into your functions from the internet - is free across major providers like AWS Lambda, Azure Functions, and Google Cloud Functions [5]. However, data egress - data leaving your serverless environment - comes with a price tag, typically ranging between £0.06 and £0.09 per GB [5].

The good news? Free tiers help to offset some of these costs. AWS and Azure offer 100 GB of free egress each month, while Google Cloud Functions provides 2 million free invocations before charging £0.30 per million requests - double AWS's rate of £0.15 [5][6].

But that's not all. Internal transfers also come with their own charges. For instance:

• Moving data between Availability Zones in the same region costs about £0.008 per GB.
• Cross-region transfers are more expensive, at roughly £0.07 per GB [5].

If your Lambda functions operate within a Virtual Private Cloud (VPC), you'll also face NAT Gateway processing fees, which add approximately £0.034 per GB on top of the standard egress rates [3]. As Thomas Smart, an AWS Ambassador, explains:

A general rule of thumb is that all traffic originating from the internet into AWS enters for free, but traffic exiting AWS is chargeable outside of the free tier [5].

These pricing details highlight how quickly costs can escalate as data volumes increase.

How Data Volumes Affect Costs

The pricing model for serverless platforms, which charges per invocation, means that even moderate data transfers can lead to surprising costs. In fact, as data volumes grow, these charges can dominate your overall bill. In some cases, data-related costs can account for over 70% of total serverless expenses.

Take this example: a function transferring 10 GB of data per month, invoked 1,000 times daily, with each invocation transferring 10 MB. At this rate, the monthly data total reaches 300 GB - far exceeding free tier limits and resulting in steep egress fees [3]. For high-throughput applications, these hidden costs can push data-related expenses to as much as 78% of the total serverless bill [3].

Understanding these dynamics is crucial for managing costs effectively, especially for data-intensive workloads.

Data Transfer Costs in Containers

Internal vs External Traffic Charges

In containerised environments, data transfer costs share some similarities with serverless setups, particularly when it comes to data ingress. Traffic entering your cluster from the internet is free. However, the story changes when you look at internal traffic.

Traffic that stays within a single Availability Zone (AZ) and uses private IP addresses incurs no additional cost. But as soon as data crosses AZ boundaries within the same region, charges kick in. For example, transferring data between AZs typically costs around £0.008 per GB. Since this fee applies to both sending and receiving data, a round-trip doubles the expense.

When data leaves your cloud provider's network and heads to the internet (external egress), the costs rise sharply - about 8 to 12 times higher than internal cross-AZ transfers. Depending on the provider and region, external egress rates range between £0.06 and £0.09 per GB.

Using NAT Gateways adds another layer of cost. These gateways process data at an additional rate of around £0.034 per GB, on top of the usual transfer fees. As Cloud Burn points out:

If your tasks run in private subnets (recommended for security), NAT Gateway becomes your second-largest cost. This catches many teams off guard. - Cloud Burn

A 2024 case study by Apiko illustrates the impact of inter-AZ traffic costs. A DevOps team discovered their Kubernetes setup was incurring $12 daily in transfer costs for 1.2 TB of data, simply because pods were distributed across three AZs. By configuring nodeAffinity to keep traffic within a single AZ, they reduced daily data transfer to 75 GB, slashing costs to just $0.75 per day - a 93% reduction.

These differences between internal and external traffic costs are crucial for understanding how cloud providers structure their pricing.

How Costs Vary Across Cloud Providers

While the basic principles of data transfer pricing are similar across cloud providers, the specific details often differ. For instance, AWS ECS and EKS charge £0.07 per GB for internet egress after the first 100 GB, which is free. In comparison, Azure's AKS charges about £0.066 per GB for outbound data in the East US region. Google Cloud's Premium Tier starts at £0.09 per GB for the first 1 TB, but its Standard Tier - relying on the public internet rather than Google's private network - is roughly 25–30% cheaper.

Another key distinction is how providers handle inter-AZ traffic. Azure AKS does not charge for network traffic between AZs, whereas AWS and Google Cloud both set this cost at £0.008 per GB. Additionally, AWS charges around £0.076 per hour for its EKS control plane, while Azure offers a free control plane tier, with Standard options priced similarly to AWS.

These cost variations highlight the importance of aligning your cloud provider choice with your workload's specific data transfer patterns and requirements.

Serverless vs Containers: Cost Comparison

Cost Comparison Table

When comparing serverless and containerised environments, their pricing structures reveal some clear differences. While both charge for data egress, the way costs are calculated varies significantly.

The table shows that egress costs are nearly identical for serverless and containerised solutions within the same cloud provider. However, the real differences lie in how compute resources and networking infrastructure are billed. This breakdown provides a foundation for understanding how these differences affect overall costs based on usage patterns.

What the Numbers Tell Us

Serverless platforms charge based on GB-seconds and the number of requests, meaning you only pay for code that’s executed. On the other hand, containerised environments charge for provisioned vCPU and memory hours, regardless of how much is actually used. As explained by Binadox:

In short, containers charge for capacity you keep running, whereas serverless charges for the capacity you actually consume [2].

This creates a tipping point: serverless is generally more cost-efficient when CPU utilisation averages below 20%, as you avoid paying for idle resources. However, when utilisation exceeds 40%, well-optimised container setups (especially when using spot instances) start to offer better value [2].

Another factor is networking. Containers can bypass NAT Gateway fees by running in public subnets with public IPs, a setup that isn’t usually available for private serverless functions [8].

For high-throughput workloads, the cost differences become even more pronounced. For instance, at 50 requests per second, AWS Fargate costs around £76 per month, while Lambda combined with API Gateway costs approximately £497 – a nearly sixfold increase. A notable example comes from Amazon Prime Video’s 2024 case study: by migrating their video quality monitoring service from distributed Lambda functions to a monolithic ECS architecture, they reduced costs by 90%, primarily by eliminating cross-service data transfer fees [8].

Serverless vs Virtual Machine vs Containers | Lambda vs EKS vs EC2 | Choosing Compute

Cost Implications for Different Workloads

Building on the pricing comparisons above, let's delve into how costs shift depending on workload types and usage patterns.

Event-Driven Workloads

Serverless platforms shine in handling event-driven workloads, especially when traffic is unpredictable or irregular. The pricing model - charging only for executed GB-seconds and request counts - means there’s no cost for idle time when functions aren’t running. This makes serverless a great fit for tasks like asynchronous IoT messages, cron-triggered ETL jobs, or image uploads, where usage is generally low [2].

Another advantage is the fine-grained billing. For example, AWS Lambda measures usage in 100 ms increments, while Google Cloud Functions Gen2 goes even further, metering down to 1 ms. For workloads that experience sudden traffic spikes, you only pay for the exact capacity used [2]. However, when traffic becomes more predictable, a different cost approach may be more suitable.

High-Throughput Applications

For steady and predictable traffic, containers often provide a more economical choice. While serverless costs rise with each additional request, container costs stabilise once the infrastructure is in place [4]. For example, EC2 container fleets become more cost-effective than AWS Lambda once traffic exceeds 66 requests per second [4]. With AWS App Runner, this threshold is even lower, at just 15 requests per second [4].

Containers also give you more control over data flow between regions. By directly targeting pods using IP-based TargetGroups, you can avoid cross-AZ traffic charges, a significant saving for high-throughput scenarios [1]. Additionally, using spot instances - a cost-saving method that can reduce expenses by up to 90% - is more feasible with containers than in serverless setups, which are inherently ephemeral [9].

Global Applications

For applications spanning multiple regions, cost considerations become more complex. Edge functions, like Cloudflare Workers, offer cold start times as low as 6 ms, making them an excellent choice for tasks like auth token validation, A/B testing, or lightweight API gateways [10]. However, if these edge functions rely on a single-region database, the latency advantage diminishes due to round-trip delays [10].

On the other hand, containers running in multi-region clusters provide more predictable data transfer costs but come with additional networking fees, such as NAT Gateways, VPC peering, or Transit Gateways [1]. For instance, cross-region egress on AWS costs £0.07 per GB, charged at both the source and destination [5]. For logic that can operate entirely at the edge without heavy database interaction, serverless remains a more cost-efficient option.

How to Reduce Data Transfer Costs

Cutting down on data transfer costs is essential when working with serverless or containerised architectures. While both environments offer ways to save money, the specific strategies vary significantly between them.

Methods for Serverless Environments

One of the simplest ways to save in serverless setups is through compression. Using tools like gzip, zstd, or Brotli for Lambda payloads and API responses can reduce your network footprint by up to 80% [11][13]. Among these, Brotli often outperforms gzip, offering 15–25% better compression for similar CPU usage [13]. For example, compressing a 1 MB JSON payload could reduce its size by 70%, potentially saving around £300 for every 10 million invocations [11].

Data compression enables larger payload transfers and reduces network footprint. It can help to lower network latencies and optimise data transfer costs.

• Anton Aleksandrov and Daniel Abib, AWS [11]

Another effective tactic is using VPC Gateway Endpoints for S3 and DynamoDB traffic. These endpoints completely bypass NAT Gateway processing fees, and they’re free to use [12][15].

For workloads involving large payloads, avoid routing substantial data through Lambda or API Gateway, which have size limits of 6 MB and 10 MB, respectively. Instead, store large payloads in S3 and use pre-signed URLs to allow clients direct access [11].

These approaches provide a strong starting point for reducing costs before moving on to containerised environments.

Methods for Containerised Environments

In containerised setups, load balancer configuration and topology-aware routing are key to cutting costs. Configuring Application Load Balancers and Network Load Balancers to operate in IP mode allows traffic to flow directly to pods, avoiding unnecessary network hops. Additionally, enabling topology-aware routing in Kubernetes (through Topology Aware Hints or internalTrafficPolicy: Local) ensures traffic stays within the same Availability Zone, eliminating cross-AZ and inter-node data transfer costs, which are typically £0.01 per GB [1][7][13].

A real-world example highlights the savings potential. In February 2026, Hardeep Singh Tiwana, a Senior Technical Account Manager at AWS, detailed how a Kubernetes fleet in the us-east-1 region handled 178,000 GB of ECR traffic monthly. By introducing three VPC endpoints (ECR API, ECR Docker, and S3 Gateway), the team slashed their NAT Gateway costs from £8,010 per month to £0 for that traffic. Even after accounting for the £1,823.80 monthly cost of the VPC endpoints, they saved £6,284.75 per month - an annual reduction of over £75,000 [16].

NAT Gateways charge $0.045/GB for data processing. For ECR-heavy workloads, this adds up fast... The solution? Amazon ECR VPC endpoints. They dropped NAT bills by >75% in one setup I worked on.

• Hardeep Singh Tiwana, Sr. Technical Account Manager, AWS [16]

For multi-region applications, employing ECR cross-region replication allows containers to pull images from a local registry, avoiding expensive cross-region data transfer fees, which start at £0.02 per GB [1][13].

Comparing Optimisation Methods

Here’s a breakdown of how different optimisation techniques impact data transfer costs:

For serverless environments, starting with compression and Gateway Endpoints delivers quick and impactful savings. In containerised setups, focusing on VPC endpoints and topology-aware routing can significantly reduce costs, especially for high-throughput applications with large volumes of internal traffic. These strategies lay the groundwork for broader architectural decisions, which will be explored further in the conclusion.

Conclusion

When deciding between serverless and containerised architectures, the choice largely hinges on your workload requirements. Serverless works best when CPU utilisation remains under 20%, making it a great fit for event-driven tasks like S3 uploads or SNS notifications. With millisecond-level billing and no idle costs, serverless can offer genuine savings in these scenarios [2]. However, as workloads grow - surpassing 50,000 daily invocations or 40% CPU usage - containers tend to be 70–90% cheaper. This cost advantage comes from lower per-unit pricing and the ability to bypass costly NAT Gateway fees by using VPC endpoints [3].

One of the challenges with serverless is the hidden costs. Data transfer and NAT fees can significantly inflate the bill. In fact, compute typically accounts for just 22% of serverless expenses, while data transfer, NAT Gateway processing (around £0.045 per GB), and logging make up nearly 80% [3]. Containers, on the other hand, avoid many of these charges by leveraging free VPC endpoints for internal AWS communications. This makes containers particularly cost-effective for data-heavy workloads, such as image processing tasks involving payloads of 5–20 MB, which can be up to 79 times cheaper compared to serverless [3].

These cost differences have led many organisations to adopt a hybrid FinOps strategy. By using serverless for unpredictable triggers and containers for steady-state APIs, teams have achieved cost reductions of 30–48%. This approach often involves auditing high-cost serverless functions - typically those costing over £500 per month - and migrating them strategically [3]. To make informed decisions, it’s crucial to thoroughly profile your workloads by exporting p95 CPU metrics, analysing traffic patterns, and calculating actual data transfer volumes.

Ultimately, the most economical solution depends on your specific needs. Serverless offers simplicity for sporadic, event-driven tasks, while containers excel in handling high-throughput, steady-state applications. Managing data transfer fees effectively is a key factor in keeping costs under control. By understanding these trade-offs, you can avoid the pitfalls of a pay-per-use model that may become expensive with consistent usage [3].

For tailored cloud optimisation advice, consider reaching out to Hokstad Consulting.

FAQs