Together in the Cloud
Sai Charan Kuppa · July 1, 2024 · 7 min read
Ever wondered what makes the magic happen behind all those web applications and services you use daily? They run in the cloud! Well, not literally, but virtually. The Cloud is just someone else’s computer. There are various components that ensures successful running of a web application in the cloud. Virtual Private Cloud (VPC) is the most fundamental building block that helps us in creating our own space in the cloud. This is the space where your data and resources reside securely, isolated from the rest of the digital world. In this blog post, we will explore the fundamental concepts of Virtual Private Cloud(VPC) and how it is shared across multiple accounts in AutoScout24.
Before we jump into looking at Shared VPCs, let’s try to understand VPC and its components relevant to the VPC sharing.
Virtual Private Cloud (VPC)
The Virtual Private Cloud (VPC) is a cornerstone of AWS networking, providing users with a virtual network dedicated to their AWS account. It enables network communication and is isolated from other virtual networks in the AWS Cloud, offering enhanced security and control over resources. It consists of various components, so let’s take a look at each component and understand them with an analogy of a house.
VPC provides an isolated network environment where only authorized devices and users can access. A VPC can be likened to a house with specific boundaries. It also acts as a secluded area where only authorized people can enter.
Subnets are logical divisions within a network. A VPC can be divided into subnets, out of which some subnets are public and some subnets are private. Resources that need to be secure are usually placed in the private subnet, while public subnets can be accessed from the internet. In this analogy, subnets can be imagined like rooms in a house. Each room (subnet) can serve a different purpose and can be used to organize and manage different parts of network (like a kitchen, bedroom, and living room).
A NAT Gateway allows devices (private instances) inside the house (private subnet) to send mail (requests) out to the internet without directly exposing the inside of the house to the outside world, similar to how you can send letters from your mailbox without allowing strangers into your house.
Route tables determine the paths that residents (data packets) take to move between rooms and to the front door, similar to hallways and paths that direct you around a house.
Security groups control who can enter and leave each room (instance), similar to how locks on doors ensure that only authorized people can access certain rooms.
VPC peering connections allow two houses (VPCs) to communicate directly through a private passage, enabling easy and direct interaction without having to go through the public street (internet). In this analogy, we can consider a bridge to a neighbor’s house.
Transit Gateways acts as a network transit hub that can be used to interconnect your virtual private clouds (VPCs) and on-premises networks. In this analogy, you can consider as a road that connects multiple houses.
The diagram above visualizes the concepts with a simple illustration. The VPC has two subnets: a public subnet and a private subnet. The public subnet, which can be accessed from the internet, consists of an Application Load Balancer (ALB) to distribute the traffic load, an EC2 instance, and a NAT Gateway to send requests from the private subnet to the internet. The private subnet contains EC2 instances that host the applications, as well as an AWS RDS instance to store the data. A Transit Gateway is used to connect the newly created VPC to other VPCs.
VPC sharing
A VPC is a fundamental building block for a cloud infrastructure. As your cloud environment grows, managing resources within a single VPC can become cumbersome. This is when we expand our resources across multiple AWS accounts. When an organization has multiple AWS accounts, managing a VPC per AWS account can be complex. Different services need to communicate with each other, and every time a service in a private subnet needs to communicate with a service outside of the network, this request has to leave the VPC through a NAT Gateway. When such inter-account communication occurs, it results in the traffic going out to the internet before reaching another account’s VPC. This results in increase of costs.
Imagine a single VPC spanning across multiple accounts, ensuring centralized standards. Well, this is exactly where VPC sharing comes into the play. VPC sharing allows you to share resources within a VPC and enables VPC communication with other accounts in your organization. This can reduce the NAT Gateway costs by reducing the amount of NAT Gateways and enabling internal communication between services so that less traffic has to go through NAT Gateways -> VPC -> Internet.
With VPC sharing, an account that owns the VPC can share its subnets with other accounts. Teams can now deploy their resources in these subnets. The VPC owner can define security best practices and enforce them across all shared subnets, ensuring a standard of security. Teams can also manage their resources without needing to access or modify the underlying network configuration, reducing the risk of accidental misconfiguration.
How VPC Sharing Works
- Resource Ownership: The owner of the shared VPC retains control over the network resources, which include subnets, route tables, and internet gateways.
- Participant Accounts: Other AWS accounts, which are known as participants, are invited to join the shared VPC. They can launch their resources within the shared subnets.
- Permissions and Policies: The VPC owner can set permissions to restrict or allow certain actions by participant accounts, ensuring that each participant operates within their designated boundaries.
Implementing VPC Sharing
- Designing the Shared Network: This process starts with designing a VPC that can accommodate the needs of all participant accounts, including considerations for IP address ranges, subnetting, and networking requirements.
- Inviting Participants: Once the VPC is set up, the sharing of the VPC happens via a Resource Access Manager (RAM). RAM allows the sharing of resources (in this case, subnets) across multiple AWS accounts. The VPC owner’s account can invite other accounts to participate. Once the participant accounts accept the resource share, each account gets its share of these subnets to deploy their resources.
In the diagram above, we have two AWS accounts under the same AWS organization. In the main account, a VPC with public and private subnets is created. The private subnet is then shared with a participant account. The participant account can then use this subnet to deploy its resources. In the AWS main account, a resource share is created by selecting the private subnet. The participant account’s AWS account ID is then specified as a principal. In the participant account, the resource share invitation is accepted. The shared subnet will then be visible in the participant account, allowing Account B to launch resources into it as if it were a local subnet.
Shared VPC at AutoScout24
At AutoScout24, we use a shared VPC to enhance network management and cost efficiency. The shared VPC allows multiple AWS accounts within the AS24 organization to share a single VPC, centralizing network resources and simplifying management. This approach has led to significant cost savings and improved security through a clear separation of duties and permissions. When a new AWS account is created in the AutoScout24 organization, a stackset containing a lambda is deployed that adds the AWS account principal to the AWS RAM share. Once this is done, it allows the new AWS account to launch resources in its own account in the shared private subnet.
Key Takeaways
- Cost Savings: The consolidation of network resources has led to significant cost reductions, primarily by reducing the number of NAT Gateways in each VPC.
- Security and Compliance: The ability to enforce strict security policies and maintain compliance standards has been promoted, thanks to the clear separation of environments within the shared infrastructure.
- Operational Simplicity: The centralization of network management has simplified the oversight of cloud resources, making it easier for teams to focus on development rather than administrative tasks.
- Scalability: Shared VPCs offer a scalable solution that can grow with the company, accommodating new services and acquisitions without the need for complex network reconfigurations.
In conclusion, the Shared VPC model is not just a technical solution; it’s a strategic asset that empowers AutoScout24 to harness the full potential of cloud computing, making us be together in the cloud.
