Code360 powered by Coding Ninjas X Naukri.com. Code360 powered by Coding Ninjas X Naukri.com
Last Updated: Mar 27, 2024

Virtual Private Cloud (VPC)

Leveraging ChatGPT - GenAI as a Microsoft Data Expert
Speaker
Prerita Agarwal
Data Specialist @
23 Jul, 2024 @ 01:30 PM

Introduction

A virtual private cloud (VPC) is a private cloud that is housed inside of a public cloud and is secure and separated. Customers of VPC can perform all of the functions of a typical private cloud, including running code, storing data, hosting websites, and so on, but the private cloud is hosted remotely by a public cloud provider. (This is not how all private clouds are hosted.) VPCs combine the data isolation of private cloud computing with the scalability and practicality of public cloud computing.

Need of VPC

Google Kubernetes Engine (GKE) clusters, the App Engine flexible environment, and virtual private cloud (VPC) instances all receive networking capability from VPC. VPC offers global, scalable, and adaptable networking for your cloud-based resources and services.

There are many cloud providers which support the VPC like amazon,azure and many more but we are going to focus on VPC provided by Google private cloud.

virtual private cloud

Consider a virtual private cloud as a reserved table in a busy restaurant, and a public cloud as the latter. A table marked "Reserved" can only be reached by the party that booked the reservation, even if the restaurant is full of patrons. 

A VPC reserves some of those resources for use by just one client, in contrast to a public cloud that is congested with numerous cloud users accessing computational resources.

How can we isolate a VPC in a public cloud?

VPC


Computer resources are separated from other computing resources in the public cloud by a VPC. 

The following are the main techniques for separating a VPC from the rest of the public cloud:

Subnets: A subnet is a group of IP addresses that are reserved in a network so that no one else can use them. This effectively separates a portion of the network for private use. These IP addresses are private in a VPC, as opposed to normal IP addresses, which are accessible via the public Internet.

VLAN: A local area network, or LAN, is a collection of connected computing devices that are not all connected to the Internet. A virtual LAN is a VLAN. Similar to a subnet, a VLAN is a method of dividing a network, however the division occurs at a different layer of the OSI model (layer 2 instead of layer 3).

VPN: A virtual private network (VPN) overlays a public network with a private network using encryption. VPN traffic travels through routers, switches, and other publicly accessible Internet infrastructure, but it is scrambled and hidden from view.

A VPC will have a unique subnet and VLAN that only the VPC customer may access. This effectively puts the "Reserved" sign on the table and stops anyone else using the public cloud from accessing computing resources inside the VPC. Data entering and leaving the VPC is not visible to other users of the public cloud since the VPC client connects via VPN.

Advantages of VPC

advantages

Scalability: Customers can add more computer resources as needed because a VPC is hosted by a public cloud provider.

Easy hybrid cloud deployment: Connecting a VPC to a public cloud or to on-premises infrastructure through a VPN is not too difficult. 

Better performance: Websites and apps hosted in the cloud often perform better than those hosted on local servers located on-site.

Greater security: Especially for small and mid-market organisations, the public cloud providers that offer VPCs frequently have more resources for updating and maintaining the infrastructure. This has less of a benefit for large corporations or any businesses that must adhere to extremely strict data security requirements.

Network features

NETWORK FEATURES

VPC firewall rules

Based on a configuration you define, VPC firewall rules enable you to accept or restrict connections to or from your virtual machine (VM) instances. Regardless of their configuration or operating system, instances are always protected by enabled VPC firewall rules, even if they have not yet started up.

Distributed firewall functionality is provided by each VPC network. Although connections are approved or rejected on an instance-by-instance basis, firewall rules are specified at the network level. The VPC firewall rules can be thought of as governing communication not only between your instances and other networks, but also between particular instances located inside the same network.

VPC Firewall policies 

Firewall policies, which are essentially managed by Identity and Access Management (IAM) roles, allow you to group various firewall rules so that you may update them all at once. These policies, like the firewall rules for Virtual Private Cloud (VPC), contain rules that can expressly allow or refuse connections.

Different types of firewall policies

Hierarchical firewall policies

You can establish and enforce a uniform firewall policy across your department using hierarchical firewall policies. You can link hierarchical firewall rules to specific folders or the entire organisation.

Network firewall policies

By combining all firewall rules into a single policy object, network firewall policies allow you to batch update every firewall rule. A VPC network can be associated with network firewall rules.

Regional firewall policies

Regional firewall policies guarantee that only workloads located in the given area are deployed and subject to the rules defined in these policy objects. A VPC network can be linked to regional firewall policies.

