(I am trying to understand how ELB networking works within a VPC, and post this question)
When we add two subnets to a public ELB, aws elb create-load-balancer --load-balancer-name my-load-balancer --listeners "Protocol=HTTP,LoadBalancerPort=80,InstanceProtocol=HTTP,InstancePort=80" --subnets subnet-15aaab61 subnet-198aab81, I assume I need to setup these two subnets as public subnets before running the this step -- is this understanding correct? Also, I assume the above public subnets must be configured to automatically assign public IPs to each of its instances (otherwise, DNS resolution of this ELB destination won't get a public addressable IP) -- is this understanding also correct?
Next, I have instances running in two private subnets and I register them to the ELB that were created above. I guess I need to make sure the two public subnets and the two private subnets are connected -- do I need to do extra work to make that happen? (i.e., Will the default 10.0.0.0/16 -> local rule be sufficient? I thought so, but [1] seems to say otherwise because it added a NAT rule in the context of ELB setup procedure)
Thanks for helping me understand the ELB related networking.
[1] Blog about ELB and route table
I assume I need to setup these two subnets as public subnets before running the this step -- is this understanding correct?
Not technically. But they will need to be set up this way before the ELB will be usable.
Also, I assume the above public subnets must be configured to automatically assign public IPs to each of its instances (otherwise, DNS resolution of this ELB destination won't get a public addressable IP) -- is this understanding also correct?
Incorrect. ELBs get their public IP addresses independently of whether the subnet is configured for automatic assignment of public IP addresses. This setting only applies to EC2 instances you create on that subnet. Not ELBs.
Next, I have instances running in two private subnets and I register them to the ELB that were created above. I guess I need to make sure the two public subnets and the two private subnets are connected -- do I need to do extra work to make that happen? (i.e., Will the default 10.0.0.0/16 -> local rule be sufficient?
Yes. All VPC subnets can always route to all other subnets in the VPC because of the local rule. You can't mess this one up, even if you try.
I thought so, but [1] seems to say otherwise because it added a NAT rule in the context of ELB setup procedure)
The NAT instance (or NAT Gateway) is referenced by the default route to allow the instances on a private subnet to initiate outbound Internet requests. It doesn't relate to traffic sent to the instances from the ELBs, or to the responses to that same traffic, which follows the "local" route -- traffic sent to the instances from a balancer has the internal source IP address of the balancer, not the address of the browser accessing the ELB.
In order for your instances in the public subnets to have outbound internet connectivity they need to be behind an internet gateway. All instances that are created within that public subnet should automatically be assigned a public IP after you associate the internet gateway with the public VPC. If you want a server to have a fixed public IP you need to associate an Elastic IP with that node.
Instances within your VPC can talk to each other by default, the real restriction is your security group rules that allow or prevent ingress/egress on whatever ports you set in the security group for the VPC. So if you want the public nodes to be able to talk to the private nodes open up those ports with the security group rules.
Where you will need a NAT instance in your public subnet is if you want your private instance nodes to be able to make software updates or external calls to the internet.
You can find information about setting up the NAT instance here:
http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_NAT_Instance.html
Related
I just obtained static IP from ISP and configured port forwarding on my Sercomm AOT-4221SR Router
While accessing outside network it works properly and shows webpage of my server however when i connect my machine to same network within LAN and visit website or static IP it shows router page i.e 192.168.0.1 (with original website URL which i entered in browser)
Please help me to solve this.
192.168.0.1 this is a private IP and shouldn't be used. I am guessing that you received a public IP from ISP. Use your public IP and add port forward rules for that IP to your web server IP
X.X.X.X:80 ------------> 192.168.0.x:80
X.X.X.X:443 ------------> 192.168.0.x:443 for HTTPS
X.X.X.X is your public IP and 192.168.0.x is the ip of machine where you are running webserver.
And point your domain name to that public IP. You can add entries in /etc/hosts for testing purposes
What you are looking for is NAT reflection.
It would not work, as most routers, including the Sercomm one does not have NAT reflection feature.
I was in the same boat as you.
What I did:
Let us assume you have 3 devices from which you want to forward ports. After adding the rules in the router, with LAN IPs 192.168.0.A, 192.168.0.B, 192.168.0.C
and your static IP is W.X.Y.Z.
Go to duckdns.org and create a free account.
create 3 entries
somethingdevice1.duckdns.org --> W.X.Y.Z
somethingdevice2.duckdns.org --> W.X.Y.Z
somethingdevice2.duckdns.org --> W.X.Y.Z
Now create static DNS entries as follows (I am using AdGuard instance inside a HASS instance which I am using as DNS, I created DNS rewrite rules there)
somethingdevice1.duckdns.org --> 192.168.0.A
somethingdevice2.duckdns.org --> 192.168.0.B
somethingdevice3.duckdns.org --> 192.168.0.C
Now use these URLs to access your devices withing or outside your local network.
I have a system with a URL like sub.domain.tld that resolves to a local server. I'm looking to create a cloud-based system where I would like to resolve all requests for *.sub.domain.tld, while still resolving sub.domain.tld to the local server. Is this possible?
Yes, you can set sub.domain.tld to have an A record set to 10.0.0.1 (or whatever internal IP you want), and also have foo.sub.domain.tld with an A record set to 1.2.3.4 (or any other IP).
You can even have a wildcard subdomain like *.sub.domain.tld with an A record of 1.2.3.4 and then anything.sub.domain.tld will resolve to 1.2.3.4.
Another option is to delegate control to another DNS provider. Add foo.sub.domain.tld to the new DNS provider as a main domain, and in the sub.domain.tld DNS config, set NS records on foo.sub.domain.tld that point to the other nameservers. Then from the new account you can independently add new DNS records like bar.foo.sub.domain.tld, which can be handy when you want to give someone else control of a subdomain, or when you just want to isolate different environment configs.
You can also override public DNS for local DNS queries in a variety of ways if that's desired, e.g. via hosts file entries.
There are a lot of options depending on what you want to do.
This is all assuming this is public DNS on a public domain. You can also use private domains in private DNS servers, which is fairly common to see in enterprise networks.
I have created a failover environment with route 53 and two elbs. Every elb have to attach multiple app servers. If allow https traffic to open everyone the application accessible but when i restrict the https traffic to specific ip address range the application is not accessible even those ip addresses who have permission.
I assume when you say you allow http traffic from specific IP addresses ,you are doing it at the security group level.If yes then make sure you modify the security groups of the Load balancers and not the backend instances.The backend instances will receive http traffic from the load balancer IPs (which would be your ELB subnets cidr block or if not being too restrictive you can allow http traffic from the vpc cidr range.
Additionally ensure that the load balancers and the backend instances have different security groups.
ELB SG > HTTP:80 ,SOURCE
BACKEND SG -> HTTP:80 ,SOURCE ELB SUBNET/VPC CIDR BLOCK
The would be simple changes if you are using ssl termination but the logic remains the same.
If you are not using security groups but something else then we would have to check your specific configuration.
This seems to have something to do with the subnet/availability zone, but I'm new to using a VPC and it's eluding me.
VPC: 10.80.0.0/16
subnet: 10.80.1.0/24 (us-east-1b)
subnet: 10.80.2.0/24 (us-east-1a)
All instances are Windows Server 2012.
I have an internet facing ELB created within my VPC (10.80.0.0/16). There is one instance added from AZ us-east-1a, which is on subnet 10.80.2.0/24. The instance is running IIS 7.5, with an app running on port 80 and /health.aspx set up for use as the ELB health check.
Internal traffic on the VPC is flowing normally (unrestricted). I can request health.aspx from this instance from another instance in us-east-1b (10.80.1.0/24). I can also copy files from one instance to another.
Outbound traffic is unrestricted. I can RDP to the instance (when connected to our VPN) and open a browser and request a web page and get it.
The ELB says the instance is healthy and I can see the requests to health.aspx in the IIS logs. Both the ELB and the instance are configured with a security group that allows 80 and 443.
But if I try to request {elb-url}/health.aspx over the open internet the request just times out. Similarly, with an elastic IP associated to the instance, a request to {elastic-ip}/health.aspx times out.
#Chris, thanks for the response...as it happens, I've already worked it out with some help from a friend. I'll post my findings here for posterity (in case anybody else was similarly confused about how ELB works).
This would be more clear with a diagram. But the summary is that in each availability zone, you need to create both a public and a private subnet. When you add availability zones to your ELB, you need to select the public subnet for the zone. This had already been done in us-east-1b before I got to this setup, and I had simply missed this nuance of ELB configuration. So for the new availability zone, I had to do this...
us-east-1c
private subnet 10.1.3.0/24 (using nat instance as default route)
public subnet 10.1.4.0/24 (using internet gateway as default route)
Then my instance goes in the private subnet as expected.
And the lynch pin of this whole thing is (drum roll....)
When I add us-east-1c to my ELB, I have to select the public subnet...10.1.4.0. Otherwise the instances will pass the health check (since the ELB can communicate with any instance within my entire VPC) but the responses from the servers cannot make it back out to the public internet.
This is what is so confusing. And I still don't fully understand it. The instance can make a request for, say, www.google.com. I can RDP to it and open a browser and get the web page. But a request from a host (like my laptop at my house) will die. strange.
PS: another note...make sure you are using enough NAT instance for your load. I think we ran into an issue where our NAT instance simply ran out of ports because too many web servers were trying to route outbound connections to 3rd party APIs through it. Quite honestly, I'm not good enough at this level of network/OS troubleshooting to be sure. But my theory is that our 8 instances of IIS were holding too many connections open to the NAT instance. We were also abusing the NIC on that micro instance. I upped us to two large instances, one per AZ and things smoothed back out. Both NAT instances are humming and we're not seeing the hung processes in IIS anymore.
Debugging this kind of issue is always a challenge. I have a few ideas to suggest based on what you have written (and generally apply to trying to solve this problem) that come from dealing with this a number of times.
Have you checked both the security groups and network ACLs? Bear in mind that all network ACLs need to be specified in both directions, as they are stateless. Also bear in mind that ELBs are a bit unique in this regard. While they are associated with your VPC, they sometimes need extra rules to ensure connectivity. In the past I have debugged this by opening all network ACLs on all ports, then removing these rules until it has stopped working in order to identify where the block was.
Security groups should be checked too. They are stateful but ensure that your load balancer has permissions to be hit from the web.
Have you checked this isn't an application configuration problem? I don't know how IIS comes out of the box but I would check it is setup to respond to all hostnames.
Check the ELB isn't an internal one, as that wouldn't be publically addressable.
You say the ELB is configured with the health check, but it's worth checking you also have the listener setup for port 80? It's in a separate tab on the dashboard and you will need this in addition to the health check for connectivity through the ELB.
Hope one of these tips is useful to you.
I am working on an AWS EC2 instance, I installed an apache server.
Is it possible to set a url to my server?
I would like to write on my browser:
http://myServiceWebSite
instead of
http://23.26.31.178
Can I hide the ip of my server by a face name?
Thank you.
You can set a DNS using a domain registrar such as Go Daddy
You can use FREE domain names such as co.nr though I think that 13$ a year for a .com is a descent price.
As ajay wrote, Amazon Does provide a default DNS but it is "ugly" and you will probably not use it.
By default, every time you restart a machine it will probably assign a different IP address, and the DNS name is ugly because it is based on IP, and it is released on instance shutdown.
If your server is used by the public internet you might have at least 3 choices:
Make the IP address static by using Elastic IP option from EC2 console and register this IP using some DNS Service such as Go Daddy.
Leave your IP assigned dynamically and use a dynamic DNS service such as DynDns.
If need to use an Elastic Load Balancer use the AWS Route 53 DNS Service, and instead of creating an A Resource Record pointing to a static IP address, you could use an Alias Resource Record pointing to your Elastic Load Balancer, I think this would be the best option if you have more than 1 server.
If you want a quick and dirty solution, you could use a url shortener and use the url it generates from your default AWS DNS. This is not a long term solution, but just something to use if, for example, you want to deploy a prototype quickly and display it for someone temporarily without handing them an IP address.