Virtual Private Cloud (VPC)

Network tags

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

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

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.

 

Please upvote our blog to help other ninjas grow.

Happy Learning