Amazon Web Services today announced that AWS RTB Fabric supports custom domains for real-time bidding transactions received through external links. The announcement, posted on May 14, 2026, means that advertising technology companies can route bid traffic through Fabric's private, high-performance network while keeping their existing public endpoints intact - without requiring any URL changes from their demand-side or supply-side partners.

The practical implications are significant. In programmatic advertising, an endpoint like bid.company.com/path is rarely just a technical address. According to AWS, these endpoints "are typically representative of established, long-term traffic contracts." Changing them requires coordination across multiple organizations, applications, and DNS configurations - a process that, as anyone who has managed large-scale programmatic integrations knows, can take months and still stall before completion.

Custom domains solve that problem by separating the visible interface from the underlying network path. The endpoint that partners have hardcoded into their bidding configurations stays the same. What changes is where DNS points.

How the feature works

The mechanism relies on a CNAME record update. An AdTech company creates a canonical name record pointing their existing public endpoint - say, east-bid.dsp.example.com - to a regional RTB Fabric Gateway endpoint. From that moment, bid requests addressed to the original domain travel through Fabric's infrastructure without any action required from the counterparty.

According to the AWS documentation, the end-to-end flow involves five distinct steps once a partner sends a bid request to the custom domain.

First, DNS resolution: the partner's resolver looks up the custom domain, finds the CNAME pointing to a regional RTB Fabric Gateway endpoint, and resolves to the IP address of that gateway in the target region.

Second, TLS termination for HTTPS traffic: the gateway inspects the Server Name Indication (SNI) extension in the TLS ClientHello to determine which certificate to present. The resolver checks for an exact hostname match in the customer certificate store first, then looks for a wildcard match. If neither matches, it falls back to a service certificate selected based on the client's supported signature schemes. The certificate's private key is decrypted within the VPC. For HTTP traffic, this step is skipped entirely.

Third, link ID resolution: after the connection is established, the gateway must determine which link should process the request. It evaluates three extraction methods in sequence - URL-based extraction, host header extraction, and rule-based routing. For custom domain traffic, the first two methods typically produce no match, because the URL does not contain a Fabric link ID. Rule-based routing then evaluates the routing rules defined by the customer. According to AWS, "rules are flattened across all links, sorted by priority (ascending), and the first matching rule determines the link ID."

Fourth, module flow execution: the gateway runs the link's configured module flow, which can include fraud detection, identity resolution, geo-enrichment, and independent software vendor modules as defined in the link configuration. Crucially, the original host header, request path, and query string are preserved throughout this step.

Fifth, delivery to the bidder: the gateway delivers the processed request to the customer's bidder running in their VPC via a cross-account network interface. The bidder receives the request with the original host, path, query string, and body intact.

It is worth noting that custom domain links use the same module flow and delivery mechanism as standard RTB Fabric links. The differences are confined to steps two and three: TLS termination uses the customer's own certificate, and link ID resolution uses routing rules rather than URL-based extraction.

Routing rules and certificate matching

AWS highlights an important distinction that customers need to understand when configuring HTTPS inbound external links with custom domains: routing rules and certificate resolution use different matching semantics.

Routing rules apply case-insensitive host matching and follow RFC 6125 single-label wildcard matching. Under this logic, *.example.com matches bid.example.com but does not match a.b.example.com.

Certificate resolution, by contrast, uses case-sensitive host matching with suffix-based wildcard matching. Under this logic, *.example.com may match a.b.example.com. The two systems therefore behave differently for multi-level subdomains, and misconfiguration at this boundary could result in unexpected TLS behaviour or failed routing.

Customers managing HTTPS custom domains should verify that their routing rules and certificate coverage align, and not assume they are equivalent.

Why endpoint migration stalls

To understand why this feature matters for the ad tech market, it helps to think about the structure of RTB partnerships. A demand-side platform or supply-side platform typically maintains connections to dozens or hundreds of counterparties. Each counterparty has hardcoded the DSP or SSP's endpoint URL into their bidding configuration, often alongside allowlists, traffic contracts, and operational runbooks.

When an infrastructure provider asks a DSP or SSP to switch to a new URL format - as adopting RTB Fabric previously required - that request effectively becomes a coordination problem spread across an entire partner graph. No single organization can complete the migration unilaterally. Every connected partner must update their configuration, test the new endpoint, and cut over at or around the same time. In practice, this kind of synchronized migration rarely happens cleanly. Traffic contracts create dependencies. Operational teams prioritize stability. Migration stalls.

According to AWS, the custom domains capability "removes this requirement entirely." Partners continue sending bid requests to the same endpoints. The DNS record changes, Fabric processes the traffic, and no counterparty needs to act.

Sergio Serra, product manager at Amazon AWS, described the significance on LinkedIn: "It decouples infrastructure migration from ecosystem reconfiguration. Customers can move traffic onto RTB Fabric incrementally, without a synchronized cutover, while gaining the benefits of lower-latency routing, simpler integration, and lower networking cost."

Serra also noted: "For a market built on high-QPS systems, hard latency budgets, and years of accumulated integration debt, that is game changing."

Traffic migration options

Beyond the initial CNAME setup, the feature supports gradual traffic shifting. According to AWS, companies can "use weighted DNS routing to shift traffic gradually, or cut over instantly." Because the migration is DNS-driven, there is no interruption to live bid traffic during the transition. AWS describes this as zero-downtime cutover.

