Cloud Computing is the on-demand delivery of IT resources (compute, storage, databases, networking) over the internet with pay-as-you-go pricing, eliminating the need to own and maintain physical infrastructure.

Key characteristics (NIST):

• On-demand self-service – provision resources automatically without human interaction.
• Broad network access – available over the network via standard mechanisms.
• Resource pooling – multi-tenant model serving multiple consumers.
• Rapid elasticity – scale out/in quickly as demand changes.
• Measured service – metered usage for transparent billing.

Role of Virtualization:

• Virtualization uses a hypervisor to abstract physical hardware into multiple virtual machines (VMs).
• It enables resource pooling by letting many isolated VMs run on one physical server.
• It supports multi-tenancy, isolation, and elasticity, which are the economic basis of the cloud.
• Without virtualization, the efficient sharing and rapid provisioning that define cloud computing would not be possible.

In short, virtualization is the enabling layer that lets cloud providers deliver scalable, isolated, and cost-efficient services.

Cloud services are typically grouped into three delivery models based on the level of management responsibility.

1. IaaS (Infrastructure as a Service):

• Provides fundamental compute, storage, and networking resources.
• The user manages the OS, runtime, and applications; the provider manages the hardware.
• AWS Example: Amazon EC2, Amazon EBS, Amazon VPC.

2. PaaS (Platform as a Service):

• Provides a managed platform for building and deploying applications.
• The provider manages OS, runtime, and scaling; the user focuses on code.
• AWS Example: AWS Elastic Beanstalk, AWS Lambda.

3. SaaS (Software as a Service):

• Delivers ready-to-use software over the internet.
• The provider manages everything; the user only consumes the application.
• AWS Example: Amazon WorkMail, Amazon Chime.

Responsibility spectrum: As we move from IaaS → PaaS → SaaS, the user's management burden decreases while provider abstraction increases.

Cloud computing architecture refers to the components and subcomponents required for cloud delivery, broadly divided into front-end and back-end, connected via a network (the internet).

1. Front-End (Client Side):

• The interface the user interacts with.
• Includes client devices, browsers, and applications used to access cloud services.

2. Back-End (Provider Side):

• Compute: Servers and virtual machines that process workloads.
• Storage: Block, object, and file storage systems.
• Hypervisor/Virtualization layer: Enables resource pooling and isolation.
• Management software: Handles orchestration, provisioning, and monitoring.
• Security components: Authentication, encryption, and access control.

3. Network: The communication channel (internet/intranet) linking front-end and back-end.

Supporting concepts:

• Middleware enables communication between networked machines.
• Service orchestration automates workflows across resources.

This layered architecture provides scalability, availability, and manageability for delivering cloud services.

Cloud Optimization is the process of right-sizing and configuring cloud resources to achieve the best balance of cost, performance, and reliability while avoiding waste.

Key optimization strategies:

• Right-sizing: Match instance types/sizes to actual workload needs rather than over-provisioning.
• Elasticity & Auto Scaling: Automatically add/remove capacity based on demand so you pay only for what you use.
• Choosing the right pricing model: Use Reserved Instances or Savings Plans for steady workloads, Spot Instances for fault-tolerant batch jobs, On-Demand for unpredictable spikes.
• Storage tiering: Move infrequently accessed data to cheaper tiers (e.g., S3 Infrequent Access/Glacier).
• Monitoring & analytics: Use tools like Amazon CloudWatch and AWS Cost Explorer to identify idle/underused resources.
• Eliminating idle resources: Stop/terminate unused instances and release unattached volumes/IPs.

Pillars of optimization: cost efficiency, performance efficiency, and operational excellence—aligned with the AWS Well-Architected Framework.

AWS infrastructure is built on a hierarchy designed for high availability, fault tolerance, and low latency.

1. Regions:

• Geographically distinct locations around the world (e.g., us-east-1, ap-south-1).
• Each region is isolated from others for fault containment and data sovereignty.
• You choose a region based on latency, cost, and compliance requirements.

2. Availability Zones (AZs):

• Each region contains multiple AZs (usually 3 or more).
• Each AZ is one or more discrete data centers with independent power, cooling, and networking.
• AZs are interconnected with low-latency, high-bandwidth links.
• Deploying across multiple AZs provides high availability and fault tolerance.

3. Edge Locations / Points of Presence:

• Sites used by services like Amazon CloudFront and Route 53 to cache content closer to users.
• Reduce latency for content delivery and DNS resolution.

Benefit: This multi-tier design lets architects build resilient applications that survive data-center or even region-level failures.

