AWS services such as AWS Security Hub, AWS CloudFormation, and AWS Config, among many others, can leverage an AWS Organizations feature known as Trusted Access to piggyback on organization service capabilities and automatically manage multiple accounts throughout the organization. This greatly simplifies administrating certain tasks such as enabling compliance recording of all AWS resources in an account as soon as it is created, for example. Similarly, Security Hub can auto-enroll any new account in the organization and start scanning it for security risks. To find a list of all AWS services that integrate with AWS Organizations, you can refer to this page: https://docs.aws.amazon. com/organizations/latest/userguide/orgs_integrate_services_list.html.
Focus on cross-account and hybrid networking needs
Whether you are planning to use AWS to migrate on-premises workloads or develop new applications in the cloud, network connectivity is going to be a fundamental requirement. Applications will need to communicate with shared services hosted in another account and talk to other counterparts on-premises. From a security and compliance standpoint, you might want to implement packet-level inspection for internet ingress and egress or cross-account communication. The network flow can be customized to a great extent to address organization-specific needs. AWS offerings in the networking space have increased exponentially over the past years, but that does not mean you need to adopt and use the fanciest of services from the very beginning. A Landing Zone evolves over time and this applies equally well to networking needs.
As an example, I have often observed teams leveraging AWS Transit Gateway from the very beginning. If you are just managing a handful of accounts, the majority of the use cases can be simply solved by sharing subnets across multiple accounts and implementing VPC peering connections, even for cross-region data transfer needs. You should be conscious of the design tradeoffs and cost, or complexity implications, that can come up with a premature adoption of such services. Furthermore, a mesh network is oftentimes not needed, so it’s invaluable to start by understanding the different network flows that the platform needs to support and build an architecture that does what’s necessary in a cost-optimized and secure manner.
The same goes for on-premises connectivity, where high bandwidth, low latency Direct Connect connections might not be needed unless there are concrete requirements from the applications depending on it. Grouping multiple site-to-site VPN connections over a single Transit Gateway can often solve the bandwidth and high availability requirements for a hybrid setup.
However, there are scenarios where enterprises do need a more complex setup to support the compliance, packet inspection, or needs of performance-sensitive applications. In these cases, several networking constructs, such as ingress VPCs, egress VPCs, and centralized packet inspection architectures, can support the needs of any new AWS account that gets onboarded onto the Landing Zone. Diving deeper into the architectural details is beyond the scope of this chapter, but if you’re interested in learning more, I recommend the following blog:https://aws.amazon.com/blogs/networking-and-content-delivery/tag/hybrid-connectivity/.