Unit 5: AWS Compute Services

I. Orientation — Compute as Elastic, On-Demand Capacity

Cloud computing replaces the purchase of fixed physical servers with programmable access to processing capacity. In AWS, compute resources can be virtual machines, containers, serverless functions, managed application platforms, or batch workers, usually deployed within an AWS Region and scaled according to demand.

• On-demand provisioning: Resources are created through the AWS Management Console, AWS CLI, SDKs, APIs, or infrastructure-as-code tools such as AWS CloudFormation.
• Elasticity: Capacity can increase or decrease with workload demand; EC2 Auto Scaling, for example, adjusts the number of instances in an Auto Scaling group.
• Measured usage: Charges are based on dimensions such as runtime, instance type, request count, memory allocation, or consumed vCPU capacity.
• Shared responsibility: AWS secures the underlying cloud infrastructure, while customers retain responsibilities determined by the service model.
  • With EC2, the customer manages the guest operating system and applications.
  • With AWS Lambda, AWS also manages servers, operating systems, and runtime infrastructure.
• Regional design: Compute services operate in Regions and Availability Zones; a highly available application commonly distributes instances across at least two Availability Zones.
• Automation: APIs, monitoring, scaling policies, and deployment pipelines allow capacity to respond without manual server installation.
• Service-selection principle: Greater infrastructure control generally creates greater management responsibility; more highly managed services reduce administration but impose additional platform constraints.

II. AWS Compute Portfolio — Matching Capacity to Workloads

A. Overview of compute services

AWS provides several compute models, distinguished primarily by the unit deployed and the amount of infrastructure managed by AWS.

• Virtual machines: Amazon EC2 supplies resizable virtual servers called instances.
  • Appropriate for custom operating systems, legacy software, persistent servers, and workloads requiring network or storage control.
  • The customer selects an Amazon Machine Image, instance type, storage, networking, and security configuration.
• Serverless functions: AWS Lambda runs event-driven code without requiring users to provision servers.
  • Typical events include an Amazon S3 object upload, an API Gateway request, or a message arriving in an Amazon SQS queue.
  • Billing reflects requests and execution resources rather than an always-running server.
• Containers: Amazon ECS and Amazon EKS orchestrate containerized applications, while AWS Fargate supplies serverless container capacity.
• Managed platforms: AWS Elastic Beanstalk deploys applications while handling activities such as capacity provisioning, load balancing, and health monitoring.
• Batch processing: AWS Batch schedules jobs, creates suitable compute environments, and integrates with EC2 or Fargate capacity.
• Simplified cloud servers: Amazon Lightsail bundles compute, storage, networking, and predictable allowances for smaller applications.
• Selection criteria: A workload should be matched to its technical and operational requirements.
  • Control: EC2 offers operating-system access; Lambda does not.
  • Execution pattern: Continuous services suit EC2 or containers, while short event-driven tasks often suit Lambda.
  • Portability: Container images provide a standardized deployment artifact.
  • Operations: Managed services reduce patching, scheduling, and capacity-planning work.

B. Core Design Considerations

Compute architecture must account for availability, performance, security, and scalability rather than treating server selection as an isolated decision.

• Availability: Deploying identical application capacity across multiple Availability Zones avoids dependence on one data-center location.
• Scalability: Horizontal scaling adds instances or tasks; vertical scaling moves to a larger instance type.
• Security: IAM roles provide temporary credentials to compute resources, while security groups act as stateful virtual firewalls.
• Observability: Amazon CloudWatch collects metrics such as EC2 CPUUtilization and supports alarms and automated responses.
• Statelessness: Storing sessions and durable data outside individual compute nodes makes replacement and scaling safer.
• Decoupling: Services such as SQS separate producers from consumers, allowing worker capacity to scale independently.

III. Amazon EC2 — Configurable Virtual Servers

A. Amazon EC2

Amazon Elastic Compute Cloud provides virtual machines whose processor, memory, storage, networking, operating system, and lifecycle remain substantially customer-configurable.

• Amazon Machine Image: An AMI is the launch template containing operating-system and related configuration information.
  • AWS, software vendors, and customers can provide AMIs.
  • AMIs are Region-specific, although they can be copied between Regions.
