Networking & Content Delivery
Shared DNS views for multi-account environments with Amazon Route 53 Global Resolver
DNS views in Amazon Route 53 Global Resolver give networking teams centralized control over shared name resolution, but application teams still need the freedom to manage their own DNS records. Striking that balance gets harder with multi-account architecture and as services grow. Amazon Route 53 Global Resolver addresses centralized resolution piece by delivering a single DNS endpoint that works across all AWS Regions, serving on-premises data centers, branch offices, and remote users alike. With DNS views, administrators can control which private hosted zones are visible through that resolver. However, associating hosted zones with a DNS view was previously limited to the account that owned the view, which made the networking team the sole gatekeeper for every DNS change in the hosted zone.
In this post we show you how to share a DNS view across accounts with AWS Resource Access Manager (AWS RAM). With view sharing, consumer accounts can attach their own private hosted zones to a shared DNS view without involving the networking team for each request. Resolver governance stays centralized, and zone management stays distributed.
The problem: Centralized zone association as a bottleneck
In multi-account environments, the networking team owns and operates the Amazon Route 53 Global Resolver along with its DNS views. Application teams, operating in their own accounts, create private hosted zones for their services, such as payments.internal.example.com for a payments microservice. For those records to be reachable through the Global Resolver, the hosted zone must be associated with the relevant DNS view.
Before DNS view sharing, only the view owner could perform that association. The typical process looked like this:
- The application team provisions a private hosted zone in their account.
- They submit a request to the networking team, usually through a ticket system, Slack channel, or email, asking them to associate the zone.
- The networking team evaluates and approves the request.
- The networking team performs the association on the DNS view.
- The application team confirms that resolution works.
When only a handful of teams need zone associations, this workflow is manageable. In organizations where dozens of application teams ship services daily, the networking team becomes a scheduling constraint. Deployments stall while association requests queue up. The networking team also needs cross-account visibility into hosted zones they do not own, adding permission complexity.
The root cause was straightforward: a consumer account had no way to associate its own hosted zone with a DNS view owned by another account.
What’s new: DNS view sharing via AWS RAM
You can now share a DNS view with other AWS accounts through AWS RAM. Once a consumer account accepts the share, it can associate its own private hosted zones with that view. The records in those zones then become resolvable through the owner’s Global Resolver in the Regions where the resolver operates, without transferring ownership of the resource.
This introduces several operational improvements:
- Separated ownership boundaries – The networking team continues to own the resolver and the DNS view. Application teams continue to own their hosted zones. Neither account requires permissions in the other’s environment.
- Elimination of manual handoffs – Application teams associate and disassociate zones on their own schedule. The request-and-wait cycle disappears.
- Automatic multi-Region reach – An association made in one Region propagates to other Regions where the global resolver is active. One association covers all supported Regions.
- Tiered access through managed permissions – With AWS RAM you can choose from predefined permission sets: a default that allows association only, a lifecycle permission for view management, and full access that combines both. Custom permissions are also supported.
- Transparent audit trail – Associations belong to the consumer’s account but remain visible to the view owner, who can remove any association at any time.
Application teams can make a hosted zone resolvable through the owner’s global resolver, without transferring ownership of the hosted zone or the DNS View.
DNS view sharing via AWS RAM is available at no additional cost in the AWS Regions where Amazon Route 53 Global Resolver is supported. Standard Amazon Route 53 Global Resolver pricing applies for resolver queries and hosted zone usage.
Architecture: Multi-account setup
The reference architecture for this capability uses three accounts collaborating through DNS view sharing:
- Central Networking Account (Owner) – Operates the Amazon Route 53 Global Resolver and maintains the DNS view. This account creates the AWS RAM resource share and distributes the view to consumer accounts. The networking team retains administrative control: it can inspect all associations, revoke sharing, or remove individual zone associations at any time.
- Application Team Account (Consumer) – Manages private hosted zones for application services such as
payments.internal.example.comandorders.internal.example.com. After accepting the AWS share, this account associates its zones with the shared DNS view. The association is self-service and requires no action from the networking team. - Security Account (Consumer) – Owns private hosted zones for security infrastructure, for example
siem.security.example.comandwaf.security.example.com. This account receives the same shared DNS view independently and manages its associations without coordination with the application team.
Each consumer account operates autonomously by associating zones, updating records, and validating resolution on its own schedule. The networking team maintains a unified view of all associations and can enforce governance at the resolver level.
Walkthrough: End-to-end setup
In this walkthrough, you do the following:
- Create a DNS view in the central networking account (owner)
- Share the DNS view with consumer accounts using AWS RAM
- Accept the AWS RAM share in the consumer account
Prerequisites
For this walkthrough, you need the following:
- An organization in AWS Organizations with at least two accounts (owner and consumer)
- An Amazon Route 53 Global Resolver created in the owner account
- Resource sharing with AWS Organizations enabled in AWS RAM, (or manual share acceptance in each consumer account)
- AWS Identity and Access Management (AWS IAM) permissions to manage Amazon Route 53 Global Resolver, AWS RAM, and Amazon Route 53 hosted zones
Step 1: Create a DNS view (Owner account)
In the central networking account, create a DNS view within your global resolver. The DNS view defines the resolution scope for consumer accounts.
- Navigate to the Amazon Route 53 console
- From the left navigation pane, go to Global resolvers
- Select the global resolver, then go to DNS views at the bottom
- Choose Create DNS view
- Enter a DNS view name, then choose Create DNS view at the bottom right
Step 2: Share the DNS view via AWS RAM (Owner account)
Share the DNS view with consumer accounts using AWS RAM.
- Navigate to the AWS Resource Access Manager console and choose Create a resource share. Verify you are in the United States (N. Virginia) us-east-1 region
- Enter a resource share name. Under Resources select Amazon Route 53 Global Resolver DNS views, then select the DNS view you created in Step 1
- For Associate managed permissions, choose the permission you need. The “AWS RAM managed permissions” section later in this post describes each permission tier.
- Grant access to a principal: account, organization, organization unit (OU), IAM role, IAM user, or service principal
- Review and Create
Step 3: Accept the AWS RAM share (Consumer account)
- In the consumer account, accept the pending AWS RAM resource share. If the share is within an AWS Organizations organization and AWS RAM sharing with AWS Organizations is enabled, acceptance is automatic.
- Create a private hosted zone (Consumer account) – In the consumer account, create private hosted zone or use an existing one. For this walkthrough, create a private hosted zone for
payments.internal.example.com. - Associate the private hosted zone with the shared DNS view (Consumer account) – With DNS view sharing, you can now make this step possible. In the consumer account, associate your private hosted zone with the shared DNS view. You now have permissions to do this directly, with no request to the networking team.
- Validate resolution (Consumer account) – Verify that the private hosted zone records are now resolvable through the global resolver from all associated VPCs, in each Region.
AWS RAM managed permissions deep dive
AWS RAM provides predefined managed permissions that control what actions consumer accounts can perform on the shared DNS view. Amazon Route 53 Global Resolver DNS views support the following managed permission tiers:
Default (Association-only)
Allows consumer accounts to associate their own private hosted zones with the shared view. This is the least-privilege option and the recommendation for most use cases.
Actions:
- route53globalresolver:AssociateHostedZone
- route53globalresolver:GetDNSView
Full access
Grants all actions on the shared DNS view. Use this tier only for accounts that need administrative control. To see every available permission, choose Create customer managed permissions to view all the available permissions
Key considerations
- Association ownership: Private hosted zone associations created by the consumer belong to the consumer’s account. The consumer can disassociate their own zones at any time. The view owner can also remove any association, providing a governance safety mechanism.
- Cross-Region resolution: Once a private hosted zone is associated with a DNS view, the global resolver resolves it in all the supported regions. No per-Region association is required.
- Hosted zone and view lifecycle: If the consumer deletes their private hosted zone, the association is automatically removed. If the owner removes the AWS RAM share, consumer associations are revoked.
- AWS RAM organizational sharing: If AWS RAM organizational sharing is enabled, shares within the Organization are automatically accepted. Otherwise, consumer accounts must manually accept the share.
- Monitoring and auditability: AWS CloudTrail records all association and disassociation actions. The view owner can monitor which accounts have associated hosted zones and audit changes over time.
- Relationship to Amazon Route 53 Profiles: Amazon Route 53 Global Resolver with DNS views and Amazon Route 53 Profiles are complementary but distinct. Profiles centralize per-VPC DNS configuration (rules, firewall, logging) whereas Global Resolver provides Region-agnostic DNS resolution, choose based on whether your primary need if it is a VPC-level configuration management or global resolution.
Cleanup
To avoid ongoing charges, clean up the resources created in this walkthrough in the following order:
- Consumer account: Disassociate private hosted zones from the shared DNS view
- Consumer account: Delete private hosted zones (if created for this walkthrough)
- Owner account: Delete the AWS RAM resource share (this revokes consumer access)
- Owner account: Remove the DNS view from the global resolver (if created for this walkthrough)
- Owner account: Delete the global resolver (if created for this walkthrough)
Conclusion and next steps
This post showed how to share a DNS view across accounts with AWS RAM so that application teams can associate their own private hosted zones with a centrally owned Amazon Route 53 Global Resolver. DNS view sharing removes the operational bottleneck of centralized hosted zone association. With DNS View sharing, Application teams can self-serve DNS registration through the global resolver while infrastructure teams retain governance and visibility. The result is a federated operating model that separates resolver ownership from zone ownership.
To get started:
- Review the Amazon Route 53 Global Resolver DNS View
- Turn on AWS RAM organizational sharing if not already configured
- Share your existing DNS views with application team accounts using the default (association-only) managed permission
- Communicate the new self-service workflow to your application teams
- Monitor associations via CloudTrail and the Amazon Route 53 Global Resolver console
![[Figure 1: Multi-account DNS view sharing architecture with Amazon Route 53 Global Resolver]](https://d2908q01vomqb2.cloudfront.net/5b384ce32d8cdef02bc3a139d4cac0a22bb029e8/2026/08/24/MultiaccountDNSView.png)
![[Figure 2: Navigate to the Global Resolver to create the DNS view]](https://d2908q01vomqb2.cloudfront.net/5b384ce32d8cdef02bc3a139d4cac0a22bb029e8/2026/08/24/GlobalResolver.png)
![[Figure 3: Create DNS view]](https://d2908q01vomqb2.cloudfront.net/5b384ce32d8cdef02bc3a139d4cac0a22bb029e8/2026/08/24/CreateDNSView.png)
![[Figure 4: Create a resource share in the AWS RAM console]](https://d2908q01vomqb2.cloudfront.net/5b384ce32d8cdef02bc3a139d4cac0a22bb029e8/2026/08/24/RAMConsole.png)
![[Figure 5: Create a resource share for the DNS view]](https://d2908q01vomqb2.cloudfront.net/5b384ce32d8cdef02bc3a139d4cac0a22bb029e8/2026/08/24/CreateResourceShare.png)
![[Figure 6: Grant access to principals]](https://d2908q01vomqb2.cloudfront.net/5b384ce32d8cdef02bc3a139d4cac0a22bb029e8/2026/08/24/RAMPrincipalAccess.png)
![[Figure 7: Review and Create]](https://d2908q01vomqb2.cloudfront.net/5b384ce32d8cdef02bc3a139d4cac0a22bb029e8/2026/08/24/ReviewandCreate.png)
![[Figure 8: Navigate to the shared resources from the consumer account]](https://d2908q01vomqb2.cloudfront.net/5b384ce32d8cdef02bc3a139d4cac0a22bb029e8/2026/08/24/PendingDNSView.png)
![[Figure 9: Accept the shared resource]](https://d2908q01vomqb2.cloudfront.net/5b384ce32d8cdef02bc3a139d4cac0a22bb029e8/2026/08/24/AcceptDNSView.png)
![[Figure 10: Default managed permissions for the resource share in AWS RAM]](https://d2908q01vomqb2.cloudfront.net/5b384ce32d8cdef02bc3a139d4cac0a22bb029e8/2026/08/24/DefaultPermissions.png)
![[Figure 11: Custom managed permissions details for DNS view]](https://d2908q01vomqb2.cloudfront.net/5b384ce32d8cdef02bc3a139d4cac0a22bb029e8/2026/08/24/CustomPermissionOptions.png)

