Major AWS Services

EC2 is Amazon Elastic Compute Cloud, providing resizable compute capacity — that is, virtual servers. S3 is Amazon Simple Storage Service, storing any amount of data as objects. Swapping these two has long been a common mix-up, so it helps to recall the role from the spelled-out name. Running function code is Lambda's role, and sharing files is EFS's role.

Lambda lets you run code without provisioning or managing servers, and you are billed only for the compute time you consume. No charge accrues while code is not running, which is the key difference from EC2, where cost accrues for as long as the instance keeps running. The number of functions or the size of the uploaded code itself is not the billing unit.

Serverless does not mean there is no physical server; it means the customer does not need to provision, configure, or scale servers. Lambda is described as letting you "run code without provisioning or managing servers," and Fargate is described as removing the need to "provision, configure, or scale servers or clusters." The physical server exists on AWS's side, and deciding the OS type or patch policy is characteristic of a form like EC2.

Fargate is a serverless, pay-as-you-go compute engine for containers that removes the need to provision, configure, or scale servers or clusters, and is used as a launch type for ECS or EKS. Managed Kubernetes operation is EKS; choosing instance type and count yourself is the EC2 launch type; and defining steps as a workflow is Step Functions.

The basic capacity choices for ECS are Fargate, which is serverless with AWS managing the underlying compute, and EC2, where the customer selects and manages the instance type and count. There are also ECS Managed Instances and, for on-premises, ECS Anywhere. Regardless of which one you choose, ECS is the service that places and scales containers; what changes is only who takes care of the underlying compute.

EKS is Amazon Elastic Kubernetes Service, a managed service that lets you run Kubernetes on AWS without installing and operating a Kubernetes cluster yourself, and it is certified Kubernetes-conformant. Automating database operations is RDS's role, delivering content from a nearby location is CloudFront's role, and distributing traffic is Elastic Load Balancing's role.

Lambda lets you run code with no server management, billed only for the compute time consumed, with no charge while it is not running. So for processing that is triggered sparsely, Lambda is favorable because no cost accrues during the idle waiting time. Configurations that keep an EC2 instance or an EKS cluster running continuously incur cost for the large stretches of time when no processing is happening.

EC2 is officially described as a service that provides secure, resizable compute capacity in the cloud, where you pay only for what you use and have full control over the compute resource. Being billed only for execution time and never touching the OS describes Lambda, storing data as objects describes S3, and defining a workflow as states describes Step Functions. The tradeoff for such broad control is that OS management remains with the customer, which is worth keeping in mind alongside it.

ECS is Amazon Elastic Container Service, a fully managed container orchestration service that makes it easy to deploy, manage, and scale containerized applications. Providing a Kubernetes-conformant cluster is EKS's role, launching virtual server instances is EC2's role, and running code in response to events is Lambda's role. ECS and EKS both group containers together, but they differ over whether Kubernetes is used.

EKS is a managed service that lets you run Kubernetes on AWS without installing and operating a Kubernetes cluster yourself, and it is certified Kubernetes-conformant. ECS, on the other hand, is AWS's own fully managed container orchestration service that does not presuppose Kubernetes. Both are services that handle containers, not services limited to virtual server images. As a launch target, both can also use Fargate.

EBS is a persistent block storage volume for use with EC2 instances, automatically replicated within an Availability Zone, and in principle attached to and used by a single instance. EFS is a file system for Linux workloads that grows and shrinks automatically and supports parallel shared access from thousands of EC2 instances. Sharing is a capability of EFS; it is not the case that both are for sharing, or that both are exclusively for a single connection.

S3 is Amazon Simple Storage Service, object storage with excellent scalability and availability that can store and protect any amount of data. Block storage is EBS, a shared file system for Linux is EFS, and an in-memory cache is ElastiCache. The distinction among these three ways of holding data — object, block, and file — is the starting point for choosing AWS storage.

EFS is file storage whose capacity automatically grows and shrinks with the number of files and which supports parallel shared access from thousands of EC2 instances, so it fits the use case of mounting the same directory from many instances at once. EBS is block storage within an Availability Zone that is in principle attached to a single instance, giving each instance its own separate area. Glacier Deep Archive is an archival class designed for slow retrieval, and ElastiCache is an in-memory cache rather than a file system.

EBS is persistent block storage for EC2 instances, automatically replicated within an Availability Zone, providing consistent, low-latency performance. Because of this single-AZ property, a separate mechanism is needed if availability across AZs is required. Replicating across Regions or delivering from edge locations is not EBS's role.