Add IP addresses

In Google Cloud, resources like VM instances and load balancers have IP addresses. These IP addresses enable communication between Google Cloud resources and those on-premises networks, the public internet, and other Google Cloud resources.

The following labels are used by Google Cloud to categorise various sorts of IP addresses. An internal IP address, for instance, is not routed publicly. An openly routed IP address is one that is external. An external IP address can be assigned to a Google Cloud VM's network interface.

External IP address

  • Since external IP addresses are publicly available, any host on the internet can access them. Publicly routable IP addresses are required for external IP addresses. The public internet can be accessed by resources with external IP addresses.
  • Google can give external IPv4 addresses for resources, or you can BYOIP (bring your own IP) addresses to Google. There are certain exceptions even though BYOIP addresses are static external IPv4 addresses and can be used with the majority of sites that accept them.
  • Google offers IPv6 addresses from outside networks. See IPv6 subnet ranges for further details.

Internal IP address

  • Internal IP addresses are not publicly routable and cannot be accessed through the internet.
  • Internal IPv4 addresses can be either privately utilised public IPv4 addresses or private IPv4 addresses. See Valid IPv4 ranges for a list of legitimate internal IPv4 addresses.
  • Within Google Cloud, internal IPv6 addresses are exclusive. See IPv6 subnet ranges for further details.

Private IP address

  • Internet traffic cannot be routed through private IP addresses.
  • See the entries for Private IP address ranges in the table of valid internal IPv4 address ranges for a list of private IPv4 ranges.
  • distinctive local addresses (ULAs). are IPv6 private addresses. For internal IPv6 subnet ranges, ULAs are used.

Public IP address

  • Internet routable public IP addresses are available. External IPv4 and IPv6 addresses are always public IP addresses in Google Cloud.
  • When configuring the primary or secondary IPv4 address range of a subnet in your VPC network, you can also use public IPv4 addresses as internal addresses. These numbers are known as publicly available IP addresses that are privately used.

Routes

A route in a VPC network consists of a single CIDR-formatted destination prefix and a single next hop. If the packet's destination address falls within the destination range of the route, Google Cloud will transmit the packet to the next hop when an instance in a VPC network sends a packet.

Routes in Google cloud

A scalable, distributed virtual routing system is used by every VPC network. The network is not given any physical hardware. However, the routing table for a VPC network is set up at the VPC network level. Some routes can be implemented selectively.

Get the tech career you deserve, faster!
Connect with our expert counsellors to understand how to hack your way to success
User rating 4.7/5
1:1 doubt support
95% placement record
Akash Pal
Senior Software Engineer
326% Hike After Job Bootcamp
Himanshu Gusain
Programmer Analyst
32 LPA After Job Bootcamp
After Job
Bootcamp

Network tags

network tag

A tag is just a character string that is appended to the tags field of a resource, like instance templates or Compute Engine virtual machine (VM) instances. You cannot create a tag independently because it is not a separate resource. It is assumed that all resources with that string have that tag. You can apply firewall rules and routes to certain VM instances using tags.

New VMs can have their network tags allocated when they are created, or you can update the set of assigned tags at any time in the future. Without pausing a VM, network tags can be changed.

Specifications

  • All of the network interfaces in an instance are affected by the network tags you provide it. A network tag only applies to VPC networks that are physically connected to the network interfaces of the instance. 
  • This still holds true for VPC Network Peering since peer networks are still separate networks. 
  • The network tags still only have value in the network to which the network interface of the instance is connected.
  • Network tags can contain lowercase letters, digits, and hyphens and must begin with a lowercase letter. Tags have to have a lowercase letter or number at the end.

For the configuration of network tag in Google cloud you check out this article:

Configure network tag

Capabilities of VPC

Shared VPC

shared VPC

A company can link resources from several projects to a shared Virtual Private Cloud (VPC) network utilising shared VPC, enabling secure and effective communication between those resources using internal IPs from the shared VPC network. By designating a project as a host project and attaching one or more other service projects to it, you can use Shared VPC. Shared VPC networks are the name of the VPC networks in the host project. Use of the Shared VPC network's subnets is permitted for resources from service projects that qualify.

The following is possible for companies using this model:

  • Use the least privilege principle in network management, auditing, and access control. Without permitting Service Project Admins to make changes that would affect the network, Shared VPC Admins can assign network administration duties to Network and Security Admins in the Shared VPC network. Only instances that use the Shared VPC network can be created and managed by Service Project Admins. 
  • Apply and enforce uniform access control policies at the network level for a variety of organisation service projects while assigning administrative duties. In their project, Service Project Admins, for instance, can be Compute Instance Admins, which allows them to create and remove instances that make use of authorised subnets.

