Build a digital assets exchange on AWS: A reference architecture

This post presents a reference architecture for a centralized digital assets exchange (CEX) on AWS. Rather than documenting a single customer journey, it aggregates the architectural decisions that recurred across CEX deployments that AWS Solutions Architects have supported in the field. We show how the stack fits together on Amazon Elastic Kubernetes Service (Amazon EKS), Amazon Elastic Compute Cloud (Amazon EC2), and Amazon Aurora, and explain the rationale behind each component choice.

For migration mechanics such as AWS Transform MGN (formerly AWS Application Migration Service), AWS Database Migration Service (AWS DMS), testing, and cutover, see Migrate centralized crypto exchange workloads to AWS – Part 1 and Part 2.

Common challenges when running a centralized digital assets exchange

Exchange operators typically face four challenges. Self-managed infrastructure consumes engineering capacity that could go to product work. Data sovereignty and audit requirements call for controls that keep data in defined jurisdictions and produce durable, queryable audit trails. Growing trading volumes require infrastructure that scales without losing low-latency performance. And digital asset custody demands a strong security posture.

Reference architecture for a centralized digital assets exchange on AWS

Figures 1 and 2 show the reference architecture. It reflects decisions we validated across multiple production deployments.

AWS organization structure

A multi-account structure in AWS Organizations, following AWS best practices for account separation and governance, sets clear boundaries between environments and workload types.

Figure 1: Recommended AWS organization structure for a CEX

We recommend the following organizational units (OUs):

• Control Panel OU – delegated administrator for organization-wide services such as AWS CloudTrail, Amazon GuardDuty, and AWS Security Hub CSPM.
• Production OU – all production systems, with separate accounts for trading engine services, data, and wallets.
• Staging OU – mirrors Production for testing and validation.
• Continuous integration and continuous delivery (CI/CD) OU – DevOps pipeline tooling.

AWS Control Tower standardizes account creation and governance, service control policies (SCPs) enforce security and compliance requirements centrally, and AWS CloudTrail logs activity across all accounts. The separation also simplifies cost allocation across environments.

Production architecture overview

Figure 2 shows the production architecture.

Figure 2: Reference production architecture for a CEX on AWS

Diagram conventions: solid arrows indicate data and control flows. Dashed arrows indicate cross-account Amazon Virtual Private Cloud (Amazon VPC) peering, asynchronous flows, and audit flows. The bold dashed border marks the low-latency Amazon EC2 cluster placement group. Arrows labeled ZeroMQ indicate brokerless messaging.

High availability for each layer

In a latency-sensitive exchange, you don’t achieve high availability by stretching every layer across Availability Zones. The matching-engine hot path—client gateways, the sequencer, and the risk and matching engine—runs in one Availability Zone, inside one cluster placement group, because round trips between Availability Zones (AZs) add latency that sub-millisecond matching can’t absorb. Within that zone, the matching engine runs as a replicated cluster (for example, three nodes using Raft), so a single instance failure doesn’t stop trading. A planned Multi-AZ recovery layer covers zone failure: durable state (write-ahead logs, trade and settlement records) replicates continuously to a second Availability Zone, where a warm standby is ready for promotion. Systems that tolerate higher latency—surveillance, custody, the web platform, post-trade analytics, and deployment automation—run Multi-AZ by default. Design the recovery layer against explicit Recovery Time Objective (RTO) and Recovery Point Objective (RPO) targets, which make the trade-off visible: how much data you can lose at failover versus how quickly the matching engine must recover.

Identity and authentication

An Application Load Balancer offloads retail user authentication to Amazon Cognito, which handles sign-in, multi-factor authentication, and sessions for the web and API tier on Amazon EKS. Institutional clients using the Financial Information eXchange (FIX) or binary protocols bypass Amazon Cognito and authenticate at the client gateway with mutual TLS and signed session tokens, the convention for latency-sensitive trading connectivity.

Core trading infrastructure

The web platform, order management, and other trading microservices run on Amazon EKS for efficient resource use and scaling. The risk and matching engine runs on dedicated Amazon EC2 instances, which removes Kubernetes orchestration overhead and gives the engine all available compute and memory.

