This guidance shows best practices for building a customer data platform covering customer data on AWS from a broad range of sources – including contact centers, email, web/mobile entries, point of sale (POS) systems, customer relationship management (CRM) systems and social media. It explores each stage of building the platform and covers data ingestion, identity resolution, segmentation, analysis and activation.

Architecture Diagram

Disclaimer: Not for production use

Download PDF 

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.

  • Multiple approaches are often required for optimal performance across a workload. Well-Architected systems use multiple solutions and features to improve performance. This layered component-oriented architecture shown in this guidance allows you to build each layer independently using infrastructure as code. By separating the ingestion, processing, storage, unified governance, cataloging, and consumption, the modules in it can be more easily tested and deployed. In addition, each layer can have defined response procedures and organized game days focused on practicing runbooks and applying lessons learned. Observability is built in with process level metrics, logs and dashboards. Customize these mechanisms to your needs, and create alarms in Amazon CloudWatch to inform your on-call team on any issues.

    Read the Operational Excellence whitepaper 
  • The Security and Governance layer is responsible for providing mechanisms for access control, encryption, auditing and data privacy. Using AWS Key Management Service (AWS KMS), data is persisted in an encrypted format to protect it from unauthorized access. AWS Lake Formation applies central audited governance, fine-grained access controls, and data classification tagging - enabling you to secure data at the object, database, table, column, and row-level.

    Read the Security whitepaper 
  • Each architecture layer can be independently monitored with Amazon CloudWatch key performance indicators (KPIs) using Amazon CloudWatch with automated resolution using services such as Amazon EventBridge. In addition, serverless services such as AWS Glue and Amazon DynamoDB scale horizontally, automatically responding to the velocity of data ingestion and processing. Finally, with a siloed isolation tenant architecture, you can also deploy tenant-specific resources to reduce the impact of a single failure.

    Read the Reliability whitepaper 
  • Using serverless technologies, you only provision the exact resources you use. The serverless architecture reduces the amount of underlying infrastructure you need to manage, allowing you to focus on onboarding new customers and building new product feature enhancements. You can use automated deployments to deploy the isolated CDP tenants into any region quickly - providing data residence and reduced latency. In addition, you can experiment and test each CDP layer, enabling you to perform comparative testing against varying load levels, configurations, and services.

    Read the Performance Efficiency 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 Amazon Glue is performing data transformations, you only pay for infrastructure during the time the processing is occurring. In addition, through a tenant isolation model and resource tagging, you can automate cost usage alerts and measure costs specific to each tenant, application module, and service.

    Read the Cost Optimization whitepaper 
  • By extensively using serverless services, you maximize overall resource utilization - as compute is only used as needed. The efficient use of serverless resources reduces the overall energy required to operate the workload. You can also use the AWS Billing Conductor carbon footprint tool to calculate and track the environmental impact of the workload over time at an account, region, and service level.

    Read the Sustainability whitepaper 
AWS Architecture

A modern approach to implementing the serverless Customer Data Platform

When building a Customer Data Platform (CDP), advertising and marketing Independent Software Vendors (ISVs) face a unique set of challenges. The ISV can help organizations with the heavy lifting required to build, secure, and maintain near real-time, high volume CDPs. However, architecting CDPs using traditional on-premises technologies can introduce multiple complexities and can limit deployment options. 
This post demonstrates how one strategy that may address these complexities is to use serverless technologies.
Read the full blog post 
AWS Architecture

An overview and architecture of building a Customer Data Platform on AWS

The deprecation of digital consumer identifiers, such as third-party cookies and mobile advertising IDs, and the rapid growth of data from expanding consumer touchpoints, has created challenges in identifying, managing, and reaching customers in digital channels. Organizations must rethink their strategies for collecting and storing customer data. 
This post demonstrates how Customer Data Platforms (CDPs) collect, aggregate, and organize customer data sources, and create individual centralized customer profiles to better manage and understand customers.
Read the full blog post 


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.