AWS Web3 Blog

Migrate centralized crypto exchange workloads to AWS – Part 2

This is the English version of the original post published in the AWS Indonesia blog channel.

Part 1 of our series introduced key components for running centralized cryptocurrency exchanges (CEX) on AWS. Part 2 (this post) builds upon that knowledge and guides you through migrating CEX workloads to AWS successfully. In the upcoming Part 3 we will explore how recommendations from Part 1 and Part 2 were used in real migration scenario.

Our guidance comes from real-world migration projects of Indonesian cryptocurrency exchanges. We focus on practical lessons learned from actual migrations that were built upon more generic prescriptive guidance for large migrations. These insights can help both crypto exchanges and high-performance trading platforms.

In this post, we discuss how to plan your AWS migration strategically, execute it securely, and validate its success through testing. We share best practices for Multi-AZ deployments, auto scaling configurations, and database management. We also show you how to perform a smooth cutover and optimize your post-migration environment.

Design and plan your move to AWS

Moving your crypto exchange to AWS starts with good planning. Before you begin the move, you must understand your current system and decide how to set it up in AWS. This section shows you the key steps to plan your move, from mapping your system design to setting up AWS accounts and checking service limits.

Document your workload architecture design before migrating it to AWS

Migration to AWS starts with knowing your current crypto exchange setup. Before moving, you must plan how your system will handle high availability, performance scaling, network speed, and multi-cloud operations. By mapping out these key areas now, you can build a strong AWS system that grows with your needs. For guidance, refer to the reference architecture in Part 1 of this series. In the following sections, we discuss the key design decisions to make on this stage.

Design for high availability

Your crypto exchange must maintain continuous operation. This means deploying your services across multiple Availability Zones. Set up your databases with automatic failover capabilities to prevent downtime. Distribute your application servers across different zones to support service continuity. Remember that Amazon Simple Storage Service (Amazon S3) automatically stores data across multiple zones for built-in redundancy.

For more information, refer to the following resources:

Plan your scaling for performance

Crypto exchanges serve massive number of users and process large transaction volumes. Your scaling strategy should include Amazon EC2 Auto Scaling or Kubernetes Horizontal Pod Autoscaler with Amazon Elastic Kubernetes Service (Amazon EKS) for applications to handle varying loads. Consider using a combination of Amazon Elastic Compute Cloud (Amazon EC2) On-Demand and Spot Instances to manage costs effectively. For databases, solutions like Amazon Aurora Serverless can help handle unpredictable transaction patterns.

For more information, refer to the following resources:

Minimize latency impact in multi-cloud migrations

For crypto exchange workloads, latency is a critical performance factor that can be compromised in multi-cloud environments. When applications run on AWS while databases remain with other cloud providers, the increased latency can significantly impact performance. To minimize this impact in microservices architectures, prioritize migrating related services and their databases as complete units to AWS, limiting cross-cloud communication to only non-essential service interactions.

Optimize network performance with cluster placement groups

For processing hot paths in trading systems where every microsecond matters, network latency between instances can significantly impact performance. Amazon EC2 cluster placement groups help optimize these critical paths by placing EC2 instances close to each other in the same Availability Zone, reducing the physical network distance between components. By implementing cluster placement groups strategically along processing hot paths, trading systems can achieve more consistent and lower latency network performance, which is crucial for competitive market making and exchange operations.

For more information, refer to Optimize tick-to-trade latency for digital assets exchanges and trading platforms on AWS.

Establish foundation for your AWS accounts

Before beginning your migration, it’s important to establish a well-structured AWS organizational framework. AWS Organizations and AWS Control Tower serve as the foundation for managing multiple AWS accounts effectively. Your organizational structure should reflect your business needs, with separate accounts for different purposes such as business units, development environments, or specific workloads. Configure a dedicated management account and use a root user only for tasks that truly require it.

AWS Control Tower plays an important role in standardizing account creation and management, making sure accounts adhere to your regulatory requirements and security standards. It’s important to set up your management accounts several days before migration begins, because they require manual configuration, including payment methods to prevent operational disruptions.

