I want to develop my application separately (API, JOBS, WEB), so that it stays in this manner:
API: api.myaddress.com
JOBS: jobs.myaddress.com
WEB: myaddress.com
I know how to do that with distinct instances with Amazon and GoogleComputing, however, I was wondering IF, I could setup a single instance to do all that, and each DNS namespace, going to a different port on that machine, like:
api.myaddress.com resides in xxx.xxx.xxx.xxx:8090
jobs.myaddress.com resides in xxx.xxx.xxx.xxx:8080
myaddress.com resides in xxx.xxx.xxx.xxx:80
Also if that is possible, I don't know where I should configure that (Is it in the DNS, or a specific setup on my instance in Amazon/Google?)
Why do you want them to go to a different port? Its certainly not necessary. You can use DNS to point all of those domains/subdomains to a single server/ip address, and then thru your webserver configuration bind the various subdomain names to each particular website on that server.
In IIS you bind in the IIS Manager tool, and apache has a similar ability:
http://httpd.apache.org/docs/2.2/vhosts/examples.html
It sounds like what you are looking for is an HTTP reverse proxy. This would be a web server on your machine that binds to port 80 and, based on the incoming Host: header (or other criteria) it forwards the request to the appropriate Node.js instance, each of which is bound to a (different) port of its own.
There are several alternatives. A couple that immediately come to mind are HAProxy and Nginx.
DNS cannot be used to control which port a request arrives at.
Another approach, which is (arguably) unconventional but nonetheless would work would be to set up 3 CloudFront distributions, one for each hostname. Each distribution forwards requests to an "origin server" (your server) and the destination port can be specified for each one. Since CloudFront is primarily intended as a caching service, you would need to return Cache-Control: headers from Node to disable that caching where appropriate... but you could also see some performance improvements on responses that CloudFront can be allowed to cache for you.
what you are looking for is a load balancer (ELB in case of amazon).
setup the load balancer to send traffic to the different ports and at DNS level setup CNAMES for your services that point to the 3 load balancers that you have.
Related
I have 2 clustered EC2 instances with 2 Classic ELB's one is for the DNS xxx.com and one for xxx.net. Both point to the same cluster of EC2 instances. My application needs to know whether the incoming request came from the .com or the .net URL.
The problem is that technically the ELB forwards the request, so I lose that in the header. I can get the IP address of the ELB, but Amazon will occasionally drop the ELB and give us a new one with a different IP, so it works for a while, then breaks out of nowhere.
Does Amazon offer something like a "static" ELB? I can't find anything so I assume not.
Is there any other way around this?
My application needs to know whether the incoming request came from the .com or the .net URL.
Read this from the incoming HTTP Host header. If it doesn't contain one of the two expected values, throw an error (503, 421, whatever makes the most sense) and don't render anything.
The problem is that technically the ELB forwards the request, so I lose that in the header.
I don't know what this statement is intended to convey. The Host header is set by the user agent and is not modified by the ELB so your application can read it from the incoming request.
You should not be looking at the internal IP address of the ELB for anything except to log it for correlation/troubleshooting if needed.
Of course, you also don't actually need 2 Classic ELBs for this application. You can use a single classic balancer with a single certificate containing both domains, or a single Application Load Balancer with either a combo cert or two separate certs.
Tonight, my client is going to be on a high-profile television show to pitch his business. I created their API and had it running on a small server on Google Cloud Platform with a static IP on the instance since that was all that we needed.
Now I am trying to scale it for the inevitable traffic, I'm moving to a load balancer and multiple, scalable instances. I thought I could use the IP address from the instance and transfer it to the load balancer. But the load balancer requires a global forwarding IP, and the IP address of the instance is only regional.
For some reason, the mobile developers hardcoded their URLs to the IP address and not the domain name. It's too late in the day for them to resubmit the app code, so I need a way to forward the regional IP to the global forwarding IP that the load balancer takes.
Could I do this through Google Cloud Platform? Or should I set this up through the domain name provider?
I realize that this may break some rules on SO, but I only need the answer for today, the question can come down tomorrow if it does break rules.
Your best shot today may be to increase the memory/cpu of the current machine type and/or use something like Nginx to proxy requests from the instance to the load balanced fleet.
It is possible to use nginx as a very efficient HTTP load balancer to
distribute traffic to several application servers and to improve
performance, scalability and reliability of web applications with
nginx.
I would do both: increase instance capacity and try an Nginx proxy on that instance. You will still have a single point of failure, but would be able to handle greater capacity.
Essentially this configuration will forward requests from the instance (the regional ip) to your GCP load balancer (the global ip)
I have a single Windows Amazon EC2 instance and one public IP. The instance is running multiple web server EXEs which all sit on port 80. I want to have different domain names which I want to point to each server. On my old dedicated server I achieved this simply by having different public IPs, but with Amazon EC2 I want to keep to just one public IP.
I am not using IIS, Apache, etc. otherwise life would be a lot simpler (I would simply bind hostnames accordingly). The web server executables perform unusual "utility" tasks as part of a range of other websites, but still need to be hosted on port 80. There is no configuration other than address to bind to and port #.
I have setup several private IPs and bound each server application to those private IPs. Is it possible to leverage some of the Amazon networking products to direct the traffic to the correct private IP? e.g. I have tried setting up a private-DNS using Amazon Route53, and internally at least this seems to point to the correct servers - but not (perhaps logically) when I try to access the site externally.
In absence of any other solutions I decided to solve this using the blunt hammer approach and use a reverse proxy. Downside is my servers now only see the user IPs as 127.0.0.1 which was less than ideal, but better than nothing at all.
For my reverse proxy I used Redbird (uses node.js) but Nginx may also be an option. Both are free / open source.
Good Day,
I have been using AWS quite a bit for my cloud based system for a hardware project. Using SimpleDB and the notification service provided is great.
However, I need a backend on AWS that basically listens to requests coming in, processes it and sends it back to a particular address. Some kind of UDP service.
I could easily write a c#/c++ app for it, but i am not sure if I can host it on AWS. Does anyone know how this works?
Short answer: yes.
EC2 instances are just like any other virtual machine, obviously you can put in a server that listens to UDP. Configuring the network for this is, of course, slightly more complicated, but possible. The one thing making it more complicated is that with UDP you will not be able to enjoy the load balancer service that Amazon offers, as it (currently) only supports TCP-based protocols.
So, if you have one server you wish to put on the internet, the procedure is probably same as what you'd do with a TCP server: set up a server and an elastic IP pointing to it, and then have your clients connect to it (by knowing the elastic IP you've been allocated, or by referring to that IP via a DNS resolution). If you have multiple servers you wish to set up, answering the same address, life is a bit more complicated. With TCP, you could have set up an Amazon load balancer and assign your elastic IP to the load balancer. If you'd want a load balancer for UDP, the Amazon stock load balancer can't do that, but you can still find a software load balancer (there are hundreds of them on Amazon's public images library) to set up.
Nginix has an Amazon image that will load balance UDP for $2,500/yr or you can launch your own EC2 instance and use open source Nginx.
My specific use case was for a UDP logging service, if you can use hostnames Route 53 could be a scalable managed solution as well.
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.