Place the client gateway and the matching engine in the same cluster placement group and connect them with a brokerless messaging library. ZeroMQ is a common choice because it avoids the latency of an intermediate broker. For the lowest and most predictable tail latency, purpose-built transports such as Aeron are a common step up, and shared-memory libraries such as Chronicle Queue suit intra-host communication. An AWS prototype using ZeroMQ measured round trips of 55–124 microseconds at the median and 75–157 microseconds at p99, including simulated matching logic. More recent benchmarks show open-source Aeron transport round trips of 32–84 microseconds at p99, or 29–39 microseconds with Aeron Premium using kernel bypass through the Data Plane Development Kit (DPDK). For Amazon EC2 instance selection, co-location strategies, and timing precision, see Optimize tick-to-trade latency for digital assets exchanges and trading platforms on AWS Part 1 and Part 2.

Order management runs on Amazon EKS outside the cluster placement group. Retail orders already cross the internet, so the extra hop is negligible, and Amazon EKS gives order management elastic scaling, rolling deployments, and integration with databases, KYC providers, and custody. It forwards retail orders to the client gateway over ZeroMQ, with no load balancer in between. Latency-sensitive clients connect directly to the gateway over FIX or a binary protocol, through an Network Load Balancer (NLB) or Direct Connect. With pre-trade risk enforced inside the placement group, their orders go straight to matching without passing through order management. Execution reports return to order management asynchronously, keeping it the system of record. Every order, retail or institutional, passes through the client gateway to a single sequencer in front of the matching engine, so all orders share one deterministic sequence.

High-performance data layer

The data layer uses purpose-built stores:

• Amazon Aurora PostgreSQL-Compatible Edition is the primary transactional database for user accounts, trade history, and settlement records, with up to six times the throughput of stock PostgreSQL and automated Multi-AZ failover. Where single-digit-millisecond key-value access at scale dominates, Amazon DynamoDB is an alternative, as described in Part 1 of the migration series.
• Amazon ElastiCache for Valkey holds order book snapshots and session data, and fans out market data to downstream consumers. Keep it off the gateway-to-matching-engine path: in the AWS low-latency exchange prototype, a broker on that path added significant p99 latency.
• Amazon Managed Streaming for Apache Kafka (Amazon MSK) is the durable event backbone for trade, order, and settlement events and for replication to analytics. Kafka’s durability, per-partition ordering, and long retention support audit trails, replay, and disaster recovery. With careful tuning, Kafka also meets trading-grade latency: a Tier-1 bank working with Confluent reported sub-5 ms p99 at 1.6 million messages per second.
• kdb Insights is a columnar time-series store for historical tick analytics such as backtesting, market surveillance, and transaction cost analysis (TCA). It’s available as a subscription in AWS Marketplace, and you deploy it onto Amazon EKS or Amazon EC2. ClickHouse is a common open-source alternative, self-managed on Amazon EC2 or with subscription through AWS Marketplace.
• Amazon Simple Storage Service (Amazon S3) stores trade archives, compliance records, and the data lake for post-trade analytics.

Post-trade analytics

Post-trade analytics runs off the hot path against the Amazon S3 data lake, following the pattern in Part 1 of the migration series. AWS Glue catalogs trade, order, and settlement data landed from Aurora and Amazon MSK, and Amazon Athena queries it for on-demand and regulatory reporting. Some teams add a data warehouse such as Amazon Redshift for deeper analysis.

Secure digital asset management (wallet and custody)

Custody carries the tightest security requirements in the architecture, because a compromised signing key is an unrecoverable loss. AWS Nitro Enclaves run sensitive cryptographic operations in an isolated environment and provide cryptographic attestation, so you can verify the code running in the enclave. Combine attestation with AWS Key Management Service (AWS KMS): specify the enclave’s Platform Configuration Register (PCR) measurements, and AWS KMS permits decrypt operations only for that enclave.

For multi-party computation (MPC) wallets, you can integrate the Fireblocks cosigner, which distributes private key shards across multiple secure locations. On AWS, operations on those shards run inside Nitro Enclaves, so shard material isn’t exposed to the parent instance, its operating system, or operators.

