AEP-heavy enterprise — adopt AEP-as-edge-node over full displacement or status quo
When a large enterprise (typically >$1B revenue, >500K profiles in AEP) has AEP as the incumbent CDP under matrixed IT/Marketing governance, and a cloud data warehouse team has grown organically and is now hitting AEP's export, query, and batch-scheduling guardrails, this recommendation names the middle path between the two extremes the organization is usually weighing.
Why this recommendation exists. archetype.aep-heavy-enterprise-evaluating-composable documents the trigger pattern in detail: egress limits, ad-hoc query timeouts, and batch-activation scheduling congestion are discovered during production scale-up, not anticipated at purchase time. pattern.aep-as-edge-node is the archetype's own stated recommended direction — this node makes that traversal path explicit in the graph and states the tradeoff alongside the alternatives.
What this recommendation is not. It does not recommend ripping out AEP, and it does not recommend ignoring the guardrail friction as a configuration problem. Both of those are the alternatives, not the default. The edge-node pattern is the default because it honors the existing AEP investment (activations, destinations, integrations already built) while moving the data-intensive work to where compute is unconstrained.
Scope limitation. This recommendation assumes a CDW team already exists (tech-dim.dev-team.backend-data-warehouse) — without one, there is no destination for CDW-computed audiences and the edge-node pattern has nothing to move work to. Organizations without a CDW team should first evaluate whether an enterprise packaged CDP replacement or continued AEP-only operation is the realistic near-term path.