{"id":6258,"date":"2023-09-15T09:00:00","date_gmt":"2023-09-15T07:00:00","guid":{"rendered":"https:\/\/blog.besharp.it\/?p=6258"},"modified":"2023-09-15T10:07:49","modified_gmt":"2023-09-15T08:07:49","slug":"networking-design-approaches-for-landing-zone-based-organizations-on-aws","status":"publish","type":"post","link":"https:\/\/blog.besharp.it\/networking-design-approaches-for-landing-zone-based-organizations-on-aws\/","title":{"rendered":"Networking design approaches for Landing Zone-based organizations on AWS"},"content":{"rendered":"\n
When we are faced with designing a Landing Zone in the Cloud, one of the most salient issues is networking since our networking configuration choice will affect our employees’ daily operations. Also, all the decisions we will make will also relate to the Cloud-to-on-prem communication in case of hybrid Cloud environments.<\/p>\n\n\n\n
(New to the Landing Zone concept? Start from here<\/a>!)<\/p>\n\n\n\n For designing the networking of our organization, AWS provides us with several possible solutions and approaches, each with particular benefits and specific use cases.<\/p>\n\n\n\n Remember that despite the multiple available possibilities, not all will always work for any use case. We should always start by figuring out which will best suit our needs and requirements while also meeting the main pillars of our underlying infrastructure.<\/strong><\/p>\n\n\n\n Designing networking doesn’t always mean reinventing the wheel; the perfect solution could also be an upgraded version of our current infrastructure and not a new implementation. This depends on considering the strengths and weaknesses of our past experience.<\/p>\n\n\n\n This article will look at the best solutions for implementing a shared, centralized network infrastructure on AWS<\/strong>. As we will see, there are two main roads for the network infrastructure in a multi-account approach: single VPC VS multiple VPCs<\/strong>.<\/p>\n\n\n\n Single-VPC approach is hard to adapt to a multi-account context, BUT, thanks to the AWS RAM service, this solution can be efficient and very functional. <\/p>\n\n\n\n This approach is one of the less-known ones; it consists of using a single centralized VPC to deliver connectivity to the entire AWS organization<\/strong>. As we will see in a moment, despite its simplicity, this solution will provide us with many benefits that are often overshadowed but can sometimes make all the difference.<\/p>\n\n\n\n First, however, let us understand how to implement a centralized VPC and how to adapt it to our particular requirements.<\/p>\n\n\n\n For the implementation of this infrastructure, we will need only a few services: a single VPC and the AWS RAM service.<\/p>\n\n\n\n As a small tip, we recommend using a VPC with a wide CIDR address<\/strong>. This will allow us to create numerous subnets without having to resort to extending the CIDR associated with the VPC.<\/p>\n\n\n\n To begin, we will only need to configure an account used for managing the network, from which we will later share all subnets to accounts in our organization (we will call it a “network-account<\/em>“).<\/p>\n\n\n\n Once we create our VPC and a small subset of subnets, we can proceed with sharing them to the desired account, through the use of AWS RAM,<\/p>\n\n\n\n As a final step, we will just need to connect to the target account and accept the sharing of subnets.<\/p>\n\n\n\n <\/p>\n\n\n <\/p>\n\n\n\n For everything related to sharing, we will use the AWS RAM service. It also allows us to configure certain parameters to differentiate how our resources will be shared, and therefore used.<\/p>\n\n\n\n If all has gone well, we should see the subnets we have just shared and their VPC in the application account.<\/p>\n\n\n\n Don’t worry if the VPC will be visible, too since, anyway, each account will only have access to the subnets that you have decided to share with it.<\/p>\n\n\n\n Now that we have the subnets on the target account we can create the resources using shared networks while not being the owners of said VPC. Obviously, since we don’t have the ownership of these subnets we will not be able to create routes or delete others as we are not the owners of the various routing tables. For all these activities it will be necessary to have a network administrator with ‘network-account’ access<\/strong>, making us also guess one of the advantages we will see later.<\/p>\n\n\n\n <\/p>\n\n\n <\/p>\n\n\n\n In the diagram, we can see an example of Organization structure. In this example, the Network-Account<\/em> will share 3 subnets of each type with the various accounts (production and non-production). The only difference we see between the environments will be the number of Nat Gateways. For the production account, it will be necessary to have at least 2 NATs in order to maintain high availability. For the non-production account, we will only have one so as to reduce costs. These configurations make us realize that the solution turns out to be really versatile and lends itself well for evolving along with our idea of Landing Zone and Business.<\/p>\n\n\n\n After focusing on the use of a single VPC, it is also necessary to understand what other possibilities are made available to us by AWS. <\/p>\n\n\n\nNetworking design<\/h2>\n\n\n\n
Single VPC with AWS RAM<\/h2>\n\n\n\n
Implementation<\/h3>\n\n\n\n
<\/figure><\/div>\n\n\n
<\/figure><\/div>\n\n\n
To optimize costs further, we could consider creating 3 centralized NAT Gateways that will be used by all accounts instead of having a dedicated one for each non-production environment.<\/p>\n\n\n\nMulti-VPC Approaches<\/h2>\n\n\n\n