Many operators also place wallet applications in a dedicated AWS account for tighter access control and separation of duties. Other accounts typically connect through AWS PrivateLink rather than VPC peering, which adds access control through endpoint policies and the endpoint service’s allowed principals.

Blockchain nodes for deposits and withdrawals

Deposit monitoring and withdrawal broadcast need access to public blockchain networks. Two patterns are common, and exchanges often mix them per chain.

Self-managed nodes on Amazon EC2 or Amazon EKS, often mixing x86 and AWS Graviton processors for cost efficiency, give full control over client versions, peering, and remote procedure call (RPC) latency. Exchanges with meaningful deposit and withdrawal volumes usually choose this pattern, and AWS Blockchain Node Runners provides reference implementations for major networks. Managed providers such as Alchemy, QuickNode, or Kaleido, reached over HTTPS through a NAT gateway, remove node operations in exchange for per-request cost and a dependency on the provider. They’re a common starting point for newer exchanges and for low-volume chains.

Network architecture and connectivity

Amazon VPC peering connects the service and data environments with minimal latency impact. Part 1 of the migration series uses AWS Transit Gateway for general multi-network connectivity, but the matching-engine hot path uses VPC peering to avoid Transit Gateway’s extra routing stage. Outbound traffic to external services goes through a NAT gateway, and inbound retail traffic arrives through Elastic Load Balancing over HTTPS, WebSocket.

External partner connectivity (market makers and liquidity providers)

Market makers (MMs) and liquidity providers are the liquidity backbone of the exchange. They’re known, contract-bound partners running high-frequency strategies, and they expect dedicated, deterministic, low-latency connectivity rather than shared internet paths. The following options cover the range of MM deployment profiles.

With a shared cluster placement group, MM sessions connect directly to the client gateway and skip the NLB used for institutional FIX clients. In AWS testing with One Trading, this topology was 41% faster at p99 than VPC peering without a shared placement group. MMs authenticate with mutual TLS (mTLS) using pinned client certificates provisioned at onboarding. Because placement groups narrow the available capacity pool, reserve capacity with On-Demand Capacity Reservations.

Choosing a connectivity option

Which options an MM can use depends on how the exchange has built its network and on its onboarding policy, so confirm early. For AWS Direct Connect, check circuit options, port speeds, and lead times with an AWS Direct Connect Partner at the colocation facility.

Security, monitoring, and observability

Amazon CloudWatch collects infrastructure and application metrics and logs, with custom dashboards for trading metrics. Amazon GuardDuty detects threats, and AWS Security Hub CSPM centralizes security findings.

Scalability and performance optimization

Amazon EKS scales microservices with the Kubernetes Horizontal Pod Autoscaler, Amazon EC2 Auto Scaling manages compute capacity, and Aurora Replicas scale reads for analytical queries without affecting transactional performance.

Conclusion

In this post, we presented a reference architecture for a centralized digital assets exchange on AWS, built from patterns we validated across production deployments. Its core principle is matching each component’s platform to its latency needs: Amazon EKS for microservices, and dedicated Amazon EC2 instances for the matching engine.Across these deployments, the decisions that most often separated a smooth launch from a troubled one were trade-offs rather than individual service choices, and above all is the choice between matching-engine latency versus availability. The most latency-focused teams treated the single-AZ hot path as a deliberate choice bounded by explicit RTO and RPO targets, rather than defaulting to Multi-AZ everywhere and discovering the latency cost in production.

Next steps

• Set up the foundation: start with the multi-account structure using AWS Control Tower.
• Measure your hot path: benchmark gateway-to-matching-engine latency in a cluster placement group with the open-source Aeron benchmark harness.
• Secure custody: follow Build secure MPC wallets using AWS Nitro Enclaves.
• Deploy nodes: start from a blueprint in AWS Blockchain Node Runners.
• Go deeper: read Migrate centralized crypto exchange workloads to AWS and Optimize tick-to-trade latency for digital assets exchanges and trading platforms on AWS.

If you run an exchange on AWS, tell us in the comments which trade-offs mattered most for you.

About the authors