Navigating the AWS Cloud: A Beginner's Guide to Getting Started

AWS for the first time could be really overwhelming. In this blog post, I’ll point your attention to the most commonly used AWS services and describe their place in the bigger picture.

Entering the AWS Console for the first time could be really overwhelming. Once you click on the search tab you will see a dropdown containing a huge list.

And how do you suppose to know that EC2 (standing for Amazon Elastic Compute Cloud) is your virtual machine?

So the purpose of this guide is to highlight the most commonly used AWS Cloud services so you are not lost when you start your AWS journey.

VPC and networking

Amazon Virtual Private Cloud (Amazon VPC) is a service provided by Amazon Web Services (AWS) that allows users to create isolated virtual networks within the AWS cloud, enabling them to launch and manage resources with control over network configuration and security settings.

VPC is definitely worth mentioning, you’ll need to create one so you have a place where you can put other AWS resources (like EC2, databases, etc.) - but most likely if you are joining a company that already using AWS - it should have VPC and networking setup so you won’t need to configure it yourself and probably won’t need to modify it too much.

But once you are more familiar with AWS in general I highly recommend setting up your personal AWS account and going through the VPC setup yourself. It will be definitely useful long-term and will learn a lot of new things (for most people), like CIDR blocks, private and public subnets, how to use VPC flow logs, etc.

If you want to learn more - start here: https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html

EC2 (Amazon Elastic Compute Cloud)

Now let’s move to something more used in day-to-day work: EC2. So it’s just a fancy name for you well-known virtual machines, you can request an instance (in most cases some sort of Linux) with some amount of CPU and RAM then log into it (via SSH from the local machine or from AWS Console) and do whatever you need. Install tools, run your applications, etc.

AWS Containers services

In many recent years, I don’t remember seeing anything that wasn’t eventually deployed as a container, so this is probably the most important section that you need to learn about AWS.

Of course, before you deploy something as a container you need to build it and publish it. So once you’ve built your Docker image (how and where you are doing it is up to you, that could be locally in the simplest case or as part of your CI pipeline) - it’s time to publish your image.

Amazon Elastic Container Registry (Amazon ECR) is a fully managed container registry offering high-performance hosting, so you can reliably deploy application images and artifacts anywhere.

ECR is the service to store your Docker images (privately), so you can use them in other AWS services, like ECS or EKS. A simple way of thinking about ECR is as a Docker Hub that is private to your AWS account.

The next bit is more interesting - how and where do you actually run your containers? And there are a couple of options.

Amazon Elastic Kubernetes Service (Amazon EKS)

Amazon Elastic Kubernetes Service (Amazon EKS) is a managed Kubernetes service to run Kubernetes in the AWS cloud and on-premises data centers. In the cloud, Amazon EKS automatically manages the availability and scalability of the Kubernetes control plane nodes responsible for scheduling containers, managing application availability, storing cluster data, and other key tasks.

So one option is to use an AWS-managed Kubernetes cluster (EKS) - it is a really powerful option as you basically have all Kubernetes features available, but it’s still quite a lot to manage. Yes the cluster itself is managed by AWS, but everything on top (e.g. a tool to deploy your Helm charts, etc) is up to the operating team in your company.

Honestly, I prefer a simpler approach to running containers in AWS - and it is ECS.

Amazon Elastic Container Service (ECS)

Amazon Elastic Container Service (ECS) is a fully managed container orchestration service that helps you to more efficiently deploy, manage, and scale containerized applications

So a couple of things to understand about ECS, first of all, new a need to create an ECS cluster - this will be the place where you can put your services.

The next thing is to define the underlying infrastructure, and again same as with EKS you have two options: EC2 and Fargate.

On EC2

In the case of EC2, you are responsible for creating instances first (that could be just single EC2 instances or they could live inside an auto-scaling group) - then you can add those instances to the ECS cluster, so they will be available for ECS to place your ECS services and tasks.

On Fargate

AWS Fargate is a serverless, pay-as-you-go compute engine that lets you focus on building applications without managing servers. Moving tasks such as server management, resource allocation, and scaling to AWS does not only improve your operational posture, but also accelerates the process of going from idea to production on the cloud, and lowers the total cost of ownership. 

In the case of Fargate, it’s even simpler - you don’t have to manage underlying EC2 at all.

