Mergers and acquisitions are complex processes. Besides the legal and financial hoops to jump through and the joining of staff and client bases, there is also the consolidation of IT infrastructure and services.
IT consolidation is complicated to begin with, but it is even more complicated when the companies involved have high security standards and requirements. OSS Group is grappling with these challenges first hand as they help Sovereign, now known as AIA, the large New Zealand insurance company, move ownership of their Amazon Web Services (AWS) presence from one company to another.
AIA, the world’s largest independent publicly listed pan-Asian life insurance group, bought Sovereign from Commonwealth Bank of Australia (CBA) in 2018. Matt Poole, an architect at OSS Group, leads the team that has been tasked with disentangling Sovereign’s network infrastructure from ASB (which is also owned by CBA) and then connecting it to AIA.
“Sovereign had previously stood up an AWS presence in its own right, but this was tightly coupled with Sovereign functionality hosted in the ASB datacentre,” says Poole.
OSS Group had built a relationship with Sovereign through their success at providing Sovereign with an AWS-based hybrid cloud in 2016 to supplement their proprietary datacentre. This move enabled key features, innovations and automations for AIA. Given their intimate knowledge of the initial AWS build, Sovereign trusted OSS Group to move their AWS infrastructure across to AIA.
The move presents an interesting security challenge. Banks and insurance companies store information that is highly protected. While there are numerous solutions for executing a move like this, the key challenge for Poole’s team was finding a solution that fit the security requirements of both companies.
“The easiest migration solution would have been to connect Sovereign’s AWS to the new AIA network and transfer access to services.”
This was strictly prohibited by both parties, as both ASB and AIA needed to maintain the ownership of all aspects of the security of their respective networks.
“We did investigate the possibility of protecting this connection with a fully auditable airgap. We would know with complete confidence what information is accessible to one company or the other.”
Although OSS Group could have jumped all of the audit hurdles, this solution was not accepted by either of the security teams.
Instead, the decision was made to build a clone of the original AWS environment.
“For both security and testing reasons, it made no sense to disconnect the original environment (AWS 1) from Sovereign’s existing ASB-based infrastructure and connect it to AIA.”
By making a clone, AWS 1 would continue to be attached to ASB and provide Sovereign’s existing infrastructure. Meanwhile, the new environment, AWS 2, could then be built connected only to AIA.
Because the AWS 1 environment is described as code, the current state can be rolled over easily into the clone.
“The fact that it exists in AWS means that we can just use the code that we ran to build it. We don’t have to discover what we have.”
Poole and his team did hit a few snags along the way.
“We needed to change the IP addresses because there was a conflict between what Sovereign is using and what AIA uses. This required a straightforward search and replace in the code to change the IP address ranges.”
Building the clone was fully automated, with the exception of creating the AWS accounts.
“Naturally, we didn’t have access to the AIA systems to do the auditing during account creation so we had to work with them to obtain the account credentials.”
Not only does building a clone meet the ASB and AIA security requirements, it also allows for complete testing of the new connection to AIA without disrupting on-going BAU testing in the AWS 1 environment.
“There are services provided by AWS to Sovereign that will move across to AIA. We will need to test those against the new network environment and datacentre environment.”
AIA is establishing a new datacentre in Sydney for all Sovereign workloads that were in ASB.
“If this were an on-premise build, we would have had to wait for the completion of the datacentre before the build could even be started.”
Poole marvels at how using an infrastructure as code approach has facilitated the transition of IT services from one company to another.
“This is made possible by the power of the code,” says Poole.
The OSS Group team were able to build a clone of the environment in a matter of days. When the migration is complete, AWS 1 will be terminated. Until then, OSS Group continues to manage AWS 1 using DevOps methodology. Operations, monitoring and data and integration is done using a combination of AWS tools, including CloudWatch and CloudTrail, and third-party tools, like Jenkins, Bitbucket, Puppet, Ansible and Terraform.
No Comments Yet
Let us know what you think