The Gamer Guide to Playing Amazon Web Services (AWS)

If you have played an MMORPG then you know the feeling of starting out in a new game. Your character is level one. You have a vast open world to explore, and there are tons of game systems and gear and skills to learn about. It all feels a bit intimidating when you start, but also exciting. After playing the game for a while you have a max level character. You’ve learned all the game mechanics and systems. If you look back at your journey of playing the game, it all seems a lot easier now.

I’ve made this gaming journey a few times myself over the years. According to Steam I’ve spent over 3000 hours playing Elder Scrolls Online since it launched in 2014. There was a lot to learn along the way, but it has been a really fun journey playing the game. Gaming isn’t the only thing I’ve spent a lot of time doing. Over the past 10 years I’ve spent far more than 3000 hours learning Amazon Web Services (AWS), but it has been an equally fun (and rewarding) journey.

In this article, I share a getting started guide for AWS, in a similar style to the getting started guides that many experienced MMORPG players write for new players. It is a lot easier to get into a game, understand what to do, where to go, and how to play optimally when you have tips from other players who have gone before you.

Behind the game: the community

The community for a online game is one of the things that makes a game what it is. Most people want to play popular games that have a lot of other players to interact with. Just like an MMORPG, you will find that AWS attracts countless players from around the world. The community is huge, and constantly growing. You can find fellow players in classrooms, workplaces, and attending tech meetups and conventions. You can connect to AWS Heroes and DevRel experts. There are AWS User Groups around the world, where you can meet up with fellow AWS players. And you can find AWS developers, heroes, and advocates on social media websites like Twitter.

Behind the game: the developers

One of the common complaints about video games is that the developers are unresponsive to issues that the game has. Developers leave bugs in the game, or break existing game features. The game servers go down and the game is unplayable. Or there are large gaps between new content releases for the game, leaving players bored.

AWS is built and supported by fantastic developers. One large expansion drops every year in late November or early December, during a week long event called re:Invent. This is when the developers release a ton of new features and content for AWS. But AWS is also regularly patched and updated with new content, quality of life improvements, and performance improvements throughout the year.

As you play with AWS you will find that the developers are extremely responsive to what you and other players ask for. Your social media posts, support tickets, Github issues, and IRL feedback directly contributes to deciding the roadmap for AWS.

What type of game is AWS?

Some games are heavily scripted, story driven games that take you down a main quest path to a destination. These games feel like theme parks, but they don’t give you very much freedom. When you play a story driven game it feels fun while you go through the main quest, but afterward there isn’t much left to do and you just move on to another game.

Other games are open world, sandbox style games that let you go anywhere and do anything, and play your own way. They put you in the middle of a vast area to explore, and let you decide what you want to do. These are the games that you can keep coming back to because there is always more to do and more things to try out. Next thing you know you have spent hundreds or even thousands of hours playing!

Main Quest	Open World Sandbox

 

AWS is a true sandbox game. There is no scripted main quest to follow. Instead AWS gives you a toolbox filled with everything you might need to build virtually anything you want on the Internet:

• A personal website or blog
• A small software as a service side hustle
• A social media website
• An online game
• A large unicorn startup with millions of users

All these things and more have been built and run on AWS.

If you have your own ideas, you can build and host them online. If you don’t have your own ideas about what to build yet, there are numerous companies that are building on AWS. If you know how to use AWS they will hire you to help them build. Both building on your own and working for a company can be very profitable for you.

Decide your character class

Because AWS is a sandbox there are no preset character classes. Instead your character class is up to you and what you like to do. However, here are a few popular roles that many AWS players take:

The Software Engineer - People who play this role are like a glass cannon damage dealer with high damage per second (DPS). They like to write code to solve business problems, but they often don’t like to worry so much about how their code gets run. They may interact with AWS services by writing code that uses the AWS API, but they are not as involved with the infrastructure that runs their code. Just like a glass cannon damage dealer, the software engineer can get a lot of work done, but they require other players to support their work.

The Operations Engineer - This support role is for people who enjoy infrastructure, but do not like writing business logic code as much. People in this role take code from a software engineer, and make it run on infrastructure in AWS. You could compare the Operator to a support whose role is to buff the damage dealers.

