When you create your first cloud account, you’re faced with a blank sheet of paper and it can be difficult to know where to start. It’s all too tempting to jump in and start mobilising teams to move your applications across as quickly as possible – something we saw several organisations attempt in response to the pandemic in 2020.However without proper planning, it’s easy to end up in a quagmire of technical debt that can soon slow the pace of your migration. As the last few years have shown, once the genie is out of the bottle, it’s very difficult to put it back in.
- Structure your AWS accounts to meet your organisation’s needs
The AWS account acts as a natural security, access and billing boundary. Any well architected AWS design will need multiple accounts to allow the effective management of workloads, access, polices and budgets.
Amazon’s answer to this requirement is ‘AWS Organisations’, which allow you to structure the accounts within your organisation in different Organisation Units (OUs) to best suit the way your business works.
Before starting the migration of your workloads, you should take the time to understand how you want to break down your organisation into OUs. Getting this right from the start will provide the foundation to properly apply policies to your accounts with minimum effort.
For example:
Foundational OUs: it’s best practice for almost all organisations to start with OUs for security and infrastructure, as these are common to the majority of organisations. Once you have these set, you should consider how best to split the rest of your workload up.
Workload OUs: splitting by function or a common set of security controls can work best here, rather than mirroring your organisation’s reporting structure.
Other workload OUs: these hold your day to day workloads and cover a range of areas. For example: the ‘Individual Users’ OU for those with special requirements; the ‘Deployments’ OU for hosting CI/CD solutions; and the ‘Sandbox’ OU which enables developers to innovate.
- Connect AWS to your on-prem network
You’ll quickly discover that once you start to progress with your migration, the workloads you move will still need to be accessed by or within your corporate network. It’s unlikely that you would want to expose all of your on-prem and cloud resources to the public internet, so how can you manage this connection?
The mechanics of connecting your network to AWS are straightforward, consisting of the following choices:
Direct Connect: this establishes either a 1Gb or 10Gb fibre connection from your network to AWS for a private dedicated high speed, low latency connection.
Virtual Private Network (VPN): a quicker solution is to set up a VPN which establishes a secure encrypted network over the public internet.
Hybrid: to provide a resilient solution with the cost of a stand by Direct Connect, it is possible to use both Direct Connect and a VPN, with the VPN acting as low cost standby connection.
Once you have the mechanics of the connection sorted, it’s time to think about the other aspects of your connection – most notably managing IP address ranges across AWS and on-prem to avoid clashes. Having a central process to manage IP ranges is essential. All too often we see teams left to their own devices and giving no thought to the ranges they use, only to have to rebuild their networks to resolve clashes when they reach the integration stage.
- Establish guard rails to help engineers do the right thing
Once you have your environment up and running, with the right structure and connectivity, you are already to let your engineers go wild, right? Not quite. You really want to make sure you have some guard rails in place to help make sure your engineers don’t make expensive or risky mistakes.
Failing to do so could result in:
Expensive services or instances used where they aren’t required, resulting in a large bill.
Data exposure due to misconfigured S3 buckets
Data processes in the wrong region, which may breach data sovereignty rules
Thankfully, AWS provides you with right tools to solve this problem. These tools include Service Control Policies – which help prevent unwanted behaviours by restricting access to AWS services, regions, APIs and permissions – and AWS Config, which helps you pick up on misconfigured services, flag these non-compliant components and even auto remediate these before any harm can be done. Setting IAM Permission Boundaries is also valuable, helping you set boundaries for what an IAM role can have access to.
Ultimately, there’s no one-size-fits-all approach to an AWS cloud migration. Every organisation must consider their own specific challenges, as well as their technical and operational requirements. Taking the time to properly plan the journey up front can save considerable headaches further down the road.
