
Ask HN: DNS naming conventions for cloud environments - bndw
- What sort of naming conventions do you use for your cloud environments?<p>- How do names correlate to environment (dev, staging, prod, etc), region (us-west-2, etc) and so on?<p>- How do you scope non-prod environment sub domains to reduce collision with business&#x2F;product subdomains (e.g. marketing might want to use stage.example.com)?<p>For example:<p>- staging.example.com points to a load balancer for staging workloads<p>- the request is routed to us-west-2.staging.example.com via a geolocation routing policy (closest region to the user)<p>- us-west-2.staging.example.com load balancer proxies the request to the backend workload(s)
======
rorychatt
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.

