AWS deployment: architecture
Personalisation Hub runs as a set of microservices on Amazon EKS inside your own AWS account, with managed AWS services for data, messaging, search and encryption. This page describes the parts and why the platform is built this way.
The Installation Wizard
The CloudFormation template you launch from AWS Marketplace creates a small EC2 instance that hosts the Installation Wizard. The wizard is a one-step deployer: once you have created the Master Admin account and chosen the environment type, size and platform domain, it provisions the complete platform stack into your AWS account using Terraform. The same wizard later serves the Cost Control settings page.
Platform components
The platform is modular and distributed, so each component can scale independently.
| Component | What it does |
|---|---|
| Auth API | User authentication, roles and permissions |
| Campaign Mobile and Campaign API | Access to the campaign repository, with localisation and personalisation by store, display and visitor |
| Retail Admin | Store staff view and update retail data, control localised campaign playback, and manage queues and appointments |
| HQ Admin | Head-office management of localised and personalised campaigns across all stores, displays and devices, including hardware, software/CMS, third-party integrations and visitor identification |
| Store Queuing | Lets customers join a queue and surfaces integrated customer data to retail staff |
| JCR | Integration layer to Adobe Experience Manager through Java Content Repository APIs |
| Location API | Localised data for refining campaign targeting; hosts the Visitor API for customer data matching |
| MIST | Proximity-based targeting inside the store |
| Background Task | Daemon service for background jobs and scheduling |
| Monitoring Tools | Prometheus and Grafana for issue detection and performance monitoring |
| Location Toolkit | Receives campaign playback data from displays; provides performance reporting and issue alerts |
| Squid proxy | Outbound communication with external parties |
| Adobe Experience Manager | AEM content and interactions, where AEM is in use |
AWS services used
| Service | Role in the platform |
|---|---|
| Amazon EKS | Runs the Kubernetes clusters that host the components |
| Amazon RDS | PostgreSQL databases |
| Amazon S3 | Platform data and assets |
| AWS KMS | Encryption keys for data at rest |
| Amazon ElastiCache for Redis | Caching for platform performance |
| Amazon MSK | Kafka for high-volume, real-time data streams |
| Amazon SNS | Email and SMS messaging |
| Amazon OpenSearch Service | Scalable search for logging and monitoring |
Why Kubernetes on EKS
Running the platform on a managed Kubernetes service shapes most of its operational characteristics:
- Less cluster management. EKS abstracts the Kubernetes control plane, so operation focuses on the application rather than the cluster.
- Scaling and availability. Worker nodes and pods scale automatically with demand, which also keeps cost in line with usage.
- Native AWS integration. The cluster works directly with EC2, Elastic Load Balancing, RDS, S3 and the other services in the table.
- Security and compliance. IAM integration, network isolation in a VPC, encryption, audit logging and CloudTrail integration come from the AWS platform itself.
- Portability. Standard Kubernetes APIs mean workloads can move between environments.
- Automated deployment. Containerised components support CI/CD-style automated deployment.
Related
Last updated 15 September 2026
