As the industry iterates beyond simple cloud deployments, application & identity architects confront new challenges in deploying and managing complex application instances which span the globe across multiple provider regions. Rapid failover from one region to another is a critical component for these distributed applications- but did you know how much your cloud DNS service and DNS architecture impact the speed that traffic can be rerouted from one region to another? In this talk, Jon Lehtinen shares his experiences testing several DNS architectures, and highlights how different resolution methods, failover policies, and other seemingly inconsequential components greatly impact how instantaneous- or not- your failover can be. Join him as he walks through tests of several cloud DNS architectures in search of instantaneous failover.
Key Takeayways:
1) Even in well-architected, multi-region application deployments, there are significant differences in failover times based upon the DNS resolution method selected. Balancing region selection/geolocation with speed of recalculation on regional failover is not as rapid as one would think- and I have the benchmarks that prove it.
2) There are several additional, subtle settings which greatly impact the failover speed from one region to another within a cloud service- things like TTL on the DNS service itself, the frequency, timeout duration, and failure threshold of health checks, as well as the nature of the load balancers distributing traffic to application nodes. I also have data that show the impact of each of these items.
3) There may be a true, lower limit threshold for failover speed across regions when using native cloud services like Route53 that enterprise architects need to be aware of when designing their applications and anticipating their app's tolerance for interruption during failover. The instantaneous failover may need to start within an organization's own network and then step into the public cloud as it seems possible to narrow the window for failover to below the threshold for triggering an outage alert, but not below the notice of an API call or automated process.
4) The quickest failover methods require a significant number of DNS aliases, health checks, and routes, all of which need to be updated each time any of the DNS endpoints get updated. As such, a mature infrastucture-as-code process is a must to maintain the best designs, otherwise the opportunity for human-introduced error is very likely.
With the evolution of the wireless network, the transformation of the 5G Core Network to a RESTful design of standardized open Application Programming Interfaces (APIs) used in the service-based architecture (SBA) enabling the various authorized network functions (NFs) to access services. The authorization framework used for the NF service access is based on the OAuth 2.0 framework. Similarly, the authorization framework used for capability expose to third-parties, such as service providers and vertical industries outside the mobile network operator’s (MNOs) domain, is also based on OAuth 2.0.
This presentation will provide an overview of the 5G Core Network SBA, the key architectural components, security threats and recommended measures for protecting it in order to enable this fundamental shift in next-generation cellular system and unlock the potential of what 5G can deliver.
Key Takeaways:
* Provide an overview of the 5G Core Network SBA and key architectural components including the API and authorization framework defined.
* Provide an overview and detailed examples of the security threats that are introduces with this architecture.
* Recommendations for how to address the security threats both in terms of implementation and standards development community.
