I'm trying to experiment with changing the domain name & certificate associated with a GCP Load Balancer.
Currently, the domain name and certificate is attached to Load Balancer A, and I want to attach that domain to Load Balancer B with no downtime to the site.
The two load balancers are of different types, so I cannot change the associated Backend to a Service B.
I'm trying to change the certificate associated with Load Balancer B to the preferred domain, then update the DNS records to point to that Load Balancer.
However, this results in a 404, "your connection is unsecure".
The certificate is shown in ACTIVE state within GCP. As it has previously been activated when attached to Load Balancer A.
Is there anyway to avoid the site being unavailable, without the unsecure certificate warning?
A short answer would be NO.
Moving the domain from Load Balancer A to B would require updating the current A Record of your DNS from the front end IP of Load Balancer A to the front end IP of Load Balancer B. In general, DNS changes are processed and propagated within 48 hours, but sometimes it can take up to 72 hours.
Secondly, the certificate requires to have the correct front end IP for successful provisioning. Since the current certificate points to the front end IP of Load Balancer A, you'll need to reprovision another SSL certificate for Load Balancer B which will be associated to its own Front End IP.
Provisioning a Google-managed certificate might take up to 60 minutes from the moment your DNS and load balancer configuration changes have propagated across the internet. If you have updated your DNS configuration recently, it can take a significant amount of time for the changes to fully propagate.
The best approach will be to plan these changes ahead of time.
Related
It sounds like I cannot use an elastic ip with AWS Application Load Balancer.
I currently own a domain through GoDaddy and the DNS server points to the load balancer via the CNAME. However, if the load balancer dies and gets recreated, its url changes and I then have to change the CNAME and wait for the change to propagate.
There must be a solution around this - what is it?
It looks like the solution might be to use two load balancers - https://aws.amazon.com/blogs/networking-and-content-delivery/using-static-ip-addresses-for-application-load-balancers/, but this seems really excessive - I have a small application right now.
As far as I know, the only way to have a fixed static-IP for a LB is to use a Network Load Balancer.
As stated here
Support for static IP addresses for the load balancer. You can also assign one Elastic IP address per subnet enabled for the load balancer.
An Elastic Load Balancer retains its DNS name as long as you don't replace it manually. If you still want to have a temporary, low-cost solution to this problem, you can consider the following approach:
Assuming the application is deployed in a private subnet, I would proxy the traffic through an EC2 instance until your primary DNS changes propagate.
Launch a small EC2 instance and attach an Elastic IP to it (consider your bandwidth requirements to determine which size).
Configure a proxy (nginx) to forward traffic to your application.
Configure active-passive DNS failover using ELB DNS name and EIP.
I have multiple EC2 instances connected to a load balancer and the traffic is routed to load balancer using Route53.
Suddenly, I can longer access my website if I type my domain name "www.domain.com". I tried to debug the problem by directly typing the load balancer DNS in the browser and it worked.
To investigate the problem further, I created a single instance and directed the traffic using route53 to the current public IP of the instance. If I use the domain name "www.domain.com" in the browser, I get an error stating that the site can't be reached. If I use the public IP of the instance I can reach the page. I think that means that Route 53 is not directing the traffic to instance.
How can I check that because I have been in this problem for almost two days. Is there is a way to check whether Route 53 routes traffic or not? I am sure my security group of allows traffic For HTTP, HTTPS, SSH and the port numbers are correct.
I've set up my application on AWS Elastic Beanstalk. I added a load balancer and pointed a CNAME for 'www' to it. But now I need to get root pointed there too. I can't use Route53 and use AWS nameservers because the client wants to use theirs. How can I get root to my app? Can I redirect the traffic? The tech lead I'm working with suggested setting up a server to do the redirect?
Since AWS ELB's only offer DNS Record (Instead of IPs) you need to use a CNAME mapping. However with DNS, CNAMEs do not allow root domain to point to it. To overcome this AWS has provided Alias Records (Custom implementation to AWS) to point root domain to ELBs.
If your client want to use their nameservers still you can use, AWS Route53 in between to solve this with following steps.
First create a Public Hosted Zone in Route53 for your domain.
Then create a record set inside the Hosted Zone for the root domain to point to the ELB with Type = A - IPv4 Address, Alias = Yes with ELB CNAME as for the Alias value.
In the external domain management service, create a NS record to point the root domain to Route53 nameservers.
Then when the DNS resolution happens, the root DNS query will first go to external nameservers(Managed outside of Route53) and then it will be forwarded to route53 where it will resolve the ELBs IP address and sent back.
You can set up a machine with a single static IP address that does nothing but redirect requests to the www host. Then you can put an A record on the bare domain at the apex of the DNS zone pointing to that machine.
There is at least one service, http://wwwizer.com/naked-domain-redirect, that will do this for you. (I'm not affiliated with this service, but it appears to do what it claims and will serve your purpose. There are probably others like it.)
Ideally, though, you'd persuade your client to change the authoritative nameservers to point to a Route 53 hosted zone that you create for them. They are still the registrant and "owner" of their domain, and can take control back from you by simply changing the nameservers to something else.
I generally persuade clients with the explanation that our load balancer infrastructure is integrated with the DNS servers so that if a balancer node fails, or we need to add or scale up capacity, or experience a traffic surge or DDoS event, the load balancer system will automatically update the DNS records for their domain to try to mitigate the issue and keep the site up. To do otherwise is to do things in such a way that removes those layers of redundancy.
Ideally, you can set up a apache server with a static IP, and install a free SSL certificate on that web server at first.
Second you need to redirect your root domain name request to AWS ELB.
Then go to your DNS management and set up your apex point to the server you created.
It is now possible to setup a Network Load Balancer and allocate one or more Elastic IP Addresses to it (one per Availability Zone). The Network Load Balancer can have an Application Load Balancer as a target. The Application Load Balancer would target the Elastic Beanstalk. An A record can then be created in the external DNS for each Elastic IP Address of the Network Load Balancer.
If you don't need the functionality that the Application Load Balancer provides, you may be able to target Elastic Beanstalk or whatever application directly from the Network Load Balancer.
Since AWS ELB's only offer DNS Record (Instead of IPs) you need to use a CNAME mapping. However with DNS, CNAMEs do not allow root domain to point to it. To overcome this AWS has provided Alias Records (Custom implementation to AWS) to point root domain to ELBs.
If your client want to use their nameservers still you can use, AWS Route53 in between to solve this with following steps.
First create a Public Hosted Zone in Route53 for your domain.
Then create a record set inside the Hosted Zone for the root domain to point to the ELB with Type = A - IPv4 Address, Alias = Yes with ELB CNAME as for the Alias value.
How can I assign a static IP address to a ELB. Seems like I cannot.
Some articles online asks to create a Route 53 record but this requires changing CNAME of domain which also redirect email traffic. I just want to change A record not CNAME.
Some articles also mention that I can use a EC2 instance as a reverse proxy. But will a single proxy be able to handle a lot of traffic?
Any solution for this?
AWS' Elastic Load Balancer is actually elastic on two levels as described here:
http://shlomoswidler.com/2009/07/elastic-in-elastic-load-balancing-elb.html
The first level is the load balancer itself. In order to make sure that ELB can scale to whatever volume you have and burst to whatever volume you suddenly encounter, AWS assigns a 'static' DNS hostname (e.g. MyDomainELB-918273645.us-east-1.elb.amazonaws.com). That hostname points to multiple IP addresses. You can see that (from a command line) by running
$ host MyDomainELB-918273645.us-east-1.elb.amazonaws.com
MyDomainELB-918273645.us-east-1.elb.amazonaws.com 172.31.7.2
MyDomainELB-918273645.us-east-1.elb.amazonaws.com 172.31.11.33
The second form of elasticity within the ELB is obviously then ELB directing the query to one of your EC2 instances in the pool.
So, you can see that trying to assign a static IP address to the load balancer would be self-defeating.
Using an EC2 instance as a reverse proxy would also seem self-defeating as you would then create a bottleneck before even getting to the ELB. Might as well just create your own load balancer.
The recommended solution (which you've pointed out) is to create a CNAME that points to the ELB hostname (which won't change).
i.e. my-app.mycompany.com ->
MyDomainELB-918273645.us-east-1.elb.amazonaws.com
This would allow you to integrate your scalable application, behind the ELB within your domain.
I'm not sure I fully understand why you cannot create a CNAME in your DNS or what that has to do with directing email traffic, can you explain?
A new feature in AWS (I believe it was announced at Re:Invent 2017) allows for static IPs with Network Load Balancers (NLB). NLB can only handle layer 4 (TCP) and not HTTP specifics (layer 7).
You can assign one Elastic IP address per availability zone.
For details see the AWS blog post or the NLB documentation.
The "Classic Load Balancer" and "Application Load Balancer" do not support static IPs. If you need a feature only provided by those, you have to fall back to the CNAME solution described above.
A blog was recently published by AWS support on this topic leveraging NLB to provide static IP to Classic and Application load balancer - https://aws.amazon.com/blogs/networking-and-content-delivery/using-static-ip-addresses-for-application-load-balancers/
Summary of solution as described by the post
We end up with a TCP listener on a NLB that accepts traffic and forwards it to an internal ALB. The ALB terminates TLS, examines HTTP headers, and routes requests based on your configured rules to target groups with your instances, servers, or containers. The AWS Lambda function keeps everything in sync by watching the ALB for IP address changes and updating the NLB target group. In the end we’ll have a few static IP addresses that are easy for whitelisting, and we won’t lose any of the benefits of ALB. Note that we will be sending all of the traffic through two load balancers
I found setting up AWS Global Accelerator very straight forward and simple. It created 2 static IP Addresses and a static DNS pointing to my Application load balancer.
Configuring Global Accelerator
Set listeners as TCP port 80, 443
Select your load balancer endpoint (AWS Global Accelerator Configuration)
Add cname record for your dns pointing to the static dns it created
(mywebsite.com > globalacceleratorDNS.com). If any client needs to
whitelist, give them the 2 static IP it created
Pricing is $18 per month + a few pennies per GB of data transfer.
I'm pretty sure its cheaper than the NLB, Nat Gateway, Elastic IP setup.
https://docs.aws.amazon.com/global-accelerator/latest/dg/about-accelerators.html
For little traffic, it might be a solution to set up an EC2 Instance running Nginx as a forwarding proxy.
So you can use the EC2's static IP Address to forward your traffic resolving the ALB's DNS name.
However, it's a kind of a hack, but using a Global Accelerator or an NLB seems to me also like a hack :-)
Unlike the Network Load Balancer, the Application Load Balancer (ALB) does not support Elastic IPs, but that's not the worst part. If you use Route 53 together with the ALB, the DNS automatically sets the TTL to 60 seconds. This appears to be causing problems for our institutional - mainly government - customers running older Windows DNS servers. They just can't keep up with the ALB's Listener changing its public-facing IP on such a short notice. Older DNS infrastructure is either not respecting or is not capable of handling such aggressive TTL.
While I don't like it, AWS recommends to put a Network Load Balancer in front of the Application Load Balancer, per here: https://aws.amazon.com/blogs/networking-and-content-delivery/using-static-ip-addresses-for-application-load-balancers/
I have a sub domain and pointed this to an amazon elastic load balancer which includes a few EC2 instances. To point the sub domain we created a CNAME record and put the value of the DNS name of the load balancer.
Now my question is:
You know the IP address of elastic load balancer changes randomly.
So if I request to resolve DNS of my sub domain from any application is there any possibility that there will be a DNS propagation delay issue (which can cause to return me old IP address of the load balancer) if the load balancer's IP has changed.
Should I wait for the propagation of the new IP? Or will the new IP be propagated real time even if the elastic load balance changes just before the DNS request gets resolved?
You need not worry about the IP address of the ELB and its tendency of changing IP address. Instead of the IP address in the CNAME record you just need to put one of the DNS Names (IPv4 or IPv6) an ELB would provide ex: Test-ELB-12345678.us-east-1.elb.amazonaws.com
Quote from the ELB info page
Note: Because the set of IP addresses associated with a LoadBalancer
can change over time, you should never create an "A" record with any
specific IP address. If you want to use a friendly DNS name for your
load balancer instead of the name generated by the Elastic Load
Balancing service, you should create a CNAME record for the
LoadBalancer DNS name, or use Amazon Route 53 to create a hosted zone.
For more information, see Using Domain Names With Elastic Load
Balancing.
There seems to have been such concerns some years ago. You can read the following interesting article which describes some of the potential issues: Elastic Load Balancer: An Elasticity Gotcha
A new ELB IP is added to your ELB pool. The clients of another application that keep the old DNS entry will hit your application:
The problem is that DNS resolution is cached at many layers across the internet. When the ELB scales up and gets a new virtual appliance IP address from the global pool, some client somewhere might still be using that IP address as the resolution of a different ELB’s DNS name. This other ELB might not even belong to you. A few hours ago, another ELB with a different DNS name returned that IP address from a DNS lookup. Now, that IP address is serving your ELB. But some client somewhere may still be using that IP address to attempt to reach an application that is not yours.
An ELB IP is removed from your ELB pool and assigned to some other application's ELB pool. Your clients that keep the old DNS entry will end up hitting that other application:
The flip side occurs when the ELB scales down and releases a virtual appliance IP address back to the global pool. Some client somewhere might continue resolving your ELB’s DNS name to the now-relinquished IP address. When the address is returned to the pool, that client’s attempts to connect to your service will fail. If that same virtual appliance IP is then put into service for another ELB, then the client working with the cached but no-longer-current DNS resolution for your ELB DNS name will be directed to the other ELB virtual appliance, and then onward to back-end instances that are not yours.
Now, this article is from 2009 and as of March 2010, Amazon has partially addressed this concern:
ELB IP addresses will continue to direct traffic to the ELB for one hour after being withdrawn from that ELB’s DNS pool
Keep in mind that some clients that cache DNS entries for longer periods of time could still be affected.