The DevOps Engineer - This is a hybrid role that combines the skills of the software engineer and the operations engineer. People in this role write code to automate infrastructure operations. The enjoy streamlining and optimizing how things get built, to save time for people in other roles. They usually have a “you build it, you own it” mentality. They can play solo if needed, writing their own code, creating their own infrastructure, and operating their code on their own infrastructure.

The Site Reliability Engineer (SRE) - This role is great for support players who want to help people in other roles work better together. The SRE focuses on the stability of what gets built. They help build tools for detecting when there are problems with what gets built, and tools for fixing things when they break. The SRE is like the party’s healer, keeping everyone alive and resurrecting allies that die in combat.

The Application Security Engineer - This role is like the party’s tank. They protect against attackers by helping engineers in other roles find and fix vulnerabilities that would allow attackers to destroy what the party is building. A good security engineer educates the rest of the team on security vulnerabilities in order to keeps the system safe, just like a tank might explain the raid mechanics to their group, in order to keep the raid boss from wiping the team.

The Quality Assurance Engineer - This is a support role similar to SRE, but it is more heavily focused on testing what gets built to make sure that the business logic is working correctly. While an SRE may be more focused on whether the code is crashing or slow, or whether the infrastructure is performing as intended, a QA engineer is able to use their depth of experience about common bugs, and find more subtle unintended behaviors in the overall system. The QA engineer is like that party member who has addons installed to monitor the team DPS, gear, and stats. During the fight they can identify problems that need to be fixed for the party to succeed.

Specialize first, then become more adaptable

There are many people who have played on AWS long enough that they can adopt multiple character roles from the list above. These people have really deep understanding of AWS, and are highly valuable in teams. However, if you are just starting out on AWS it is best to start out by focusing on a single role and becoming a specialist at it. Over time you should increase your scope by learning other adjacent specialties as well.

Unlike in most online games there is no limit to how many skill points, levels, or how much experience you can accumulate on AWS. Instead, it’s all about how much time you are willing to spend playing and learning. The more depth and breadth of understanding your character has the more successful and valuable you will be, both when implementing your own ideas, and when looking for a job at a company that is building on AWS.

A good party in any MMORPG requires people to fill all the key party roles like tank, support, healer, and damage dealer. On AWS it is the same: a party that is all software engineers would be like a party with all damage dealers. You need operations engineers, SREs, and other support roles to get things done effectively and efficiently. If you see a gap in your team or your own skills, try to level up the skills necessary to fill that gap.

Pick out the equipment your character will use

Equipping your character in an MMORPG is what gives you the strength to fight tough battles. Most games have hundreds or even thousands of different pieces of equipment you can collect and use. Some pieces of equipment may be more viable for certain styles of game play or character classes, so it is important to carefully consider which equipment is best for you.

On AWS there are over 200 services you can use, and thousands of features within those services. Choosing which services and service features to use can feel daunting, in the same way that picking the right equipment can feel daunting in an MMORPG.

One way to approach this problem is to start by looking at the basic “equipment slots” that need to be filled. On AWS there are no hard rules on equipment slots. You can collect and wear as much equipment as you want. However, there are a few key equipment slots you’ll probably want to have in your character build.

Boots: Data Persistence

Boots give you traction and keep you standing solidly on the ground. Likewise, persistence provides the stable foundation that you can build everything else on top of.

Your code probably needs to save data that your users send to the website, and then your code needs to retrieve that data and use it later. Persistence is what solves this problem. Some use cases for persistence might be hosting blog posts for your personal blog, remembering user accounts for your SaaS company, or storing and hosting photos that people uploaded to your social media website.

There are a wide variety of different AWS services that can fit into this equipment slot, and it is typical to use several pieces of persistence equipment at the same time.

• Database
  • Amazon DynamoDB - Serverless, NoSQL database. Great for low latency storing and querying of application data.
  • Amazon RDS - SQL database, for application data that fits well into a more rigid SQL schema
  • Amazon Redshift - Highly scalable SQL queries federated across multiple data storage sources
  • Amazon DocumentDB - NoSQL database with support for using the MongoDB query API to lookup matching arbitrary JSON documents.
• File and Object Storage
  • Amazon S3 - Durable, scalable storage for larger image files, video, or HTML page hosting. Objects are stored and retrieved via API request.
  • Amazon Elastic Block Store - Attach to an EC2 instance to add a highly performant durable filesystem.
  • Amazon Elastic File System - Attach to one or more EC2 instances so they can share the same networked filesystem.