Weighted DNS routing is particularly relevant for large-scale deployments. A DSP handling billions of bid requests per day cannot realistically validate a new infrastructure path at full volume from day one. By routing 5% or 10% of traffic to RTB Fabric while the remainder continues through the existing path, engineering teams can monitor latency, error rates, and bid response quality before committing to full cutover.

TLS certificate management

For HTTPS endpoints, customers provide their own TLS certificates through AWS Certificate Manager (ACM). RTB Fabric terminates TLS using the customer's certificate, which means the certificate presented to the partner is the same one the partner already trusts. This preserves trust chains without requiring partners to update their certificate pinning configurations.

The private key is decrypted within the customer's VPC, not exposed to the wider RTB Fabric infrastructure. AWS describes this as customer-managed TLS.

Performance and cost context

AWS RTB Fabric launched in October 2025, introducing a dedicated network for real-time ad bidding with single-digit millisecond latency and up to 80% lower networking costs compared to standard cloud networking. That original announcement covered the service's transaction-based pricing model, its module framework for fraud detection and traffic management, and its initial partner list.

According to AWS, RTB Fabric "helps you connect with your AdTech partners such as Amazon Ads, GumGum, Kargo, MobileFuse, Sovrn, TripleLift, Viant, Yieldmo, and more in three steps while delivering single-digit millisecond latency through a private, high-performance network environment." The service does not require upfront commitments and uses per-billion-transaction pricing.

Custom domain support is available in all AWS Regions where RTB Fabric is supported: US East (N. Virginia), US West (Oregon), Asia Pacific (Singapore), Asia Pacific (Tokyo), Europe (Frankfurt), and Europe (Ireland). Six regions covering the primary programmatic advertising markets in North America, Asia, and Europe.

The 80% cost reduction claim against standard cloud networking is material for SSPs and DSPs that process high query-per-second volumes. PPC Land reported in October 2025 on how AWS's infrastructure strategy extends beyond Amazon's own advertising business, with the cloud division generating $30.9 billion in revenue and $10.2 billion in operating income in a single quarter - roughly 70% of Amazon's total profit at that time.

What full request fidelity means in practice

One detail in the AWS documentation deserves attention: full request fidelity. According to AWS, "the host header, request path, query string, and request body are preserved exactly as sent by the partner."

This matters because many DSP and SSP implementations use the host header or path to route requests internally, identify traffic sources, apply filtering rules, or calculate fees. If Fabric modified any of these fields, it would break downstream logic in ways that might not be immediately obvious during testing. Preserving the original request exactly means that the bidder's application code does not need to change.

Combined with the CNAME-based migration path, this creates a scenario where neither the partner sending the bid request nor the bidder receiving it needs to make any code or configuration changes. The entire migration is handled at the DNS and gateway layer.

Market context for ad tech infrastructure

The programmatic advertising sector has seen ongoing infrastructure consolidation throughout 2024 and 2025. Publishers have deployed bid throttling to address auction inefficiency, with PubMatic having processed 56 trillion impressions in a single quarter at the height of header bidding duplication. The Amazon Prebid adapter reached open beta in January 2026, reflecting Amazon's broader push to reduce infrastructure friction for publishers working within existing Prebid implementations.

More recently, Bedrock became the first DSP to run its bidder inside an exchange, demonstrating how the industry is exploring architectures where decisioning logic moves closer to the impression source. These developments share a common theme: reducing the per-request cost and latency overhead that have historically made programmatic infrastructure expensive to scale.

RTB Fabric's custom domain feature fits within that context. By removing the endpoint migration barrier, AWS lowers the activation threshold for DSPs and SSPs that might otherwise delay adoption because of the coordination cost involved.

The Amazon advertising business crossed $70 billion on a trailing twelve-month basis as of Q1 2026, with RTB Fabric running in production across six AWS regions. For ad tech vendors evaluating cloud infrastructure, the combination of purpose-built RTB networking, transaction-based pricing, and now custom domain support changes the migration calculus meaningfully.

Timeline

Summary

Who: Amazon Web Services, serving advertising technology companies including demand-side platforms and supply-side platforms that process real-time bidding traffic.

What: AWS RTB Fabric today added support for custom domains on inbound external links. The feature lets AdTech companies preserve their existing public bidding endpoints by updating a CNAME record to point their domain to an RTB Fabric Gateway. Partners do not need to update their endpoint configurations. Traffic migrates at the DNS layer, with zero downtime and optional weighted routing for gradual cutover. HTTPS is supported through customer-managed TLS certificates provisioned via ACM, with private key decryption occurring within the customer's VPC. Full request fidelity is preserved: host header, path, query string, and body reach the bidder unchanged.

When: Announced on May 14, 2026.

Where: Available across all six AWS Regions where RTB Fabric is supported - US East (N. Virginia), US West (Oregon), Asia Pacific (Singapore), Asia Pacific (Tokyo), Europe (Frankfurt), and Europe (Ireland).

Why: Adopting RTB Fabric previously required DSPs and SSPs to update their endpoint URLs to Fabric-managed domains, a change that necessitated coordination across entire partner graphs and frequently stalled migrations. Custom domain support removes that barrier by decoupling the public interface from the underlying network path, making it possible for ad tech companies to move traffic onto Fabric incrementally without requiring any action from their partners.

Share this article
The link has been copied!