Back into the workshop mode, this time for what I think is an interesting one, not just from the tech perspective but broader IT and business use. AWS Landing Zone helps you more quickly set up a secure, multi-account AWS environment based on AWS best practices. AWS obviously has a large number of options, so setting up an account can take some time. AWS Landing Zones is deployed into an AWS Organisations account.
Why Multiple Accounts?If you’re initially thinking, “well, so what, we don’t set up AWS accounts that often, in fact we only have one or two for our organisation”. You may want to have another think about that.
AWS initially suggested keeping AWS account numbers simple, don’t have many, even one was fine or perhaps one for PROD and one for DEV. AWS now wants you to think of AWS accounts as single tenant homes. This could mean distinct AWS accounts for each department or even each application. How about each environment of an application being a separate AWS account? Why on earth would you do that? Well, compartmentalising applications is a good idea for a number of reasons. Billing is one, you can simply know exactly what each environment for each application costs rather than having to work through the crazy complicated AWS billing. You can identify data transfer costs per account which is something you can’t do with tags and billing. When you migrate to a new application you can cleanly shut down the old one by deleting the account. Multiple accounts are useful if you need administrative isolation between workloads or want to minimise your blast radius so an issue in one account is minimised especially from a security perspective. You can use service limits per account and also reserved instances are per account.
As with Microsoft Active Directly Organisation Units, AWS Organisational Units can be sliced and diced in any way you choose. You could chose to have AWS OUs based on business units, projects, locations or environments or a mixture of some or all. Could be a nightmare to manage. AWS Landing Zone is meant to help with all this with an automated solution.
The workshop went through building a Landing Zone which starts with a baseline environment with four core accounts and resources and an Account Vending Machine which uses a ServiceCatalog so users can create new accounts without needing to be admins.
This wasn’t as hands on as other workshops as the actual Landing Zone takes 2 hours to deploy. We registered and received a login to a pre-baked Landing Zone environment,it was all there so we could have a good look around. Would have been nicer to have some more tasks to do to create further accounts for example.
AWS Organisations Account
AWS Landing Zone is deployed into a central AWS Organisations account which is then used to create and financially manage other member accounts. This account has an S3 bucket, a CodePipeline, account configuration StackSets, AWS Organisations Service Control Policies (SCPs), and SSO configuration. Here are the accounts created:
Shared Services AccountThe Shared Services account is a reference account for infrastructure shared services such as directory services. This account starts within an AWS Managed Active Directory for AWS SSO integration. This runs in a shared VPC which can be peered with new member AWS accounts created with the Account Vending Machine. I would think you would deploy multiple shared services accounts for centralised application logging, monitoring, backups, deployments sources etc.
Log Archive AccountThe Log Archive account contains a central Amazon S3 bucket for storing copies of all AWS CloudTrail and AWS Config log files.
Security Account
The Security account creates read-only cross account roles for auditors and administrator roles for your security team to all your managed accounts. This gives your auditors central access to check compliance and break-fix for you security team in an emergency. This account is also the master Amazon GuardDuty account which can be used to see and manage GuardDuty findings for all accounts. Using Landing Zone
There are a lot of CloudFormation stacks which are automatically created by this with loads of baseline security settings like RDS encryption, default VPC deleted, disable deleting CloudWatch Logs etc. AWS Config had a Dashboard which you can see from any of the resources any noncompliant rules so for example we had an alert that MFA wasn’t enabled. as we used SSO (via on-prem AD), it was easily to jump between all the different accounts. We looked into the Security account and can see the S3 bucket with all the access logs from all accounts in the same place, all encrypted.
Account Vending Machine (AVM)The AVM is what you use to create additional accounts. It’s a Service Catalog Product preconfigured with a security baseline and a predefined network. We went on to the idea of modifying the default deploy code for custom deployments which uses a CI/CD pipeline. This is then all infrastructure as code.
We then had a custom account template which could be launched by users to create their own AWS account on demand.
This was a useful workshop and gave me some concrete technical steps to achieve what I’ve been working through my head which is how to automate enterprise account infrastructure in a continuous deployment model.
This has bigger ramifications than just the account creation process but ongoing management of your cloud(s). If your Singapore team needs to install a new domain controller, how do you manage the security groups and other firewall rules for all your accounts to be able to talk to it? You decide to change your logging destination or standards for all applications, how do you centrally push out this config to so many accounts. Being able to use Infrastructure as Code to deploy and more importantly keep up to date and audit a whole new account which has all the compliance, security, app standards, everything is super useful. Third-party vendors can plug into this so if you’re sending your logs to another service not run by AWS, they could provide the code to extend your accounts to use this system, put it into CodePipeline and you’re extended. The days of connecting to multiple AWS accounts to make similar changes are thankfully coming to an end.
I had to run off a little early to head to another hotel to be in time for the next workshop.
