Getting Started with Amazon Web Services

Amazon Web Services is a cloud platform that allows fast and cheap provisioning of environments. This gives businesses the opportunity to build environments, scale them when their requirements change, and test at a low cost, all with a few clicks.

The idea here is that instead of going to an external hardware infrastructure supplier, working out sizing and cost, and having fixed contracts — you simply go to AWS and provision all this yourself, with no fixed contract, scaling up and down based on demand.

Regions and availability zones

In order for this to work, there obviously needs to be some physical hardware infrastructure somewhere. Amazon splits theirs into Regions. Amazon currently has 25 regions, and this number is steadily increasing. These regions relate to the geographic locations of data centres.

As an example, there is a region called US East (Ohio) and another called EU (London). That means there are data centres in specific geographic locations. When building an AWS instance, you want to make sure the Region selected is the one closest to those who will be accessing it frequently, to reduce latency.

Each region has a number of locations within it called Availability Zones. These provide failover functionality — if one Availability Zone is down, the others should be isolated and therefore available. They’re designed to be isolated but have low-latency connections to other Availability Zones in the same region.

Edge locations

If you are accessing a service hosted in a particular region from far away, your latency increases as the data has to travel a larger physical distance.

To resolve this, AWS has the concept of Edge Locations — data centres that hold cached data that was at some point transferred from the origin server. When someone wants to access that content, they get much lower latency because they’re accessing a cached copy local to them, rather than pulling it from the origin region.

Edge locations tend to be hosted within highly populated areas, and naturally there are more edge locations than regions.

Route 53 — DNS

Route 53 is the AWS Domain Name System (DNS) web service. Its goal is to translate domain names to IP addresses so web content can be served to users.

It gets its name from Route 66 in America as a metaphor — and the number 53 comes from the port used for DNS server requests.

IAM

IAM stands for Identity and Access Management. IAM allows you to secure how people access resources and services within AWS. You can create Roles and Groups and assign them to users.

You can also use IAM for tasks such as enabling Multi-Factor Authentication and enforcing a password policy for your users.

Groups, users, roles, and policies

A Group is just a cluster of Users. This allows you to apply roles and policies to a group, and every user within it automatically inherits them.

A User relates to an account, in most cases for a single individual. Users can be added to groups to obtain their roles and policies, and you can add further roles and policies to an individual user if they have a special requirement outside their group.

A Role provides delegated access to AWS services or resources. A role has policies attached to it similar to a User, but it’s intended to be used by whoever requires temporary access to a service or resource that wouldn’t usually have it — for example, granting a mobile app access to a service without embedding access keys directly in the app, or granting someone in another AWS account access to a resource.

Policies specify a set of permissions that allow Users or Roles to perform certain activities. They’re a great way to define exactly what can and can’t be done, and can be attached to Users or Roles.

API calls and authentication

If you have a service that needs to continually connect to AWS, you don’t want to store access keys within the application for each call — this could allow someone to extract them and gain access to your AWS account.

To get around this, for web applications, AWS uses Web Identity Federation. A user authenticates with the origin application first; that application then gives the user a token they can use to call AWS via the AssumeRoleWithIdentity API, which grants temporary security credentials.

The same flow applies with Active Directory: you log in via Single Sign-On, the browser receives a SAML assertion from the AD server, and posts that assertion to the AWS SAML endpoint using the AssumeRoleWithSAML API to request temporary security credentials. The user can then access the AWS console.