Similar to software development life cycles, it’s important to test new Landing Zone features and changes in an isolated environment first, and then roll them out in the production AWS organization. Small changes such as SCP modifications, network route configurations, and security policy upgrades can have a big impact with multiple accounts being affected all at once. Misconfiguring CloudTrail S3 buckets, for example, can result in log and audit data not being aggregated as expected, resulting in the loss of valuable information.
Developing the overall platform in the same AWS organization that hosts production workloads increases the blast radius by a great deal. AWS accounts are free resources, so there isn’t a huge cost impact for replicating a similar structure to what you have in production. To further limit any additional spending in the development environment, it’s a good practice to set up billing alerts and remove all the resources across the entire organization using IaC automation when not needed, after office hours or during weekends. It’s a common practice to empty all the accounts using tools such as aws -nuke (https://github.com/rebuy-de/aws-nuke). This validates the functionalityand repeatability of the IaC framework so that it can spin up the entire platform from scratch, should the need arise, such as in the event of a disaster.
Avoid provisioning any IAM users
The single most frequent source of credential leaks is AWS IAM access keys, which can be accidentally committed into source code or left in an EC2 instance that is no longer used. You should always aim to leverage IAM roles for any access requirements in the AWS Landing Zone. It’s a security best practice to deny the creation of IAM users in all AWS accounts in your Landing Zone. Technically, all AWS identities, be it users, services, or resources themselves, can assume an IAM role and request temporary credentials at the time of use, from the IAM control plane. EC2 instances have the concept of an instance profile, and services such as Lambda and RDS use service roles, which gives them access to the allowed resources.
The majority of enterprises already have some form of IdP solution in use in the organization. AWS IAM supports out-of-the-box integration with such providers through OIDC or Security Assertion Markup Language (SAML), which removes the need to provision and manage any users throughout the organization. IAM federation further prevents credential sprawl and any employees that are offboarded from the authoritative identity source, such as Active Directory, automatically lose access to all AWS accounts, which is a good security win.