不同子网下所允许的业务类型：

公有子网：对于流量较大的web服务、前端应用、堡垒主机等适用。

私有子网：对于数据库服务、后端业务系统等适用。

AMI镜像迁移

Accesso在其它AWS站点上运行的EC2，通过快照将其转换为私有AMI，并授权给新的账号，在新账号下启动“我拥有的AMI”找到并直接启动，而后根据需求修改这个EC2。

ova镜像迁移

 使用AWS的CLI命令行，将OVA镜像导出至S3，然后新账号利用AMI导入授权的方式启动，而后根据需求修改这个EC2进行上线。

 使用AWS的专业云主机迁移工具SMS来迁移其它平台VM。

Oracle数据库迁移

使用专业的数据库迁移工具DMS+SCT将作为主要的迁移手段来配合Accesso进行同构或异构数据库的迁移任务。

对于关系型数据库要求高性能的业务，本方案建议迁移至Amazon Aurora关系型数据库当中，因为Aurora 是一款兼容 MySQL 和 PostgreSQL 的企业级数据库，高安全性且使用成本较低，每天费用起价不到一美元。提供更大的存储空间，最高支持 64TB 自动扩展存储容量和在三个可用区进行 6 种方法复制，以及 15 个低延迟只读副本。

Aurora需要提供至少3个可用区进行保护，故使用该数据库及服务部署在中国宁夏Region，同账号内直接切换region即可方便管理。

对于客户的使用场景，建议将Accesso读写负载较高的某交易系统迁移至此。该交易系统之前使用的关系型数据库为Oracle Enterprise Edition，它是运行在国外站点的RDS下，那么新的方案将在中国使用Aurora。数据库异构迁移至Aurora能为客户带来一定的业务优势如下：

 满足Accesso某交易系统的读写极高负载；

 满足该交易系统数据库容量不断增大，并且增长速度较快；

 解决数据库并发量高，包含OLTP和部分数据分析；

 满足对数据库高可用性、持久性的要求。

 Aurora的扩展性更高，具有自动故障迁移（如下图所示）

我们要迁移至不同类型的数据库引擎，则需要使用到 AWS的一个专用的工具 Schema Conversion Tool，他可以帮助我们自动的完成许多架构和代码转换任务。Amazon SCT支持同构迁移 (例如 Oracle 到 Oracle) 以及不同数据库平台之间的异构迁移 (例如 Oracle 到 Amazon Aurora)。我们也可以使用 DMS 将本地数据库迁移至在 Amazon EC2 实例上运行的数据库。根据客户业务系统部署来判断使用哪种方式进行异构迁移是最快最高效的方法。

Accesso的某交易系统迁移模式如下：

迁移过程将会捕获源数据库中的变更并以事务上一致的方式将其应用到目标数据库中。可以从源端向目标端数据库执行持续复制，或反之，也就是从目标端向源端的数据库进行复制。在同构或异构数据库之间，也可以执行持续复制。