S3 Glacier is a group of archival storage classes: S3 Glacier Instant Retrieval for data that needs immediate retrieval, S3 Glacier Flexible Retrieval for long-term data accessed rarely, and S3 Glacier Deep Archive, which retrieves at the lowest cost over a period of hours. The design lets you choose a class based on the tradeoff between retrieval speed and cost, so retrieval time is not uniform. There is no restriction on the kind of data that can be stored, and it is not used by attaching it as block storage.

S3 is object storage, EBS is block storage attached to EC2, and EFS is file storage for Linux workloads. It helps to think of objects as things moved in and out wholesale via an API, blocks as things that appear to the OS as a disk, and files as things that can be mounted and shared from multiple hosts — this framing makes it easier to choose confidently based on requirements.

EBS is persistent block storage for use with EC2 instances that provides consistent, low-latency performance, making it well suited for use as an OS or database disk. S3 is object storage and does not attach a bucket as a block device. Glacier is an archival class designed for slow retrieval, and CloudFront is a CDN for speeding up delivery.

S3 is object storage that can store and protect any amount of data, with excellent scalability, availability, security, and performance, and AWS officially lists use cases such as web, mobile, backup, archive, IoT, and big data analytics. Appearing to the OS as a disk is a property of EBS, being restricted in principle to a single instance connection is also a property of EBS, and holding data in memory is a property of ElastiCache.

EFS is a simple, scalable, elastic file system whose capacity automatically grows and shrinks as files are added and removed, eliminating the need for advance capacity planning. Fixing a decided capacity in advance, or rebuilding to expand it, reflects a block-storage way of thinking, and the connected instance's memory size does not determine capacity either. This elasticity is what makes it easy to use as a shared working area.

S3 Glacier Deep Archive stores rarely accessed data at the lowest cost, with retrieval taking a period of hours, so it fits this condition. EBS and EFS are designed to preserve retrieval speed and tend to be expensive as a place for long-dormant data. ElastiCache is an in-memory cache and is not a mechanism for long-term storage in the first place. Deciding in advance how long a retrieval wait is acceptable is the guiding logic for choosing a storage class.

RDS is a managed service that makes it easy to set up, operate, and scale a relational database in the cloud, automating management tasks such as hardware provisioning, database setup, patching, and backups. Designing tables and columns, deciding on indexes, building the application, and validating the correctness of the data content all remain the customer's job. Managed means the operational burden is handed off, not that design is handed off too.

Aurora is part of Amazon RDS, the managed database service, and uses the same management console, CLI, and API operations for provisioning, patching, backup, recovery, and failure detection. The difference is the unit of management: standard RDS manages individual DB instances, whereas Aurora manages an entire cluster of DB servers kept in sync through replication. Aurora is a MySQL- and PostgreSQL-compatible relational database, not a key-value database.

DynamoDB is a key-value and document NoSQL database, a fully managed, multi-Region database delivering single-digit-millisecond performance at any scale. A data warehouse is Redshift, a relational database compatible with MySQL and PostgreSQL is Aurora, and reading and writing in memory is ElastiCache.

Redshift is a fully managed, petabyte-scale data warehouse service in the cloud that delivers fast query performance from existing SQL-based tools or BI applications regardless of dataset size. ElastiCache is an in-memory cache, EFS is a shared file system, and SQS is a message queue — none of these is a platform for aggregating and analyzing large volumes of data.

ElastiCache is a service that makes it easy to deploy, operate, and scale an in-memory cache in the cloud, improving web application performance by retrieving information from a fast in-memory cache instead of relying on a disk-based database. Speeding up analytical queries is Redshift's job, reducing long-term storage cost is a job for S3 Glacier classes, and sharing a directory is EFS's job.

Aurora is a fully managed, MySQL- and PostgreSQL-compatible relational database engine with a high-performance, distributed, shared storage subsystem, and its storage expands automatically as needed. There is no need to decide capacity up front and manually expand it. Storing data as key-value pairs is DynamoDB, and keeping storage cheap in exchange for retrieval taking time is an archival S3 Glacier class.

Redshift is a fully managed, petabyte-scale data warehouse service well suited to aggregating and analyzing large volumes of data from SQL-based tools or BI applications. RDS is a service that makes it easy to set up, operate, and scale a relational database, well suited to a business system reading and writing day-to-day transactions. Both are queried with SQL, which can make them look similar, but neither is NoSQL, and the difference is not merely one of data volume.