Security and compliance form the basis of your AWS organization. Service Control Policies (SCPs) help you maintain control by setting maximum permissions across your organization, so you can restrict actions like resource deletion or limit EC2 instance types. Backup policies provide consistent data backup across all accounts, while maintaining compliance with retention requirements and disaster recovery standards.

Threat detection and security monitoring are essential components of your AWS environment. Amazon GuardDuty provides real-time threat detection using machine learning to identify potential cyber attacks and malware. AWS Security Hub offers a centralized dashboard for security monitoring, collecting security checks, and providing recommendations based on best practices. These services should be enabled organization-wide and monitored from designated administrator accounts.

Activity tracking and auditing capabilities are fundamental for maintaining security and compliance. AWS CloudTrail records API activity in your AWS environment, providing audit trails for security investigations and operational troubleshooting. By centralizing these logs through a designated administration account, you maintain complete visibility across your organization.

The organizational structure of your accounts on AWS creates a secure, manageable foundation for your crypto exchange operations on AWS, providing proper governance while maintaining operational efficiency.

Increase service quotas

AWS services come with default quotas that require careful review before you start your migration journey. These quotas represent the maximum limits for various service resources and API operations in your AWS account. You can quickly check both default and current quotas through the Service Quotas dashboard on the AWS Management Console.

Quota management requires advance planning and proactive action. Request quota increases well before your migration project starts, because approval processes can take from minutes to days, with larger quota requests taking longer. Waiting until the last minute to request quota increases can cause significant project delays—even a single day’s delay in quota approval can impact your entire migration timeline. This is particularly important for crypto exchanges, where service capacity directly affects trading operations.By understanding and managing your service quotas early in the planning phase, you can achieve smooth resource provisioning during migration and avoid unexpected constraints that could affect your project timeline or operational capabilities.

Plan migration implementation details

Good planning helps make your AWS migration successful. A clear plan helps your team understand what work needs to be done, when to do it, and how long it will take. This makes it straightforward to track progress and make sure nothing important is missed.The following are the main technical decisions to make:

  • Choose how to move your servers—either set them up fresh or use AWS Application Migration Service
  • Pick a way to move your database—either export/import or use AWS Database Migration Service (AWS DMS)
  • If changing database type, check if the AWS Schema Conversion Tool (AWS SCT) can help
  • Choose how to move files—either download/upload or use AWS DataSync
  • If you are using Kubernetes, check what changes your Kubernetes template files need
  • Update your continuous integration and continuous delivery (CI/CD) pipeline system to deploy on the right AWS accounts according to the organizational structure you designed earlier
  • Look for code that needs updates to work with AWS tools
  • Convert infrastructure code from previous cloud providers to options compatible with AWS

Some of these activities can be done in parallel, whereas others must be done one after another. Using project management tools that your team knows well can help keep everyone informed about the progress. A clear and detailed plan can help your team work better together during the migration.

Test your migration plan with proof of concept

Before starting your full migration, it’s helpful to run small tests to check if your plan will work. The following are the main areas to test:

  • Virtual machine migration – Test if AWS Application Migration Service can move your servers to AWS correctly. Even though AWS supports many operating systems, you might face issues with SSH access or server identity changes. Finding these problems early helps you fix them before the real migration starts. If your Linux-based EC2 instance becomes inaccessible, use the EC2Rescue tool to remediate common problems.
  • Database migration – Try moving a small part of your database with AWS DMS. This helps you check if you need to make any changes in your source database before the migration. It also validates that data moves correctly between different database versions. During the proof of concept, the pre-migration assessments in AWS DMS tasks can help identify problems that might prevent a migration task from running as expected. If during migration you are changing database engines, test schema conversion with the AWS SCT.
  • Transaction hot path testing – Check if your transaction processing path keeps latency low after moving to AWS. Test how orders flow from inbound APIs, to matching and performing trade, to delivering updated market data to the end-users. Check if transactions and market data move quickly enough. Testing early helps find slow spots before you move everything.
  • Multi-cloud performance – Check if your applications work well when some parts are on AWS while others are still on your old infrastructure. This is important because network delays between different clouds can affect how fast your crypto exchange works.
  • Code changes – Test how your application code works with AWS services. For example, check if your storage management code works with Amazon S3. Also test if your CI/CD pipeline and infrastructure code work properly with AWS. Consider using Amazon Q Developer to help migrate, test, and review your code.
  • AWS Support Plan – Remember to upgrade your AWS Support Plan to at least Business level. This gives you quick access to AWS support teams if you need help solving problems during testing.

