A governed traveler-memory platform, ready for its first enterprise deployment

The customer’s product compiles governed traveler profiles from a stream of interaction events — and intends to serve enterprise travel partners such as hotel groups and large online travel agencies, an audience with exacting expectations for data compliance. That puts the platform squarely under the EU AI Act and GDPR before its first production event: every piece of traveler data must be deletable on request, every AI access to that data must be authorized against explicit policy, and an immutable audit trail must survive even the deletions. The proof-of-concept proved the product idea, but it ran in the application partner’s own environment, with none of this governance in place.

The company needed a production-grade AWS architecture designed around those obligations, and the cloud infrastructure built so its application partner’s code could land inside a governed environment — with cost behavior understood at the scale of its ambition, which is traveler profiles at consumer-internet volume.

VeUP ran the work in two phases. Phase 0 was architecture alignment: VeUP proposed the platform architecture, walked it with the customer and its application-development partner, and reconciled it with the partner’s in-flight sprints so their code has a defined landing zone. Phase 1, in delivery since June 2026 on a standing standup cadence, is the build: VeUP is standing the architecture up as infrastructure-as-code, with pull-request review, while the partner’s proof-of-concept components migrate out of ad-hoc accounts into the governed environment.

The customer’s incoming product leadership walked the full architecture end-to-end in July 2026 and accepted it — describing it as clean and easy to digest, which matters for a platform that will be reviewed by enterprise partners’ compliance teams as much as by engineers.

Ingress.Events enter through AWS WAF and AWS Shield behind an Application Load Balancer, authenticate through Amazon Cognito, and are routed by an Amazon ECS (AWS Fargate) service into Amazon Kinesis Data Streams. Cognito was a deliberate cost call: at the platform’s intended scale, per-user-priced third-party authentication would dominate the bill.

Two processing branches. From Kinesis, processing splits by purpose. Branch one sends raw logs, analytics events, and other immutable operational records through Amazon Data Firehose into Amazon S3 — the compliance spine, queryable for audit through Amazon Athena. Branch two feeds ECS Fargate compiler workers — the AI-extraction layer that builds governed traveler profiles in Amazon Aurora — with every AI access to data checked against AWS Verified Permissions before it happens. Amazon SQS bridges the two branches, so immutable records can be promoted into profile fields later without re-architecting.

Deletion without losing the audit trail. Deletion requests are honored by crypto-shredding: AWS KMS keys are scoped per domain and partner, combined with a per-record salted hash, so any individual data asset can be made permanently inaccessible while the immutable record set required for compliance is retained.

A policy control plane.Authorization policy lives in AWS Verified Permissions, written in the Cedar policy language. Policy managers and compliance optimizers make changes through AWS Lambda triggers — trigger-shaped work priced as triggers, not as always-on containers — and every policy change lands in an audit trail recording who changed what, and when. Partner-specific rules layer on top without touching the platform’s base compliance policies.