I have a web app running on my Amazon EC2 instance. How can I integrate a Web Application Firewall with my EC2?
I have tried setting up the WAF, but it can only be associated with either a CloudFront distribution or an Elastic Load Balancer. Do I need to setup a CloudFront distribution and point it at my EC2 instance?
I ended up setting up an elastic load balancer pointing to my single instance and then adding the web application firewall pointing to the load balancer. It works pretty well and doesn't cost too much more per month from AWS.
The two approaches you can connect AWS WAF to your EC2 instance through,
AWS CloudFront
Application Load Balancer (ALB)
Each approach has its own pros and cons. If your application servers more of content that can be cached, then having AWS CloudFront along with WAF. If your application cluster needs to scale but most of it is dynamic content then going for ALB is more reasonable.
Note: There is an added fixed cost for ALB (In addition to the variable cost which is not significant though) for each month while CloudFront cost is variable and consumption driven.
It is also possible to have both CloudFront and ALB together where you can add the WAF to CloudFront only.
This is how you use AWS WAF, it only works in these two scenarios. For an EC2 application it is best to configure an ALB in front of it (even if you have only one instance).
BTW: You might get away with only using the Application Loadbalancer (ALB) from AWS, this is doing more content validity checks than classic AWS ELB is doing.
You need to set up at least Application layer Loadbalancer to use AWS WAF.
side note: AWS WAF has a lot of restriction. For request count based blocking you will end up having LAMBDA scripts to COUNT and update the AWS WAF ruleset. Also, they don't provide WAF logs as of my Knowledge. Try looking at cloud WAF solutions like SOPHOS.
Related
My applications run on ElasticBeanstalk and communicate purely with internal services like Kinesis and DynamoDB. There is no web traffic needed? Do I need an ElasticLoadBalancer in order to scale my instances up and down. I want to add and remove instances purely based on some cloudwatch metrics? Do I need the ELB to do managed updates etc.?
If there is no traffic to the service then there is no need to have a load balancer.
In fact the load balancer is primarily to distribute inbound traffic such as web requests.
Autoscaling can still be accomplished without a load balancer with scaling based on the CloudWatch metric that you want to use. In fact this is generally how consumer based applications tend to work.
To create this without a load balancer you would want to configure you environment as a worker environment.
#Chris already anwsered, but I would like to complement his answer for the following:
There is no web traffic needed?
Even if you communicate with Kinesis and DynamoDB only, your instances still need to be able to access internet to communicate with the AWS services. So the web traffic is required from your instances. The direct inbound traffic to your instances is not needed.
To fully separate your EB env from the internet you should have a look at the following:
Using Elastic Beanstalk with Amazon VPC
The document describes what you can do and want can't be done when using private subnets.
I was going through the article https://github.com/Netflix/eureka/wiki/Eureka-at-a-glance#how-different-is-eureka-from-aws-elb about Eureka when I came across this term. Also quite confused what the paragraph means (EC2 classic and AWS security groups). It said
AWS Elastic Load Balancer is a load balancing solution for edge services exposed to end-user web traffic. Eureka fills the need for mid-tier load balancing. While you can theoretically put your mid-tier services behind the AWS ELB, in EC2 classic you expose them to the outside world and thereby losing all the usefulness of the AWS security groups.
I'm completely new to Microservice architecture and reading articles from sources I can find. Any help would be helpful!
A mid-tier load balancer is a load balancer that isn't exposed to the Internet, but instead is intended to distribute internally-generated traffic between components in your stack.
An example would be the "order placement" (micro)service verifying prices by sending requests to the "catalog item details" (micro)service -- you need a mid-tier load balancer in front of the multiple nodes providing the "catalog item details" service so that the request is routed to a healthy endpoint for that service, without "order placement" needing to be responsible for somehow finding a healthy "catalog item details" endpoint on its own.
Eureka was first committed to Github in 2012. Back then, much of EC2 was still running inside "EC2 Classic" -- in simple terms, this is the old way EC2 worked, before VPC. It was a much more primitive environment compared to today.
With EC2-Classic, your instances run in a single, flat network that you share with other customers. With Amazon VPC, your instances run in a virtual private cloud (VPC) that's logically isolated to your AWS account.
The EC2-Classic platform was introduced in the original release of Amazon EC2. If you created your AWS account after 2013-12-04, it does not support EC2-Classic, so you must launch your Amazon EC2 instances in a VPC.
https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-classic-platform.html
EC2 Classic supported security groups for securing access to EC2 instances, but Elastic Load Balancers (ELB) inside EC2 Classic did not.
VPC became generally available in August, 2011.
Elastic Load Balancer -- originally the only type, this type was later rebranded as "ELB Classic," and is not recommended for new environments -- was released for VPC in November, 2011 but only in the Internet-facing variety. Before this, as noted above, ELB only worked in EC2 Classic, only faced the Internet, and accepted HTTP and HTTPS traffic from everywhere. You couldn't control access with security groups.
ELB Classic learned a new trick in June 2012, with the release of Internal Elastic Load Balancers -- accessible only from services inside the VPC. These could be used securely for mid-tier, but they were very limited because they could not make routing decisions based on hostname or path. ELB Classic was a very barebones load balancer with very little flexibility. You'd essentially need a different balancer for each service. One commom configuration was to use HAProxy behind ELB Classic to fill in some of the feature gaps.
AWS didn't have a solid, managed, mid-tier load balancer offering until August, 2016, when the new Application Load Balancer was announced -- with the ability to send traffic to different backend target groups based on pattern matching in the request path sent to the balancer... and with support for deploying in an Internet-facing or internal-only scheme.
In April, 2017, Application Load Balancers were enhanced with the ability to also select a back-end target group based on pattern-matching the HTTP Host header and/or the path, as before.
At this point, VPC and ALB fill many (but, in some cases, not all) of the needs that seem to have driven the development of Eureka.
I would assume that this middle tier is something that can act as a barrier or protection against your AWS ELB. Let use examples of people trying to do an SQL injection attack or spamming your AWS ELB. Also, SG in AWS allows you to specify what protocols are coming to the ALB or any other resources in AWS when you create them. So for example, you can set up an SG that only accepts traffic from your middle-tier server as an additional level of security.
Hope this helps with a better understanding.
if we try to enable WAF in Classic ELB i am unable to create may i know way to implement it so it will be help full for us to set a layer of security in the infra
To use WAF two options:
Test your application with ALB. If successfully tested, migrate your application from the current Classic ELB to ALB and deploy WAF
If you do not want to do option 1, you can look at deploying a CloudFront distribution, set your ELB as the origin of the distribution and deploy WAF in front of the CloudFront distribution
I have two custom hardware servers running a service for me, need to set up a load balancer. Till I can get my service provider to provide one for me, can I set up AWS ELB to load balance requests to my servers? Is there some other option? PS: Costs are an issue, so looking for cheaper alternatives
Our app has independent clusters of boxes running on Amazon Web Services. I need to send http requests to different clusters based on the URL. For example, http://api.mydomain.com/foo should go to the "foo" cluster, and http://api.mydomain.com/bar should go to the "bar" cluster.
I don't see anything in the elastic load balancer or Route 53 that will do it.
(The obvious thing is to have separate subdomains, but that's difficult for this app. We want to stick with just the "api" subdomain because the cluster configuration may change in the future.)
What's the best approach?
That is not supported by the load balancer. Using subdomains does work if you want to use the existing load balancer.
If you need more features, you could configure your own using a software load balancer running on top of an ec2 instance. Not likely to be as cost effective however.
It is not possible using ELB. Use Netscaler EC2 or HAProxy EC2 in your AWS environment to achieve this. NetScaler is available in AWS marketplace.