{"id":6305,"date":"2023-09-29T08:00:00","date_gmt":"2023-09-29T06:00:00","guid":{"rendered":"https:\/\/blog.besharp.it\/?p=6305"},"modified":"2023-09-27T11:56:42","modified_gmt":"2023-09-27T09:56:42","slug":"vpc-shared-vs-multi-vpc-choosing-the-best-suits-for-your-organization","status":"publish","type":"post","link":"https:\/\/blog.besharp.it\/vpc-shared-vs-multi-vpc-choosing-the-best-suits-for-your-organization\/","title":{"rendered":"VPC Shared VS multi-VPC: choosing the best suits for your organization"},"content":{"rendered":"\n
As we saw in the last article, when it comes to network infrastructure for our Landing Zone, we no longer think only about the Transit Gateway but about a broader range of possibilities. The real question we need to ask ourselves now is when to use one approach over another, understanding the benefits or drawbacks this decision will bring with it. In the course of this article, we will try to outline the advantages and disadvantages of each solution and, subsequently, provide you with some small examples of use cases for each of these solutions.<\/p>\n\n\n\n
After understanding the various possibilities we have for configuring our landing zone network, let’s explore some potential scenarios that will help us determine which approach suits our case and needs. Below, we will attempt to present three possible scenarios and together, we will assess which of the options fits the described scenario. Please remember that you may have specific requirements not covered in this article; what we are providing are simply guidelines to assist you in making your decisions without imposing strict rules.<\/p>\n\n\n\n
Let’s consider the most common scenario: a company that has decided to leverage the cloud for its entire infrastructure and has likely increased the number of its accounts over the years. For our hypothetical company, topics like the Landing Zone, cost management, and centralization of core services have become part of their daily routine.<\/p>\n\n\n\n
Unfortunately, IT hasn’t grown at the same pace as applications and business needs, often leading to struggles with excessive overhead in managing their infrastructure. In this case, among all the available options, a single shared VPC could be the missing piece that enhances the daily operations of our IT department, without giving up the scalability and compliance benefits commonly seen in a well-structured Landing Zone.<\/p>\n\n\n\n
Unlike a Transit Gateway, with this solution, we can manage the network of all accounts directly from a centralized console in our “network account.” As explained in the previous article, when we refer to the “network account,” we mean an AWS account within our Organization dedicated to creating the VPC and all its subnets, which will later be shared with various accounts.<\/p>\n\n\n\n
Being able to modify routes, create new subnets, and manage cross-account traffic directly from a console will save us a significant amount of time that would otherwise be spent switching accounts using assumeRole or our SSO portal if we’re federated with our IDP. While multi-account management has become commonplace for such companies, saving significant time helps us focus on more critical issues like security and segregation.<\/p>\n\n\n\n
Another advantage of this solution is the segregation of permissions related to network resources in the application accounts. By managing VPC ownership within our centralized account, we can limit IAM permissions for users working on various accounts, ensuring that incorrect configurations do not create security vulnerabilities in our network.<\/p>\n\n\n\n
If we want to add another piece to our hypothetical company, we can say that the various applications present in our accounts often need to communicate with each other to exchange valuable information necessary to provide a quality service to potential customers. If you’ve been in this situation, you’ll know that in these cases, extra-VPC costs tend to be one of the main causes of high bills. Remember that on AWS, traffic within a VPC and traffic passing between VPCs (even in the same AWS region) have significantly different costs. If there’s also a Transit Gateway between the VPCs, the costs increase further.<\/p>\n\n\n\n