AWS API Architecture

I recently worked on a project which involved separating out the API from a monolith application, containerizing and deploying it to AWS. This was my first experience deploying to AWS, so in order to solidify what I learned during this process I've decided to document some of the resources I used and how they interact with one another.

Regions & Availability Zones

Regions are a grouping of AWS resources in a certain geographical location. Within each region are clusters of data centres called availability zones.

Each region contains multiple availability zones which are physically separate from one another to ensure they are isolated from failures in other zones. The zones are then connected through ultra-low-latency networks.

Any AWS resource you create must be placed inside a VPC subnet (we'll cover this), which must be located within an availability zone. It's often a good idea to launch resources in multiple availability zones to ensure maximum uptime.

Virtual Private Cloud (VPC)

A VPC is a private virtual network where you can provision AWS resources - in essence your own private area within AWS. You have complete control over this environment including selecting IP addresses, route tables and network gateways.

Working with subnets we can setup private and public facing environments and control who can access these, and how. A VPC will span all of the availability zones in a region.

Subnets

A subnet is a sub section of a network and can be either public or private. The key difference being, public subnets have a route to the internet whereas private ones do not and can only communicate with other subnets within the same VPC.

One or more subnets to each availability zone, but each subnet must reside entirely within one zone, and cannot span zones.

A quick analogy for everything covered so far

Imagine an office building as being a region - an outer layer that contains many things.

Each floor is an availability zone. A region can, and most likely will, have more than one zone, much like a building and floors!

Each department is a VPC, it can span across floors.

Finally a subnet is the office suite - it can only reside within a single floor.

Security Groups

Security groups act as a virtual a firewall - they allow and deny traffic. They operate on an instance level rather than a subnet level, so you would apply a security group to each instance you launch.

You apply rules to each security group to allow traffic to and from its instances. These rules can be modified at any time and will instantly apply to all instances associated with that security group. Multiple security groups can be added to each instance.

By default all inbounded traffic is denied, and all outbound is allowed.

To continue with our office building analogy, security groups would be the key cards to access different areas of the building.

Application Load Balancer

An application load balancer is essentially a server which fronts the application and forwards traffic to instances downstream - so in our case the Fargate instances. It's used to spread the load across multiple instances whilst providing a single point of access.

It will also perform health checks on our instances and if one instance fails the load balancer will direct traffic to the remaining healthy ones. We provide a route - for example '/health', and if this returns a 200 it knows the instance is healthy.

Other features of the load balancer includes:

• Providing support for SSL/HTTPS.
• Works across availability zones, so if one zone goes down the load balancer will move all traffic to the other zones.
• Separating public from private traffic.

Route 53 && Internet Gateways

Route 53 is a managed DNS - a collection of rules and records mapping IP addresses to URLs. It can be used for both public domain names and private domains - which can only be resolved by instances within the VPC. Route 53 can also provide load balancing through DNS and limited health checks.

Internet gateways provide the VPC with a route to the internet. If you think of your home network as a subnet, your modem would be the internet gateway proving access to your ISP and the wider internet.

Only one internet gateway can be applied to any VPC, and a gateway cannot be detached from a VPC whilst there are any active instances still running on it.

AWS Fargate

The final piece of the puzzle is Fargate - "a serverless compute engine for containers that works with both Elastic Container Service (ECS) and Elastic Kubernetes Service". This is where we provision our API containers.

Fargate is a kind of evolution of Elastic Container Service. It's managed by AWS - removing the need to provision and manage servers, and it scales up and down seamlessly, meaning you only pay for what you use. You can think of it as containers on demand - where everything is managed at a container level.

Conclusion

Hopefully this provides a high level understanding of some of the resources that go into setting up a containerized application on AWS. Of course, the best way to fully grasp these concepts is to dive in and get hands on.

Here are some resources I have found to be particularly helpful:

• Linux Academy - AWS Essentials
• A Cloud Guru - Cloud Training
• Stephane Maarek - AWS Certified Solutions Architect Associate
• And of course, the AWS Documentation