How to Learn AWS – Starting Points for Frontend, Backend, Devops, and Data Engineers

If you’re just starting to learn AWS, you’ve probably realized the number of services is completely overwhelming. To date, there are over 200 AWS services available to use.

But do you really need to learn them all? The answer is unequivocally no, but there are a bunch of core services you do need to learn that you’ll interact with on the daily.

Depending on your career specialization (or aspirations), you’ll also need to learn some other services that you’ll be using regularly. After all, the services a Backend Engineer interacts with regularly will be very different than what a Devops Engineer interacts with.

In this blog post, I’m going to highlight the core services for four career paths – Frontend Engineers, Backend Engineers, Devops, and Data Engineers. I’m going to break down the services you need to learn and give you a brief explanation of what they do.

Visual learner? Check out my YouTube video below on this topic.

Common Concepts and Services Required for ALL Career Paths

There’s a number of fundamental concepts and services that any user needs to know about regardless of career path. Here they are in no particular order.

Regions and Availability Zones

Regions are physical collections of data centers in different parts of the globe. When interacting with AWS, most services are scoped to specific regions. For example, you can great table called Customers in the us-east-1 and eu-west-1 regions (two of the most popular regions out there).

As a general rule of thumb, you want to create your infrastructure in the region that is closest to where your customers are located. This will ensure low latencies for the majority of your customers.

Availability Zones or AZs

Availability zones on the other hand are partitions of data centres with isolated fibre optic lines, power supplies, and other infrastructure components. Also known AZs, availability zones help you achieve higher levels of availability by separating your infrastructure out across multiple logical partitions of aws infrastructure.

For example, if I were building an EC2 based NodeJs app, I would deploy EC2 instances to us-east-1 and distribute them across zones 1a, 1b, and 1c. This will ensure that if a single AZ goes down due to a power outage, natural disaster, or other unexpected issue, you app will still be available in the other AZs. Traffic will still be able to flow unimpeded to the remaining 2 zones.

Some managed services do not support multi az availability as a configuration option. An example is DynamoDB where all you specify is the region. Don’t worry though, behind the scenes most managed services distribute your data across multiple AZs as a feature.

CloudFormation and CDK

CloudFormation and CDK (Cloud Development Kit) – in the early days of AWS, the standard way to create your infrastructure was manually through the AWS console, or using the AWS CLI (command line interface).

As the amount of moving parts in our application has grown, so too has the amount of time we need to spend creating and managing them.

CloudFormation was the first attempt at making infrastructure creation easier. It is an AWS service that lets you ceeate template files that define your Infrastructure as Code. Template files and straightforward to create in JSON or yaml formats, but can be a bit verbose.

CDK is an improvement on CloudFormation. It allows you to write code to define your resources instead of template files. This makes it much easier to create reusable functions that contain many smaller AWS components.

Overall, the industry is trending towards using CDK as the primary way to create your infrastructure. That being said, I don’t suggest you dive into using CloudFormation or CDK if you’re just getting started with AWS. I find that using the console helps you get more familiar with the services and their components. Once you get the general idea of common services, it makes sense to hop on board and start using CDK.

IAM

IAM, or identity and Access management is the permission system of AWS. Users create users, roles, and policies that define what permissions a user or group of users has access to.

You can also attach IAM roles to Infrastructure components such as AWS Lambda to really be granular on the permissions your infrastructure has access to.

Many folks overlook learning IAM and end up getting stuck with abstract permission errors that appear non sensical. I can’t stress this point enough: learn IAM right away. You’ll save yourself a ton of headaches in the future.

Learn more about IAM here in my Youtube Video on the topic.

VPC

VPC stands for virtual private cloud. It allows you to create isolated networking environments on your account to protect your infrastructure from outside actors.

Brand new AWS accounts come with a default VPC with some very liberal permissions. This can get you pretty far on your learning AWS journey. This setup is often enough to tinker with a bunch of AWS services to get a feel for how things work.

If you’re creating a production application I’d suggest creating a simple VPC to govern your resources.

Cloudwatch Logs

Part of the unfortunate reality when working with AWS is the necessity of debugging. This can take shape in many forms – metrics, dashboards, or most importantly, logs.

Many services generate logs as an output. This is critical information for debugging during the setup phase, and also helps evaluate your application in production.

Cloudwatch is the service that contains the logging functionality in AWS. Cloudwatch itself is what I call an umbrella service. It contains a ton of other smaller features embedded within it, mostly providing monitoring functionality.

Cloudwatch Logs is the portion of cloudwatch that allows you to view application logs. Logs are divided into streams that you can browse through according to time range.

Learning about Cloudwatch logs is an important part of becoming proficient in AWS. After all, you can’t debug what you can’t see.

Career Paths

So far we’ve touched on a bunch of services that should serve as base knowledge. Here is a refined list of services that you should be familiar as a FrontEnd, Backend, Data, or Devops Engineer.

There’s a broad range of services here across AWS and it would be cumbersome to provide detailed explanations for each. I’ll provide a brief explanation on each service with a link to a resource (if available) on the topic at hand to learn more.

FrontEnd Engineer