Reliability in AWS refers to the ability of a system to recover from failures and meet demand consistently, achieved through redundancy across AZs and regions, automated scaling, and health monitoring.

Compliance refers to AWS meeting regulatory and industry standards such as ISO 27001, SOC 1/2/3, PCI-DSS, HIPAA, and GDPR. AWS provides audit reports via AWS Artifact.

Shared Responsibility Model:
Security and compliance are a shared duty between AWS and the customer.

• AWS – Security of the Cloud:

  • Physical data centers, hardware, networking.
  • The hypervisor and host infrastructure.
  • Managed service infrastructure.

• Customer – Security in the Cloud:

  • Guest OS patching and configuration.
  • Application security and data encryption.
  • IAM users, roles, and access policies.
  • Firewall (Security Group) configuration.

Note: The exact split shifts depending on the service type (IaaS gives the customer more responsibility than managed/SaaS services).

The AWS Command Line Interface (CLI) is a unified tool to manage AWS services from a terminal using commands and scripts, enabling automation without the web console.

Installation:

• Download and install the AWS CLI package for your OS (Windows/macOS/Linux).
• Verify with:
  bash
  aws --version

Configuration:
bash
aws configure

This prompts for:

• Access Key ID
• Secret Access Key
• Default region (e.g., us-east-1)
• Default output format (json, text, table)

Credentials are stored in ~/.aws/credentials and config in ~/.aws/config.

Command structure:
bash
aws <service> <operation> [parameters]

Examples:
bash

List all S3 buckets

aws s3 ls

Describe EC2 instances

aws ec2 describe-instances

Launch an instance

aws ec2 run-instances --image-id ami-12345 --instance-type t2.micro --count 1

Benefits: automation, scripting, repeatability, and integration with CI/CD pipelines.

Amazon EC2 (Elastic Compute Cloud) is a core AWS IaaS offering that provides resizable virtual servers (instances) in the cloud on demand.

Problems it solves:

• Eliminates upfront investment in physical hardware.
• Removes the delay of procuring and provisioning servers.
• Enables scaling capacity up or down within minutes.

Main features:

• Instance types: Families optimized for compute, memory, storage, or GPU workloads.
• AMIs (Amazon Machine Images): Templates containing OS and software to launch instances.
• Elasticity: Launch or terminate instances based on demand.
• Pricing flexibility: On-Demand, Reserved, Spot, and Savings Plans.
• Security: Key pairs, Security Groups, and IAM roles.
• Storage options: EBS (persistent) and Instance Store (ephemeral).
• Integration: Works with Auto Scaling, Elastic Load Balancing, and VPC.

Summary: EC2 provides secure, scalable, and cost-effective compute capacity, forming the backbone of many AWS architectures.

EC2 allows you to control how an instance behaves at launch and at runtime using User Data and Instance Metadata.

1. User Data:

• Scripts or cloud-init directives passed to the instance at launch.
• Runs automatically on the first boot (by default) with root privileges.
• Used to automate configuration such as installing packages or starting services.
• Example (bash user data):
  bash

  !/bin/bash

  yum update -y
  yum install -y httpd
  systemctl start httpd
  systemctl enable httpd

2. Instance Metadata:

• Data about the running instance accessible from within the instance via a link-local endpoint:
  bash
  curl http://169.254.169.254/latest/meta-data/

• Provides details like instance ID, AMI ID, IP addresses, and IAM role credentials.

• IMDSv2 adds token-based security to protect against SSRF attacks.

Shutdown behavior:

• You can configure whether an instance stops or terminates on OS shutdown.

Use: Together these enable automated, self-configuring, and dynamically aware instances.

Placement Groups control how EC2 instances are physically placed on underlying hardware to meet specific performance or resilience requirements.

Three types:

1. Cluster Placement Group:

• Packs instances close together within a single AZ.
• Provides low latency and high network throughput.
• Ideal for HPC and tightly coupled workloads.
• Risk: correlated failure if the rack fails.

2. Spread Placement Group:

• Places instances on distinct underlying hardware (racks).
• Minimizes correlated failures; max 7 instances per AZ.
• Ideal for small numbers of critical instances needing isolation.

3. Partition Placement Group:

• Divides instances into logical partitions, each on separate racks.
• Supports large distributed/replicated workloads (e.g., HDFS, Cassandra, Kafka).
• Failure in one partition does not affect others.

Comparison summary:

EC2 offers several pricing models to optimize cost based on workload patterns.

1. On-Demand:

• Pay by the second/hour with no commitment.
• Use when: workloads are short-term, unpredictable, or for testing/development.

2. Reserved Instances (RIs):

