Unit 5: AWS Compute Services - Subjective Questions

Cloud compute services provide processing capacity for running applications, executing code, hosting operating systems, and processing workloads without requiring customers to maintain physical servers.

Major AWS compute categories include:

• Virtual machines: Amazon EC2 provides resizable virtual servers with control over the operating system, storage, networking, and software.
• Serverless computing: AWS Lambda runs event-driven code without requiring users to provision or manage servers.
• Managed application platforms: AWS Elastic Beanstalk deploys and manages web applications while automatically handling infrastructure-related tasks.
• Batch computing: AWS Batch provisions compute resources and schedules batch jobs according to their requirements.
• Container services: Amazon ECS and Amazon EKS orchestrate containerized applications, while AWS Fargate provides serverless compute for containers.
• Simplified virtual servers: Amazon Lightsail provides bundled compute, storage, and networking for comparatively simple applications.

The appropriate service depends on the required level of control, operational responsibility, scalability, portability, and cost model.

Amazon Elastic Compute Cloud (EC2) is an AWS service that provides resizable virtual machines called instances. Users can select the operating system, processor, memory, storage, networking capacity, and purchasing model.

The main lifecycle stages are:

1. Pending: AWS prepares the instance after a launch request.
2. Running: The instance is active and can execute applications. Compute charges normally apply in this state.
3. Stopping: The operating system is shutting down and the instance is moving to the stopped state.
4. Stopped: The virtual machine is not running. Instance usage charges stop, but charges for resources such as EBS volumes and Elastic IP addresses may continue.
5. Rebooting: The operating system restarts while the instance normally remains on the same physical host.
6. Shutting-down: AWS is preparing to terminate the instance.
7. Terminated: The instance is permanently deleted and cannot be restarted. Attached EBS volumes configured with delete-on-termination may also be removed.

An instance can generally be started again after being stopped, but it cannot be recovered after termination.

The main EC2 launch components perform the following roles:

• Amazon Machine Image (AMI): A template containing an operating system and, optionally, application software and configuration. It determines the initial software environment of the instance.
• Instance type: Defines the combination of virtual CPUs, memory, networking performance, and supported storage features allocated to the instance.
• Key pair: Provides public-key credentials commonly used to authenticate administrative access to Linux instances. Windows instances can use the key pair to decrypt the initial administrator password.
• Security group: A stateful virtual firewall that controls permitted inbound and outbound traffic at the instance or network-interface level.
• IAM role: Supplies temporary AWS credentials to applications on the instance, avoiding the need to store long-term access keys in files.
• User data: A startup script or cloud-init configuration used to automate initial tasks such as installing packages, creating files, or starting services.

Together, these components define the instance's software, capacity, access controls, AWS permissions, and initial configuration.

A secure EC2 web server can be launched using the following procedure:

1. Select an AMI: Choose a trusted and supported Linux or Windows AMI.
2. Select an instance type: Match CPU, memory, and network capacity to the expected workload.
3. Configure networking: Place the instance in the correct VPC and subnet. A public-facing server normally uses a public subnet and an internet gateway.
4. Configure storage: Create encrypted EBS volumes of suitable size and type.
5. Attach an IAM role: Grant only the AWS permissions required by the application.
6. Create a security group: Permit HTTP or HTTPS from intended clients. Restrict SSH or RDP to trusted administrative addresses rather than allowing the entire internet.
7. Provide user data: Automate web-server installation, patching, and application startup.
8. Launch and test: Connect using approved administrative methods and verify application availability.
9. Harden the server: Apply updates, disable unnecessary services, enforce HTTPS, and avoid storing secrets directly on the instance.
10. Enable operations controls: Configure CloudWatch monitoring, logging, backups, alarms, and Systems Manager where appropriate.

For production systems, multiple instances should be distributed across Availability Zones behind a load balancer.

EC2 instance families are designed for different workload characteristics:

• General purpose: Provide a balanced ratio of CPU, memory, and networking. They are suitable for web servers, development environments, small databases, and business applications.
• Compute optimized: Provide high processor performance relative to memory. Typical uses include scientific modeling, media encoding, gaming servers, and high-performance web servers.
• Memory optimized: Provide large amounts of RAM for workloads such as in-memory databases, caching systems, and real-time analytics.
• Storage optimized: Provide high local storage throughput or high input/output operations per second. They are suitable for distributed file systems, data warehousing, and high-frequency transactional workloads.
• Accelerated computing: Include hardware accelerators such as GPUs or custom accelerators. They support machine learning, graphics rendering, video processing, and specialized numerical computation.

