identify ip range of ddos attacks and block it at the Network ACL level. Alternatively could do this at the Security Group Level, but it’s quicker at the Network ACL level.

Install DDOS prevention software on our EC2 instances that will monitor for DDOS attacks and filter them out.

AWS minimizes impact by:

use of CloudFront, which can absorb most of the impact. Hence the edge collections takes on the main brunt of the attack

If ddos against a static website that’s hosted on S3, then S3 will absorb this impact.

port scanning (using the nmap command) is disabled by default in AWS (even port scanning between EC2 instances that are inside the same VPC). If you want to enable port scanning, then you need to contact

You can encrypt the content of your resources. This basically means that the content can’t be viewable by an AWS employee. The only way to decrypt the content is via logging into the AWS Account that created the encrypted data in the first place, and also you need to login with the appropriate account privileges.

There are 3 main resource types, whose data you can encrypt:

S3 Buckets

Uses AES-256 encription to encrypt data at rest. It is decrypted only when it receives a valid request, by a valid IAM user or ec2 instance.

EBS volumes –

When enabled, this essentially means that the EC2 instance will first always encrypt the data before sending it to the EBS volume for storage.

EBS snapshot therefore only stores encrypted data. only A user with the right

Cloudwatch related API requests are signed with HMAC-SHA1signature from the request and the the user’s private key

Cloudwatch’s (sdk) API is only accessible via https, not http, i.e. it is encrypted with ssl

An IAM user can only access cloudwatch if they are given access via IAM

You can configure cloudtrail to send notifications to SNS, which in turn sends notifications to cloudwatch, to take particular actions when something happens, e.g. restrict a certain user’s permission if they do something unwanted.

You can also get cloudwatch to send all of your EC2 instance system logs to your cloudwatch in real time:

CloudHSM (Hardware Security Module): This is essentially the name of a dedicated physical machine that is seperate from all the other AWS hardware, and it is used to store encryption keys. If an outside party gains access to these keys, then your AWS infrastructure is compromised. Hence even AWS employees don’t have physical access to CloudHSM since they are locked in specially controlled rooms that is seperate from the rest of the AWS AZ’s hardware.

These keys are only used from inside the CloudHSM device itself. Because of this, the CloudHSM is responsible for decrypting data it receives, and decrypting data it sends out. CloudHSM has an API that all your other AWS resources can interact with. All the AWS resources that can interact with CloudHSM are referred to as “CloudHSM

In route53 you have multiple entries with the same url (aka url). In fact you have to create multiple entries with the same name in order to take advantage of the various routing policies. Here are the available routing policies:

Simple

Weighted

Latency

Failover

Geolocation

We have already covered Failover.

Latency based routing

One thing you can do is set up the exact same VPC in 2 different regions.

You can then configure route 53 to route traffic to the VPC that is going to be the first responder to a given source’s request. This usually means that the vpc that is geographically closer to the requester’s location, will end up handling the request.

This indirectly means that if one vpc goes down, all traffic will failover to the vpc that is still active, since it essentially becomes the first