• 1 or 3-year commitment for a significant discount (up to ~72%).
• Use when: steady-state, predictable long-term workloads.

3. Savings Plans:

• Commit to a consistent amount of compute usage ($/hour) for 1 or 3 years.
• More flexible than RIs across instance families/regions.
• Use when: you want discounts with flexibility.

4. Spot Instances:

• Use spare AWS capacity at up to ~90% discount; can be interrupted with 2-minute notice.
• Use when: fault-tolerant, flexible, batch, or stateless workloads.

5. Dedicated Hosts/Instances:

• Physical server dedicated to you.
• Use when: licensing or compliance requires isolation.

Optimization tip: Combine models—RIs/Savings Plans for baseline load, On-Demand for spikes, and Spot for burst/batch work.

The EC2 Instance Lifecycle describes the states an instance passes through from launch to termination.

States:

• Pending: Instance is launching and being prepared; billing has not started.
• Running: Instance is active and billable; applications can run.
• Stopping / Stopped: Instance is shut down. For EBS-backed instances, no compute charge while stopped, but EBS storage is still billed. Data on EBS root persists.
• Rebooting: Instance restarts; it stays on the same host and retains its data and IP (for the instance).
• Shutting-down / Terminated: Instance is being deleted; once terminated it cannot be recovered, and (by default) the root EBS volume is deleted.

Key transitions:

• Start ↔ Stop (only for EBS-backed instances).
• Reboot (no state change to stopped).
• Terminate (permanent).

Important notes:

• Instance Store data is lost on stop/terminate.
• Public IP (non-Elastic) changes on stop/start.
• Use Elastic IP to retain a static public address.

Resource Tags are key-value labels assigned to AWS resources (e.g., EC2 instances, EBS volumes, S3 buckets) to organize and manage them.

Structure: Each tag has a Key and an optional Value, e.g., Environment = Production.

Purposes:

• Cost allocation: Group costs by project, department, or environment in billing reports.
• Organization: Logically categorize resources.
• Automation: Target resources in scripts/automation (e.g., stop all Env=Dev instances at night).
• Access control: Use tag-based IAM policies (attribute-based access control).
• Operations: Filter and search resources easily.

Best practices:

• Define a consistent tagging strategy/standard.
• Use standard keys like Name, Environment, Owner, CostCenter, Project.
• Automate tag enforcement using AWS Config or Tag Policies.
• Avoid storing sensitive data in tags.

Limit: Up to 50 user-defined tags per resource.

Service Limits (Service Quotas) are the maximum values for resources, actions, or items in an AWS account, often applied per region.

Examples:

• Default limit on the number of running On-Demand instances per region.
• Maximum number of EBS volumes or VPCs per region.
• Number of Elastic IPs per region (default 5).

Why they exist:

• Protect customers from accidental over-provisioning and runaway costs.
• Ensure fair resource availability across all AWS customers.
• Safeguard against misuse or compromised credentials launching excessive resources.

Types of limits:

• Soft limits: Can be increased on request.
• Hard limits: Cannot be changed.

Management:

• View and track quotas via the Service Quotas console or AWS CLI.
• Request increases through the console or AWS Support.
• Monitor usage with CloudWatch to get alerts before hitting a limit.

Best practice: Proactively request increases before large-scale deployments to avoid launch failures.

Amazon EBS (Elastic Block Store) provides persistent, network-attached block storage for EC2 instances. Data persists independently of the instance lifecycle.

Key features:

• Persists after instance stop/terminate (if not set to delete).
• Can be detached and reattached to other instances in the same AZ.
• Supports snapshots to Amazon S3 for backup.
• Supports encryption at rest.

Main EBS volume types:

1. SSD-backed (IOPS-focused):

• gp2/gp3 (General Purpose SSD): Balanced price/performance; good for most workloads and boot volumes.
• io1/io2 (Provisioned IOPS SSD): High-performance, low-latency; for critical databases.

2. HDD-backed (Throughput-focused):

• st1 (Throughput Optimized HDD): For big data, log processing, streaming.
• sc1 (Cold HDD): Lowest cost for infrequently accessed data.

Comparison summary:

Both provide block storage for EC2 but differ significantly in persistence and use cases.

Instance Store Volumes:

• Ephemeral (temporary) storage physically attached to the host machine.
• Data is lost when the instance stops, terminates, or fails.
• Very high I/O performance (local disk).
• No additional cost (included with certain instance types).
• Cannot be detached or snapshotted directly.

EBS Volumes:

• Persistent, network-attached storage.
• Data survives instance stop/terminate (if configured).
• Can be detached, reattached, and snapshotted.
• Billed separately based on size/type.
• Slightly higher latency than instance store (network-based).

