Brought to you by

3 challenges architecting a secure migration to AWS

Posted 3 months ago in Xero news by Aaron McKeown
Posted by Aaron McKeown

Two years ago Xero began its massive migration to Amazon Web Services (AWS). We made the move because of the realization that, although we had grown to be hugely successful on our previous infrastructure, we needed a data-hosting environment that would enable us to scale to meet the needs of potentially millions of customers.

Today, the migration is complete, and we recently surpassed our million subscriber milestone.

It was challenging moving 59 billion records and $1 trillion worth of transactions from on-premise servers onto a fully-managed AWS environment. Not to mention that we were working at a blistering pace while simultaneously protecting and defending our environment.

I recently spoke about those challenges at RSA conference, and how we overcame them.

1. Speed

In one 12-month period at Xero, we released more than 1,200 product features and updates. The pace of innovation of our product teams means that we had to accelerate our security team as well. In order to be agile, we operate our teams on a core principle of unrestricted freedom, giving our staff the autonomy to build features and tools using whichever AWS services they needed.

This gave us the ability to build a fully automated infrastructure. Which in turn gave our developers the freedom to choose what type of platforms they can use. They can then roll them out in automated, repeatable and secure fashion.

2. Visibility

Because of the need to have a fully automated infrastructure, we quickly scaled within AWS, creating more AWS accounts rapidly. This growth, driven by our developers, necessitated continual visibility across all of this.

To negate this, we built an AWS account creation process. This process was well documented and understood by both the team that was creating the accounts and our internal product teams. Using this process, we ensure that we enable AWS CloudTrail for all accounts within our environment.

We changed the mindset of development teams by getting them invested. We assigned account owners and technical leaders for each account. Then we demonstrated how they could use the tools and how with small changes they could make the environments they were responsible for more secure. Making operational visibility a design criteria was also instrumental in overcoming this challenge.

3. Working with third-party vendors

Building security services that could scale on-demand required working with enterprise security vendors to build a best-in-breed infrastructure. To do this, we needed to engage with these vendors on many levels. In some instances this included almost the entire organization, from their account management teams, all the way up to their executives.

We’ve developed a strong relationship with these organizations. These strong relationships have changed our perception to view them as a partner in our journey to the cloud, rather than a vendor.

In facing these challenges and solving for them, we were able to build a security infrastructure without compromising on speed. Moreover we were able to ensure that our clients perceive security as an enabler, rather than a blocker.

Leave a reply

Your email address will not be published. Required fields are marked *