This Guidance demonstrates how AWS Clean Rooms can help marketers and data engineers upload audiences on the Meta Business Marketing suite. AWS Clean Rooms can help collect data from various providers and match it against first party data in a fast, privacy-compliant manner. AWS Clean Rooms allows this to be done with minimum data movement.
Architecture Diagram
Step 1
AWS Clean Rooms query UI is used to generate a data export for uploading.
Step 2
Output files are stored in a dedicated Amazon Simple Storage Service (Amazon S3) bucket.
Step 3
If more data transformation/ normalization is needed post export query, it is done through an AWS Glue job.
Step 4
Output of the AWS Glue job is written to a different bucket. Multiple files are written for downstream processing to occur in chunks.
Step 5
An AWS EventBridge rule created on the Default event bus to respond to the object create event.
Step 6
AWS Lambda function is initiated by the EventBridge rule.
Step 7
Lambda function accesses the AWS Secrets Manager service to fetch access tokens.
Step 8
Lambda function reads the files and publish data rows to Meta Business marketing API. Lambda function uses Facebook Business SDK for integration.
Step 1
AWS Clean Rooms query UI is used to generate a data export for uploading.
Step 2
Output files are stored in a dedicated Amazon Simple Storage Service (Amazon S3) bucket.
Step 3
If more data transformation/ normalization is needed post export query, it is done through an AWS Glue job.
Step 4
Output of the AWS Glue job is written to a different bucket. Multiple files are written for downstream processing to occur in chunks.
Step 5
An AWS EventBridge rule created on the Default event bus to respond to the object create event.
Step 6
AWS Lambda function is initiated by the EventBridge rule.
Step 7
Lambda function accesses the AWS Secrets Manager service to fetch access tokens.
Step 8
Lambda function reads the files and publish data rows to Meta Business marketing API. Lambda function uses Facebook Business SDK for integration.
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
To help businesses perform at their best, observability is built-in, with every service sending metrics to Amazon CloudWatch, where dashboards and alarms can be set up.
-
SecurityRead the Security whitepaper
AWS Identity and Access Management (IAM) policies are created using the least-privilege access so that every policy is restricted to the specific resource and operation. Secrets and configuration items are centrally managed and secured using the AWS Key Management Service (AWS KMS) keys. The data at rest in an Amazon S3 bucket is encrypted using the AWS KMS keys. The data in transit into the Meta API is encrypted and transferred over HTTPS. Sensitive data in the payload is SHA-256 encrypted at the attribute level.
-
ReliabilityRead the Reliability whitepaper
Each architecture layer uses services and technologies that are serverless and fully managed by AWS. This makes the architecture elastic, highly available, and fault-tolerant. The solution provides mechanisms to process data in chunks to avoid reaching API limits, memory constraints, and performance time limits. The event-driven architecture uses Message Bus to decouple components. Observability is built in; every service publishes metrics to CloudWatch, where dashboards and alarms can be set up. This solution is built with a multi-tier architecture, so each tier can be scaled, deployed, and tested alone. Dead-letter queues allow for investigations into Lambda performance issues. The EventBridge Message bus implementation includes an archive for replaying events in case of failures.
-
Performance EfficiencyRead the Performance Efficiency whitepaper
The serverless architecture reduces the amount of underlying infrastructure you need to manage, allowing you to focus on solving your business needs. You can use automated deployments to quickly deploy the solution components into any region, which will keep the data in that region and reduce the latency. In addition, you can experiment and test each solution component, enabling you to perform comparative testing against varying load levels, configurations, and services. All components of the solution are collocated in a single region and uses a serverless stack that avoids the need for you to make infrastructure location decisions apart from the region choice.
-
Cost OptimizationRead the Cost Optimization whitepaper
Using serverless technologies, you only pay for the resources you consume. As the data ingestion velocity increases and decreases, the costs will align with usage. When AWS Glue is performing data transformations, you only pay for the infrastructure while the processing is occurring. In addition, through a tenant solution model and resource tagging, you can automate cost usage alerts and measure costs specific to each tenant, application module, and service. All components of the solution use serverless services, which ensures that minimum resources are used.
-
SustainabilityRead the Sustainability whitepaper
By using serverless services extensively, you can maximize overall resource utilization because compute will be used only when it's needed. The efficient use of serverless resources reduces the overall energy required to operate the workload. You can also use the AWS Customer Carbon Footprint Tool to calculate and track the environmental impact of the workload over time at any account, region, and service level.
Implementation Resources
A detailed guide is provided to experiment and use within your AWS account. Each stage of building the Guidance, including deployment, usage, and cleanup, is examined to prepare it for deployment.
The sample code is a starting point. It is industry validated, prescriptive but not definitive, and a peek under the hood to help you begin.
Related Content
[Title]
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.
Meta and Facebook are trademarks of Meta Platforms, Inc. or its affiliates.
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.