AWS re:Invent 2019: Deep dive on DNS in the hybrid cloud (NET410)
ฝัง
- เผยแพร่เมื่อ 3 ธ.ค. 2019
- The launch of Amazon Route 53 Resolver endpoints and forwarding rules has opened up a variety of exciting new options for managing DNS resolution, especially in hybrid cloud environments. This session gives a quick overview of the product before taking a deep dive into the design of Route 53 Resolver, including how it complements Route 53 private DNS and best practices to achieve availability and performance. We also dive into some new patterns that are emerging with services such as AWS Transit Gateway, AWS PrivateLink, and AWS Directory Service for Microsoft Active Directory.
![AWS re:Invent 2019: [REPEAT] Best practices for Amazon S3 (including storage classes) (STG302-R)](/img/n.gif)
awesome presentation on DNS and hybrid arch with Route53 resolver!
one of the best Route 53 deep dive out there! Great work Gavin!
This was very, very good. Thank you.
Pretty clear explanation much thanks!
This was really useful. Great presentation!
One of the Best re:Invent i have ever seen 🙂
Excellent content nicely delivered...
Excellent!
Mindblowing.
My favorite
The only thing missing in this "deep-dive", is how to manage Resolver in multiple Regions. However, kudos for covering what you did in that very short 1 hour session! :)
I think that multiple regions iss solved via fourth model.
As a general rule, Route 53 Resolver and Resolver endpoints are regional services. We don't recommend using endpoints x-region. Private Hosted Zones can be associated to VPCs in multiple regions. But if you need to do forwarding to/from on-premises in multiple regions, we'd suggest putting endpoints and rules in each region individually so that the regions operate independently.
We do it manually region wise
Negative nelly over here.
Great job. Would love to see this expanded to talk about a Global deployment with VPCs in a dozen regions or so. With a thousand+ VPCs, options 3/4 seem to have a lot of AWS limits that would be reached.
The most likely limit to reach in option 4 would be that of the outbound endpoint ENIs. Each ENI has a hard limit of ~10K QPS and you can have up to six per Endpoint. It's possible to scale beyond that if you need to. The ENIs provide Cloudwatch graphs which you can use to keep track. But the outbound endpoints are only used for queries which need to be forwarded to on-premises resolvers. If you're forwarding 10Ks of queries to on-premises, you also need resolvers on-premises capable of handling that load.
What is the best approach for Spoke to Spoke DNS resolution?
You would point your DNS resolver or forwarder in the spoke to the DNS server in the spoke with selective rules, provided that your server supports it
If spoke-A's account is publishing a DNS zone and spoke-B's VPC needs to resolve it, the most scalable and reliable methods are typically either to share a private hosted zone cross-account and associate it to spoke-B's VPC (option 4 in the video). Another very simple and reliable approach (if you can do it) is to use public DNS, so there's no special config in any VPC. After that, the second approach outlined in the video can work (associate the zone to the hub and forward queries to the hub), but, as noted in the video, while easier to manage, it is something of a compromise, introduces new limits and complexity into DNS resolution.
completed this presentation more confused
Not an explanatory presentation in comparison to many other topics i have seen so far. Probably easy to catch for Networking guys
Less visual explanation more of you conversing it’s hard to visualize networking items just via conversation
"Deep dive" with no hands on demonstation...
One of the worst presentation ever.
Hater