What I Wish I Had Known Before Our First AEP on AWS Deployment — Summit AMA Recap

Full session transcript — AEP on AWS, Summit 2025 AMA

The complete session, for those who want the full context behind the three takeaways in the post above.

Setting the Stage

When we set out to onboard onto Adobe Experience Platform, the expectation was that it would behave like any standard cloud deployment. What we found was that AEP’s defaults — around networking patterns, identity models, and tooling integration — had been designed and tested on a specific cloud environment. Those assumptions were not documented as cloud-specific. They were discovered operationally, during a design review six weeks into the project, not in a test environment.

What sharpened the challenge was that we had no option for sequential delivery. Real-Time CDP and Customer Journey Analytics had to go live concurrently. Every foundational decision — schema design, identity resolution, data integration patterns — had to be sound for two production surfaces at the same time, while internal tooling teams, platform teams, and the platform itself were all operating under different assumptions. Nobody was wrong. Everyone was optimizing for their own system. That was precisely the complication: misaligned incentives and undocumented assumptions compounding on each other.

What Resolved It

Data Contracts. Before we ran the first pipeline, we had a formal agreement between every source system and the platform — what data would arrive, at what frequency, in what schema, on what schedule, and who owned it if something broke. Not a Slack message. A documented agreement with named accountable owners. This single artifact prevented more escalations than anything else we put in place.

Stakeholder Alignment Before Engineering. For every use case, we established a shared definition of done before engineering started. Marketing, engineering, legal, and analytics aligned on what a complete customer profile meant for each of them. That meeting sounds obvious. Almost no one has it before they need to, and by then it costs significantly more to reach alignment than it would have at the outset.

Governance From Day One. Access control, consent architecture, and data classification were designed as part of the schema from the outset — not added retroactively. Retrofitting governance into a live production platform is one of the most expensive and disruptive things a team can do. The cost does not scale linearly with the size of the gap; it compounds with every downstream system built on top of ungoverned data.

Core Takeaways

• Data contracts are not a formality — they are your immune system. Schema decisions made under pressure after go-live cost significantly more than the same decisions at the design stage.
• AEP onboarding is not a technology problem — it is an alignment problem. The teams that succeed bring marketing, engineering, legal, analytics, and data security teams together before a single architecture decision is made.
• Real-Time CDP and CJA are only as trustworthy as the data quality layer underneath. Build that layer first.

*All opinions expressed are my own and not affiliated to current or past employers.

→ Five audience questions and my full answers in the reply below.

Full Q&A — five audience questions answered

These are the questions that came from the room during the AMA, with complete answers. The live session had to move quickly; I’ve expanded a few responses here to give them the space they deserve.

Q: What was the reasoning behind deploying AEP on AWS?

Moving data to a different cloud environment requires transformation at every integration point. That isn’t just a performance consideration it introduces latency, multiplies failure surfaces, and increases the operational burden on every team that touches the pipeline. The real question was: do we build a Adobe experience platform within AWS infrastructure, or do we translate everything into a foreign environment?

Q: You mentioned schema decisions cost significantly more after deployment. What were the most painful downstream implications?

Even before we were close to our go-live deadline, data requirements surfaced that hadn’t been fully scoped during the design phase. The schema change itself wasn’t catastrophic in isolation. But it reveals a structural truth about AEP that every team should understand before they start: once a schema is published and received data, it cannot be deleted. It can only be managed around. The real cost isn’t the schema change — it’s the re-alignment across every downstream team, tool, and process that was built against the earlier version. That re-alignment is what takes the time and erodes trust in the data.

Q: As a practitioner, would you feel the difference between running AEP on AWS versus another cloud?

You don’t fully know until you’re operating it. But once you are, the differences are practical and real. When your data infrastructure, identity services, and tooling are all on the same cloud, integration points are tighter. Real-time data flows more fluidly. Latency across service boundaries is lower. Signals are less likely to be dropped or delayed at the seams between systems. There’s also a maturity dimension worth noting: a platform deployment that benefits from lessons learned on an earlier rollout arrives with fewer unresolved operational challenges. Patterns that caused friction in an earlier generation have already been identified and addressed. For teams already deeply invested in a AWS cloud ecosystem, staying on that ecosystem for the platform layer has measurable operational benefits — it is not just a convenience.

Q: With agentic AI and orchestration capabilities announced at the keynote, how are you thinking about that direction on AWS going forward?

The agentic AI and orchestration capabilities that were announced last year are now available. The convergence of the AI layer with the customer data platform layer is something we’re actively watching and excited about.

Q: What are your goals for the AEP platform over the next three to six months?

For the next six months, the primary goal is value realization. Proving out the impact and build the case for what comes next. That’s the measure of success for this phase.

*All opinions expressed are my own and not affiliated to current or past employers.

This is awesome! Thank you for sharing so generously with the Community ❤️