AWS Compute Services
Compute is the engine of every cloud architecture.
Many architects new to AWS treat compute as a server selection problem:
- “Which instance type should I choose?”
- “How much memory do I need?”
- “How many CPUs?”
Selecting a compute is about balancing responsibility, scalability, and operational overhead. Consider a background job that runs for two minutes every hour on a full-time EC2 instance. Technically, it works, but it consumes unnecessary resources and requires maintenance of an operating system that does almost nothing.
Experienced AWS architects ask different questions:
- “How much operational responsibility am I willing to carry?”
- “Do I even need a full-time server, or is there a better option?”
In AWS, you choose your compute model based on how much control you want versus how much management you want to offload to AWS. The further you move toward abstraction, the more AWS manages for you. The closer you stay to infrastructure, the more control and operational burden you retain.
Understanding this responsibility spectrum is essential for designing production systems and answering SAA-C03 exam questions correctly.
The compute responsibility spectrum
At a high level, AWS compute falls into three primary models:
| Model | You Manage | AWS Manages | Architectural Theme |
|---|---|---|---|
| Virtual Machines | OS, patching, scaling | Hardware | Maximum control |
| Containers | Application runtime | OS and orchestration | Portability and consistency |
| Serverless | Code only | Infrastructure and scaling | Minimal operations |
Each model is correct in specific contexts. None is universally superior. The architectural decision depends on workload behavior, scaling needs, compliance constraints, and operational tolerance.
Amazon EC2
Amazon EC2 represents the most traditional compute model in AWS, providing virtual machines where you control the operating system, instance type, networking configuration, storage, and security rules. In return, you assume responsibility for OS patching, security hardening, scaling logic, and capacity planning. This model offers maximum flexibility, making it ideal when you need custom OS configurations, run legacy applications, require specialized software, or must meet strict compliance controls.
However, this flexibility comes with operational cost. A single EC2 instance hosting a production application introduces multiple risks: if it fails, the application fails; if disk space fills, performance degrades; if traffic spikes, it cannot scale automatically. Architecturally mature designs therefore rarely rely on single-instance deployments.
Instead, EC2 is paired with Auto Scaling Groups, load balancers, multi-AZ deployment, and health checks, shifting the architectural goal from simply running a server to designing self-healing compute clusters.
Amazon ECS and Amazon EKS
Containers represent a middle ground between virtual machines and serverless compute. They package application code, dependencies, and runtime environment together, ensuring consistent behavior across development, testing, and production. AWS offers container orchestration through Amazon ECS and Amazon EKS, which manage deployment, scaling, and operations of containerized applications.
Architecturally, containers are ideal when multiple microservices must be deployed consistently, when teams require portability across environments, or when DevOps pipelines are container-based. Compared to EC2, containers reduce OS management overhead but introduce orchestration complexity around cluster scaling, task placement, networking, and monitoring. Compared to serverless, they offer more control over the runtime environment but require more operational responsibility.
Containers are ideal when applications run continuously with predictable traffic patterns, when you need more control than serverless allows, or when multiple tightly integrated services must be deployed together.
AWS Lambda
Serverless compute in AWS is primarily delivered by AWS Lambda, where you provide only code and AWS manages the underlying infrastructure, scaling, availability, patching, and failover. You pay only when your function executes, which fundamentally changes architectural thinking, instead of designing for capacity, you design around events.
Lambda is ideal when workloads are intermittent, traffic is unpredictable, processing is short-lived, systems are event-driven, or minimal operational overhead is required. For example, a background job that runs for two minutes every hour does not need a 24/7 server; a scheduled Lambda function triggered by EventBridge eliminates idle capacity entirely.
Serverless computing offers numerous benefits, making it an attractive choice for modern application development:
- Automatic scaling
- Built-in high availability
- Reduced operational burden
- Cost alignment with actual usage
Despite its benefits, serverless computing comes with certain limitations that need careful consideration:
- Execution time limits
- Stateless design requirement
- Cold start considerations
- Dependence on AWS-specific runtimes
Lambda architectures typically pair with other AWS services to form complete solutions. API Gateway provides HTTP endpoints to trigger functions, S3 events invoke functions when objects are created, DynamoDB streams enable real-time data processing, and SQS queues allow asynchronous message handling. Together, these integrations enable fully serverless application designs that scale automatically and incur cost only when work is being done.
Scaling strategies for compute services
One of the most important compute decisions in AWS architecture is how scaling is achieved. Vertical scaling increases the size of a single instance, while horizontal scaling adds more instances behind a load balancer.
AWS architecture favors horizontal scaling because it improves resilience, reduces single points of failure, and aligns with elasticity; a single powerful EC2 instance is far less reliable than multiple smaller instances distributed across Availability Zones.
Compute is often the largest contributor to AWS bills, making architectural cost efficiency essential. This means eliminating idle capacity, matching pricing models to workload patterns, and using interruptible capacity like Spot Instances when fault tolerance exists. For predictable workloads, commitment-based pricing offers efficiency; for flexible workloads, on-demand or serverless models reduce waste. Serverless inherently optimizes cost for burst workloads by charging only when code executes.
On the SAA-C03 exam, the requirement is often to lower the work needed to manage the system while still meeting its needs. If the system runs only now and then, is triggered by events, or doesn’t need to remember past interactions, then a serverless approach is usually the right architectural choice.
My name is Naeem ul Haq. I’ve been working with AWS since its early days and have deep expertise across its evolving ecosystem.
