I created a t1.micro instance, set up my security groups, and then associated this instance to an Elastic IP (the Elastic IP has a scope of "VPC", as it was my only option when creating the EIP).
I entered my public DNS URL into my browser, and I can access my site as expected; however, when I simply enter the Elastic-IP/Public-IP address associated with this DNS URL, I receive a blank white screen (empty HTML document). When I enter my DNS url on WhatsMyDNS.net, it shows the expected Elastic IP for all locations; also, when I dig +trace +add www.mySite.com, I see the expected nameservers; thus, I doubt this is a DNS propagation issue.
This leads me to believe I have an issue elsewhere, possibly with my security groups. For my security groups, I have the following configuration for debugging:
(Inbound)
HTTP, TCP, Port 80, 0.0.0.0/0
SSH, TCP, Port 22, 0.0.0.0/0
and
(Outbound)
All Traffic, All, All, 0.0.0.0/0
My VPC Network Interface has the same Security Group and is applied to the correct Instance, and likewise, my Elastic IP is associated to the correct Network Interface. Everything relates back to the proper EC2 Instance.
I'm far from an expert with AWS, and I've read numerous posts on this, but nothing seems to be glaringly obvious as to how I can go about fixing this. Could it be something with Network ACLs? Do I need VPN connections? Maybe something in the VPC Route Tables?
What can I check for specifically to debug and fix this? Has anyone experienced this previously and know where I may have gone wrong?
If more information is necessary, please let me know. Thank you.
Update
On my EC2 instance, if I stop my server:
on the DNS URL, I receive my expected 502 Bad Gateway, Nginx error (needless to say, I'm using Nginx as my front-end server). But...
on the Elastic IP address, I still receive that blank HTML form
I have discovered this in my error logs after making a few more attempts:
*564 connect() failed (111: Connection refused) while connecting to upstream
I assume this is a clear indicator of my problem, and I will debug this.
If anyone knows off-hand, feel free to comment of course.
If your DNS is correct, then it's not going to be anything related to security groups and ACLs, because they are completely unaware of DNS.
The problem is likely to be on your web server configuration. Since the hostname or IP address from the browser's address bar is sent to the web server in the HTTP Host: header with every request, the web server has the opportunity of serving different "sites" behind that single Elastic IP.
If you don't have it explicitly or implicitly (via some variant of a "default site" setting) configured to expect requests when the Host: header contains the IP address instead of the hostname, results vary by server, since it may have no idea what to do.
Check the web server logs for these blank screeen requests, as well as your config and the appropriate docs for the server software you are running.
Related
I have a domain that I own. I will say is example.com. I added SSO.example.com as a Type A record on GoDaddy with a value of 37.89.245.2(example).
The IP address is a elastic IP on a Windows AWS server.
I can ping the IP address but I can't ping the URL. Do I need to do something with the IP address on the AWS Windows server to be able to ping the URL?
This is pretty much one of my first web based projects so any help would be appreciated!
Ping is not a reliable test method in AWS because most security groups do not permit inbound ICMP protocol, which is used by Ping. So, if you really want to test connectivity, do it on a port that you actually need your application to support, such as HTTP (80) or trying an SSH/RDP connection.
Another common use for a Ping is to resolve the domain name to an IP address, since it displays the result on-screen. This can be a good way to check that your Amazon Route 53 configuration is correct. (Same as a dnslookup.)
I was jumping the gun a bit and the new NameServers I was using had not replicated completely yet. After replication completed everything was able to be pinged successfully.
I've registered domain with bigrock.in
Created ec2 instance in aws
created elastic ip
registered with route53 and gave my domain name
changed the name servers in bigrock with the provided names in bigrock
ssh to the ec2 instance with elastic ip
ran node.js app with forever
with the following environemnt variables
export ROOT_URL="www.domain.com"
at the time of route53 process, I created A record with www sub-domain to elasticIp
But, I'm not seeing anything at domain.com or at elasticIp xxx.xxx.xxx.xxx
Did I miss any steps, Is there anything wrong I did or do I need to do anything to make this works
EDIT
I haven't added any A or CNAME records to bigrock just changed the name server to the servers provided by ROuter53
Edit 2
that is my security group outbound details, My app is running on port 80.
Are those settings correct?
EDIT 3
My INbound rules
You've got a rule to allow all traffic from anywhere on the INBOUND security groups so its not that (make sure you fix this later when you get it working - as it is, its a bit of a security hole).
Next thing I would normally say is its a dns problem, but as you say you've tried going to the eip as well as the domain name its not that either.
Next likely candidates are:
The server isnt listening - it may be that it hasnt started properly try checking the logs,The machine's firewall is blocking connections. (try turning it off - keep this at VERY short time length though - its a huge risk in combination with your security group settings)
Or your server is not listening on port 80, e.g. it might be listening on 8080 or 443. Check the server config - by default browsers assume port 80 for http, if its not listening on that you will have to specify the port in the address bar as well e.g. http://example.com:8080
I've read a lot of questions already posted on this topic but none seem to provide an answer that helps, so forgive me for the duplicate post if I missed one...
I setup an elastic beanstalk single instance application. I then ensure'd the EC2 instance that it spawned had a security group to allow port 80 incoming requests. I then created an elastic ip and associated the EC2 instance with the ip, but neither the public dns or the elastic ip will respond to http requests.
Any ideas why this might be an issue for me?
In my case the problem was, even though I'd associated my elastic IP to my instance and created firewall rules in new security groups to provide access, I hadn't associated my new security groups with my instance. To fix this, I used the Change Security Groups menu from my Instances screen:
This caused the following popup to appear, where, sure enough, my new security groups existed but weren't associated with my instance:
After I (1) checked the appropriate boxes and (2) clicked on Assign Security Groups, all was well.
In classic-EC2 scenario:
Make sure port 80 is allowed in your AWS security group.
Make sure port 80 is allowed in local operating based firewall on your system. OR disable the local firewall for the time being to narrow down the issue.
Make sure that your application is indeed listening on port 80. You can check this by running telnet 127.0.0.1 80.
If above 3 points are satisfied, I don't see a reason why you are not able to access your application on port 80.
Let us know in case you are using VPC and not classic-EC2.
BTW, when you attach elastic IP, the instance will drop the public DNS that it had earlier. So now you should work with elastic IP only.
I have had a case where the elastic IP address was itself not responding on a specific port number. When I associated the instance with a different elastic IP, everything worked fine. So I resolved the issue by allocating a new elastic IP address. Root cause: Amazon evidently does not have an effective internal process for validating the integrity of an elastic IP. Obviously that's a tall order considering the things outside their control that can happen, with denial of service attacks and etc.
It cost me a day of doing progressive isolation to get to this, which I would have never otherwise suspected.
Any chance there is also a firewall running on the machine? I know in windows I usually need to open the port on the windows firewall AND on amazon's security.
Scenario:
I have an EC2 server which houses the api currently setup to accept connections from several iPads. I do not wish for network sniffers to see the JSON requests that are being exchanged between the servers and the devices. The idea is to have a secure protocol in place so that communication will be secured.
I have been told purchasing a SSL certificate is the way forward. The Amazon server instance I have running has an address in this format:
ec2-xx-xxx-xx-xxx.ap-southeast-1.compute.amazonaws.com/
this is where my web root is with all the appropriate web service files. My webservice urls look something similar to this:
ec2-xx-xxx-xx-xxx.ap-southeast-1.compute.amazonaws.com/Agent/Create
so on so forth. There is no hosting plan whatsoever (in the case that information is necessary).
I have been recommended to buy an SSL Cert from http://www.Godaddy.com and have thought about getting the up to 5 multiple domains SSL certificate package.
Question: 1
What things do I need to be made aware of in order to make sure nothing fails?
I have recently read that I may need to associate an elastic IP address to my instance, otherwise the IP of my instance will change on reboots? And if that is the case, that means that the SSL certificate that was used for this: ec2-xx-xxx-xx-xxx.ap-southeast-1.compute.amazonaws.com domain would no longer work since the ip address would have changed upon reboot and therefor me losing my secure domain?
Question: 2
If my thoughts in question 1 stands true, then my question would then be what is the most user friendly way or lets say, the way for beginners to create a dedicated url for my server instance (so that 1) the domain name doesnt randomly change upon server reboot (not sure when i would reboot anyway) and 2) does this mean I can have easier webservice urls that one can remember? such as.... www.pk.com/Agent/Create instead of the long ec2 ugly url?!
Any easy to follow tutorials would be very helpful. I have looked at a few articles that spoke about elastic ip address, SSL certificates, and other articles about renaming ec2 url, but I'm in a position where I dont actually know which one applies to me. lol
Hope someone can help. thanks
What you want to do is to get an elastic IP address. This lets you bind your instance to a particular IP address when you start it up. You can then register a hostname in DNS (Amazon don't help you with this part) and state that that hostname has the IP address that is the elastic IP address that you have registered.
The final piece is to get a server certificate (strictly, a keypair where the public part is the server certificate) that has the hostname in the CN field of its Distinguished Name, and to install that server keypair on the instance. (This is another part that Amazon don't help you with, and is in fact the same process as if you were hosting the hardware yourself.) Like that, the client
looks up the hostname and gets the elastic IP address,
connects and gets the server certificate, and
checks the server certificate and sees that the hostname it is for is the hostname that they expected. (There's a few other checks as well, such as whether the certificate was signed by a trusted certificate authority and whether the certificate is within its validity period.)
That allows the client to trust that who they have securely connected to is who they expected to securely connect to, which is a key part of establishing trust.
What you do not do is use the AWS machine names (internal or external) in the certificate you apply for. Those change and you really do not want to trust other people's VMs.
Donal's answer is the way to go. You need to explicitly register a domain and generate the SSL certificate containing the CN as that domain. Elastic IP addresses definitely are your friends in this issue. You will need them.
I added another answer in order to give another point of view: if you ever want to scale your backend solution, going that way will be more difficult. If you ever thought about adding more servers to host your web service, you should definitely set up an Elastic Load Balancer, add your instances to it, and point the domain you just registered to your Elastic Load Balancer. Then, you can purchase the SSL certificate and install it directly on your ELB, configuring SSL termination on the ELB. You will also configure the ELB so that connections arriving at port 443 will map to port 80 (or whatever port) on your servers. Don't worry, this is plain easy to set up.
Whenever you want to add more servers to your web service, it will just be a matter of setting up another EC2 instance (this process can - and should - be automated) and adding it to the ELB.
With this setup, you get rid of the need for Elastic IP addresses. All the connections go through the ELB.
I am trying to set up Elastic Load Balancing (ELB) in AWS to split the requests between multiple instances. I have created several images of my webserver based on the same AMI, and I am able to ssh into each individually and access the site via each distinct public DNS.
I have added each of my instances to the load balancer, but they all come back with the Status: Out of Service because they failed the health check. I'm mostly confused because I can access each instance from its public DNS, but I get a timeout whenever I visit the load balancer DNS name.
I've been trying to read through all the docs and googling it, but I'm stuck. Any pointers or links in the right direction would be greatly appreciated.
I contacted AWS support about this same issue. Apparently their system doesn't know how to handle cases were all of the instances behind the ELB are stopped for an extended amount of time. AWS support can manually refresh the statuses, if you need them up immediately.
The suggested fix it to de-register the ec2 instances from the ELB instead of just stopping them and re-register them when you start again.
Health check is (by default) made by accessing index.html on each instance incorporated in load balancer. If you don't have index.html in document root of instance - default health check will fail. You can set custom protocol, port and path for health check when creating elastic load balancer.
Finally I got this working. The issue was with the Amazon Security Groups, because I've restricted the access to port 80 to few machines on my development area and the load balancer could not access the apache server on the instance. Once the load balancer gained access to my instance, it gets In Service.
I checked it with tail -f /var/log/apache2/access.log in my instance, to verify if the load balancer was trying to access my server, and to see the answer the server is giving to the load balancer.
Hope this helps.
If your web server is running fine, then it means the health check goes on a url that doesn't return 200.
A trick that works for me : go on the instance, type curl localhost:80/pathofyourhealthcheckurl
After you can adapt your health check url to always have a 200 response.
In my case, the rules on security groups assigned to the instance and the load balancer were not allowing traffic to pass between the two. This caused the health check to fail.
I to faced same issue , i changed Ping Protocol from https to ssl .. it worked !
Go to Health Check --> click on Edit Health Check -- > change Ping protocol from HTTPS to SSL
Ping Target SSL:443
Timeout 5 seconds
Interval 30 seconds
Unhealthy Threshold 5
Healthy Threshold 10
For anyone else that sees this thread as this isn't listed:
Check that the health check is checking the port that the responding server is listening on.
E.g. node.js running on port 3000 -> Point healthcheck to port 3000;
Not port 80 or 443. Those are what your ALB will be using.
I spent a morning on this. Yes.
I would like to provide you a general way to solve this problem. When you have set up you web server like apache or nginx, try to read the access log file to see what happened. In my occasion, it report 401 error because I have add the basic auth in nginx. Of course, just like #ivankoni remind, it may because of the document you check is not exist.
I was working on the AWS Tutorial on hosting a web app and ran into this problem. Step 7b states the following:
"Set Ping Path to /. This sends queries to your default page, whether
it is named index.html or something else."
They could have put the forward slash in quotations like this "/". Make sure you have that in your health checks and not this "/." .
Adding this because I've spent hours trying to figure it out...
If you configured your health check endpoint but it still says Out of Service, it might be because your server is redirecting the request (i.e. returning a 301 or 302 response).
For example, if your endpoint is supposed to be /app/health/ but you only enter /app/health (no trailing slash) into the health check endpoint field on your ELB, you will not get a 200 response, so the health check will fail.
I had a similar issue. The problem appears to have been caused due to my using a HTTP health check and also using .htaccess to password protect the site.
I got the same error, in my case had to copy the particular html file from s3 bucket to "/var/www/html" location. The same html referenced in load balancer path.
The issue resolved after copying html file.
I had this issue too, and it was due to both my inbound and outbound rule for the Load Balancer's Security Group only allowing HTTP traffic on port 80. I needed to add another rule for HTTPS traffic on port 443.
I was also facing that same issue,
where ELB (Classic-Load-Balancer) try to request /index.html not / (root) while health check.
If it unable to find /index.html resource it says 'OutOfService'. Be Sure index.html should be available.