Having already moved some of our early apps to AWS – our community website, Spaces, and our parent passwords system, MyLogin – we were keen to explore which other apps could be moved offsite.


From the start we found it really valuable to be clear on our reasons for going IaaS with Amazon (or anyone else, really). Certainly, as a school, with access to very aggressive pricing discounting from hardware suppliers, it was not going to be about simple price – i.e. my servers vs. someone else’s.

Rather, we optimised on the following key principles:

  1. Others can run a data centre much better than us. We needed a data centre without a leaky roof, a single power provider, a single Internet connection, staff that work 8-5, etc.
  2. We want to spend time configuring, integrating and using services, rather than on infrastructure ‘plumbing’ – i.e. putting drives in servers, servicing UPSes, etc.
  3. We want to make annual decisions about which services we operate… and to take advantage of newer CPU and storage architectures released each year.
  4. We want to be SaaS first, then (reluctantly) IaaS, and lastly hosting things on premises in our campuses.

Getting more aggressive

In many ways, the 2014 AWS Sydney Summit was a game-changer. Five of us headed along to the Horden Pavillion & Royal Hall of Industries. Along with Jenny Luca I scored an invitation to an ‘executive’ track, managing to have lunch with the CIOs of about 6-8 ASX 50 companies. In each case the CIO was describing plans to move almost all services away from company data centres.

In the presentations the five of us attended the underlying message was the same: those with an eye to the future and on true organisational agility were getting the heck away from managing their own infrastructure.

Here we were thinking we were fairly innovative while teams at a bank(!) were using Netflix’s ‘Chaos Monkey’ to test and harden their cloud infrastructure.

We needed to think bigger. Much bigger.

Next Steps

Two things were clear:

  1. We needed to start ASAP
  2. We needed AWS servers on private (server) address space. It was time for VPC.

We quickly fired up a Windows AD domain controller and a ‘utility server’ and got to work planning the big ones: file, print and SQL and more.