Instance selection should be based on measurements of CPU utilization, memory use, storage I/O, network traffic, and application latency rather than on instance size alone.

Amazon EBS and instance store differ in persistence, management, and typical use:

EBS should be used when data must survive instance replacement or stopping. Instance store is appropriate only when the application can recreate the data or maintains durable copies elsewhere.

These features address different EC2 networking and security requirements:

• Security groups: Stateful virtual firewalls that specify allowed inbound and outbound traffic. Return traffic for an allowed connection is automatically permitted.
• Elastic Network Interfaces (ENIs): Virtual network cards containing private IP addresses, security-group associations, and other network attributes. Additional ENIs can support management networks, traffic separation, or failover designs.
• Elastic IP addresses: Static public IPv4 addresses that can be remapped between supported resources. They are useful when a stable public address is required, but unnecessary or idle addresses may incur charges.
• IAM roles: Grant temporary AWS credentials to applications running on EC2. They control access to AWS APIs rather than ordinary IP network traffic.

A secure design uses least-privilege security-group rules, private subnets where possible, controlled public exposure, and IAM roles instead of embedded access keys. Network controls and IAM permissions complement one another but solve different security problems.

A highly available EC2 application commonly uses the following design:

• An Application Load Balancer or another suitable Elastic Load Balancing type receives client requests.
• A target group contains EC2 instances distributed across at least two Availability Zones.
• An Auto Scaling group maintains the required minimum, desired, and maximum numbers of instances.
• A launch template defines the AMI, instance type, security groups, IAM role, and startup configuration.
• The load balancer performs health checks and sends traffic only to healthy registered targets.
• Auto Scaling replaces unhealthy instances and adds or removes instances according to policies.
• Target tracking, step scaling, scheduled scaling, or predictive scaling can be used depending on demand patterns.

This combination improves:

• Availability: Failure of one instance or Availability Zone does not necessarily interrupt the entire application.
• Elasticity: Capacity changes with demand.
• Fault recovery: Unhealthy instances are replaced automatically.
• Cost efficiency: Excess capacity can be removed during periods of low demand.

The application should avoid storing critical session state on individual instances so that requests can be served by any healthy target.

The major purchasing options are:

• On-Demand Instances: Provide capacity without a long-term usage commitment. They are appropriate for short-term, irregular, or unpredictable workloads.
• Savings Plans: Offer discounted compute usage in exchange for a commitment to a consistent hourly spend for a one-year or three-year term. Flexibility depends on the plan type.
• Reserved Instances: Provide billing discounts for eligible EC2 usage when the customer commits to a term. Standard Reserved Instances generally offer larger discounts but less flexibility than Convertible Reserved Instances.
• Spot Instances: Use spare EC2 capacity at substantial discounts, but AWS can interrupt the instances when the capacity is needed elsewhere. They suit fault-tolerant and flexible workloads.
• Dedicated Instances: Run in a VPC on hardware dedicated to one customer, although the customer has less host-level control than with Dedicated Hosts.
• Dedicated Hosts: Allocate an entire physical server and provide visibility or control useful for certain licensing and compliance requirements.

A common cost strategy combines On-Demand capacity for flexibility, commitment-based discounts for predictable baseline usage, and Spot capacity for interruptible workloads.

The estimated cost has three components.

1. EC2 compute cost

2. EBS storage cost

Each of the three instances uses 100 GB:

3. Data-transfer cost

4. Total estimated monthly cost

Therefore, the estimated monthly cost is $279.24. In an actual AWS bill, the result may differ because prices vary by Region, operating system, transfer direction, volume type, and applicable discounts.

A comprehensive EC2 cost-optimization strategy should include:

