This DNS name and load-balancing architecture shows how to use a Route 53 can be used to send traffic to both an on-premises server and an EC2 deployment. The health checks on Route 53 records (for example-on-prem.xxx.cucloud.net and example-nlb.xxx.cucloud.net) ensure that Route 53 will respond with records that are actually functional.
Draw.io Diagram File: nlb-r53-architecture.drawio
Notes
- This scheme implements weighted round-robin traffic routing at the top level. However, individual clients (e.g. servers) are likely to cache DNS results which will reduce the effectiveness that some clients experience in the event of a failure of the on-premises system (if they were routed to the on-premises system).
- When none of the EC2 instances behind the NLB are healthy, the NLB will route requests to them all. Unfortunately, this means that the Route 53 health check for the NLB will always be successful, since the NLB will always accept TCP connections regardless of state of the NLB targets. See https://docs.aws.amazon.com/elasticloadbalancing/latest/network/target-group-health-checks.html: "If one or more target groups does not have a healthy target in an enabled Availability Zone, we remove the IP address for the corresponding subnet from DNS so that requests cannot be routed to targets in that Availability Zone. If there are no enabled Availability Zones with a healthy target in each target group, requests are routed to targets in all enabled Availability Zones."
- It IS possible to get the internal IP address of the NLB for each subnet to which it is deployed. AWS documentation suggests a method to get the internal IP addresses used by an NLB deployment for use in security groups. Thus, unlike ALBs and ELBS, it appears that these internal IP addresses for an NLB are static for the lifetime of the NLB. See https://docs.aws.amazon.com/elasticloadbalancing/latest/network/target-group-register-targets.html#target-security-groups