Real-time bidding has revolutionized digital advertising—every time a user browses a website, streams a video, or opens a mobile app, split-second auctions determine which ad appears. Ad buyers (demand-side platforms (DSPs)) and ad sellers (supply-side platforms) (SSPs)) transact millions of times per second, operating in a petabyte-scale, millisecond-latency world where even minor delays erode performance and revenue. But this scale comes at a cost. The communication between SSPs and DSPs generates massive data transfer expenses—tens of millions of transactions per second flowing through load balancers, across Availability Zones, between AWS Regions, and out to the internet, all priced per gigabyte. With profit margins measured in fractions of a cent per transaction, cost efficiency isn’t just a design principle—it’s a survival requirement.

Advertising technology (AdTech) companies have historically addressed this by deploying real-time bidding (RTB) applications in collocated data centers, operating tens of thousands of servers with significant capital expenditure. Cloud migration solved the infrastructure burden but introduced a new challenge: general-purpose networking pricing that doesn’t distinguish between a revenue-generating bid and a 100-byte decline. When over 90% of all DSP responses are no-bids, the per-gigabyte tax on every transaction becomes the dominant cost driver.

The next generation: A service built for real-time bidding

AWS RTB Fabric replaces per-GB networking costs with per-transaction pricing on a low latency, purpose-built private network. Instead of routing bid traffic through generic infrastructure, advertising customers connect through a dedicated RTB gateway optimized for OpenRTB protocol traffic. With RTB Fabric, you will see the following changes:

Per GB becomes per-billion transactions: RTB Fabric charges a variable rate per billion transactions depending on the AWS Region and whether both parties are on RTB Fabric (internal transactions) or traffic is being sent to partners not using RTB Fabric (external transactions). Internal rates are consistent across all Regions, while external rates carry a premium in APAC Regions (Singapore, Tokyo) compared to US and EU Regions. Volume tiers apply with rates being reduced when monthly transaction volume exceeds 2 trillion. Each transaction includes 2 KiB (2,048 bytes) of data at no additional charge. For traffic above that threshold, excess payload is priced per GiB, with rates also varying by Region and volume tier. For the latest Regional rates, see the AWS RTB Fabric Pricing page.

Built-in intelligence – Traffic management modules: Beyond pricing, RTB Fabric embeds operational intelligence directly into the network path. Three built-in traffic management modules run inline within the service, executing at consistent low latency without requiring customers to build or maintain separate infrastructure:

• Rate limiter caps queries per second at the network layer, protecting bid engines from traffic spikes without over-provisioning compute.
• An OpenRTB filter drops non-qualifying bid requests based on protocol attributes like ad format, location, and device type before they reach application servers. This is critical when most incoming requests don’t match target criteria.

High-level architecture of RTB Fabric

The following figure shows the high-level architecture of RTB Fabric.

SSP perspective: Sending bid requests

Consider an SSP hosted in Virginia (us-east-1) sending 100,000 queries per second (QPS) of bid requests to DSP partners distributed across three destinations: 10% to DSPs in the same Region across Availability Zones, 20% to DSPs hosted in AWS Oregon (us-west-2), and the remaining 70% to DSPs reachable only over the public internet using internet gateway. Even at this moderate scale, the data transfer costs are substantial: 8.64 billion bid requests per day at an average 3 KB per bid, generating nearly 725 TB of monthly egress across three different pricing tiers.

SSP traffic profile:

100,000 QPS and an average 3 KB bid request size results in259.2 billion requests per month and 741,580 GB of data.

Data transfer types in scope for the preceding SSP profile:

• Data transfer out to internet (DTO): Charges for traffic leaving AWS to the public internet.
• Data transfer inter-Region (DTIR): Charges for traffic between different Regions (for example, us-east-1 to us-west-2).
• Data transfer across Availability Zones (DTAZ): Charges for traffic crossing Availability Zone boundaries within the same Region.

See Data Transfer Costs for Common Architectures to understand data transfer charges and types in more details.

 Data transfer cost prior to AWS RTB Fabric:

Cost using AWS RTB Fabric:

Even with only 10% of transactions internal to RTB Fabric and 90% external, RTB Fabric delivers a 65% cost reduction from $29,663 per month to $10,532 per month. As more DSP partners join RTB Fabric (shifting traffic from external to internal), the economy of RTB Fabric improves further.

DSP perspective: Responding to bids