This early testing helps you find and fix problems before they affect your real migration. It also helps your team learn how AWS services work in practice.

Review third-party licenses for AWS migration

When moving to AWS, you must check your third-party software licenses carefully. Many software vendors tie their licenses to specific cloud providers, which means your current licenses might not work after moving to AWS. To avoid problems during migration, contact your software vendors early to understand their AWS licensing requirements and make any needed license changes or purchases before starting the migration process.

Migration best practices when moving to AWS

Moving a crypto exchange to AWS requires the following proven practices to achieve a successful transition. These best practices, drawn from real implementations with Indonesian crypto exchanges, help you protect sensitive data, maintain performance, and minimize disruption during migration.

  • Daily progress monitoring – Have short daily meetings with your team to check progress and solve any problems quickly. This helps keep your migration on track and lets you fix issues before they become bigger problems.
  • Secure data transfer – Crypto exchanges handle sensitive data that needs protection. Use AWS Site-to-Site VPN when moving your data to AWS. This creates a secure connection whether you’re using the internet or AWS Direct Connect. AWS migration tools like AWS Application Migration Service, AWS DMS, and Data Sync work well with VPNs.
  • AWS migration tools – Make your migration faster by using AWS tools designed for this purpose. Move your virtual machines with AWS Application Migration Service, transfer databases with AWS DMS, and sync your files with Data Sync. For container workloads on Kubernetes, you can use your existing CI/CD pipeline to deploy to Amazon EKS.
  • Database setup – AWS DMS doesn’t automatically move everything. You must manually sync database items like functions, stored procedures, and indexes. This step is important for both application features and performance.
  • Getting help – If you face technical problems you can’t solve, contact AWS Support. AWS Support can help with migration issues, especially when dealing with unusual problems not covered in AWS documentation.

Following these best practices helps reduce risks and facilitates a smooth transition of your crypto exchange to AWS. By focusing on security, using the right tools, and maintaining proper oversight, you can achieve a successful migration while keeping your trading platform reliable and performant.

Testing after your move to AWS

After you complete the migration process, good testing helps check that your crypto exchange works well on AWS. Testing shows if your system works correctly and runs as fast as before. Your testing plan should include unit testing, functional testing, end-to-end integration testing, load testing, and performance testing. After you validate the system works correctly, run failover tests for critical components of your system, such as switching to hot standby applications and database point-in-time recovery procedures.

Setting up test environments with the right data is important for good testing. AWS Application Migration Service helps by offering test instance features before the final cutover. For database testing, Amazon Aurora or Amazon Relational Database Service (Amazon RDS) blue/green deployment lets you create separate test instances while keeping production data intact and up-to-date.

Container workloads on Amazon EKS can be tested using your current CI/CD pipeline in separate environments. For storage testing, you can create new S3 buckets and copy files from production. Using tools your team knows well makes testing less complicated and more consistent.Writing down test information helps track your progress. Keep records of what you test and what you find. Fix problems you find before moving to the next step. Testing with real-life data amounts and users shows if your system can handle actual work demands.This complete testing approach helps make sure your move to AWS goes well. Your crypto exchange needs to work reliably and quickly within the defined latency bounds. Testing helps make sure everything works right before going live.

Final cutover after your move to AWS