• Instance type: The type determines a hardware profile identified by a family and size, such as a general-purpose, compute-optimized, memory-optimized, storage-optimized, or accelerated-computing instance.
• Instance lifecycle: Important states include pending, running, stopping, stopped, shutting-down, and terminated.
  • Stopping normally preserves attached EBS volumes but ends instance-compute billing.
  • Termination permanently removes the instance and may delete volumes configured for deletion.
• Storage: Amazon EBS provides persistent block volumes; instance store provides temporary storage physically attached to the host.
• Networking: An instance launches into a VPC subnet and receives private addressing; public or Elastic IP addressing is optional.
• Access control: Security groups filter inbound and outbound traffic, while an EC2 instance profile supplies an IAM role to applications.
• User data: A startup script can install packages or configure an instance at first launch.

#!/bin/bash
dnf install -y httpd
systemctl enable --now httpd

• Meaning: The script installs the Apache HTTP server and enables it immediately on a compatible RPM-based Linux AMI.

B. Scaling, Placement, and Resilience

EC2 becomes elastic when instances are treated as replaceable members of an automated fleet rather than individually maintained servers.

• Launch template: Defines repeatable settings such as AMI, instance type, security groups, storage, and user data.
• Auto Scaling group: Maintains desired capacity between configured minimum and maximum values.
  • A target-tracking policy can add capacity when average CPU usage rises above a target.
  • Health checks replace failed or unhealthy instances.
• Load balancing: Elastic Load Balancing distributes requests across healthy targets; an Application Load Balancer operates at HTTP/HTTPS level.
• Placement strategies: Cluster placement favors low-latency proximity, spread placement separates critical instances, and partition placement isolates groups on distinct hardware partitions.
• Recovery design: Data should reside in durable services such as EBS, S3, or managed databases instead of depending solely on one instance.
• Operational limitation: Customers must patch the guest OS, manage installed software, monitor capacity, and protect credentials and data.

IV. EC2 Economics — Paying for the Required Capacity

A. EC2 pricing and cost optimization

EC2 cost optimization aligns pricing commitments and instance capacity with measurable workload behavior while preserving required performance and availability.

• On-Demand Instances: Provide capacity without a long-term commitment and suit new, irregular, or short-lived workloads.
• Savings Plans: Offer lower eligible compute prices in exchange for committing to a consistent amount of usage, measured in currency per hour, for a one-year or three-year term.
  • Compute Savings Plans provide broader flexibility across eligible compute usage.
  • EC2 Instance Savings Plans apply to a selected instance family within a Region.
• Reserved Instances: Provide EC2 billing discounts under one-year or three-year terms; they are billing constructs rather than separately reserved physical machines unless capacity reservation is involved.
• Spot Instances: Use spare EC2 capacity at reduced prices but can be interrupted when AWS needs the capacity.
  • Suitable workloads include fault-tolerant batch processing, distributed analysis, and queue-based workers.
• Dedicated options: Dedicated Instances and Dedicated Hosts provide single-customer hardware isolation; hosts also expose physical-server allocation for certain licensing needs.
• Cost equation: A simplified estimate separates compute, storage, and data-transfer costs.

Total cost = (instance rate × running time)
           + EBS storage cost
           + chargeable data transfer
           + additional service costs

• Definitions: instance rate is the applicable price per billing unit; running time is billable execution duration; other terms represent separately metered resources.
• Rightsizing: CloudWatch evidence can identify consistently underused CPU, memory, or network capacity and support movement to a smaller or different family.
• Scheduling: Non-production instances can be stopped outside working hours; stopped instances may still incur EBS and Elastic IP-related charges.
• Elastic matching: Auto Scaling avoids paying continuously for peak capacity by adding instances only when demand requires them.
• Storage optimization: Delete unattached EBS volumes and obsolete snapshots, and select EBS volume types according to required IOPS and throughput.
• Governance: Cost allocation tags, AWS Budgets, Cost Explorer, and Cost and Usage Reports help attribute and control spending.

B. Pricing Strategy and Risk

