Your Landing Zone strategy needs to factor in requirements such as the observability of your platform and applications, infrastructure monitoring, application monitoring, incident management, change management, and so on.
Notifications, alerting, and reporting should integrate with existing paging tools. This should allow the on -call operation teams to support the landing zone, or any outage, with the same priority they would give to a productive application that no longer works. AWS offers additional services such as Personal Health Dashboards ( PHD) and Service Limits alerting, which are quintessential to surface any ongoing issues with the services in a particular region, as well as the planned maintenance activities of your resources.
Having covered the key considerations of a good Landing Zone concept, let’s dive into some best practices that will set you up for success.
Best practices for managing multi-account architectures
The best practices that follow touch upon a lot of areas that we covered in the previous section. Based on my experience developing Landing Zones for multiple enterprise customers, I would like to share some insights into the best practices that you could consider adopting for your organization.
Limiting access to the management account
The AWS account where you bootstrap the AWS Organizations organization is known as the management account, or the master payer. This is a highly privileged account that gives access to policy management, centralized billing and cost reports, and account management. It should only be accessed by selected personnel, under exceptional circumstances.
SCPs do not apply to the management account, which makes it difficult to enforce any policies or governance control at this level. Secondly, by default, AWS Organizations injects an IAM role into all AWS accounts in the organization, with AdministratorAccess privileges, and a trust policy that allows the management account unrestricted access. This implies that anyone who has access to the management account can assume this role and gain escalated privileges into any other account in the organization unless some additional measures have been taken to not allow this. Furthermore, since all policies are managed and enforced from the management account, you can lift all restrictions and expose the entire organization to security risks.
As part of the Landing Zone automation process, certain use cases cannot be avoided where tools need access to the management account to carry out some operations that can only be executed from within the management account. For example, enabling an opt-in region, or moving an account to a different OU, can only be performed from within the management account. A good security practice is to create fine-grained IAM roles in the management account that give permissions to the Landing Zone automation tools to only execute the IAM actions that are permitted.
AWS Organizations also has an interesting feature known as Delegated Admin, support for which is now being expanded to many AWS services. This allows thedelegation of the administrative capabilities of a specific service to another account in the organization. Delegated Admin further limits the need to log into the management account and allows the service owners to administer a certain service from the delegated account itself.