After testing is done and you pick a date to go live, it’s time to switch your crypto exchange to AWS. This cutover requires careful planning to keep your service running smoothly. These are the key steps to follow:

  1. Make sure your old and new databases match perfectly. Use Amazon CloudWatch to check AWS DMS metrics and verify the latest data is in place.
  2. Compare files between old and new storage systems. Use CloudWatch to check DataSync metrics and count files to make sure they match.
  3. For virtual machines using AWS Application Migration Service, monitor respective CloudWatch metrics to make sure all data is copied before switching.
  4. Point your CI/CD pipeline to AWS instead of your old provider.
  5. Update DNS records and system settings to point to AWS. This includes load balancer addresses and database connection details.
  6. Have a backup plan, and keep your old system ready in case you need to switch back quickly.
  7. Set up your applications and servers on AWS before the switch. This leaves fewer tasks for the actual cutover day.

The cutover to AWS works best when you prepare well. Check each step carefully as you go. Having a backup plan helps you react quickly if something unexpected happens. Remember that good planning makes the cutover easier and safer for your crypto exchange.This careful approach helps protect your trading service during the move to AWS. Your users should see little or no downtime during the cutover. Keep your team ready and focused until the cutover is complete.

Next steps after your move to AWS

Moving to AWS is just the start. Now you need to make sure your crypto exchange keeps running well. Good monitoring and post-migration cleanup help your system stay healthy and cost-effective. The following are the main tasks to handle:

  1. Set up CloudWatch to watch your system and send alerts if problems happen.
  2. Remove old systems and accounts from your previous provider that you don’t use anymore.
  3. Clean up migration tools like AWS DMS, AWS Application Migration Service, and DataSync when you’re done with them.
  4. Update your system documents with new AWS information about setup and structure.
  5. Monitor your AWS costs and look for ways to save money.
  6. Start an AWS Support Business Plan if you haven’t, to get help quickly if you need it.

Taking care of these tasks helps your crypto exchange run better on AWS. Thorough and continuous monitoring lets you spot and fix problems early. Removing old systems saves money and keeps things simple. Having current documents helps your team work better.Remember to check your system regularly after the move. Watch how it runs and look for ways to make it better. We discussed many AWS tools that help you keep your crypto exchange running smoothly. Your team should know how to use these tools and when to ask AWS for help.Keeping your system healthy on AWS takes ongoing work. But with good monitoring and regular updates, your crypto exchange can run well and grow over time. Stay focused on both daily operations and long-term improvements to get the most from AWS.

Conclusion

Moving a crypto exchange to AWS takes careful planning and work. In this post, we discussed how to do it safely and successfully. We shared what we learned from helping real exchanges move to AWS.Good planning makes a big difference in your move to AWS. Start by designing your system well and setting up AWS accounts the right way. Check AWS limits early and test your plans before making big changes. Use AWS tools to help move your data safely. Take time to test all parts of your system before going live.AWS gives crypto exchanges a strong base to grow and try new things. The tools and features AWS help you run a safe and fast trading system. As crypto trading keeps changing, AWS helps you change with it.

In upcoming Part 3 of this series, we will provide real examples from Indonesian crypto exchanges. We show how they handled challenges and made AWS work for them. To learn more about running your crypto exchange on AWS, talk to your AWS team.


About the authors

Agung Sidharta

Agung Sidharta

Agung is a Startups Solutions Architect who loves to work with customers solving their problems. In his spare time, he enjoys traveling, reading IT-related materials, and walking in the surrounding environment with his family and little dog.

Angga Pradikta

Angga Pradikta

Angga is a Solutions Architect at AWS. Angga helps customers navigate their cloud journey by designing and implementing secure, scalable, and cost-effective solutions.

Nikolay Vlasov

Nikolay Vlasov

Nikolay is the global lead for Distributed Ledger Technology infrastructure at AWS Worldwide Specialist Solutions Architect organization. He helps customers run workloads for decentralized web and ledger technologies on AWS.

David-Paul Dornseifer

David-Paul Dornseifer

David is a Blockchain Development Architect at AWS. He focuses on helping customers design, develop and scale end-to-end blockchain solutions. He primarily focusses on confidential compute and digital asset custody related solutions as well as latency optimization for critical CEX workloads.