1. Amplify – Amplify is a newer service that allows you to easily spin up a group of functionality specific resources. It is specifically tailored towards full stack applications providing an easy way to setup the frontend, backend, authentication, and scaling. It supports web based and mobile applications and expedites the process of setting up your infrastructure.
2. Route53 – Route53 is the DNS management service of AWS. Use it to create your familiar A records and CNAMEs to manage DNS level routing to your endpoints.
3. CloudFront – Cloudfront is a content delivery network meant to increase performance of your front end applications. You can use it to create a distribution to globally serve your traffic to edge endpoints around the world. This ensure ideal performance for your users regardless of their physical location. Particularly useful for media files such as html, css, js, images, video, etc.
4. API Gateway – Allows you to create HTTP, REST, or Websocket APIs. Has additional functionalities that ‘hook in’ to backend compute services such as EC2. Supports authN and authZ via Cognito (below)
5. Cognito – Cognito is AWS’ identity provider. Use this to manage user logins, and in conjunction with API gateway, to lock down permissions to your APIs.
6. S3 – One of the oldest services offered by AWS. Allows for cost effective data storage using a folder like structure. Supports arbitrary file sizes and is highly available. For a frontend dev, you would usually store your asset files in S3, and replicate them globally with a CloudFront distribution.

Backend Engineer

Note: I am a backend engineer by profession. This list may seem large but is based on my professional experience.

1. EC2 – Elastic Compute Cloud. Allows you to ‘rent’ virtual or physical machines from AWS. Machines come in a variety of CPU and memory configurations with different costs. The bread and butter of AWS.
2. Lambda – AWS Lambda is a serverless compute resource. You write functions that are just blocks of code that can be run ad-hoc. You can also integrate them with services such as API gateway to build full-fledged REST APIs.
3. ECS/EKS – Elastic Container and Elastic Kubernetes Services. For those of you that love docker, this is the service for you. ECS/EKS makes it easier for you to manage image environments and maintain services.
4. Application and Network Load Balancers – Distribute traffic to multiple machines that back the load balancer. Targets can be a variety of types including EC2 or ECS clusters.
5. Certificate Manager – To provide SSL support for our infrastructure, we need a way to create, manage, and distrubte certificates. Certificate Manager is the service that makes this possible.
6. SNS – Simple Notification Service. Is the “Pub” in PubSub. Similar to Kafka, application owners set up topics that they publish event updates to. Subscribers ‘subscribe’ to the topic and can get notified.
7. SQS – Simple Queue Service. Is the “Sub”. Provides a mechanism to queue messages for later consumption. Allows for async message processing where you as the consumer can control the consumption rate.
8. Step Functions – Allow you to create serverless workflows by generating a Directed graph. Supports control structures including branching logic to create custom use case specific workflows.
9. DynamoDB – The classic Managed NoSQL Database. Optimized for scale and consistent performance, DynamoDB is the database of choice for developers serious about building highly available and high throughput applications.
10. RDS – Relational Database Service. The RDBMS service of AWS. Supports a variety of database engines including MySQL, Postgres, Oracle, Microsoft SQL Server, MariaDB, and more. Also within RDS is Aurora, the Amazon build RDBMS compatible with MySQL and Postgres dialects.
11. ElastiCache – The caching service of AWS. Supports Redis, Memcache, and Cacheout protocols.

Data Engineering

1. Glue – Glue is what I consider a umbrella service. It contains a whole bunch of functionalities dedicated to ETLing your data. Many of the components are serverless as well including crawlers and classifiers.
2. Batch – If you’re looking for an easy way to run batch computing workloads on a fixed schedule, AWS batch is the service for you. It is a fully managed service with a serverless option to run your jobs, even supporting priorities.
3. Redshift – Redshift is AWS’ wide column database meant for data analytics. As a data engineer, you’d likely be responsible for loading the data into your cluster. Redshift supports 1 or more machines that act as a cluster to manage your complex queries.
4. Lake Formation – If you’re looking to build a datalake for your organization, lake formation is an excellent choice. It provides methods to aggregate and index your data based on name and type, all while providing self serve access.

Devops Engineer

1. CodeCommit – CodeCommit is a source control registrar hosted on AWS. Similar to github, CodeCommit allows you to store your source on the cloud and collaborate with your peers.
2. CodeBuild – CodeBuild is a service that feeds into the continuous deployment space. It allows you to build your source code and run corresponding tests to create a ready to deploy build artifact.
3. CodePipeline – CodePipeline helps deploy your resources out to your corresponding hardware. Whether it be ECS, EC2, or Lambda functions, CodePipeline supports a variety of deployment targets. Pipeline is essential in any team serious about continuous delivery or continous integration.
4. Cloudwatch Alarms – What good is building a service if we don’t get notified when things break? Cloudwatch Alarms allow us to set an alarm that fires whenever a specific metric passes a threshold. For example, when latency rises above 1 second, or when we have a high number of errors in our application. Cloudwatch alarms can trigger emails, pagerduty pages, and other notification mechanisms to draw your attention to an application in distress.
5. Cloudwatch Monitoring – In order to have alarms, we need to know how to monitor our application. Cloudwatch monitoring helps users discover and graph service metrics related t their applications. Use it to create latency graphs, error graphs, or more sophisticated graphs using this service.
6. Cloudwatch Dashboards – Dashboards are your one stop shop for evaluating application health. As a Devops Engineer, you’ll be spending lots of time looking at dashboards to make sure things are running smoothly. Get used to building and navigating through dashboards.

Summary

Learning AWS is not an easy task and takes dedication. In addition to learning the fundamentals, learning a handful of services in each career category is an effective way to build skills for your next AWS job.

Regardless of which career path you choose, I highly encourage you to get your hands dirty in AWS. Start building things, no matter how simple, to get familiar with the services and how they operate. I can’t stress enough how important getting hands on experience is. It isn’t enough to read blog posts and watch youtube videos – you need to get your hands dirty.

If you’re looking for projects to get your feet wet, check out my YouTube channel (and this playlist below) for hands on practical projects in AWS. In fact, the one below will help you set up your first React App on AWS with S3, Cloudfront, and Route53!