Want to migrate to AWS Africa Region? Read this first!
By: Niel Malan
Tags: AWS, Compliance, Landingzone, Governance And Tech, Cloud Security

As I write this, every South African AWS customer has all of their production workloads running on AWS outside of South Africa. That’s not by choice, but because until yesterday morning (22 April 2020), they had no other options. Luckily AWS have announced that the first AWS Region in Africa (Cape Town) is open for business!

We expect mass migration to start as soon as customers and partners are happy that the local AWS Region is stable, performs well and offers the relevant services they require.

To migrate to the new region is easy, click the “Change Region” button and POOOF! Job done! Well… if only it were that easy.

Moving resources between regions involve quite a bit of planning and migration work. Just like we all promised ourselves that we’re going to use this COVID-19 lockdown period to get those elusive to-do items at home done (I still have a week left to tidy up my garage o.k!?), this migration is a golden opportunity to get rid of some technical debt. I mean, all of us have temporary solutions that became permanent...

You’re not playing anymore

The one misstep we see most often with customers is that the account they used to initially sign-up with AWS to play/test, eventually became the account in which all of their services were deployed. I mean, we did this ourselves. If you are a small outfit, you are still just testing or you don’t run too many services in the account, this is fine.

When you grow, and your company starts running multiple development and production workloads in the cloud and you have a team of people spinning up / deleting resources, you should move to a multi-account setup. Best practice for well-architected multi-account environments is to have an empty billing-only root account. A separate set of sub-accounts should be created for workloads using AWS Organizations. However, this is only the start.

Enter the Landing Zone

For those that are not familiar with the concept, the more fully-fledged version of this multi-account setup is referred to as a Landing Zone.

Photo by Pascal Meier on Unsplash

A Landing Zone is a more structured account framework that addresses various governance, compliance and security aspects. The architecture below shows the AWS Reference Design for Landing Zone. It does not show any of the service accounts, only the governance and security accounts.

AWS Landing Zone Reference Architecture (Source: https://aws.amazon.com/solutions/aws-landing-zone/)

If you use the AWS Landing Zone solution, you can get going relatively quickly. The limitation currently is however that you will not be able to link any accounts that were not created from the start using AWS Landing Zone.

An alternative approach is to create your own landing zone and build the required connections between these accounts yourself using CloudFormation or other scripts. We’ve chosen this approach as we required more flexibility in our Landing Zone structure and account onboarding. We chose to build it using our Terraform scripts, as this will eventually allow us to more easily create Landing Zones for multi-cloud environments.

Whichever way you go, the benefits of having good governance, security and compliance built into the foundation of your cloud environment is definitely worth serious consideration.

The Major Benefits of having a Well-Architected Landing Zone

Create Order in the Chaos with Control Policies

You can setup Service Control Policies (SCPs) which act like ground rules for an entire account. What users can do inside an account can be restricted/guided using SCPs. These SCPs can also be configured to apply certain governance/compliance rules.

This has further security and risk benefits by limiting damage from stolen credentials. For example: If an account is compromised, how do you quickly react to prevent unauthorised resource deletion or creation? You can link the accounts to Organisational Units (OUs) which have the required SCPs attached. In the event of compromise, you can merely drag-and-drop the account into the “LockDown” OU, which can apply extremely restrictive SCPs to prevent resource damage while you remediate the situation.

Reducing the Blast Radius with Account Level Isolation

By using Account Level separation of resources and users, you effectively also limit the blast radius of any given event. Be it stolen credentials or accidental resource deletion. By separating Sandbox, Development, QA and Production accounts, and using ever more strict SCPs described above, you could easily see how the effect of mishaps can be limited.

Another common account separation model is splitting by Business Units / Business Area. Separating IT, Engineering, Marketing, HR and Finance for example.

Maintain Visibility with Centralised Logging

As your number of developers and infrastructure engineers grow and you have resources running in multiple accounts, keeping track of everything becomes a challenge. The Landing Zone has a centralised logging account, which aggregates all the logs from your other accounts into a single read-only account from where it can be processed.

Consolidated Billing

With the separation of accounts, AWS still rolls up all the sub-accounts into the master payer account (root account). All benefits that would have accrued to a customer if everything was in a single account are available and shared across the multi-account structure. This includes benefits like Consumption Tier Discounts and Reserved Instances.

But wait, there’s more…

There are too many benefits to discuss each in detail, but some additional important ones include:

Account life cycle management

Seamless Account Security Baselining

Easier Onboarding and Self-Service with Guardrails

We will be running a Webinar on Landing Zones for AWS in the next couple of weeks, if you would like to attend please register your interest here: Webinar Registration

If you are going to move house, you can organise the garage in the process

This is a call to all of you planning to bring your data and workloads home. You will have to do quite a bit of planning and work to move your resources from Europe/US to Cape Town. While you are going through that effort, take the extra step and move it into a well-architected Landing Zone.

If you need some help, give us a shout.

Cheers and Good Luck!