I have service running on Google Compute Engine. I've got few instances in Europe in a target pool and few instances in US in a target pool. At the moment I have a domain name, which is hooked up to the Europe target pool IP, and can load balance between those two instances very nicely.
Now, can I configure the Compute Engine Load Balancer so that the one domain name is connected to both regions? All load balancing rules seem to be related to a single region, and I don't know how I could get all the instances involved.
Thanks!
You can point one domain name (A record) at multiple IP addresses, i.e. mydomain.com -> 196.240.7.22 204.80.5.130, but this setup will send half the users to the U.S., and the other half to Europe.
What you probably want to look for is a service that provides geo-aware or geo-located DNS. A few examples include loaddns.com, Dyn, or geoipdns.com, and it also looks like there are patches to do the same thing with BIND.
You should configure your DNS server. Google does not have a DNS service, as one part of their offering, at the moment. You can use Amazon's Route 53 to route your requests. It has a nice feature called latency based routing which allows you to route clients to different IP addresses (in your case - target pools) based on latency. You can find more information here - http://aws.amazon.com/about-aws/whats-new/2012/03/21/amazon-route-53-adds-latency-based-routing/
With Google's HTTP load balancing, you can load balance traffic over these VMs in different regions by exposing via one IP. Google eliminates the need for GEO DNS. Have a look at the doc:
https://developers.google.com/compute/docs/load-balancing/
Hope it helps.
Related
I see that in CloudFlare’s DNS FAQs they say this about wildcard DNS entries:
Non-enterprise customers can create but not proxy wildcard records.
If you create wildcard records, these wildcard subdomains are served directly without any Cloudflare performance, security, or apps. As a result, Wildcard domains get no cloud (orange or grey) in the Cloudflare DNS app. If you are adding a * CNAME or A Record, make sure the record is grey clouded in order for the record to be created.
What I’m wondering is if one would still get the benefits of CloudFlares infrastructure of the target of the wildcard CNAME record IS a Cloudflare Worker, like my-app.my-zone.workers.dev? I imagine that since this is a Cloudflare controlled resource, it would still be protected for DDoS for example. Or is it that much of the Cloudflare security and performance happening at this initial DNS stage that will be lost even if the target is a Cloudflare worker?
Also posted to CloudFlare support: https://community.cloudflare.com/t/wildcard-dns-entry-protection-if-target-is-cloudflare-worker/359763
I believe you are correct that there will be some basic level of Cloudflare services in front of workers, but I don't think you'll be able to configure them at all if accessing the worker directly (e.g. a grey-cloud CNAME record pointed at it). Documentation here is a little fuzzy on the Cloudflare side of things however.
They did add functionality a little while back to show the order of operations of their services, and Workers seem to be towards the end (meaning everything sits in front). However, I would think this only applies if you bind it to a route that is covered under a Cloudflare-enabled DNS entry.
https://blog.cloudflare.com/traffic-sequence-which-product-runs-first/
The good news is you should be able to test this fairly easily. For example, you can:
Setup a worker with a test route
Point a DNS-only (grey cloud)
record at it
Confirm you can make a request to worker
Add a firewall rule to block the rest route
See if you can still make the request to worker
This will at least give you an answer on whether your zone settings apply when accessing a worker (even through a grey cloud / wildcard DNS entry). Although it will not answer what kind of built-in / non-configurable services there are in front of workers.
I am new to AWS. I can't get a clear idea behind ALB vs NLB. Could anyone explain in a simple way?
There are some excellent answers out there already, let me pick out some key points that may help.
Network Load Balancer
As the name implies, this is for the network levels only. Typically layer 4.
It does not care, nor see, about anything regarding the application layer, such as cookies, headers, etc.
It is context-less, caring only about the network-layer information contained within the packets it is directing this way and that.
the 'balancing' done here is done so solely with IP addresses, port numbers, and other network variables.
Application Load Balancer
This takes into account multiple variables, from the application to the network. It can route its traffic based on this.
It is context-aware and can direct requests based on any single variable as easily as it can a combination of variables.
Key Differences
The network load balancer just forward requests whereas the application load balancer examines the contents of the HTTP request header to determine where to route the request
Network load balancing cannot assure availability of the application, where as Application load balancing can.
Some good sources from where I extracted this information are:
https://medium.com/awesome-cloud/aws-difference-between-application-load-balancer-and-network-load-balancer-cb8b6cd296a4
https://linuxacademy.com/community/show/22677-application-load-balancer-vs-network-load-balancer/
https://aws.amazon.com/elasticloadbalancing/features/#compare
In main response by #james above, network level has been defined multiple times and mentions about network layer information. However, I would like to mention, NLB yes operates on Layer4, but Layer4 is Transport Layer not Network Layer. NLB preserves source IP and thus Elastic IP can be used in case of NLB.
If I host a website on AWS EC2 with Elastic IP and I want to limit access to this website from US region users only, Is there any easy way to do this? Website is powered by Apache.
According to this link .htaccess could be an option but didn't find a way to exclusively lock down my website to US region users only.
I will limit my answer to Amazon services.
Being able to block access by world location is an important issue today. With all of the various government regulations regarding where content is located / stored, controlling access may be a legal requirement in some situations.
Amazon has three services that support geolocation: Route53, CloudFront, and WAF (Web Application Firewall). No service is completely bulletproof but given the size of Amazon's network, all of the certifications, government compliance, etc. I tend to believe Amazon's geolocation would be better than a homebrew setup.
Your question specifies Elastic IP address. I am not aware of an Amazon service that supports geolocation blocking for your EIP. Instead, you will want to use Route53 and create a resource record set (RRS) or commonly called domain name or sub domain name to that EIP. Then put the server either in a private subnet, or put the front end service (CloudFront and/or ALB) in the same security group to limit who can access the EIP. Note: private subnets do not support EIP and are not required for ALB.
Configure geolocation as part of the setup for Route53, CloudFront or WAF (better a combination of these services). You can select the parts of the world (e.g. United States) to accept traffic from and block everybody else.
If I was building a small setup that did not require auto-scaling, I would use Route53 and CloudFront in front of my server. For higher fault-tolerance and high availability I would put the servers into a private subnet and add a load balancer with ASG (Auto Scaling Group) behind CloudFront and Route53 and add WAF to CloudFront (or the ALB).
Amazon VPCs via NACLs and Security Groups do not support any form of geolocation. Security Groups and NACLs are just very fast firewalls with a specific feature set. A VPN could be used if the customer base is tightly controlled (e.g. a group of developers or business partners) but would be untenable for a publicly accessed web server (e.g. customer portal). One might think that usernames or SSH keys could be used, but this does not control geography just authentication. A user could still access a server in France from Russia. If the requirement is geolocation, then the three Amazon services in the thread are good choices for geolocation based policies.
Route53:
Geolocation Routing
CloudFront:
Restricting the Geographic Distribution of Your Content
Amason WAF:
Working with Geographic Match Conditions
You could use Cloudfront geoblocking. Block all but US. You will not 100% be able to block. You can spoof Ip and locations, but it's a start.
http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/georestrictions.html
There several Cloud Native options available in AWS that could be used to restrict users to a particular region.
Using AWS CloudFront Geo Restrictions
Using AWS CloudFront + AWS WAF with Geo Matching Conditions (Where you can do the Geo Restriction and Other IP based Whitelisting).
If you plan to use AutoScaling and Load Balancing (For Application Load Balancer), then you can attach AWS WAF to Load Balancer with Geo Matching Conditions Configured.
Does anyone know how AWS ELB with SSL work behind the scenes? Running an nslookup on my ELB's domain name I get 4 unique IP addresses. If my ELB is SSL enabled, is it possible for AWS to share these same IPs with other SSL enabled ELBs (not necessarily owned by me)?
As I understand it the hostname in a web request is inside of the encrypted web request for a https request. If this is the case, does AWS have to give each SSL-enabled ELB unique IP addresses that are never shared with anyone else's SSL ELB instance? Put another way -- does AWS give 4 unique IP addresses for every SSL ELB you've requested?
Does anyone know how AWS ELB with SSL work behind the scenes? [...] Put another way --
does AWS give 4 unique IP addresses for every SSL ELB you've
requested?
Elastic Load Balancing (ELB) employs a scalable architecture in itself, meaning the number of unique IP addresses assigned to your ELB does in fact vary depending on the capacity needs and respective scaling activities of your ELB, see section Scaling Elastic Load Balancers within Best Practices in Evaluating Elastic Load Balancing (which provides a pretty detailed explanation of the Architecture of the Elastic Load Balancing Service and How It Works):
The controller will also monitor the load balancers and manage the
capacity [...]. It increases
capacity by utilizing either larger resources (resources with higher
performance characteristics) or more individual resources. The Elastic
Load Balancing service will update the Domain Name System (DNS) record
of the load balancer when it scales so that the new resources have
their respective IP addresses registered in DNS. The DNS record that
is created includes a Time-to-Live (TTL) setting of 60 seconds,[...]. By default, Elastic Load Balancing will return multiple IP
addresses when clients perform a DNS resolution, with the records
being randomly ordered [...]. As the traffic
profile changes, the controller service will scale the load balancers
to handle more requests, scaling equally in all Availability Zones. [emphasis mine]
This is further detailed in section DNS Resolution, including an important tip for load testing an ELB setup:
When Elastic Load Balancing scales, it updates the DNS record with the
new list of IP addresses. [...] It is critical that you factor this
changing DNS record into your tests. If you do not ensure that DNS is
re-resolved or use multiple test clients to simulate increased load,
the test may continue to hit a single IP address when Elastic Load
Balancing has actually allocated many more IP addresses. [emphasis mine]
The entire topic is explored in much more detail within Shlomo Swidler's excellent analysis The “Elastic” in “Elastic Load Balancing”: ELB Elasticity and How to Test it, which meanwhile refers to the aforementioned Best Practices in Evaluating Elastic Load Balancing by AWS as well, basically confirming his analysis but lacking the illustrative step by step samples Shlomo provides.
From what I understand, if you have multiple web servers, then you need some kind of load balancer that will split the traffic amongst your web servers.
Does this mean that the load balancer is the main connecting point on the network? ie. the load balancer has the IP address of the domain name?
If this is the case, it makes it really easy to add new hardware since you don't have to wait for any dns propogation right?
There are several solutions to this "problem".
You could round-robin at the DNS-level. I.e. have www.yourdomain.com point to several IP-addresses (well all your servers).
This doesn't give you any intelligence in the load balancing, but the load will be more or less randomly distributed, but you wouldn't be resilient to hardware failures as they would still require changes to DNS.
On the other hand you could use a proxy or a loadbalancing proxy that has a single IP but then distributes the traffic to several back-end boxes. This gives you a single point of failure (the proxy, you could of course have several proxies to defeat that problem) and would also give you the added bonus of being able to use some metric to divide the load more evenly and intelligently than with just round-robin dns.
This setup can also handle hardware failure in the back-end pretty seamlessly. The end user never sees the back-end, just the front-end.
There are other issues to think about as well, if your page uses sessions or other smart logic, you can run into synchronisation problems when your user (potentially) hits different servers on every access.
It does (in general). It depends on what server OS and software you are using, but in general, you'll hit the load balancer for each request, and the load balancer will then farm out the work according to the scheme you have in place (round robin, least busy, session controlled, application controlled, etc...)
andy has part of the answer, but for true load balancing and high availability you would want to use a pair of hardware load balancers like F5 bigips in an active passive configuration.
Yes your domain IP would be hosted on these devices and traffic would connect firstly to those devices. Bigips offer a lot of added functionality including multiple ways of load balancing and some great url rewriting, ssl acceleration, etc. It also allows you to run your web servers on a seperate non routable address scheme and even run multiple sites on different ports with the F5's handling the translations.
Once you introduce load balancing you may have some other considerations to take into account for your application(s) like sticky sessions and session state but that is a different subject