Legs: Compute

Legs are used to move around and be agile. Similarly, compute is what keeps your business moving forward.

Business code has to run on a computer processor somewhere. The compute that you choose on AWS is what will provide that processor for running your code. It is possible to build “low code” services that use prebuilt building blocks to solve common business problems, but as you want to do more complex things you will always need some custom code to solve your unique business problems. This code has to run somewhere. There are multiple AWS services that can fit into the compute equipment slot and provide a place to host and run your custom code.

• Amazon EC2 - Virtual machines or bare metal instances in the cloud.s
• AWS Lambda - Upload your code as as ZIP file or Docker image and let AWS Lambda run it on-demand.
• AWS Fargate - Upload your code as a Docker image and run persistent containers that stay active for a long time.
• AWS App Runner - Upload your code as a Docker image and run it on-demand when a request comes in. Let the container “idle” when there are no requests, to save money if there is low traffic.
• Amazon Lightsail - Lightweight, cheaper compute environments, in a simpler learning environment.

Chest: Networking Ingress and Load Balancing

An armored chest plate takes incoming hits from enemies, absorbs the force, and distributes the force more evenly so you don’t get injured. If you are building and scaling an internet facing service on AWS, you need to be prepared to receive a lot of incoming “hits” from web browsers, web applications, or other clients. This is solved by ingress and load balancing.

AWS services in this equipment slot accept incoming connections and distribute them across your compute, so that you can have many copies of your compute working in parallel. Additionally, many of these services support “caching” or in other ways offloading some of the work from your compute. There are a number of services you should consider for solving this problem:

• Application Load Balancer and Network Load Balancer - An internet addressable endpoint that distributes traffic evenly across a lot of compute. Runs constantly for low latency traffic handling
• Amazon API Gateway - Serverless endpoint for distributing traffic to compute. Only runs and charges when you actually receive traffic.
• AWS App Mesh - Manages traffic ingress and traffic flow using Envoy proxy containers that run on your compute, beside your business code. Creates a service mesh for direct service to service communication with fewer networking hops in-between services.
• Amazon CloudFront - Responds to client requests using web servers that are distributed around the world, close to your customer web browser and mobile clients, so there is lower latency. Caches popular request responses that are frequently fetched, to reduce load on your compute.
• AWS AppSync - Helps you create GraphQL APIs in front of your backend data sources, so you don’t have to spend as much time coding an API, and can just focus on your data model and client code.

Head: Observability

In a game you often need perception to give you the sensory ability to detect danger and traps, as well as predict attacks before they happen, and dodge them. The helmet equipment slot for AWS encompasses various services that help you observe what is going on with your infrastructure, gather data, and make decisions. Without observability you could be making decisions based on incomplete information. Lack of observability results in slower resolution of problems, or wild guesses that actually make the situation worse.

• AWS CloudWatch - Store, graph, and alarm on statistics from your services. Store logs and query them with CloudWatch Log Insights.
• AWS X-Ray - Traces service to service connections and requests so that you can see the end to end flow of a backend request and it’s side effects in other downstream services.
• AWS CloudTrail - Keeps track of AWS API calls, what service or user made them.
• AWS Distro for OpenTelemetry - Helps you gather metrics, logs, and traces from your application and send them off to other services.
• AWS Managed Grafana and Prometheus - Prometheus is an open source database for storing metrics and other dimensional data. Grafana is an open source project for charting, graphing, and alerting on metrics.

Weapon: Infrastructure Provisioning and Orchestration

Your weapon is the tool you lead your attack with. It gives you options to change the outcome of a battle and come out victorious. On AWS you also need a primary tool to lead with. This tool is how you will initiate changes to infrastructure, and control the infrastructure. It can be used to create your compute and persistence, get your code onto your compute, setup the ingress to get traffic to your compute, and create the observability that you need to understand what is happening in your infrastructure.

This equipment slot is filled with AWS services that do infrastructure provisioning and orchestration. It is not uncommon to dual wield multiple services at the same time. Going without one of these services is like charging into battle unarmed: you might be successful if it is a low level fight in a starting zone, but in more challenging situations you will probably hurt yourself.

