I have an issue that I have been trying to work out for a while now. I am experimenting with AWS and thinking of moving sites over, but I can't get DNS to work with OpsWorks apps. I have a PHP / RDS stack that I have a few apps in.
These were working great except for the issue of OpsWorks instances having a dynamic DNS that changes upon instance reboot. I don't want to have to change my DNS records in Route53 every time that happens, so I implementated an EIP, registered it with the instance, and registered it with OpsWorks. I added rules to the policy that the EC2 uses for default VPC to accept incoming HTTP requests as well.
Now, when I add an A record to my DNS zone that points to the EIP, and add my domain in the OpsWorks app settings, my domain does not resolve in the browser. What am I missing?
OpsWorks does very little to manage DNS externally. All DNS management should be done through Route53.
To start, make sure you have your nameserver (NS) record properly configured to reference your domain in your hosted zone, and also make sure that whatever DNS provider you're using (e.g. name.com, etc) is configured to point to those DNS servers.
Also, regarding this point:
I don't want to have to change my DNS records in Route53 every time
that happens, so I implementated an EIP, registered it with the
instance, and registered it with OpsWorks.
You should really be using an elastic load balancer for this, not an elastic IP. You can associate an elastic load balancer with your OpsWorks stack so that any instances launched within the OpsWorks stack will be associated with that elastic load balancer. The additional benefit is that you can have multiple servers hosting your application as you scale.
Related
I have a domain for my new application, lets call it: app.example.com. Thats a domain registered outside my AWS account.
The application is running on AWS EKS:
Two Deployments
Two Services
One Ingress
Quite simple I guess. Those pods are running on Fargate, so I managed to configure the AWS Load Balancer controller who creates an Application Load Balancer when an Ingress is created.
Then, there is also an external-dns pod configured pointing to a hosted zone on Route 53 (example.com).
Now, each time an Ingress is re-deployed, AWS LBC re-creates the ALB with a different DNS domain, and external-dns is adding records on the hosted zone like:
If I go to the ALB DNS, the application can be reached, but if I go from the domain app.example.com it can´t.
In a close future, my idea is to use a Blue/Green deployment and that will change the DNS of the ALB, so I have to think of a solution having into account the next step.
Maybe it´s something about the external domain, I mean, AWS is not hosting the domain but I might need some kind of permission or even configure the domain from the other page?
Solved, what I was missing is reading in depth the documentation of AWS. Route 53 provides a set of Name Servers for hosted zones. On the external registrar, I had to create NS records pointing to the NS of AWS.
More info:
SafeNames
1and1
GoDaddy
AWS Wiki - Step 7
The current setup was the application is load-balanced at AWS. The domain(www.Example.com) we are using is registered at GoDaddy.com.
My concern is that, do we need to upgrade our GoDaddy hosting even if the files are load-balance at AWS?
Let's say that we have had a 50K concurrent users.
Thanks for the insight in-advanced.
When you say "the application is load-balanced at AWS", it suggests that there is the following setup on AWS:
One or more Amazon EC2 instances running a web application, and
An Elastic Load Balancer that is directing incoming traffic to those instances
Your GoDaddy account probably has a Domain Name with a CNAME record that points to the DNS Name of the Load Balancer on AWS.
If this is true, then you do not need a "hosting plan" on GoDaddy, since it would just be managing your Domain Name. Scaling is not necessary for Domain Names.
Increasing the load would possibly require creating additional EC2 instances on AWS, but you might have an Auto Scaling group doing this for you automatically.
You should investigate what you actually have on GoDaddy and on AWS.
I have a Wordpress website with a GoDaddy domain being hosted on SiteGround using the nameservers. I am looking to switch to a React App which is currently running on an EC2 instance in AWS. I want to run the ec2 instance (aka the react app) on a subdomain like beta.domain.com inside SiteGround while still keeping the Wordpress website since its a part of my business. I tried creating a subdomain in SiteGround and then pointed it to my EC2 instance elastic IP (the public ipv4) using an A record but it is showing "This site can't be reached" error once I go to beta.domain.com.
What am I doing wrong? How do I run the EC2 instance in a subdomain hosted in SiteGround?
EDIT
Thank you, everyone, for your help. The problem was the SSL certificate for the HTTPS. The website wasn't coming on due to the HTTPS setup on the Nginx on the EC2 instance. After I put in the details of the certificate it runs properly with just the A record.
Any public address in the AWS environment are never accessible from outside the security groups. Even if you try to ssh from your own machine and if it is not in the inbound rule of the security group of your EC2 instance. I feel there are 3 ways out here.
1.) Adding an all traffic rule in your EC2 Security group inbound rule. This is not recommended as it opens all traffic to your machine.(additional tip: set up secure ssh key with the machine)
2.) Use an ELB to route traffic to your EC2 instance. ELB will provide you with a DNS record which can be used an a CNAME in godaddy(Point 3 shows how to map it as a A record in GoDaddy)
3.) Using Route 53 Hosted Zones - You could delegate your DNS to be managed by AWS Route 53. This way all traffic will be routed to your machine by AWS R53.
Another tip: Elastic IP can also be used which are like permanent static IP Addresses accessible from across internet. This provided a secure communication method to your instances.
Let me know what could be the favorable solution for you. I could help you out further
If you have registered your domain name with Goaddy, you can create subdomain in Godaddy as CNAME and point it to static IP address of your ec2 instance. Here is a link to guide you.
Also your main domain name will point to your Wordpress website on SiteGround.
Now that you have EC2 instance, you can also run a wordpress site on that instance if you like.
I have a Java/Tomcat application hosted in AWS ElasticBeanstalk and bought a domain from GoDaddy and the domain points to the IP of the EC2 instance. So when I hit, for example www.abc.com, it points to the AWS IP and the application opens.
I haven't used Route 53, as I am in free tier, I added the EC2 IP in GoDaddy.
Now I want to add HTTPS/SSL to the domain using Let's Encrypt.
I searched for the solution but I found that it is also done using GoDaddy cPanel, as I have hosted the application in AWS and just registered domain from GoDaddy, I cannot do this.
How can I achieve this ?
You will want to use an Elastic Load Balancer (also known as Classic Load Balancer). I know you don’t want to use a Load Balancer but this is free and the AWS best practice. Here’s more detail - https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/elb-create-https-ssl-load-balancer.html
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.