2 Answers
Hello Senthil! I’m really glad you’re trying out new weird ways to do things! 😄 It’s excellent for your learning!
In this case, the fact that you have (it seems, anyway) two separate VPC networks means that the communication between them will appear to go through the public internet. That also means that your Service-Account-based rules won’t work, because those only affect private traffic within your VPC.
I recommend that you leave this project the way it is, for the moment, and make a new project to go back to do the networking labs in a single network. After that, though, you could go back to this two-network project and continue your exploration to see whether you can peer those VPCs and actually get it all working! This documentation page on peered VPC firewall rules could help.
Cheers!
Mattias
Hello,
Have you peered the two networks to allow for internal connection without routing traffic between the frontend and backend through the internet?
I’m not sure about using the default Service Account for your firewall rules but if you do so, then your backend servers will be allowed to connect to the frontends, which (in this lab) you want to block. If you are using two VPCs with two subnets, you could go old school and create your firewall rules using subnets ranges.
But that would not cover the case of a new instance, being neither a frontend or backend server, added in one of the VPC/subnet, which would then be granted connection because the rules would apply for the whole subnet. And restricting by specific IPs, would break the instance group’s auto-scaling. So using tags or service accounts in the firewall rules remains the best option here I think.
I hope this helps.