1. Measure utilization: Use Amazon CloudWatch, AWS Cost Explorer, cost-allocation tags, and AWS Compute Optimizer to identify usage patterns and underutilized resources.
2. Right-size instances: Move workloads to instance families and sizes that match their CPU, memory, storage, and network requirements.
3. Remove waste: Terminate unused instances, delete unnecessary snapshots and volumes, and release unused public IPv4 or Elastic IP resources where applicable.
4. Schedule non-production systems: Stop development, testing, and training instances outside business hours.
5. Use Auto Scaling: Match capacity to changing demand instead of operating permanently for peak load.
6. Adopt suitable pricing models: Cover stable baseline usage with Savings Plans or Reserved Instances, use Spot Instances for fault-tolerant jobs, and retain On-Demand capacity for uncertain usage.
7. Modernize instance types: Evaluate newer-generation and appropriate processor-based instances when application compatibility permits.
8. Optimize storage: Select suitable EBS volume types, capacities, and performance levels; apply snapshot retention policies.
9. Control data transfer: Keep communicating services in cost-efficient architectures and use caching or content delivery where beneficial.
10. Establish governance: Set budgets, anomaly alerts, tagging standards, and periodic architecture reviews.

Optimization should preserve performance, resilience, security, and business requirements rather than merely selecting the lowest-cost resource.

Both options reduce cost in return for a usage commitment, but their structures differ:

• Reserved Instances: Primarily provide a billing discount for eligible EC2 usage. The discount and flexibility depend on attributes such as the Reserved Instance class, Region or Availability Zone scope, platform, and tenancy. Some zonal reservations can also provide a capacity-reservation benefit.
• Savings Plans: Apply discounted rates in exchange for committing to a specified amount of compute spend per hour for one or three years.
• Compute Savings Plans: Provide broader flexibility across eligible compute usage, including changes in instance family, size, Region, operating system, tenancy, and eligible services such as Lambda and Fargate.
• EC2 Instance Savings Plans: Are less flexible because they are associated with an instance family in a Region, but they can provide stronger discounts than the more flexible plan type.

An organization may choose Reserved Instances when its EC2 configuration is stable or when a zonal capacity benefit is relevant. It may choose Savings Plans when workloads may move among instance sizes, operating systems, Regions, or eligible compute services. In either case, commitment levels should be based on a conservative, predictable baseline.

Spot Instances allow customers to use spare EC2 capacity at discounted rates. The main trade-off is that AWS may interrupt a Spot Instance when the capacity is required elsewhere or when related capacity conditions change.

Suitable workloads include:

• Batch processing
• Data analysis
• Rendering
• Continuous integration tasks
• Stateless web tiers
• Distributed and parallel jobs
• Machine-learning training that supports checkpoints

Spot capacity is generally unsuitable as the sole capacity for an application that cannot tolerate interruption.

A Spot-tolerant design should:

• Store durable data outside the instance, such as in Amazon S3 or EBS.
• Save checkpoints so work can resume rather than restart.
• Monitor interruption notices and shut down gracefully when possible.
• Use Auto Scaling groups or EC2 Fleet to diversify across instance types and Availability Zones.
• Keep a baseline of On-Demand or commitment-covered capacity when continuous service is required.
• Design tasks to be idempotent so they can be safely retried.
• Use queues to separate job submission from job processing.

These techniques reduce the effect of interruptions while retaining Spot pricing benefits.

These services offer different levels of abstraction:

EC2 gives the greatest infrastructure control but also creates more operational work. Lambda provides the highest abstraction for event-driven code. Elastic Beanstalk and AWS Batch manage application deployment or job scheduling, while Lightsail emphasizes simplicity and predictable bundles.

AWS Lambda is a serverless compute service that runs code in response to events or direct invocations.

Execution model:

• Developers upload code as a deployment package or container image and select a supported runtime or custom runtime.
• A function is invoked by sources such as API Gateway, Amazon S3, EventBridge, DynamoDB Streams, or an SDK call.
• AWS creates isolated execution environments, runs the handler, and automatically scales the number of concurrent executions.
• Billing is based primarily on requests and execution duration, subject to the applicable pricing model.

Benefits:

• No server provisioning or guest-OS management
• Automatic scaling
• Integration with many AWS services
• Pay-for-use pricing
• Built-in logging and monitoring integration
• Support for event-driven and loosely coupled architectures

Limitations and considerations:

• Maximum execution duration and other service quotas
• Stateless execution model, requiring durable state to be stored externally
• Possible cold-start latency
• Runtime, package, memory, temporary storage, and concurrency constraints
• Less operating-system control than EC2

Lambda is most appropriate for event-driven, stateless, short-duration tasks rather than applications requiring permanent processes or full host control.

AWS Elastic Beanstalk is a managed application platform that simplifies deployment while exposing the underlying AWS resources for customization.

A typical workflow is:

