The AWS console and documentation can get pretty overwhelming really fast. The acronyms, the system’s design and how can services get inter-connected, can raise more questions than you might already have. Here’s a cheat sheet for the most popular AWS terminology and services.
How the global AWS infrastructure is structured
AWS services are either global or region-specific. For example, user management (IAM) is global, while database management (RDS) is region-specific which means that when you deploy a database instance, it will be hosted in a data center in the region specified. Think of it as a tree like the one in the figure below:
Global (the world)
|
|--> Region (a geographic region where the data centers are in,
| eg. eu-central-1 refers to Frankfurt, Germany)
|
|----> Availability zone (A location within the region specified,
that indicates the actual data center)
The main AWS entities that have to do with your account (such as user management, organizations etc) are available globally, so are some services that are global by default (for example Content Distribution Networks). The rest are available at a region level which means they’re allocated in certain cities around the world and contain availability zones, actual physical locations for data centers in those. There also are Edge locations but let’s not bother with those, just yet.
User management
If you have already signed up with AWS, you have created the “root user” for your account. This user is the super-administrator for your account and you should make sure it’s secure with a strong password and 2FA (two factor authentication), through IAM (Identity and Access Management).
Every AWS account can have its Users that can be organized in Groups. Roles, is another type of user as well, which can and should be used, when delegating third-party access to your account, either an application or an individual, by using temporary credentials. Each user can be assigned Console (Web UI) or Programmatic access (via tooling).
A Policy is what provides access control to Users, Groups and Roles. They’re simple and thoroughly documented JSON documents that define the associations and access levels for each entity in the IAM console.
Commonly used AWS services
Next, let’s have a quick rundown of the services you’ll be frequently hearing about
EC2 – Elastic Compute Cloud
What it is: Server instances that run your applications
Use case: Anything that requires a server to run, from running a web server, to video rendering. Instances should be considered disposable and any permanent storage should be added by using one of the storage solutions AWS offers (for example Elastic Block Storage or Elastic File Systems for files, RDS for databases and so on).
When visiting the EC2 console you might need some additional context:
- Amazon Machine Images (AMI) — AMIs is what the instances are based upon. These are ready made images of operating systems you can use to run your instances by, or you can create your own, as snapshots of instances that are currently running
- Elastic Block Store (EBS) — Instances should be considered disposable and the storage that comes with them is labeled as ephemeral. Use EBS to add disk volumes that mount to your instances
- Security groups — Enable or disable access to certain ports and IPs for both inbound and outbound network connections to the resources
- Load Balancer — You’ll need this if you need to run multiple server instances. It’s responsible for distributing traffic between multiple servers
- Auto Scaling — A bit of an advanced feature, scales your EC2 instances up or down, depending the load your service is experiencing.
RDS – Relational Database Service
What it is: Managed Database Server instances
Use case: Your application needs a database and you need to run it on a dedicated instance, where you will have daily backups, the ability to switch back to a previous backup instantly and enhanced performance metrics
Note: Security groups apply here as well
ElastiCache
What it is: Managed Cache instances
Use case: Your application needs a caching backend such as Redis or Memcached and you need that to run on single or multiple nodes.
Note: Security groups apply here as well
Cloudfront – Content Delivery Network (CDN)
What it is: Fast & Efficient file caching around the world
Use case: Your application servers user-generated content or static files that you need to cache and serve fast to your users. Also helps when your app faces performance issues
S3 – Simple Storage Service
What it is: Infinite file storage
Use case: You need to store user-generated content, static files, files that your application generates periodically. This service is intended to be used with files that don’t change often if not ever.
EFS – Elastic File System
What it is: Disk volumes with infinite file storage
Use case: You need to store files that change frequently, either by your operating system or your app. Unlike S3, this is intended to be used for files that get updated regularly.
SES – Simple Email Service
What it is: Managed Email Service
Use case: Your app needs to send out a significant amount of emails
Route53 – DNS Service
What it is: DNS Management Service
Use case: Your app needs to have one or more domain names
VPC – Virtual Private Cloud
What it is: A virtual network within which you can deploy isolated resources
Use case: Grouping resources in isolated networks where you have added control of security & network access.
IAM – Identity and Access Management
What it is: User, Groups, Roles and Policies management
Use case: You need this to define your everyday-use user, the access levels and programmatic access to your account.
Note: Security groups apply here as well
ECS – Elastic Container Service
What it is: A Container Orchestration service
Use case: Your application is containerized and you need to run containers to the cloud instead of plain EC2 Virtual Machines
Note: Security groups apply here as well
What are the next steps?
AWS offers tens of services that solve real problems for developers. We’re not going to describe every single one. On the contrary, on next posts, we’ll focus on the services described above and dive a bit deeper. You’ll find that there’s a common pattern when developing with AWS services, that applies to pretty much every service available