I am having a free tier AWS account, I am adding WAF with my LB(load balancer) having one instance on EC2. Currently, the security group has only HTTP 80 port.
My instance is located on the Asia Pacific (Mumbai) region and when I am creating RULE OR Condition for ACL, I am not getting this region there.
So I have tried to make ACL with the different region and without any rule just configure with the load balancer, After creating ACL when I go for Associate the load balancer with ACL, So there is no load balancer shown in the drop down like below:
please help me, Where can be mistake done by me ?
AWS WAF is not supported yet in the Mumbia region, so if your instance and load balancer is in Mumbai you won't be able to use WAF directly:
https://aws.amazon.com/about-aws/global-infrastructure/regional-product-services/
You also can't put your WAF in a different region and connect it to your ALB, that won't work either as you have seen.
The only other option is for you to make use of a Cloudfront distribution in front of your load balancer, and your WAF is then linked to your Cloudfront distribution.
Related
Currently I have setup my web application on my 2 instance (ec2). Both instance have same web module and also SSL certificate.
And then I also have setup 1 load balancer for both instance for high availability.
But I was wondering on domain name part. Because both instance have different IP, and right now I only assign 1 IP instance into our domain provider.
So basically do I need provide both instance IP into my domain provider? Sorry I was newbie on this domain part :(
wasabiz, since you are a newbie, I would suggest going with AWS Beanstalk path.
To answer your question.
You can use Route53 to create/import your domain Name. The domain can point to DNS name of the Loadbalancer. From there LB will route the traffic to your EC2 instances. You need to introduce the autoscaling layer and move the EC2 instances inside it. So that the auto scalaing requirements can be fulfilled. All these options are configurable in AWS BeanStalk.
You have options to generate TSL certificates in AWS which is free to be used in AWS infrastructure. Otherwise, if you already have a certificate, you can import the certificate into AWS through AWS Certificate Manager and use it where ever needed, eg:load balancer.
On a AWS EC2 ELB security profile - i need a couple of IP Address to be able to access only certain pages of my website. Is it possible? The other IP Address will have access to the full website. Is this achievable
This is not possible as a configuration in the Load Balancer because the Load Balancer simply distributes requests to your application servers.
Your application will need to enforce such functionality.
Let's say I have 20 servers at Amazon AWS and I also have AWS ELB setup for these servers. I heard that HAProxy is reliable and fast TCP/HTTP Load Balancer, so question is:
do I need to have HAProxy installed in each EC2 instances while I have AWS ELB?
What is the benefit of having both ELB and Haproxy at the same time?
Thanks
There are a few scenarios where people chose their own load balancing solution like HAProxy than ELB:
Financial transactions: ELB is an opaque service. Logs are not provided. So if you are missing transactions, you won't know if ELB dropped them or not.
Doesn't work well with traffic spikes: ELBs scaling takes at least 5 minutes. If your application traffic is doubling every 5-10 minutes, it will do well. But if it is at a constant rate and you will get a spike all of a sudden, then you will have problems with ELB.
ELBs can be slower than running your own Loadbalancing: In my environment, I got 15% performance boost by using HAProxy/Nginx (for SSL termination) instead. It was roughly 30ms per call, but keep in mind I was using SSL so I use CPU power.
ELBs only do round-robin load balancing and HAProxy has a lot more.
HAProxy also has ton more configurations that ELB does not support. It depends if one needs them for their application.
In one suite of applications, I have both running. ELB->haproxy->A suite of apps. In my case the following occurs:
ELB translates HTTPS to http
HAproxy targets to the app servers based on path
The app servers run in plain old http
The upside to this is that I can move around the apps without changing their URLs
The downside is that ELB isn't a fixed IP address so if you need to point to it from an IP adress instead of a cname you can't do it.
Short answer: No you don't need HAProxy. Go with an ELB.
tldr;
Yes HAProxy is powerful and tested.
First of all, you would need to have a separate EC2 HAProxy instance (as opposed to having HAProxy installed on every EC2 instance you need to balance). In essence an ELB is equivalent to an EC2 instance loaded with some kind of load balancing software.
Second, having both ELBs and HAProxy balancing instances in your environment is a rare use case. You might come to a point that you need more fine grained access and the ability to configure more on your load balancers. It purely depends on what you're doing and what problems an ELB might be giving you. Google to read through possible use cases.
I'm using an ELB and Haproxy behind.
When a customer uses my webservices from a unique IP, ELB redirects all his requests to the same hosts. It doesn't scale. (I supposed it's a hash from the src ip or something like that).
The haproxy has another balancer algorithm.
I keep the ELB for HA (1 haproxy / availability zone). And each haproxy instance redispatchs to region zone backend servers
Is there any way to make new instances added to an autoscaling group associate with an elastic IP? I have a use case where the instances in my autoscale group need to be whitelisted on remote servers, so they need to have predictable IPs.
I realize there are ways to do this programmatically using the API, but I'm wondering if there's any other way. It seems like CloudFormation may be able to do this.
You can associate an Elastic IP to ASG instances using manual or scripted API calls just as you would any other instance -- however, there is no automated way to do this. ASG instances are designed to be ephemeral/disposable, and Elastic IP association goes against this philosophy.
To solve your problem re: whitelisting, you have a few options:
If the system that requires predictable source IPs is on EC2 and under your control, you can disable IP restrictions and use EC2 security groups to secure traffic instead
If the system is not under your control, you can set up a proxy server with an Elastic IP and have your ASG instances use the proxy for outbound traffic
You can use http://aws.amazon.com/vpc/ to gain complete control over instance addressing, including network egress IPs -- though this can be time consuming
There are 3 approaches I could find to doing this. Cloud Formation will just automate it but you need to understand what's going on first.
1.-As #gabrtv mentioned use VPC, this lends itself to two options.
1.1-Within a VPC use a NAT Gateway to route all traffic in and out of the Gateway. The Gateway will have an Elastic IP and internet traffic then whitelist the NAT Gateway on your server side. Look for NAT gateway on AWS documentation.
1.2-Create a Virtual Private Gateway/VPN connection to your backend servers in your datacenter and route traffic through that.
1.2.a-Create your instances within a DEDICATED private subnet.
1.2.b-Whitelist the entire subnet on your side, any request from that subnet will be allowed in.
1.2.c Make sure your routes in the Subnet are correct.
(I'm skipping 2 on purpose since that is 1.2)
3.-The LAZY way:
Utilize AWS Opsworks to do two things:
1st: Allocate a RESOURCE Pool of Elastic IPs.
2nd: Start LOAD instances on demand and AUTO assign them one elastic ip from the Pool.
For the second part you will need to have the 24/7 instances be your minimum and the Load instances be your MAX. AWS Opsworks now allows Cloud Watch alarms to trigger instance startup so it is very similar to ASG.
The only disadvantage of Opsworks is that instances aren't terminated but stopped instead when the load goes down and that you must "create" instances beforehand. Also you depend on Chef solo to initiate your instances but is the only way to get auto assigning EIPs to your newly created instances that I could find.
Cheers!
We usually blacklist IPs address with iptables. But in Amazon EC2, if a connection goes through the Elastic Load Balancer, the remote address will be replaced by the load balancer's address, rendering iptables useless. In the case for HTTP, apparently the only way to find out the real remote address is to look at the HTTP header HTTP_X_FORWARDED_FOR. To me, blocking IPs at the web application level is not an effective way.
What is the best practice to defend against DoS attack in this scenario?
In this article, someone suggested that we can replace Elastic Load Balancer with HAProxy. However, there are certain disadvantages in doing this, and I'm trying to see if there is any better alternatives.
I think you have described all the current options. You may want to chime in on some of the AWS forum threads to vote for a solution - the Amazon engineers and management are open to suggestions for ELB improvements.
If you deploy your ELB and instances using VPC instead of EC2-classic, you can use Security Groups and Network ACLs to restrict access to the ELB.
http://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/USVPC_ApplySG.html
It's common to run an application server behind a reverse proxy. Your reverse proxy is layer you can use to add DoS protection before traffic gets to your application server. For Nginx, you can look at the rate limiting module as something that could help.
You could set up an EC2 host and run haproxy there by yourself (that's what Amazon is using anyways!). Then you can apply your iptables-filters on that system.
Here's a tool I made for those looking to use Fail2Ban on aws with apache, ELB, and ACL: https://github.com/anthonymartin/aws-acl-fail2ban