Networking peering in VPC 

Regardless of whether two Virtual Private Cloud (VPC) networks are part of the same project or company, Google Cloud VPC Network Peering enables internal IP address connection between them.

You can link VPC networks using VPC Network Peering so that workloads in various VPC networks can talk to one another internally. Google's network is the only place that traffic travels; the general internet is not used.

VPC Network Peering is beneficial in the following settings:

  • ecosystems for SaaS (Software-as-a-Service) on Google Cloud. Private access to services can be provided across various VPC networks both within and between enterprises.
  • Organizations that need to interact using internal IP addresses and have multiple network administration domains.

Using internal IP addresses, VPC Network Peering enables you to make services accessible across VPC networks if your company has numerous network administrative domains. By employing internal IP addresses, VPC Network Peering enables you to provide services to other companies by making them accessible. If you want to provide services to other businesses, as well as if you own or control multiple firms, having the capacity to offer services across organisations is helpful.

Read about Batch Operating System here.

API’s and Services

api and services

Private service connect

groups, initiatives, or companies. Utilizing IP addresses that you provide and are internal to your VPC network, you can publish and consume services.

Access Google APIs and services, as well as managed services in another VPC network, using Private Service Connect.

Using Private Services To use Google APIs

By default, if you have a Google service-using application, such Cloud Storage, it connects to the service's default DNS domain, like storage.googleapis.com. Even while traffic delivered from Google Cloud resources stays inside Google's network, the IP addresses for the default DNS domains are publicly routable.

With Private Service Connect, you can build private endpoints inside your VPC network utilising universal internal IP addresses. These internal IP addresses can be given DNS names with descriptive names such as storage-vialink1.p.googleapis.com and bigtable-adsteam.p.googleapis.com. Your VPC network and any on-premises networks connected to it via Cloud VPN tunnels or Cloud Interconnect attachments use these names and IP addresses internally (VLANs).

Private Google access

Private Google Access is available for VM instances that have just internal IP addresses (no external IP addresses). The external IP addresses of Google's APIs and services are accessible. The network interface's principal internal IP address may be used as the packet's source IP address, or it may use an address from a designated alias IP range. The VM instances can only send traffic within the VPC network if Private Google Access is disabled, which prevents them from accessing Google APIs and services.

There is no difference between instances with external IP addresses and Private Google Access. According to the internet access requirements, instances with external IP addresses can access the internet. To send requests to, they don't require any particular settings.

Private service access

Services with internal IP addresses that are hosted in a VPC network can be made available by Google and other parties (collectively referred to as service producers). You can access those internal IP addresses using private services access. If you want your virtual machine instances in your VPC network to utilise internal IP addresses rather than external IP addresses, this is helpful.

Allocating an internal IPv4 address range and setting up a private connection are prerequisites for accessing private services. A reserved CIDR block is referred to as an allotted range and cannot be used in the local VPC network. It prevents overlapping between your VPC network and the service producer's VPC network because it is specifically designated for service producers.

Your VPC network and the service provider's VPC network are connected through the private connection. Through this connection, VM instances in your VPC network can access service resources using internal IPv4 addresses. Although external IP addresses are permissible for your instances, private services access does not require or make use of them.

Serverless VPC access

You may access your Virtual Private Cloud network directly from serverless environments like Cloud Run, App Engine, or Cloud Functions thanks to serverless VPC Access. By setting up Serverless VPC Access, you may use internal DNS and internal IP addresses to deliver requests from your serverless environment to your VPC network (as defined by RFC 1918 and RFC 6598). These queries use your internal network as well as the answers.

Serverless VPC Access has two primary advantages:

  • Requests sent to your VPC network are never made publicly available.
  • When compared to the internet, communication via Serverless VPC Access may have lower latency.

Only when a request was made from your serverless environment through the Serverless VPC Access connection does Serverless VPC Access transfer internal traffic from your VPC network to your serverless environment. Discover how to deliver additional internal traffic to your serverless environment by visiting.

Monitor and log

Flow log for VPC

A sample of network flows transmitted to and received by VM instances, including instances utilised as Google Kubernetes Engine nodes, are recorded in VPC Flow Logs. These logs can be used for forensic investigation, real-time security assessment, and cost reduction.

In Cloud Logging, you may see flow logs and export them to any location that supports Cloud Logging export.

From Compute Engine VMs, flow logs are combined by connection and immediately exported. You can use real-time streaming APIs to evaluate flow logs by subscribing to Pub/Sub.

