This Guidance enables supply-side and demand-side platforms to optimize data transfer cost and improve security. When you connect over the AWS PrivateLink service, real-time bidding (RTB) traffic is routed on the AWS backbone network through a private endpoint.
Architecture Diagram
Step 1
When a reader accesses a webpage with an ad impression, an ad request is sent to the Publisher Ad Server.
Step 2
The Publisher Ad Server processes the request and sends it to the endpoint URL provided by the supply-side platform (SSP) to fill the ad impression. The Elastic Load Balancing (ELB) on the SSP’s virtual private cloud (VPC) forwards the request to the Auction Server, which sends out a bid request to endpoint web address (URL) of participating demand-side platforms.
Step 3
The SSP VPC does a DNS lookup with the VPC DNS or the Private Hosted Zone and routes the request either through the interface endpoint or out to the internet.
Step 4
If the DSP is set up with AWS PrivateLink, the bid request is then routed to the endpoint Elastic Network Interface (ENI) in the SSP’s private subnet. The request is then forwarded to the endpoint service on DSP side.
Step 5
The endpoint service then routes the bid request to associated Network Load Balancer (NLB), which load balances the bid request to the Bidder fleet. The Bidder instance will process the request and return a bid response back to the SSP Auction Server. All the requests and responses are routed through the AWS network.
Step 6
In order for demand side platforms (DSPs) to use a private hostname for their endpoint URL, the DSP should verify the domain by creating a TXT record on their DNS. This architecture assumes that DSP uses Amazon Route 53 for DNS.
Step 7
Both the SSP and the DSP can set up Amazon CloudWatch dashboards to gain visibility into active connections and bytes processed per endpoint.
Step 1
When a reader accesses a webpage with an ad impression, an ad request is sent to the Publisher Ad Server.
Step 2
The Publisher Ad Server processes the request and sends it to the endpoint URL provided by the supply-side platform (SSP) to fill the ad impression. The Elastic Load Balancing (ELB) on the SSP’s virtual private cloud (VPC) forwards the request to the Auction Server, which sends out a bid request to endpoint web address (URL) of participating demand-side platforms.
Step 3
The SSP VPC does a DNS lookup with the VPC DNS or the Private Hosted Zone and routes the request either through the interface endpoint or out to the internet.
Step 4
If the DSP is set up with AWS PrivateLink, the bid request is then routed to the endpoint Elastic Network Interface (ENI) in the SSP’s private subnet. The request is then forwarded to the endpoint service on DSP side.
Step 5
The endpoint service then routes the bid request to associated Network Load Balancer (NLB), which load balances the bid request to the Bidder fleet. The Bidder instance will process the request and return a bid response back to the SSP Auction Server. All the requests and responses are routed through the AWS network.
Step 6
In order for demand side platforms (DSPs) to use a private hostname for their endpoint URL, the DSP should verify the domain by creating a TXT record on their DNS. This architecture assumes that DSP uses Amazon Route 53 for DNS.
Step 7
Both the SSP and the DSP can set up Amazon CloudWatch dashboards to gain visibility into active connections and bytes processed per endpoint.
Well-Architected Pillars
The AWS Well-Architected Framework helps you understand the pros and cons of the decisions you make when building systems in the cloud. The six pillars of the Framework allow you to learn architectural best practices for designing and operating reliable, secure, efficient, cost-effective, and sustainable systems. Using the AWS Well-Architected Tool, available at no charge in the AWS Management Console, you can review your workloads against these best practices by answering a set of questions for each pillar.
The architecture diagram above is an example of a Solution created with Well-Architected best practices in mind. To be fully Well-Architected, you should follow as many Well-Architected best practices as possible.
-
Operational ExcellenceRead the Operational Excellence whitepaper
For optimal operational support, we recommend having a secondary route to the internet in case PrivateLink services fail.
-
SecurityRead the Security whitepaper
AdTech customers deploy their programmatic workload on a public subnet to reduce data transfer and NAT Gateway costs. This architecture helps customers move to a private subnet and route the traffic over private endpoints.
-
ReliabilityRead the Reliability whitepaper
This architecture is powered by PrivateLink, which is built on top of AWS Hyperplane, a highly scalable and reliable distributed system used for managing connections that allows PrivateLink to have defined SLAs in place. For more information about PrivateLink and AWS Hyperplane, visit the AWS Blog: Understanding VPC links in Amazon API Gateway private integrations.
-
Performance EfficiencyRead the Performance Efficiency whitepaper
The major component in the architecture is PrivateLink, which is a managed service and is available in all AWS regions. PrivateLink is easy to set up and configure, which helps customers to go global in minutes.
-
Cost OptimizationRead the Cost Optimization whitepaper
Both demand-side (DSP) and supply-side (SSP) customers can save costs by moving to Private Network for AdTech. DSPs will bring their data transfer cost to connected partners to zero and SSP will use PrivateLink tiered pricing.
-
SustainabilityRead the Sustainability whitepaper
PrivateLink is a managed service and AWS managed services shift responsibility for maintaining high average utilization and sustainability optimization of the deployed hardware.
Disclaimer
The sample code; software libraries; command line tools; proofs of concept; templates; or other related technology (including any of the foregoing that are provided by our personnel) is provided to you as AWS Content under the AWS Customer Agreement, or the relevant written agreement between you and AWS (whichever applies). You should not use this AWS Content in your production accounts, or on production or other critical data. You are responsible for testing, securing, and optimizing the AWS Content, such as sample code, as appropriate for production grade use based on your specific quality control practices and standards. Deploying AWS Content may incur AWS charges for creating or using AWS chargeable resources, such as running Amazon EC2 instances or using Amazon S3 storage.
References to third-party services or organizations in this Guidance do not imply an endorsement, sponsorship, or affiliation between Amazon or AWS and the third party. Guidance from AWS is a technical starting point, and you can customize your integration with third-party services when you deploy the architecture.