AWS re:Invent 2019: Deep dive on DNS in the hybrid cloud (NET410)

Поделиться
HTML-код
  • Опубликовано: 6 сен 2024
  • 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.

Комментарии • 30

  • @38khampha
    @38khampha 4 года назад +5

    awesome presentation on DNS and hybrid arch with Route53 resolver!

  • @AlexLi-zige
    @AlexLi-zige 2 года назад +2

    one of the best Route 53 deep dive out there! Great work Gavin!

  • @bevomcbevenstein
    @bevomcbevenstein 4 года назад +4

    This was very, very good. Thank you.

  • @smellyvideo
    @smellyvideo 4 года назад +5

    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! :)

    • @RaulViitor1
      @RaulViitor1 4 года назад

      I think that multiple regions iss solved via fourth model.

    • @gmccullagh
      @gmccullagh 4 года назад +5

      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.

    • @komalthecoolk
      @komalthecoolk 3 года назад

      We do it manually region wise

    • @sebastianalfarolopez6205
      @sebastianalfarolopez6205 Год назад

      Negative nelly over here.

  • @kirannagonde1532
    @kirannagonde1532 2 года назад

    One of the Best re:Invent i have ever seen 🙂

  • @FirehawkVFX
    @FirehawkVFX 4 года назад +2

    This was really useful. Great presentation!

  • @jbabaria
    @jbabaria 3 года назад +1

    Excellent content nicely delivered...

  • @127bits7
    @127bits7 3 года назад +2

    Excellent!

  • @zemanekm
    @zemanekm 2 года назад

    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.

    • @gmccullagh
      @gmccullagh Год назад

      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.

  • @Ntwobike
    @Ntwobike 4 года назад +2

    Pretty clear explanation much thanks!

  • @fringefringe7282
    @fringefringe7282 2 года назад

    Mindblowing.

  • @alienekoo
    @alienekoo 3 года назад

    My favorite

  • @akshaysaxena9137
    @akshaysaxena9137 3 года назад

    What is the best approach for Spoke to Spoke DNS resolution?

    • @komalthecoolk
      @komalthecoolk 3 года назад

      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

    • @gmccullagh
      @gmccullagh 3 года назад

      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.

  • @manishkashyap1594
    @manishkashyap1594 2 года назад

    Not an explanatory presentation in comparison to many other topics i have seen so far. Probably easy to catch for Networking guys

  • @francistony7110
    @francistony7110 4 года назад +3

    completed this presentation more confused

  • @kawshiksark1
    @kawshiksark1 2 года назад

    Less visual explanation more of you conversing it’s hard to visualize networking items just via conversation

  • @jimbosliceOG
    @jimbosliceOG 4 года назад

    "Deep dive" with no hands on demonstation...

  • @sauravverma6179
    @sauravverma6179 4 года назад

    One of the worst presentation ever.