Posts in Category: aws

AWS – Cloudwatch related security features

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:


AWS – Route 53 routing policy types

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

AWS – Direct Connect

Some Internet Service Providers can connect your on premise devices directly to aws AZ without being rerouted via the rest of the internet.

  • this results in faster connection
  • more stable connection
  • reduced latency
  • No need to go via the public internet
  • better security
  • No need to have any special hardware on-site
  • aws charges less for data traffic going to from aws via direct connect, rather than via the internet
  • It gives you dedicated private network connection. I.e. you can connect to your ec2 instances via it’s private ip addresses. Previously we saw that this is possible by setting up vpn, however with Direct Connect, you don’t need to set up connection. This is achieved by your onsite devices connecting to your vpc via a Virtual Gateway that’s attached to your vpc. To achieve this you need to setup

AWS – Cloudfront

Cloudfront is a (Content Delivery Network) CDN that delivers content to Edge Locations around the world.

Origin: This term means the location where the content can originate from. There are a few places:

  • EC2
  • ELB, with ec2 instances behind it
  • S3 bucket
  • route53 – e.g. if actual source is an microsoft azure vm.



Edge locations effectively stores cached content.

Distribution: This term is the name for a given “cloudfront resource”. You can create  two types of distributions:

  • Web distribution – most commonly used, e.g. cdn for static website
  • RTMP – Used for media streaming.


you can restrict access to your distributed content using one of the following cloudfront features:

  • signed urls
  • signed cookies

Objects in an Edge Location are cached for the life of the TTL (Time To Live). But can delete these sooner, but you will be charged for this.

Edge Locations are

AWS – Setting up DNS failover in Route 53

You can set up active and passive entries for the same url in route 53. So when route 53 discovers that the active (primary) source has become unhealthy it will failover to the passive (secondary) entry.

For example, we have a static website running on an EC2 instance. This EC2 instance is attached to an ELB. We have a route 53 alias that points to the ELB.

Now let’s say we have a file called “index.html” that is stored in S3. Also let’s assume that we configured S3 to act as a regular website. Now on the index.html file,  let’s assume it  says something like “this website is currently down, come back later”. Also let’s say we created a cloudfront distribution, that used this S3 bucket as a source.


Now to set up

AWS – Bastion hosts

For security reasons you should not have your aws resources (e.g. ec2 instances) directly accessible via the internet unless it is necessary, i.e. keep your aws resources internal. However you still want to be able to access your VPCs, there’s a few ways to achieve this:

  • Setup bastion hosts
  • setup vpn – covered later
  • set up AWS Direct Connect – covered later
  • A combination of the above.

A “bastion host” is a general concept and isn’t something specific to AWS. A bastion host is essentially an EC2 instance that sits inside a public subnet, which in turn resides inside a vpc. You can ssh into all the other ec2 instances inside this vpc, by first ssh’ing into the bastion host (since by design, all ec2 instances inside a vpc can communicate with each other via

AWS – Launch Configurations, Autoscaling Groups, and ELBs

Launch Configurations – let’s you specify a template for automatically create new instance, based on this presets. Therefore when creating a Launch Configuration resource you specify things like:
– AMI id
– Instance type
– Which vpc to build instances in
– IAM role
– default storage requirements. E.g. number and size of ebs blocks to attach to new EC2 instances
– User data script
– security groups
– which ssh keys to use, to log into instances

Autoscaling Groups – this is where you specify under what conditions to scale up and down. This includes specifying which Launch Configuration to use when scaling up/down, in fact this is the most important your autoscaling group requires. The autoscaling group resources needs to know which launch configuration to use when starting new

AWS – Amazon Machine Images (AMI)


AMIs created in one region cannot be used to create instances in another region. However you can get round this by copying the AMI to another region first.


You can also modify access permissions of the AMI, in the following ways:

  • Make the AMI public, so anyone can use it by finding it on the marketplace
  • Specify a list of AWS account names that can access the ami

However the region restriction still applies in both of the above cases.


An AMI is made up of 3 parts:

  • a snapshot of the root volume, /dev/sda1
  • launch permissions, i.e. is it a public ami, or restricted to a particular aws account
  • block device mappings. This means that an ami can be made up of several ebs snapshots in addition to /dev/sda1


You can create an AMI from an existing EBS

AWS – Virtual Private Network (VPN)

A VPN is essentially a subnet where it’s members are a combination of AWS resources and on premise devices. I.e. a a VPN is a subnet that extends to an on premise site. There are 2 ways to set up VPN:

  • Hardware based
  • VPN Tunnelling (OpenVPN)


Hardware based VPN

To set up a VPN, you need to have the following components:

  • Virtual Private Gateway (VPG) – This is an AWS resource that you create under the VPC section of your AWS console, and then attach it to your vpc, in the same way that you attach other things, e.g. route table. When creating a VPG, all you have to do is to provide a name for the VPG, and specify which VPC to attach it to:

  • Customer

AWS – DB Subnet Groups

A subnet by design is attached to a particular AZ. So all instances/resources that reside in a subnet actually exists in the same AZ.

However RDS has features such as Multi-AZ and Read Replicas, which are used for improved redundancies and performance reasons. However these features needs to know what other subnets it is allowed to build read replicas and multi-AZ passive/standby db’s into. You can tell this to RDS by providing a list of subnets, this list is referred to as a DB subnet group.

Note: if you want your read replicas and Mult-AZ standbys to be accessible via the internet, the subnets that you add to your DB subnet group needs to be public subnets (i.e. the subnet’s route table must have an entry pointing to your vpc’s internet gateway).