Comparison table:

Use case: Instance store suits temporary data, caches, and buffers; EBS suits data that must persist, such as databases and boot volumes.

Accessing an EC2 Instance:

• Key Pairs: Use a public/private key pair for authentication. AWS stores the public key; you keep the private key (.pem).

  • Linux: connect via SSH:
    bash
    ssh -i mykey.pem ec2-user@<public-ip>

  • Windows: use the private key to decrypt the administrator password for RDP.

• Session Manager (SSM): Access without opening SSH ports or managing keys.

Securing an EC2 Instance:

• Security Groups (virtual firewalls):

  • Control inbound and outbound traffic at the instance level.
  • Stateful: return traffic is automatically allowed.
  • Only allow needed ports (e.g., 22 for SSH, 443 for HTTPS) from trusted IP ranges.

• Network ACLs: Stateless subnet-level filtering for an extra layer.

• IAM Roles: Grant instances permissions to AWS services without storing credentials on the instance.

• Best practices:

  • Restrict SSH access to specific IPs, not 0.0.0.0/0.
  • Keep the OS patched.
  • Use IMDSv2 and encrypt EBS volumes.
  • Rotate and protect private keys.

EC2 Auto Scaling automatically adjusts the number of EC2 instances to maintain performance and optimize cost based on demand.

Benefits:

• Availability: Replaces unhealthy instances automatically.
• Elasticity: Scales out during peaks and in during low demand.
• Cost efficiency: Run only the needed capacity.

Key components:

• Launch Template / Launch Configuration: Blueprint specifying AMI, instance type, key pair, security groups, and user data.
• Auto Scaling Group (ASG): Logical group of instances with defined minimum, desired, and maximum capacity, spread across multiple AZs.
• Scaling Policies: Rules that trigger scaling actions.

Types of scaling policies:

1. Target Tracking Scaling: Maintain a metric at a target value (e.g., keep average CPU at 50%).
2. Step Scaling: Add/remove instances in steps based on alarm thresholds.
3. Simple Scaling: Single adjustment per alarm with a cooldown.
4. Scheduled Scaling: Scale based on known time patterns (e.g., scale up every weekday morning).
5. Predictive Scaling: Uses ML to forecast and pre-provision capacity.

Integration: Works with Elastic Load Balancing and CloudWatch alarms for health checks and metrics.

AWS Systems Manager (SSM) is a unified management service that provides visibility into and control over AWS resources, enabling operational tasks at scale without manual access to each instance.

Prerequisite: The SSM Agent must be installed on managed instances, and the instance needs an appropriate IAM role.

Key capabilities:

• Session Manager: Secure shell/RDP access to instances without SSH keys or open inbound ports, with full audit logging.
• Run Command: Execute commands/scripts across many instances simultaneously (e.g., patch, restart services).
• Patch Manager: Automate OS and application patching across fleets.
• Parameter Store: Securely store configuration data and secrets (plain or encrypted with KMS).
• State Manager: Maintain instances in a defined, consistent state.
• Automation: Create workflows (runbooks) for common maintenance tasks.
• Inventory: Collect metadata about installed software and configuration.
• Maintenance Windows: Schedule disruptive operations in defined windows.

Benefits:

• Improves security (no exposed ports, centralized secrets).
• Enables automation and consistency across large fleets.
• Reduces operational overhead and improves compliance.

The AWS CLI allows full EC2 management from the terminal, enabling automation and scripting. Below are common examples.

1. Launch an instance:
bash
aws ec2 run-instances \
--image-id ami-0abcd1234 \
--instance-type t2.micro \
--key-name MyKeyPair \
--security-group-ids sg-0123456 \
--count 1

Launches one t2.micro instance using the specified AMI, key pair, and security group.

2. List instances:
bash
aws ec2 describe-instances

Returns details of all instances in the region.

3. Start / Stop an instance:
bash
aws ec2 start-instances --instance-ids i-0abcd1234
aws ec2 stop-instances --instance-ids i-0abcd1234

4. Terminate an instance:
bash
aws ec2 terminate-instances --instance-ids i-0abcd1234

5. Create a tag:
bash
aws ec2 create-tags --resources i-0abcd1234 \
--tags Key=Environment,Value=Production

6. Create an EBS snapshot:
bash
aws ec2 create-snapshot --volume-id vol-0abcd1234 \
--description "Backup before update"

7. Allocate an Elastic IP:
bash
aws ec2 allocate-address

Benefit: These commands can be combined into scripts for repeatable, automated infrastructure management.