• AWS CloudFormation, and AWS Cloud Development Kit - AWS CloudFormation lets you declaratively describe the infrastructure you would like to create by writing a YAML document, and then you can let AWS CloudFormation create the described infrastructure on your behalf automatically. AWS Cloud Development Kit lets you use popular programming languages like TypeScript and Python to describe your infrastructure, with more advanced logic.
• Amazon Elastic Container Service, and AWS Copilot - Elastic Container Service launches containers on your behalf, monitors their healthiness, relaunches them or replaces them as needed, and automatically configures other AWS resources like load balancers to point at the containers. AWS Copilot is a tool that sets up ECS for you, as well as helping with local development workflows like building and pushing your Docker containers.
• Amazon Elastic Kubernetes Service - Elastic Kubernetes Services is AWS managed open source Kubernetes. Kubernetes has it’s own YAML based manifest format for describing infrastructure that you want to create, and it launches and orchestrates containers on that infrastructure.
• AWS App Runner - App Runner takes a container and gives you an endpoint for it. App Runner handles load balancing, autoscaling, and other operations automatically. You don’t have to provision or manage that infrastructure anymore.
• AWS Systems Manager - Systems Manager provides a variety of tooling for automating operations across a fleet of machines. You can run commands, install updates, and monitor and control an entire fleet from a single interface point.
• AWS Proton - Proton allows infrastructure experts to build reusable templates that developers can use to deploy their services. The templates can be centrally managed and updated after the fact to update all the services that were deployed using the templates.

Accessories: Specialized Solutions

Most games have equipment slots for rings, amulets, or similar accessories that empower your character with more capabilities. On AWS you can use as many accessory services as you want. Many of these can add specialized capabilities that are extremely useful for certain types of business problems.

• Amazon SageMaker - SageMaker help you train machine learning models, and then use the models at scale.
• Amazon Elastic MapReduce - Elastic MapReduce helps process large datasets using huge fleets of machines.
• AWS IoT - Services for managing, connecting to, and gathering data from Internet of Things devices.
• Simple Notification Service and Simple Queue Service - Send notifications to other services or to mobile devices with SNS. Absorb large numbers of incoming messages in a queue and process them at your own speed using SQS.

Equipment Set Bonuses

Games generally have equipment sets, and if you use multiple pieces of equipment from the same set then you get extra bonuses that make your character more powerful. Similarly, on AWS there are services which give you extra bonuses when you use them together, and you should consider using them in combination with each other. The following sets show some popular builds that people use when playing AWS.

Serverless Set

Business data is stored in DynamoDB, with on-demand scaling and billing. AWS Lambda executes business code on-demand in response to events like incoming requests. API Gateway serves as the ingress which executes an AWS Lambda function in response to an incoming request. Amplify is used to setup the infrastructure and deploy the function code. CloudWatch is used to monitor the infrastructure, and SNS and SQS are used to deliver and queue up events between the components.

Set Bonuses:

• Reduced operational burden: Services scale automatically, so no need to provision capacity ahead of time. Additionally all services used are automatically patched and maintained behind the scenes. No need to roll out an operating system update.
• Reduced cost when usage is lower: Services can “scale to zero” so lower usage means a lower bill.

Containerized Set

Data is persisted by a self managed, containerized database that writes into an EFS filesystem. The EFS filesystem is attached to AWS Fargate tasks that run application containers that are stored in Elastic Container Registry. AWS Fargate containers are launched and monitored by Elastic Container Service. AWS App Mesh handles ingress and distribution of traffic across a service mesh. AWS Distro for OpenTelemetry runs besides the application containers as a sidecar that sends observability data to other places. In the off peak hours large amounts of data are queued and processed using AWS Batch, which executes AWS Fargate spot tasks for each piece of work in a queue.

Set Bonuses:

• Reduced operational burden: AWS Fargate executes containers without you needing to provision EC2 instances as capacity. Additionally AWS Fargate manages host level maintenance and patching. You only need to be responsible for your application container. Elastic Container Service restarts your application if it crashes, and rolls out updates to the code automatically.
• Container ecosystem: Easily deploy prepackaged software containers that were built by other people, distribute your own software as containers, and benefit from the ecosystem of container focused tools.
• Reduced networking overhead: AWS App Mesh makes low latency service to service communication easier by connecting service containers directly to each other, with no load balancer hop in the middle.