Consider a DSP hosted in Virginia (us-east-1) receiving 100,000 QPS of inbound bid requests from SSP partners through an application load balancer (ALB) as an entry point across three origins: 10% from SSPs in the same Region across availability zones (DTAZ), 20% from SSPs hosted in AWS Oregon us-west-2 (DTIR), and 70% from SSPs sending over the public internet (DTO). The DSP evaluates each request against device and audience data and campaign targeting, then returns a bid or no-bid—all within sub-millisecond latency at a 10% bid response rate (90% of responses are no-bid).

Traffic profile (inbound)

100,000 QPS, 3 KB bid request size, with 259.2 billion requests per month, results in 741,580 GB of inbound data

Traffic profile (outbound) – 10% responses, 90% no-bids

10,000 QPS, 5 KB bid response size, with 25.9 billion bid responses and 233.3 billion no-bids per month results in 145,322 GB per month of outbound data

Before AWS RTB Fabric:

ALB Load Balancer Capacity Unit breakdown

Assuming HTTP keep-alive and connection reuse (standard for RTB server-to-server), processed bytes become the dominant Load Balancer Capacity Unit (LCU) dimension:

Total monthly data processed through ALB:

Inbound (bid requests): 741,580 GB + outbound (bid responses + no-bids) = 145,322 GB

Processed: 886,902 GB at 1,215 GB per hour uses 1,215 LCUs

• ALB fixed monthly cost: $16
• ALB LCU cost: 1,215 LCUs × $0.008/LCU-hour × 730 hours = $7,095

See Elastic Load Balancing (ELB) Pricing for more details.

After AWS RTB Fabric:

Even with only 10% of transactions internal to RTB Fabric and 90% external, RTB Fabric delivers an 84% cost reduction from $13,666 per month to $2,192 per month. The DSP doesn’t need to wait for ecosystem-wide RTB Fabric adoption to see significant savings. The DSP can receive traffic from supply partners using RTB Fabric and from supply partners not using RTB Fabric or AWS. The economics improve as more SSP partners use RTB Fabric.

Ninety percent of all inbound traffic results in no-bids. Even with a no-bid response as small as 100 bytes, the DSP is still billed for ELB on both the inbound bid requests and the outbound responses, because ELB charges are metered by the total volume of data the load balancer processes. RTB Fabric (through an RTB Fabric responder gateway) replaces the ELB, eliminating ELB processed byte charges, and eliminates DTO, DTIR, and DTAZ charges, replacing these charges with the more cost effective RTB Fabric charges outlined previously

Key takeaways

The key takeaways from the preceding information include:

• An RTB Fabric gateway replaces the ALB or Network Load Balancer (NLB) as the entry point for bid traffic
• Pricing shifts from per-byte to per-transaction
• The ingress of bid requests doesn’t incur costs
• No-bid responses are priced as a first-class category
• The built-in OpenRTB filter module drops non-qualifying requests at the network layer before they reach bidder pods, reducing compute load and shrinking the fleet accordingly
• The rate limiter module absorbs SSP traffic spikes in the gateway instead of the pod fleet, eliminating the need to over-provision for peak capacity

Analyzing RTB Fabric cost

Understanding your RTB Fabric costs is essential for optimizing spending and managing your ad tech infrastructure budget. This post walks through two approaches: AWS Cost Explorer for visual analysis and AWS Cost and Usage Report (AWS CUR) queries for detailed, granular insights.

Method 1: Cost Explorer

Cost Explorer provides a quick, visual way to analyze your RTB Fabric spend without writing any queries.

To analyze your RTB Fabric:

1. Sign in to AWS Cost Explorer.
2. In the navigation pane, choose e, then select Cost and Usage.
3. Select the date range for the period you want to analyze and choose Apply.
4. Under Filters, select Service, then select RTB Fabric. choose Apply filters.

5. Under Group By, select Usage type as the Dimension to see an itemized breakdown of costs by usage category.

This gives you a clear visual breakdown of where your RTB Fabric spend is going.

Understanding RTB Fabric usage types

The following list describes each of the RTB Fabric usage types.

