During the first stage, Renova started with establishing the Landing Zone by using Control Tower to implement the MVP (Minimum Viable Product) of the migration project. Simultaneously, the multi-account framework was also introduced, to which the three above mentioned services must adhere to. On the other hand, Renova employed AWS Infrastructure as Code for pre-defined and pre-approved resource deployment, which considerably helped cut down on time and resources spent on deployment tasks.

With regards to the migration stage, Renova initially recommended the use of an automated lift-and-shift solution – AWS Application Migration Service (MGN), which could have significantly reduced the complexity and duration of migration tasks. However, this would have violated the bank’s internal security policy so the proposal failed to receive final approval. As a workaround, Renova instructed the bank team to manually export and import the source workloads onto S3 to restore the servers themselves. This method was thought to be time-consuming at first but the team of this bank was already using virtualization techniques on-premise so the process took less time than expected without any issues.

Overall, the monitoring and logging approach in the bank project was centered around the Amazon CloudWatch service for infrastructure and migration. For the whole system that was migrated using the Re-host approach, most of the workloads were lifted onto EC2 instances so they would have EC2 metrics by default. With regards to logging, CloudWatch Logs were used to store live logs with the retention at 90 days as short-term storage, while for longer storage duration, Renova Cloud replied on S3 bucket using a Log Archive account. As for back-up strategy, EBS volumes were designed to have backup automatically loaded onto Vault for each EC2 instance. The storage for all back-ups was also centralized for ease of management, in which there was one short retention copy in the resource-hosting account and one replication copy in the shared-service account. In the event of backup restoration, the latest snapshot would be automatically loaded onto a new cluster. The policy used to govern the backup restoration mechanism was not rigid but rather flexible, depending on the system level, which also dictate the length of retention.

In addition, the whole bank system was founded upon multi-AZ deployment with load balancers at the forefront. In order to have this bank architecture further reinforced, Renova Cloud configured an auto-scaling mechanism for some of the applications based on the metrics retrieved from CloudWatch. All of the above equipped the bank’s system with the ability to tolerate fault against AZ outage and to scale automatically in accordance to the rise and fall of business needs.