Traditional VM Set

Data is persisted into Amazon RDS using basic SQL queries. Compute is done using EC2 instances. Incoming connections are accelerated by Amazon CloudFront servers around the world, then requests are distributed to EC2 instances by Elastic Load Balancing. The entire infrastructure is provisioned using CloudFormation and monitored using Amazon CloudWatch. Some data is also stored in S3 and hosted from an S3 bucket.

Set Bonuses:

• Tried and true: This set uses legendary AWS services that have been used by many other players for many years, so it is easier to find documentation and examples.
• Increased personal control: You control the underlying capacity that runs your service, even down to choosing a specific EC2 instance generation (and CPU) that is used for the database and compute.

Open Source Set

Compute and database are powered by EC2 instances orchestrated by Elastic Kubernetes Service. EKS managed by AWS is upstream, open source Kubernetes. The database is open source, containerized software that is running on EC2, managed by controllers within Kubernetes, and backed by persistent volume claims that use Elastic Block Store. Ingress is also managed by Kubernetes, which creates an Elastic Load Balancer to distribute traffic to Kubernetes pods. An open source OpenTelemetry sidecar sends application metrics to Amazon Managed Service for Prometheus, which is compatible with open-source Prometheus.

Set Bonuses:

• Portability: Because this set uses so much open source or open source compatible services it can more easily be replicated elsewhere, including on-premise data centers.
• Open Source: Most of the software in use is open source so you have the option to contribute back to the underlying tech that powers the stack.
• Abstracted: Kubernetes is used as an abstraction for many of the underlying AWS services, so if you have preexisting knowledge of the Kubernetes API, it can help you get up and running faster, without having to learn as many AWS concepts.

Starter Set

This set prioritizes simplicity. It is built around Amazon Lightsail, which is a low cost service that reduces your need to learn as many AWS concepts right from the start. Lightsail can be your database, your compute, and your ingress. Additionally, in this set we recommend using the AWS Console manually to start with, rather than learning infrastructure as code or orchestration. This allows you to focus on learning code first, then learn the rest of the concepts as you go.

Set Bonuses:

• Simplified pricing model: Lightsail has a simplified, reduced cost pricing model that can be easier to start out with.
• Abstracted: Lightsail abstracts away a lot of the pieces like orchestration, load balancing, networking, and logging. This makes it easier for you to focus on your code when you are just starting out.
• Not as configurable: This approach does not have as many configuration options. In the long run you may want to move to more configurable services, but initially the reduced configuration surface area means less ways to misconfigure things and mess up.

Build your own equipment set

There is no single equipment set that is perfect for every battle. Veteran players become experienced with multiple sets, and use different sets of AWS services to solve different problems.

However, the best set of AWS services to use is always going to be the set that you know best, because that is the set that will allow you to build faster and more efficiently. When you are working with tools that you know then you don’t have to spend as much time learning the tool itself. For example if you know SQL best then you will probably get the best results from using a SQL based persistence service, instead of NoSQL. Or if you know how to deploy your applications by using EC2 virtual machines directly then don’t feel like you have to use Kubernetes or other container orchestration just because it is popular.

In the long run you will gradually get better and better at AWS as you discover new use cases and expand the scope of things you understand how to use. But in the short term focus on delivering results with the things you do know.

Conclusion (of the article, but your journey is just beginning!)

Like an MMORPG, you will find that Amazon Web Services can keep you occupied for thousands of hours. AWS is a sandbox that offers you flexibility in what type of character you want to be: software engineer, devops engineer, SRE, QA engineer, etc. MMORPGs have lots of equipment to gather, and equipment set bonuses. Similarly, AWS has tons of services to choose from, but they fit into a few standard equipment slots: persistence, compute, ingress, orchestration, and observability. You can choose combinations of AWS services for these equipment slots that activate powerful set bonuses, such as the “serverless set”.

Just like when you are first starting out in a complex new sandbox game, things can look intimidating when you first start using AWS. But sandboxes are for playing in, so remember to have fun as you try things out. And don’t forget that if you get stuck there is a huge community of other players who can help you out!

If you have questions or suggestions, you can message @nathankpeck on LinkedIn.

You can also download the source file for the graphics in this post:

Downloads

• gamer-guide-for-aws.pptx (12148 kb)