Regarding costs, on paper Fargate is a bit more expensive, in reality, to make EC2-based deployment cost-efficient you need to spend a lot of time optimizing and balancing your tasks and underlying EC2 infrastructure and it’s really hard to fully automate. So you will end up with not fully utilized EC2 instances at some point. If your company don’t have a dedicated infrastructure team - I would suggest just using Fargate and focusing on the applications, not the infrastructure.

ECS services and tasks

In ECS you define your deployments and ECS services and tasks. The service will contain one or multiple tasks and you can define things like deployment strategy, instance count, etc. ECS tasks on the other hand describe which containers to run as part of the task, the core here is container definitions - JSON data that defines your deployment. I really like the simplicity of the format and that you can just use Terraform without any additional tools to provision your ECS services.

A simple task definition will look something like this:

{
  "family": "my-service",
  "containerDefinitions": [
    {
      "name": "web",
      "image": "my/image:latest",
      "cpu": 128,
      "memory": 512,
      "portMappings": [
        {
          "containerPort": 8080,
          "protocol": "tcp"
        }
      ]
      "essential": true
    }
  ]
}

Load balancers (ALB, NLB)

If you decide to use ECS, most likely you will need a load balancer in front of your ECS service, so you will have a single DNS name for your service and the load will be distributed across your ECS service instances. The integration between ECS and ALB (Application load balancer) is really common and easy to configure. There are other use cases for load balancers as well (not related to ECS).

S3 (Amazon Simple Storage Service)

The next crucial and really popular AWS service is S3 (it’s a triple S in the service name, that’s why it’s called S3). But it’s also really easy to describe - you can store any files or objects you want. The granularity is the S3 bucket where you can put your objects in a nested way (different S3 paths).

Databases

It’s almost a 100% chance that you’ll use some kind of database in your system. Depending on your architecture it will be most likely relational (SQL) or NoSQL database.

Amazon Relational Database Service (RDS)

If you want a PostgreSQL or MySQL you’ll use an RDS with the required engine type. The other thing to consider is Aurora which is the same RDS in a nutshell but with additional options like high availability and easier to scale.

NoSQL

A popular NoSQL database solution is DynamoDB. There is also a managed Cassandra (called Amazon Keyspaces).

CloudWatch

CloudWatch is a service where you will be able to find your logs and metrics. Most AWS services have a way to configure CloudWatch integration to save logs and additional metrics. There are some metrics available by default - so you can just explore what’s available. There is also an option to configure custom metrics and set up alerts and dashboards so you have better visibility of your system.

Messaging

There are different options regarding messaging and queues so you can pick something depending on your needs.

Amazon Simple Queue Service (SQS)

Amazon SQS provides queues for high-throughput, system-to-system messaging. You can use queues to decouple heavyweight processes and to buffer and batch work. Amazon SQS stores messages until microservices and serverless applications process them.

Kinesis

Amazon Kinesis cost-effectively processes and analyzes streaming data at any scale as a fully managed service. With Kinesis, you can ingest real-time data, such as video, audio, application logs, website clickstreams, and IoT telemetry data, for machine learning (ML), analytics, and other applications.

Managed Kafka (MSK)

Securely stream data with a fully managed, highly available Apache Kafka service

It’s out of the scope of the article to discuss differences and where to use what - but hopefully you won’t be surprised now when you hear SQS, Kinesis or MSK.

Serverless (AWS Lambda)

AWS Lambda is a compute service that runs your code in response to events and automatically manages the compute resources, making it the fastest way to turn an idea into a modern, production, serverless applications.

Some people use AWS Lambda quite heavily, and some do not. AWS Lambda is a service that will allow you to run your serverless functions (in supported languages) without provisioning the infrastructure (like EC2s).

Analytics

If you work with data and analytics, most likely you will end up working with Athena (a query engine, for example on top of data stored in S3), AWS Glue (a tool to manage schemas for your Athena tables)

AWS Costs

It’s also worth mentioning the AWS Costs Explorer - a place where you can check your costs (hopefully they are not skyrocketing). A useful feature there is that you can split it by service, resource or tag (it’s really important to tag our resources when you create them).

I hope that was a useful overview of AWS Cloud. There are a lot of nuances in all of the services and it just takes time to become familiar - so don’t worry too much!