How Axel Springer transformed ad monetization by migrating from client-side bidding to AWS RTB Fabric

Axel Springer is a family-owned transatlantic media company focused on publishing (including BILD, BUSINESS INSIDER, POLITICO, and WELT) and commerce (including Idealo, Bonial, and Awin). Axel Springer aims to become the leading provider of digital and AI-supported journalism in the free world. Axel Springer Tech is the company’s technology organization, building and operating technology products and platforms for Axel Springer’s global portfolio of digital brands. Its advertising technology teams process billions of bid requests per month across this portfolio, a scale that requires low-latency infrastructure, operational resilience, and a continuous focus on yield optimization.

In 2025, Axel Springer began evolving its programmatic advertising infrastructure to gain greater flexibility, scalability, and control over its monetization stack. As part of this transformation, the company introduced a self-hosted Prebid Server on AWS, complementing its existing header bidding setup and creating a foundation for faster experimentation, deeper infrastructure ownership, and future AI-powered optimization. Following this migration, Axel Springer became the first publisher to adopt AWS RTB Fabric.

This post walks through the motivation, architecture, and results of that transformation.

The challenge: Client-side bidding at scale

Like many large publishers, Axel Springer originally monetized its digital inventory through client-side header bidding. In this model, the user’s browser executes JavaScript adapters that call multiple supply side platforms (SSPs) and demand side platforms (DSPs) in parallel before the primary ad server makes its final decision.

While effective at smaller scales, client-side bidding introduced several pain points as Axel Springer’s traffic grew:

• Latency and user experience – Each adapter added milliseconds to page load. On mobile web and especially in-app environments (where client-side header bidding isn’t natively supported), the approach was limiting.
• Limited auction participation – Browsers impose connection limits and timeout constraints, capping the number of demand partners that can realistically compete in each auction.
• Lack of transparency and control – The company relied on external Prebid Server technologies for its server-side component, paying a revenue fee with limited ability to customize auction logic, implement dynamic floor pricing, or influence the server-side configuration in any way.
• No in-app native prebid for header bidding – Client-side header bidding is only feasible using a server-side intermediary.

Phase 1: Self-hosted Prebid Server on AWS

The first step was to deploy an open source Prebid Server instance on Amazon Web Services (AWS) infrastructure, giving Axel Springer full control over bidder configuration, auction logic, and deployment cadence.

Architecture

Key design decisions

Rather than re-platforming everything at once, the team made targeted choices that kept risk low and delivery fast:

• Hybrid deployment (AWS plus third-party CDN) – The team maintained the third-party CDN for ad creative delivery while routing all bid orchestration through AWS – allowing a phased migration without disrupting live traffic.
• Dynamic configuration without redeployment – Prebid Server allows for dynamic configuration changes through deploying config files to Amazon Simple Storage Service (Amazon S3), which get imported without having to restart the server
• Two-week delivery – By using AWS CDK templates and the open source Prebid Server Go implementation, the team achieved a working hybrid deployment in only two weeks.

Results (Phase 1)

• Revenue parity achieved immediately – Prebid Server on AWS matched or exceeded the previous managed server-side bidding setup from day one of A/B testing.
• Cost efficiency maintained – The infrastructure cost of the self-hosted Prebid Server on AWS was comparable to the previous managed setup, while providing greater technical flexibility and infrastructure ownership.
• Increased technical ownership – Enabling faster experimentation with auction logic, bidder configurations, and future optimization approaches.

Phase 2: Adopting AWS RTB Fabric

With Prebid Server running on AWS, the natural next step was to use AWS RTB Fabric, a purpose-built, private network for real-time bidding workloads that delivers single-digit millisecond latency between bidding partners with up to 80% savings compared to standard cloud networking costs.

Why RTB Fabric?

Traditional server-side bidding routes bid requests over the public internet, introducing variable latency, packet loss, and high data transfer costs at scale. For a publisher processing billions of requests per month, even small inefficiencies compound dramatically.

AWS RTB Fabric addresses this by providing:

• Dedicated, low-latency network paths between SSPs and DSPs – Enabling more bidders to respond within timeout windows, increasing auction pressure and yield.
• Up to 80% savings compared to standard cloud networking costs without the need for upfront commitments – Critical at Axel Springer’s request volumes.
• OpenRTB-native communication – Bidirectional request-response model supporting standard OpenRTB protocols without application changes.
• Inline optimization modules – Including rate limiter, OpenRTB filter, and error masking to help you protect RTB workloads and improve operational efficiency.

Integration architecture

Figure 1: Phase 2 integration architecture

Integration challenges

The primary operational challenge was bidder onboarding—obtaining credentials, endpoints, and technical specifications from each demand partner to route traffic through RTB Fabric rather than the public internet. This process often took multiple days per bidder, requiring coordination across different teams and time zones.

Results (Phase 2)

Whats’ next: AI-powered monetization

With the infrastructure foundation in place, Axel Springer is now building the next generation of its monetization stack around a hybrid model: combining Prebid Client and Prebid Server depending on the environment, use case, and performance requirements.

Client-side Prebid remains an important revenue driver across Axel Springer’s web inventory and continues to provide strong demand access and auction pressure. At the same time, server-side bidding becomes increasingly important in environments where latency, scalability, and control are critical, especially in mobile web, app, and high-performance ad experiences where every millisecond matters.

Rather than replacing one model with the other, Axel Springer’s strategy is to bring both worlds together: using Prebid Client where it creates incremental value, and Prebid Server with RTB Fabric where speed, reliability, and deeper infrastructure control deliver the strongest advantage.

On top of this hybrid foundation, Axel Springer is exploring how AI-powered optimization could further improve its monetization stack in the future.

Potential areas of innovation include dynamic floor pricing, smarter demand routing, and more intelligent bid request management. These capabilities could help publishers make more data-driven decisions about which partners to call, how to balance latency and auction pressure, and how to optimize yield without increasing operational complexity.

In addition, the flexibility of Prebid Server and RTB Fabric creates opportunities to evaluate more customized optimization logic over time, for example around routing, filtering, throttling, and decisioning, while keeping the publisher in control of its infrastructure strategy.

Lessons learned

• Start with ownership, not perfection – Deploying your own Prebid Server, even without every optimization, immediately unlocks experimentation velocity that managed solutions cannot match.
• Prove revenue parity first – The team ran rigorous A/B tests comparing their self-hosted stack against the incumbent before scaling.
• Bidder onboarding is the bottleneck – The technology migration is fast; the partner ecosystem coordination is slow. Start bidder communication early.
• RTB Fabric is complementary, not a replacement – RTB Fabric optimizes the network layer between your Prebid Server and demand partners—your auction logic remains fully in your control.
• Plan for AI from day one: Designing the stack with dynamic configuration and real-time data pipelines makes it straightforward to layer ML-powered optimizations later.

Getting started

• Evaluate your current vendor fees – Revenue-share models compound quickly at scale.
• Deploy Prebid Server on AWS – The open source Go implementation runs well on Amazon ECS Fargate with auto-scaling.
• Connect to AWS RTB Fabric – Request access to the private network for immediate latency and cost benefits.
• Instrument everything – Use CloudWatch and your BI tools to establish baselines before and after each change.
• Engage AWS Solutions Architects – our AdTech specialists can help design your target architecture and accelerate bidder onboarding.