Multiple Account Strategies & AWS
Taking advantage of the speed, power and global reach that cloud platforms provide, is on the critical path for almost all organisations looking to deliver the greatest returns to their investors. Kicking off a digital transformation project initiates multiple work streams within an organisation, which in general run in parallel and require significant overlap from cross function teams.
For any organisation with complex application estates, a well-structured multi-account landing zone is critical in providing an organised base to host each application as it is migrated. Investing time up front to plan a landing zone that provides strong governance, caters for compliance needs and increases build times through standardisation is fast becoming a de-facto strategy in any digital transformation project plan.
Building out a multi-account cloud environment is comparable to building a block of apartments. A project team will organise the building of the apartment structure and for the all utilities to be installed such as plumbing, heating and security.
Once complete, building inspectors are brought in to check that all aspects of the building work meet industry regulations before being signed off as being fit for purpose. Once the build phase is complete, administrative teams are then contracted to run the apartment block, keeping a close-eye on costs and coordinate maintenance as needed. Before applications can be re-hosted, relocated, refactored or simply retired, a carefully planned cloud landing zone needs to be built and signed off before it can receive its first applications, or should I say tenants.
The AWS account construct provides a clean, robust and secure mechanism to isolate control of data plane access to contained resources. The account boundary is very effective against human error and misconfigured IAM policies or security groups. Separate accounts also provide the best separation from a governance standpoint when it comes to costing and reporting. Tagging resources allows you to see which resource belongs to which cost centre, but it becomes difficult to separate network traffic belonging to multiple applications within a single account.
Provisioning multiple accounts does not cost any more than running multiple VPCs, and it’s my experience that separating by account whenever possible provides the best operating model for an enterprise landing zone solution. I will just say though, running an AWS account with multiple AWS VPCs is perfectly reasonable and at times necessary. For example, replication using the AWS Aurora service can’t be set-up across accounts just yet, so it makes sense to deploy into a second region in the same account so that you can take advantage of the inbuilt replication capabilities provided.
Accounts are generally categorised into two types based on whether they house shared services consumed by business applications or whether they host specific applications. The following are some of the account types I commonly see in use, but it really depends on individual business requirements and preferences as to which accounts are ultimately utilised.
The transit account can be used to provide a single gateway in and out of a multiple account estate. It could be used to pass all north-south, east-west traffic through highly available and scalable firewalls that provide central IPS and IDS filtering. VPN and AWS Direct connect services can also be terminated here providing private IP connectivity from corporate datacentres and office locations. Services such as AWS transit gateway can also be set-up here to provide connectivity between all accounts. This account would be locked down to NetSec level team members only with varying degrees of privileges based on job role.
Identity and security
Identity accounts can be used to centrally manage AWS user accounts, allowing access to all other accounts via cross-account roles removing the need to create users in any other account. If using AWS, organisations can configure the AWS single-sign-on (SSO) service to centrally manage privileges to resources in other accounts. Alternatively, SSO to the AWS console can be set-up using Active Directory Federations Services and SAML 2.0. Central Antivirus type services and security scanners could also be set-up here if required.
Logging is one of the more popular shared accounts I see in use with clear reason for being. AWS services such as Cloudwatch Logs and CloudTrail can be redirected to central S3 buckets housed within the logging account. If you’re running any third party logging applications, this is the perfect place to deploy the supporting infrastructure. A logging account really benefits from being locked down with minimal access when it comes to compliance.
It makes sense from a security perspective to share services centrally rather than allowing a mesh of application interconnectivity throughout many accounts. A shared services account is generally used to provide non-security related services to applications estate wide. Microsoft active directory, remote desktop services and small non-critical shared databases or file systems are a few examples of how I’ve have seen this type of account used.
Application accounts (dev, test, staging & production)
At Rackspace, we recommend separate accounts for different environments where possible for the reasons already covered. No single application account should have or need access to any other application account, this makes sure all applications are protected from the highest levels of security and separation. VPCs within application accounts will be configured with the relevant networking upon creation so that relevant shared services can be consumed as required.
AWS landing zone service
Amazon brought landing zones to the forefront when it launched the AWS Landing Zone and subsequently introduced a highly automated approach to building them. This is a fantastic service that brings AWS best practices codified into a single account deployment experience. The AWS Landing Zone service does come with a level of complexity and requires a good level of AWS know-how to be able to manage it.
The concept of a landing zone is not new and is relevant across all public cloud providers and datacentre hosting providers, the only difference being the terminologies and methods needed to set them up. At Rackspace, our customers have varying business challenges and so each landing zone takes on a slightly different configuration. Within AWS this could be a single AWS account to prove out a concept, a few accounts in a Dev - Test - Production pattern, or a complex multiple account strategy hosting 300 applications as part of a large digital transformation project.
Rackspace has expertise across the leading public, private and hybrid cloud platforms, including AWS, Google Cloud Platform™, Microsoft Azure®, Openstack® and VMware. Rackspace can support any migration strategy — Lift & Shift, DevOps, Application, and Built from Scratch — and migrate into IaaS, PaaS, and SaaS platforms with minimum disruption, all while tailoring the plan to your timeline and business needs.
To learn more about how Rackspace services can assist with business challenges related to multiple account strategies, digital transformation and migration please visit Professional Services.