Properties

  • The programme that runs VPC networks, Andromeda, includes VPC Flow Logs. When enabled, VPC Flow Logs don't cause any delays or performance issues.
  • Only VPC networks, not legacy networks, are supported by VPC Flow Logs. Per subnet, you can enable or disable VPC Flow Logs. When a subnet is activated, VPC Flow Logs gather information from all of the VM instances in that subnet.
  • Virtual machines with multiple network interfaces are supported by VPC Flow Logs. For each subnet with a network interface in a VPC, you must enable VPC Flow Logs.
  • You must enable Intranode visibility for the cluster in order to log flows across Pods on the same Google Kubernetes Engine (GKE) node.

Firewall rules logging

You may audit, confirm, and examine the outcomes of your firewall rules using firewall rules logging. For instance, you can check to see if a firewall rule meant to block traffic is working as it should. If you need to figure out how many connections are impacted by a specific firewall rule, Firewall Rules Logging is very helpful.

For each firewall rule whose connections you need to log, you enable Firewall Rules Logging separately. Any firewall rule has the option of firewall rules logging, regardless of the rule's action (allow or deny) or direction (ingress or egress).

Wall Rules Logging records traffic to and from instances of virtual machines (VMs) on Compute Engine. This covers Google Cloud products based on Compute Engine VMs, such as App Engine flexible environment instances and Google Kubernetes Engine (GKE) clusters.

Every time a firewall rule allows or refuses traffic while logging is enabled, Google Cloud creates a connection record entry. These records are viewable in Cloud Logging, and you can export logs to any location that supports Cloud Logging export.

Packet mirroring

In your Virtual Private Cloud (VPC) network, Packet Mirroring copies certain instances' traffic and forwards it for analysis. All traffic and packet data, including payloads and headers, are recorded by packet mirroring. The capture can be set to record only egress traffic, only egress traffic and both egress and ingress traffic.

Instead of on the network, the virtual machine (VM) instances are where the mirroring takes place. Packet Mirroring uses more bandwidth on the VMs as a result.

When you need to keep track of and evaluate your security situation, packet mirroring is helpful. Not just the traffic between sampling intervals is exported; all traffic is exported. To find any dangers or irregularities, for instance, you can utilise security software that examines mirrored communications. You can also look at the entire traffic flow to find any problems with the functioning of the application.

Frequently asked questions

What purposes serve GCP?

Client libraries from Google Cloud make it simple to create and manage resources. There are two main uses for the APIs that Google Cloud client libraries expose: Services are accessible through app APIs. App APIs are designed to work with supported languages like Node.

Can the size of a subnet be altered after it has been created?

A subnet cannot be resized once it has been established.

What is the maximum character count for a VPC name?

The current cap is 100. If you go beyond this limit, you can get a "internal error" notice.

Can the names of any of my VPC resources start with a number?

No, even if the name can have a number in it, it has to start with a letter.

Does the public gateway for the VPC include a timeout feature?

The TCP connection timeout for the VPC public gateway is fixed at four minutes and is not changeable.

Conclusion

In this article, we learned about the VCP and its various features in different sectors like networking, api’s and services, capabilities and monitor log. The information contained in this blog is just an overview of each of the topics for the configuration. You can check out the google documentation for VCP. 

For more cloud related information you can refer to the following articles:

Cloud APIs

Cloud DNS

Google Cloud Console

Cloud Domains

To learn more about DSA, competitive coding and many more knowledgeable topics, please look into the guided paths on Coding Ninjas Studio. Also, you can enroll in our courses and check out the mock test and problems available to you. Please check out our interview experiences and interview bundle for placement preparations.

thank you

 

Please upvote our blog to help other ninjas grow.

Happy Learning

Topics covered
1.
Introduction
1.1.
Advantages of VPC
2.
Network features
2.1.
VPC firewall rules
2.2.
VPC Firewall policies 
2.3.
Add IP addresses
2.4.
Routes
3.
Network tags
4.
Capabilities of VPC
4.1.
Shared VPC
4.2.
Networking peering in VPC 
5.
API’s and Services
5.1.
Private service connect
5.2.
Private Google access
5.3.
Private service access
5.4.
Serverless VPC access
6.
Monitor and log
6.1.
Flow log for VPC
6.2.
Firewall rules logging
6.3.
Packet mirroring
7.
Frequently asked questions
7.1.
What purposes serve GCP?
7.2.
Can the size of a subnet be altered after it has been created?
7.3.
What is the maximum character count for a VPC name?
7.4.
Can the names of any of my VPC resources start with a number?
7.5.
Does the public gateway for the VPC include a timeout feature?
8.
Conclusion