• RTBFabric-Tx-Billion-External: Bid transactions (requests or responses) sent to parties external to AWS RTB Fabric—meaning the partner operates outside RTB Fabric (for example, on-premises, in another cloud, or on AWS but not using RTB Fabric).
• RTBFabric-Tx-Billion-Internal: Bid transactions sent between two RTB Fabric customers within the same Region over the private RTB Fabric network.
• RTBFabric-TransactionExtraData-External: Excess payload charges for external transactions where the average request or response size exceeds the included 2 KiB (2,048 bytes) per transaction.
• RTBFabric-TransactionExtraData-Internal: Same excess payload charge but for internal (within RTB Fabric) transactions.
• RTBFabric-NoBid-Billion-External: No-bid responses sent to partners external to RTB Fabric. A no-bid occurs when you receive a bid request but choose not to bid, less expensive than full transactions because no-bids carry minimal payload.
• RTBFabric-NoBid-Billion-Internal: No-bid responses sent to partners inside RTB Fabric within the same Region.

Method 2: CUR query through Amazon Athena

For deeper, row-level analysis, query your CUR data directly using Amazon Athena. This is especially useful for building custom reports, tracking costs over time, or integrating with business intelligence (BI) tools. See the CUR Library for setup instructions and curated SQL queries for Athena against CUR data.

The following sample query pulls all RTB Fabric cost and usage line items from your CUR table for a given month.

Replace <your_cur_table_name> with your actual CUR table name in Athena. The year and month partition filters help limit the scan to the relevant billing period, reducing query cost and execution time.

Note: Usage types are prefixed with the Region identifier (for example, USE1-RTBFabric-Tx-Billion-External for us-east-1).

Sample query:

SELECT
 line_item_usage_start_date,
 line_item_usage_end_date,
 line_item_resource_id,
 line_item_usage_account_id,
 product_region,
 pricing_unit,
 line_item_usage_amount,
 line_item_product_code,
 line_item_unblended_cost,
 line_item_blended_cost
 FROM
 <your_cur_table_name>
 WHERE
 line_item_product_code = 'AWSRTBFabric'
 AND year = '2026' -- <Replace with the desired year>
 AND month = '02' -- <Replace with the desired month>
 ORDER BY
 line_item_usage_start_date;

Both methods described in this section give you full visibility into your RTB Fabric spend—from high-level trends down to individual transaction-level costs.

For more information about RTB Fabric pricing and capabilities, see AWS RTB Fabric.

Why it matters beyond cost

Cost isn’t the only advantage offered by RTB Fabric.

Latency has become a competitive advantage: RTB Fabric delivers consistent single-digit millisecond latency on a dedicated network. In programmatic advertising, latency kills revenue. Every millisecond added to a DSP’s bid response time reduces win rates. Every millisecond added to an SSP’s request distribution reduces fill rates. RTB Fabric prioritizes routing between partners that share the same Availability Zone

Load balancer elimination simplifies architecture: RTB Fabric replaces load balancers with a managed gateway that includes load balancing directly to Amazon EC2 and Amazon Elastic Kubernetes Service (Amazon EKS) clusters—no separate ALB or NLB required for bid traffic. That’s fewer components to manage, monitor, and pay for.

Built-in traffic management reduces wasted compute: RTB Fabric includes inline modules for rate limiting, OpenRTB filtering and error masking. Today, most SSPs and DSPs implement these functions in their application layer, consuming AWS Lambda invocations, Amazon EC2 cycles, or container resources. Moving traffic shaping into the network layer means fewer bid requests that will ultimately result in no-bids are sent to compute resources.

Partner connectivity becomes frictionless: As more participants in programmatic advertising join RTB Fabric—Amazon Ads, GumGum, TripleLift, Sovrn, Yieldmo, MobileFuse, Kargo, Viant, and others are already on the platform—every participant benefits from network effects. Lower latency and lower cost to every partner on the fabric, without individual peering arrangements, virtual private network (VPN) tunnels, or colocation contracts.

Ready to give AWS RTB Fabric a try?

AWS RTB Fabric is available today in US East (N. Virginia), US West (Oregon), Europe (Frankfurt), Europe (Ireland), Asia Pacific (Singapore), and Asia Pacific (Tokyo). Whether you’re an SSP looking to reduce egress costs or a DSP ready to eliminate your load balancer, the path to per-transaction pricing starts with a single gateway.

To get started, contact your AWS account team or reach out through the AWS RTB Fabric Contact Us page to discuss your workload and get a cost comparison tailored to your traffic profile.

AWS RTB Fabric Resources

• AWS RTB Fabric product page
• Pricing
• User Guide
• Customers