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

Поділитися
Вставка
  • Опубліковано 21 вер 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

  • @AlexLi-zige
    @AlexLi-zige 2 роки тому +2

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

  • @38khampha
    @38khampha 4 роки тому +5

    awesome presentation on DNS and hybrid arch with Route53 resolver!

  • @bevomcbevenstein
    @bevomcbevenstein 4 роки тому +4

    This was very, very good. Thank you.

  • @kirannagonde1532
    @kirannagonde1532 2 роки тому

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

  • @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.

  • @FirehawkVFX
    @FirehawkVFX 4 роки тому +2

    This was really useful. Great presentation!

  • @Ntwobike
    @Ntwobike 4 роки тому +2

    Pretty clear explanation much thanks!

  • @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.

  • @fringefringe7282
    @fringefringe7282 2 роки тому

    Mindblowing.

  • @alienekoo
    @alienekoo 3 роки тому

    My favorite

  • @akshaysaxena9137
    @akshaysaxena9137 4 роки тому

    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.