1. The developer creates an application and selects a supported platform, such as Java, .NET, Node.js, Python, PHP, Ruby, Go, or a container platform.
2. The developer uploads an application version.
3. Elastic Beanstalk creates an environment and provisions the required infrastructure.
4. The service deploys the code and reports environment health.
5. New application versions can be deployed using configurable deployment policies.

Depending on the environment type and configuration, it can manage:

• EC2 instances and launch configurations or templates
• Auto Scaling
• Elastic Load Balancing
• Security groups
• Application deployment
• Environment variables and platform configuration
• Health monitoring and CloudWatch integration
• Rolling, immutable, or traffic-shifting deployment approaches where supported

The customer remains responsible for application code, data, access configuration, and appropriate platform settings. Elastic Beanstalk itself does not add a separate service charge, but the provisioned AWS resources are billed normally.

AWS Batch is a managed service for running batch workloads without manually operating a dedicated batch scheduler or fixed compute cluster.

Its major components are:

• Job definition: Describes how a job should run, including its container image, commands, resource requirements, environment variables, IAM roles, and retry or timeout settings.
• Job: A unit of work submitted to AWS Batch. Jobs may have dependencies and can be arranged into arrays for parallel processing.
• Job queue: Holds submitted jobs until they can be scheduled. Queue priority helps determine which work is considered first.
• Compute environment: Defines the compute resources on which jobs run. It may use managed or unmanaged resources and can use supported EC2, Spot, or Fargate capacity.
• Scheduler: Evaluates queued jobs, their priorities, dependencies, resource requirements, and available compute capacity before placing them.

AWS Batch is suitable for rendering, simulation, financial analysis, genomics, and data transformation. It can scale resources according to queued work and reduce costs by using Spot capacity for retryable jobs.

Containerization packages an application with its libraries and dependencies into a portable image. Containers share the host operating-system kernel, making them generally lighter and faster to start than separate virtual machines.

Major Amazon ECS components include:

• Cluster: A logical grouping in which containerized workloads run.
• Task definition: A versioned blueprint specifying container images, CPU, memory, ports, environment settings, storage, logging, and IAM roles.
• Task: A running instance of a task definition.
• Service: Maintains a desired number of tasks and can integrate with load balancing and automatic scaling.
• Container instance: An EC2 instance registered with an ECS cluster when the EC2 launch type or capacity provider is used.
• Fargate capacity: Serverless container compute that runs tasks without customer-managed worker instances.
• Capacity provider: Defines how ECS obtains and scales the infrastructure used to run tasks.

ECS handles task placement, service scheduling, health replacement, and integration with AWS networking, IAM, monitoring, and load-balancing services.

Amazon ECS and Amazon EKS both orchestrate containers, but they use different control models.

Choose ECS when the organization wants a relatively simple, AWS-native orchestrator with deep AWS integration. Choose EKS when Kubernetes compatibility, ecosystem tools, existing Kubernetes expertise, or workload portability is a major requirement.

Neither option completely removes application-level operational duties. Teams must still manage container images, security, observability, scaling policies, and deployment practices.

A managed container architecture can be designed as follows:

1. Build the image: Application code is packaged into a container image through a controlled build pipeline.
2. Store the image: The image is scanned and pushed to a private Amazon Elastic Container Registry (ECR) repository. Lifecycle policies remove obsolete images.
3. Define the workload:
   • In ECS, create a task definition and service.
   • In EKS, create Kubernetes pod and deployment specifications.
4. Select Fargate compute: Fargate supplies the required container compute, so the organization does not manage EC2 worker instances.
5. Configure networking: Run tasks or pods in private subnets across multiple Availability Zones. Assign security groups and restrict network access according to least privilege.
6. Attach an Application Load Balancer: Place the load balancer in suitable subnets, terminate HTTPS with an approved certificate, and route requests to healthy container targets.
7. Configure identity: Use an execution role for image retrieval and logging, and a separate task or pod role for the application's AWS permissions.
8. Add scaling: Scale the ECS service or Kubernetes deployment using CPU, memory, request count, or other workload metrics.
9. Enable observability: Send logs and metrics to CloudWatch and configure health checks, dashboards, alarms, and tracing where required.
10. Automate deployment: A CI/CD pipeline builds, tests, scans, publishes, and gradually deploys new image versions with rollback support.

This design reduces server-management effort, improves availability through multi-AZ placement, and supports repeatable deployments. Its trade-offs include Fargate pricing, platform constraints, image-startup time, and the need to manage container security and application state correctly.