The lowest nominal rate is not always the lowest total cost because interruption, administration, and underused commitments carry economic consequences.

1. Stable workloads:

   • Commitment advantage: Savings Plans or Reserved Instances can reduce costs when baseline usage is predictable.
   • Risk: An oversized commitment remains payable even when demand falls.

2. Variable workloads:

   • Flexibility advantage: On-Demand capacity supports uncertain usage, while Spot capacity reduces costs for interruptible work.
   • Risk: Spot-dependent applications require checkpointing, retries, diversification, or graceful interruption handling.

• Capacity Reservations: Reserve EC2 capacity in a specific Availability Zone when launch certainty is essential; billing discounts must be evaluated separately.
• Optimization rule: Cover a reliable baseline with commitments, use On-Demand for uncertain demand, and use Spot for interruption-tolerant portions.

V. Managed Compute — Reducing Infrastructure Administration

A. Managed compute services

Managed compute services transfer server provisioning and selected operational tasks to AWS, allowing developers to focus more directly on applications and jobs.

• AWS Lambda: Executes functions in response to events and automatically scales concurrent executions.
  • Appropriate for API back ends, file processing, automation, and stream-event handling.
  • Functions remain subject to service limits, runtime constraints, and cold-start considerations.
• AWS Elastic Beanstalk: Accepts application packages and creates supporting resources such as EC2 instances, Auto Scaling groups, and load balancers.
  • Developers retain access to the underlying resources while the platform coordinates deployment and health management.
• AWS Batch: Queues and schedules batch jobs onto managed compute environments, avoiding manual construction of a job scheduler.
• Amazon Lightsail: Provides simplified virtual private servers and bundled resources for small websites, development systems, and straightforward applications.
• AWS App Runner: Builds and runs web applications from source code or container images while managing deployment, scaling, and service endpoints.
• Operational benefit: Automated provisioning, scaling, health checking, and platform maintenance reduce undifferentiated administrative work.
• Limitation: Managed platforms may restrict operating-system access, supported runtimes, networking choices, or specialized software configuration.

VI. Containers — Portable, Isolated Application Packaging

A. Container services

AWS container services separate application packaging from orchestration and compute capacity, enabling repeatable deployments across development and production environments.

• Container image: A read-only package containing application code, libraries, dependencies, and startup instructions.
• Amazon ECR: Stores, versions, scans, and distributes private or public container images.
• Amazon ECS: AWS-native orchestration that runs applications as tasks grouped into services.
  • A task definition specifies settings such as image, CPU, memory, ports, environment variables, and IAM roles.
• Amazon EKS: Provides a managed Kubernetes control plane for organizations using Kubernetes APIs and tooling.
• AWS Fargate: Supplies serverless compute for ECS tasks and EKS pods, removing the need to provision EC2 worker instances.
• EC2 launch capacity: Running containers on EC2 provides deeper host control and may suit specialized instance types, GPUs, or established capacity-management practices.
• Service behavior: Long-running services maintain a desired task count, while standalone tasks perform finite work.
• Load balancing and discovery: Container services can integrate with Elastic Load Balancing and service-discovery mechanisms for network routing.
• Security: Task or pod roles should grant only necessary AWS permissions; image scanning and immutable version tags strengthen software-supply-chain controls.

B. Selection and Limitations

Container architecture requires a choice between orchestration portability, operational complexity, and infrastructure control.

1. ECS versus EKS:

   • ECS: Offers simpler AWS-native integration and fewer orchestration components to administer.
   • EKS: Offers Kubernetes compatibility and ecosystem portability but requires Kubernetes operational knowledge.

2. Fargate versus EC2 capacity:

   • Fargate: Reduces host patching and capacity management; billing follows requested task or pod resources.
   • EC2: Provides host-level control and can improve utilization when many containers share a well-managed fleet.

• Container limitation: Containers share a host kernel and are not equivalent to separate full virtual machines.
• State management: Durable state should use services such as EBS, EFS, S3, or managed databases rather than an ephemeral container filesystem.
• Best fit: Containers are strongest for microservices, standardized deployment pipelines, independently scalable components, and applications requiring consistent runtime dependencies.