Hi Richard,
Here’s how I like to keep things distinct:
- Not all workloads need a Role label.
- Role labels are only used to distinguish a specific workload within an application with a different role than the rest.
- Roles are only needed if workload(s) have distinct traffic requirements than the rest of the workloads in that application.
That said, if you have servers that are shared across multiple applications, this can get challenging and needs a more robust process to keep things straight.
A-SQLServer for example is not really the main application, and serves as database for one or more applications. It’s important to see how rule writing is impacted here. If you intend to write a global rule to allow all apps to talk to all A-SQLServer, the role vs App label decision May not matter. This is a more nuanced situation so I recommend reaching out to your PS consultant to see what they recommend.
With the DC example, you do not need a role label here. I’d reserve that for if you need to specify the role as a DC with a CA server, WSUS server for example. This is again not needed, but an option if you want to be more granular.
A clearer example of a rule should be a multi tier app called ThreeT. 3 workloads - one web server, one DB, and one backend. All three will be labeled A-ThreeT, but the DB server has a role of R-Database, and the web server R-Web or R-Apache.
This allows you to write a rule to allow inbound traffic from all endpoints to R-Web for example, and only allow SQL traffic to the R-Database role. Or, you could restrict RDP access to R-Database only to an AD group that contains DB administrators. That’s one example of leveraging labels in that way. Hope that helps. I know labels can get away from you without a structure in place, so I think this is a great question with several potential answers. :-D