Your web application has several VM instances running within a VPC.
You want to restrict communications between instances to only the paths and ports you authorize, but you don't want to rely on static IP addresses or subnets because the app can autoscale.
How should you restrict communications?
Click on the arrows to vote for the correct answer
A. B. C. D.B.
The correct answer is B. Use firewall rules based on network tags attached to the compute instances.
When working with a web application that is deployed across multiple virtual machine instances within a VPC, it is important to restrict communications between instances to only the paths and ports you authorize, while still allowing the application to autoscale. This can be achieved by using firewall rules based on network tags attached to the compute instances.
Network tags are labels that can be attached to Google Cloud Platform (GCP) resources, including virtual machine instances. By using network tags, you can group instances together and apply firewall rules to the entire group, rather than individual instances.
To implement this approach, you can follow these steps:
Create a firewall rule that specifies the allowed paths and ports. For example, you may allow incoming traffic on port 80 for HTTP requests, and port 443 for HTTPS requests.
Assign a network tag to all the instances in the autoscaling group. This can be done using the GCP Console, the gcloud command-line tool, or the API.
Modify the firewall rule to only allow traffic from instances with the network tag you assigned in step 2. This ensures that only authorized instances are allowed to communicate with each other.
By using this approach, you can ensure that all instances in the autoscaling group have the same firewall rules applied, without relying on static IP addresses or subnets. This makes it easier to manage and scale your web application while maintaining a high level of security.
Option A, using separate VPCs, would be more complex and difficult to manage, especially when autoscaling is involved. Option C, using Cloud DNS, is not appropriate for restricting traffic between instances, as it is used for DNS resolution. Option D, using service accounts, is more appropriate for granting access to other GCP services, rather than restricting traffic between instances.