In the organisations I have worked, we have normally done something like this: - <environment>-<component>-<application>.<application-portfolio/team>-<tenancy>

In the organisations I have worked, we have normally done something like this: - <environment>-<component>-<application>.<application-portfolio/team>-<tenancy>.<hosting-environment>.<business_name>.com This allowed us to delegate hosted zones to the application teams to self-manage their dns. Example, the hosted zone: - marketing-nonprod.aws.example.com Would appear as a hosted zone in the Marketing, Non-Production aws account. Note that we track the "Tenancy Environment", i.e. whether it's a prod/non-prod/labs. This will map to multiple application environments, e.g. UAT/INT/etc will be under non-prod. Then an application like: - prod-web-app.marketing-prod.aws.example.com could have a cname to: - app.example.com Which we would handle as a one-off service request to the central DNS management team (often dealing with things like Akemai at that stage). If the application stack required multi-regionality, we could added a regional identifier into the application name. My approach is overkill in many orgs. Many of these issues are made simpler through mechanisms like service discovery.