DynamoDB is a key-value and document NoSQL database that is officially described as delivering single-digit-millisecond performance at any scale. Redshift is a data warehouse well suited to aggregating and analyzing large volumes of data, RDS is a service for reading and writing under the relational model, and EFS is storage for sharing files — none of these is primarily aimed at this requirement.

RDS is Amazon Relational Database Service, a managed service that makes it easy to set up, operate, and scale a relational database in the cloud. Storing data as key-value pairs is DynamoDB, an in-memory cache is ElastiCache, and aggregating large volumes of data is the job of the data warehouse Redshift. Note that Aurora is an engine offered as part of RDS.

Aurora is offered as part of RDS, and provisioning, patching, backup, recovery, and failure detection can all be performed using the same management console, CLI, and API operations. There is no need to stand up a separate management instance, nor does the customer need to build these procedures themselves. The difference from standard RDS, which manages individual DB instances, is that Aurora treats the entire cluster as the unit of management.

SQS is a point-to-point service that holds messages in a queue, typically pulled out by a single consumer polling it. SNS is a pub/sub service where publishers send messages to a topic that are pushed simultaneously to multiple subscribers. Swapping the two is a classic mix-up, and it is not the case that both deliver in the same way. It helps to remember the direction: a queue is a place a receiver goes to fetch from, and a topic is a sender that pushes out.

SQS has standard queues and FIFO queues. Standard queues provide at-least-once delivery, so the same message can arrive more than once. FIFO queues provide exactly-once processing and order preservation, so the order sent is preserved and each message is processed exactly once. For workflows where order and avoiding loss matter, a FIFO queue is the choice.

SNS pushes a message sent to a topic simultaneously to multiple subscribers, and an SQS queue can be specified as a subscriber. This shape, from one SNS topic to multiple SQS queues, is the fan-out pattern officially presented as the standard approach. A queue is a receiving end, not a delivery source, so the direction never runs from queue to topic.

SNS subscriber types are organized into two groups: A2A, meaning app-to-app destinations such as SQS, Lambda, HTTP(S), and Data Firehose; and A2P, meaning app-to-person destinations such as email, mobile push, and SMS. It is not limited to either one, nor is it a mechanism limited to EC2 instances as destinations. This breadth is why SNS is used both for notifying people and for connecting applications.

Step Functions is a service that lets you create workflows, i.e., state machines, enabling the building of distributed applications, process automation, microservices orchestration, and data or machine learning pipelines. Each step is called a state, and a running instance is called an execution. Distributing traffic is Elastic Load Balancing's job, storing objects is S3's job, and caching key-value pairs is ElastiCache's domain.

API Gateway is a service for creating, publishing, maintaining, monitoring, and securing REST, HTTP, and WebSocket APIs at any scale, functioning as the front door for access to backends such as workloads on EC2, Lambda, or any web application. Running the processing itself is the backend's job, applying protection rules centrally across accounts is AWS Firewall Manager's job, and caching at the edge is CloudFront's role.

EventBridge is a serverless service that connects application components together using events, handling event ingestion, filtering, transformation, and delivery. An event bus is a router that routes events from many sources to many targets. A queue is described by SQS, a state machine by Step Functions, and a front door by API Gateway.

EventBridge Scheduler is a mechanism for managing recurring and one-time invocations using cron expressions or rate expressions, so scheduled invocation at fixed times is handled here. SQS is a queue that holds messages for a receiver to pull out, SNS is pub/sub delivery to subscribers, and API Gateway is a service for publishing and relaying APIs — none of these is aimed at time-based invocation.

SQS is a secure, durable, highly available, hosted queue service that lets you integrate and decouple distributed software systems and components. The acceptance side can respond as soon as it has placed a message into the queue, and the downstream process can pull it out and proceed at its own pace, so a delay on one side does not readily stop the other. In a direct-call or single-program configuration, a delay in the downstream process becomes waiting time for the acceptance side.

SNS pushes a message sent to a topic simultaneously to multiple subscribers, and an SQS queue can be specified as a subscriber, so delivering one event to three processes calls for the fan-out pattern of an SNS topic with multiple SQS queues. If three processes share one queue, typically once any one of them pulls an item out, the others cannot receive it. Having the source send three times, or having the receiving process forward it on, means the sender has to be modified every time a destination is added, which is not loose coupling.