There certainly are! It is a design consideration based on granularity and interdependence. We typically see VPGs created on a per-application basis with the VPG containing all the VMs that form the application so you can then apply boot ordering to the VMs. The failover granularity then needs to be taken in scope as a failover/test/move operation is performed per VPG. Some customers choose to create smaller VPGs for this granularity, but this then removes the consistency between the VMs. You can also have scenarios where multiple VMs and applications share the same database VM. The best solution here might be to create a single VPG for all the VMs, or 3 VPGs, 1 for the database and 1 for each stack. An interesting point here is that quite often databases are consolidated to a single VM to make management easier for a DBA or for licensing considerations, but this has a negative impact on DR granularity. For DR purposes it is always better to have 1 database VM per application.
There is no real maximum limit per VPG. I see customers have VPGs sized everywhere from 1 VM to 90 VMs, but as a best practice there is usually a happy medium of 1-20 VMs per VPG for manageability/granularity. Let me know if you have any further questions.
Joshua S.
