- Newest
- Most votes
- Most comments
Hello, It depends on the use-case of the public IP. You can open up a support Ticket and request the same and also explain the detailed use-case and how it would help the team or ease the onboarding towards the AWS. also, it depends on the type of Support plan you have to get to the right person in the accounts team. Without the use-case, it is unlikely to get the same. Hope this helps.
One way to accomplish this would be CloudFront, however you would not have a static public IP.
- Create a CloudFront distribution with multiple Origins in an Origin Group. The Origin points to your DC.
- Set up your FQDN as a CNAME to the CloudFront Distribution, assuming your own DNS here.
- Set the caching policy to NoCache if you are serving up dynamic content
You could also use Route 53 to host the FQDN and use health checks with primary and secondary pointing your your DC.
It seems the Elastic Load Balance may do this in conjunction with Route53 but I'm still trying to connect the pieces together to see if it'll actually work like I think it will.
You can definitely do this with private IP addresses. Consider a (very primitive) network diagram:
Web client -> AWS Public IP -> Application Load Balancer -> VPN -> On premises router -> On premises host
Here, we take the traffic from the load balancer, carry it across the VPN to your data centre where it is delivered to the host. This is possible because ALB can have targets which are defined purely by IP address.
You can also replace the VPN with a Direct Connect service.
You cannot, however, point ALB to a public IP address.
As per one of the other answers here, a better solution would be to use CloudFront with the caveat that it wouldn't be a single, static IP address. But there are other benefits such as WAF, caching and request modification if you need it.
Relevant content
- AWS OFFICIALUpdated a year ago
- AWS OFFICIALUpdated a year ago
- AWS OFFICIALUpdated 2 years ago