AWS Microservices Cheatsheet

When working with microservices on AWS, we tend to use multiple tools/services provided by AWS to seamlessly create and deploy our entire architecture. I’ve been working with these services for over 5 years and compiled the list below based on that experience.

API Gateway
It acts as a front door to all the APIs in our system that is all APIs from all our services will have a common point of entry and that will be the gateway.
AWS API gateway helps us create REST as well Web socket APIs, and that too we can have edge or regional optimized.
We have used it for centralized authentication system as it provides multiple built in authorizers like AWS IAM, Cognito and we can create custom as well from Lambda.
If your microservices need data to be exposed via API Keys and you have requirements of throttling and rate limiting, then the gateway provides with API Keys and Usage plans too. (*It has limit quotas so be cautious*).
We can forward our incoming request to our server, lambda or various other services directly with the integrations it provides.

Cognito
Every application has to have user management, and for the secure authorization and authentication of users there are various 3rd party services like Okta, Auth0, OneLogin, keycloack and similarly AWS has cognito.
We have preferred cognito as it is integrated seamlessly on our API gateway and as our other tech stack is also on AWS our whole data is consolidated at the same place. With app clients we generate set of tokens (Access, Identity, Refresh) and use this for authentication & authorization. It provides separate pools like User Pool and Identity pool and aslo MFA everything else pre setup to configure and use..

Lambda
Small Functions that trigger based on events what makes Lambda very useful to create independent functionalities and utilities. Like we used lambda for Authentication at api gateway, and also have created several small utilities like resizing of images, sending 3rd party notifications. The beauty of AWS lambda is prebuilt trigger services like Event Bridge, SQS, SNS, Gateway and many other which helps us to connect the part and serve the functionality by going serverless.

Network Load Balance (NLB)
A load balancer serves as the single point of contact for clients. The load balancer distributes incoming traffic across multiple targets. We do configure NLBs wherever we need to server our servers running inside our private VPC to the public clients. Also while integrating API Gateway with our microservices running in private subnet, we have created VPC Links using NLB to route our request.

VPC Links
VPC links enable you to create private integrations that connect your HTTP API routes to private resources in a VPC, such as Application Load Balancers or Amazon ECS container-based applications. While working with AWS API Gateway exposing our servers running privately is not as straight forward and for that vpc links come handy.

Application Load Balancer (ALB)
An Application Load Balancer functions at the application layer, the seventh layer of the Open Systems Interconnection (OSI) model. After the load balancer receives a request, it evaluates the listener rules in priority order to determine which rule to apply, and then selects a target from the target group for the rule action. You can configure listener rules to route requests to different target groups based on the content of the application traffic. Various routing algos can be configured. By creating listener rules like header based, path based we are able to route our request to service it belongs too, like if path is /users we are able to send it to user-service similarly if path is say /orders we can route it to order-service.

Target Groups
Each target group is used to route requests to one or more registered targets. When you create each listener rule, you specify a target group and conditions. When a rule condition is met, traffic is forwarded to the corresponding target group. We can configure Health Checks, Sticky Sessions in target group and that will keep checking whether our service is available or not.

AWS Private VPC
A virtual private cloud (VPC) is a virtual network dedicated to your AWS account. It is logically isolated from other virtual networks in the AWS Cloud. You can launch your AWS resources, such as Amazon EC2 instances, into your VPC. Its always preferable to create all your services in Private VPC and allow only restricted access wherever required.

AWS ECS (Elastic Container Service)
Containerization is heart of microservices. AWS provides with ECS that has been mine DeFacto standards to deploy and manage all the services which I have come across till now. With compute options like Fargate, EC2, Anywhere it makes deployments of containers very easy for developers.
Also autonomous provisioning, auto-scaling makes sure that our tasks running in services are adequate to server the incoming traffic and as well cut down extra cost when not needed. We can also setup Service discovery as it uses AWS Cloud Map API actions to manage HTTP and DNS namespaces for ECS services.

AWS ECR (Elastic Container Registry)
To maintain all our docker images we have setup a CI-CD pipelines say why various tools like jenkins, github actions etc and after build of our code push the docker image to ECR. Then these images can be pulled in Task Definitions of Service running in ECS and container can run. This repository is well maintained with all versions and timestamps which helps us to restore back containers whenever required.

AWS MSK (Managed Streaming Service for Kafka)
In Microservices, events and asynchronous communication plays a vital role in integrated functioning of decoupled servers. With various options like SQS, SNS and other queues like ActiveMQ, Rabbit MQ, the products I have worked on have chosen Kafka as standard and MSK as the core service. Running and maintaining Kafka brokers oneself is a big pain and MSK has always helped us in using Kafka rather then maintaining it.

AWS Aurora
In Microservices our services can have databases dependent on requirements, since Aurora support MySQL and Postgre. Most of us would be familiar with RDS, but Aurora tend to have better performance in our usecase.

AWS DynamoDB
If you are working with AWS then its instead of using other opensource dbs like Mongo, Cassandra for NoSQL requirements the AWS team will always focus on DynamoDB as it gets along well with its other set of services. With dynamo there is also DAX which act as a caching layer.

Event Bridge
Amazon EventBridge is a serverless event bus that makes it easier to build event-driven applications at scale using events generated from your applications, integrated Software-as-a-Service (SaaS) applications, and AWS services. Lot of prebuilt sources and sinks make it plug and play useable.

Apart from these several services like Cloudwatch, X-Rays, IAM are always available and common across services that comes handy and while working you must have idea about.