I'm trying to figure out how to effectively set up an organization with dedicated accounts for live, UAT, and development environments, in addition to internal resources like documentation and email. My primary concern is how this setup will conflict with DNS organization. Here's what I have in mind:
- example.com as the main website
- auth.example.com linked to the main site
- uat.example.com for UAT stage
- auth.uat.example.com for UAT auth
- docs.example.com for internal documentation
- [email protected] as our email address
I see a few options to achieve this:
1. Keep the main website in the management account along with internal resources, and have UAT, dev, etc. in separate accounts using NS records in the main hosted zone. However, this setup feels wrong because the live site should be isolated.
2. Place the main site in its own account to host example.com, but I'm uncertain about managing email and internal subdomains properly, as well as the delegation for subdomains in this account.
3. Perform all DNS setup in the management account, but I'm not sure if it's feasible to point a Route 53 record to resources in another account. It complicates certificate creation since validation records would need manual creation.
4. Use live.example.com for the main site, which simplifies delegation for DNS and allows for easy management of DNS records and certificates. A CNAME from example.com to live.example.com could also be created.
5. What's the usual approach for organizing setups like this? Any insights would be greatly appreciated!
4 Answers
I recommend keeping the management account free of anything that isn't just management-related. Internal resources often have different DNS requirements, so they should ideally be in a different account. You can indeed point DNS records to other accounts, including all sorts of external services. Just be wary that managing DNS records for public domains is crucial to avoid exposing any unwanted information, especially in testing environments.
For our setup, we keep our domain registration in the production account and create separate hosted zones in lower accounts (dev, test, etc.). For example, the zone for example.com lives in the production account, while dev.example.com exists in the dev account. This allows the test account to create its own subdomains easily, always within the test.example.com context. This way, it keeps things tidy and organized.
Just a heads up: option 4 won’t work as expected since CNAME records at the apex aren’t allowed. You'll need to reconsider how you want to manage your domains.
I've found option 3 works! You can actually point an alias record in Route 53 to a distribution in a different account. It really simplifies things if you manage it correctly from the parent zone.
Related Questions
Cloudflare Origin SSL Certificate Setup Guide
How To Effectively Monetize A Site With Ads