Introduction to Cloud Computing and AWS

# ==========================================================================================
COMPUTING ARCHITECTURE EVOLUTION

[ TRADITIONAL ON-PREMISES ]               [ VIRTUALIZED / CLOUD INFRASTRUCTURE ]

+-------------------------+               +------------------------------------+
| Monolithic Application  |               | VM 1 (App A) | VM 2 (App B) | ...  |
+-------------------------+               +------------------------------------+
| Operating System (OS)   |               | Guest OS 1   | Guest OS 2   | ...  |
+-------------------------+               +------------------------------------+
| Physical Server (Bare)  |               | Hypervisor Abstraction Software     |
+-------------------------+               +------------------------------------+
| Physical Power & Cooling|               | Automated API Orchestration Layer  |
+-------------------------+               +------------------------------------+
| Corporate Real Estate   |               | Bare-Metal Server Pools            |
+-------------------------+               +------------------------------------+

==========================================================================================

Let's look at a comparative matrix detailing how traditional architecture compares directly with cloud native ecosystems across core operational dimensions:

Operational Dimension	Traditional On-Premises Infrastructure	Modern Cloud Computing Ecosystems
Procurement Speed	Weeks to months for hardware sourcing, shipping, racking, and stack configuration.	Seconds to minutes via programmatic API calls, CLI commands, or infrastructure-as-code scripts.
Scalability Style	Vertical scaling only (buying larger servers); constrained by physical space and limits.	Dynamic horizontal scaling; automated scaling rules provision resources as demand shifts.
Cost Model	High upfront Capital Expenditure (CapEx) with fixed ongoing maintenance costs.	Variable Operational Expenditure (OpEx); pay-as-you-go based on actual consumption metrics.
Disaster Recovery	Requires expensive, redundant secondary data centers with manual failover setups.	Built-in global redundancy; automated multi-region replication and failover routes.
Resource Elasticity	Static; infrastructure must be provisioned for peak load, leading to idle resources.	Dynamic; instances are automatically de-provisioned when demand drops to eliminate waste.

1. Trade Fixed Expense for Variable Expense

Instead of investing heavily in physical data centers and hardware before knowing how your applications will perform, you only pay when you consume computing resources. This shifts your financial model from heavy upfront investments to flexible operational expenses based on actual usage.

2. Benefit from Massive Economies of Scale

Because providers like AWS aggregate usage from millions of active customers, they can purchase physical hardware at a scale individual companies cannot match. These cost savings are passed back to customers in the form of lower usage prices.

3. Stop Guessing Capacity

In traditional setups, under-provisioning leads to application downtime, while over-provisioning results in wasted expenditures. The cloud eliminates this guesswork by letting you scale capacity up or down automatically in response to real-time traffic demands.

4. Increase Speed and Agility

In a cloud environment, new technology resources are always just a click or an API call away. This reduces the time required to make infrastructure available to your development teams from weeks to minutes, drastically accelerating your organization's pace of innovation.

5. Stop Spending Money Running and Maintaining Data Centers

Managing data centers requires significant operational overhead, from racking servers and provisioning backup power to managing physical security. The cloud allows organizations to hand off this "undifferentiated heavy lifting" to the provider, freeing up teams to focus on building features and delivering business value.

6. Go Global in Minutes

Cloud networks allow you to deploy applications across multiple regions around the world with just a few clicks. This helps you reduce network latency for international users and improve their overall user experience at minimal cost.

Infrastructure as a Service (IaaS)

IaaS provides the foundational building blocks for cloud IT, offering access to virtualized networking, storage, and computing power. It offers the highest level of control and management flexibility over your infrastructure, making it closest to traditional on-premises IT setups.

• Provider Responsibility: Physical security, cooling, power, networking cables, physical servers, and hypervisor virtualization software.
• Customer Responsibility: Guest operating system configuration, patching, middleware, application runtimes, data storage configurations, and network security rules.
• AWS Example: Amazon Elastic Compute Cloud (EC2). For guidance on configuring virtual servers, see our Amazon EC2: Launching and Managing Virtual Servers handbook.

Platform as a Service (PaaS)

PaaS abstracts away the underlying operating system, hardware runtime, and resource procurement layers. This allows developers to focus entirely on deploying and managing their application code without worrying about server provisioning, capacity planning, software patching, or system maintenance.

• Provider Responsibility: Everything in IaaS, plus OS scaling, runtime environments (e.g., Node.js, Python, Java runtimes), and automated patch management.
• Customer Responsibility: Core application code and environment-specific configurations.
• AWS Example: AWS Elastic Beanstalk.

Software as a Service (SaaS)

SaaS delivers a complete, fully managed application product over the web. The end-user doesn't need to understand how the underlying infrastructure is built or maintained; they simply consume the software through a web browser or client interface.

• Provider Responsibility: The entire application stack, from physical hardware up to the user interface software.
• Customer Responsibility: Basic user account settings, internal data inputs, and access management configurations.
• Examples: Microsoft 365, Salesforce, and Amazon WorkDocs.

Public Cloud (Cloud-Native Deployment)

In a public cloud model, all components of the application run entirely within the cloud provider's infrastructure. Organizations leverage multi-tenant environments where physical resources are shared across customers but completely isolated at the virtual layer. This approach minimizes upfront capital costs and maximizes resource elasticity.

Private Cloud (On-Premises Deployment)

A private cloud deployment uses virtualization technologies (like OpenStack or VMware) to manage dedicated physical hardware owned entirely by a single organization. While this model provides maximum control over data residency and physical security, it lacks the true elasticity, cost efficiencies, and economies of scale of the public cloud.

Hybrid Cloud Topology

A hybrid cloud topology connects on-premises legacy data centers directly to public cloud infrastructure. This model allows organizations to keep highly sensitive databases or legacy workloads inside their private infrastructure while leveraging the public cloud's scalable compute capacity during traffic spikes.

+------------------------------------+                    +------------------------------------+
|    CORPORATE PRIVATE DATA CENTER   |                    |        PUBLIC AWS CLOUD REGION     |
|                                    |  Dedicated Tunnel  |                                    |
|  [ Internal Legacy Database ]     |====================>|  [ Elastic Compute Web Fleet ]     |
|  Strict Data Sovereignty Perimeter |  AWS Direct Connect|  Scalable, Public-Facing App Layer |
+------------------------------------+                    +------------------------------------+

To build these secure hybrid connections, companies use dedicated networking links like AWS Direct Connect or managed VPN tunnels. This allows secure, low-latency communication across both environments.

AWS Regions

An AWS Region is an isolated, independent geographic area where Amazon clusters data centers (e.g., us-east-1 in N. Virginia, eu-west-1 in Ireland). Regions are completely isolated from one another to ensure fault isolation and data compliance. When you provision resources, you must explicitly select a target Region.

Selecting the right Region depends on four primary criteria:

• Data Sovereignty and Compliance: Many countries enforce strict data laws (like GDPR) requiring local citizen data to remain within geographic borders.
• Proximity and Network Latency: Choosing a Region physically close to your user base minimizes packet travel times, ensuring a faster user experience.
• Pricing Disparities: AWS costs vary by Region due to local land values, electricity rates, and tax laws.
• Service Availability: While foundational services are universal, some specialized, newer capabilities may take time to roll out to every Region.

Availability Zones (AZs)

An Availability Zone (AZ) consists of one or more discrete, physically separate data centers housed in distinct buildings within an AWS Region. Each data center features redundant cooling infrastructure, isolated backup power grids, and independent network connections.

All AZs within a Region are interconnected via a private, ultra-low latency fiber-optic network. By spreading application instances across multiple AZs (Multi-AZ architecture), you ensure that a physical fire, flood, or power failure in one zone will not take down your entire application. Every AWS Region contains at least three distinct Availability Zones to provide this high availability.

Points of Presence: Edge Locations and Regional Caches

While Regions and AZs host your core infrastructure, Edge Locations are smaller, specialized data centers located in major metropolitan areas worldwide. These sites work alongside Amazon CloudFront (a global Content Delivery Network, or CDN) to cache content closer to end-users, lowering latencies for website downloads and video streams. Regional Edge Caches sit between your core Regions and Edge Locations, providing a larger, mid-tier caching layer to reduce traffic loads on your origin servers.

AWS Scope: Security OF the Cloud	Customer Scope: Security IN the Cloud
Physical Hardware Protection: Securing bare-metal compute nodes, storage racks, and network infrastructure.	Customer Data Management: Configuring server-side file encryption, data classifications, and lifecycle rules.
Physical Facility Access: Biometric controls, security guards, video cameras, and physical access logs at data centers.	Identity and Access Management (IAM): Enforcing password complexities, managing API keys, and assigning roles via least-privilege principles.
Global Network Fabric: Maintaining underlying routers, switches, and fiber links connecting Regions and AZs.	Network Security Settings: Configuring firewalls, security groups, routing tables, and network access control lists (NACLs).
Hypervisor Layer Security: Securing virtualization software to prevent host breakout vulnerabilities.	Guest Operating Systems: Applying security patches, managing system configurations, and handling internal software packages.

1. Core Compute Services

• Amazon EC2 (Elastic Compute Cloud): Secure, resizable virtual servers provisioned on demand.
• AWS Lambda: A serverless compute service that executes code in response to events, automatically managing all underlying computing resources.
• Amazon ECS / EKS: Managed container orchestration platforms supporting Docker container deployment at scale.

2. Scalable Storage Services

• Amazon S3 (Simple Storage Service): An object storage service built to store and protect flat files, media assets, and unstructured data. For details on bucket management, check out our Amazon S3: Scalable Object Storage Essentials handbook.
• Amazon EBS (Elastic Block Store): High-performance block storage volumes designed for persistent use with Amazon EC2 instances.
• Amazon EFS (Elastic File System): A scalable, shared file storage system that can be mounted simultaneously by multiple virtual servers.

3. Managed Database Engines

• Amazon RDS (Relational Database Service): Simplifies setting up, operating, and scaling relational engines like PostgreSQL, MySQL, and Oracle.
• Amazon DynamoDB: A fully managed NoSQL database service that provides single-digit millisecond response times at scale.

4. Cloud Networking Architecture

• Amazon VPC (Virtual Private Cloud): An isolated, private virtual network where you launch your AWS resources.
• Amazon Route 53: A highly available, scalable Domain Name System (DNS) web service.

5. Governance and Compliance Visibility

• AWS CloudTrail: Audits account activity by logging all API actions taken across your AWS infrastructure. For implementation patterns, see our AWS CloudTrail: Governance and Compliance guide.
• Amazon CloudWatch: A monitoring and observability platform that tracks application logs, system metrics, and real-time operational alarms.

Scenario A: An EC2 Web Server Launched inside a New VPC Cannot Connect to the Internet

• Root-Cause Analysis: This issue typically stems from a missing network routing path between the virtual network and the public internet. Common culprits include a missing Internet Gateway (IGW) connection, an incorrectly configured routing table, or an EC2 instance launched inside a private subnet without a NAT Gateway path.
• Remediation Steps:
  1. Open the Amazon VPC console and verify that an Internet Gateway is explicitly attached to your target VPC.
  2. Check the Route Table associated with the instance's subnet and confirm it contains a default route (0.0.0.0/0) pointing to the Internet Gateway.
  3. Verify that the EC2 instance has been assigned a public IP address or a public Elastic IP address.

Scenario B: A Cloud Storage Application Throws an HTTP 403 Access Denied Error

• Root-Cause Analysis: HTTP 403 errors indicate an identity or permission mismatch. The IAM user, role, or application attempting to access an Amazon S3 bucket lacks the explicit permissions required to execute that action, or is blocked by an explicit Deny statement in a bucket policy.
• Remediation Steps:
  1. Check the explicit IAM Policy attached to the calling identity and verify it includes the necessary actions (e.g., s3:GetObject or s3:PutObject) for that resource.
  2. Review the target S3 Bucket Policy to ensure it doesn't contain a public access block or an explicit Deny statement that overrides the IAM permissions.
  3. Verify that the AWS credentials used by the application are valid and haven't expired.

Scenario C: Monthly AWS Bills Substantially Exceed Forecasted Projections

• Root-Cause Analysis: Unexpected cost increases are often driven by untracked cloud resources, such as orphaned block storage volumes (EBS), unmanaged database snapshots, or rogue developer instances running in unmonitored AWS Regions.
• Remediation Steps:
  1. Open AWS Cost Explorer to pinpoint the exact services and Regions driving the cost increase.
  2. Use AWS Cost Anomaly Detection to set up alerts for unusual spending spikes.
  3. Locate and delete unattached EBS volumes, old snapshots, and idle environments to eliminate wasted costs.

Q1: Explain the exact technical relationship and structural differences between an AWS Region and an Availability Zone.

Answer: An AWS Region is an independent, distinct geographic area somewhere in the world (such as us-east-1 in Northern Virginia or ap-south-1 in Mumbai). Each Region is completely isolated from the others to ensure data compliance and fault isolation.

An Availability Zone (AZ) is a physical cluster of data centers located within a specific AWS Region. Each AZ consists of one or more discrete data centers housed in separate buildings with independent power grids, cooling infrastructure, and network connections to protect against localized disasters.

Regions are geographic boundaries, while AZs are physical infrastructure installations within those boundaries. AZs within a Region are connected via a private, ultra-low-latency fiber network. This allows engineers to build highly available, fault-tolerant applications by distributing instances across multiple AZs within a single Region.

Q2: A company needs to host a legacy database containing sensitive data that cannot be moved to public cloud infrastructure due to regulatory requirements. However, the customer wants to use AWS compute power to run their public web applications. What cloud deployment model solves this problem, and how is it implemented?

Answer: This use case requires a Hybrid Cloud deployment model. This model allows an organization to connect its existing on-premises infrastructure directly to the public cloud, keeping sensitive database assets inside their local private data center while leveraging the scalability of the public cloud for web applications.

To implement this architecture safely, you establish a secure network connection between the on-premises environment and the AWS Virtual Private Cloud (VPC). This is typically done using an encrypted AWS Site-to-Site VPN tunnel over the internet, or a dedicated, high-speed physical link like AWS Direct Connect for workloads requiring consistent network performance. The public web applications are deployed within public subnets in the AWS VPC, while the backend application layers communicate securely with the private on-premises database through the network tunnel.

Q3: An application developer creates an EC2 instance, installs an Apache web server, and verifies the application runs locally. However, public internet users cannot access the website via their browsers. Under the AWS Shared Responsibility Model, whose responsibility is this to fix, and what configuration components must be reviewed?

Answer: Under the AWS Shared Responsibility Model, resolving this network access issue is entirely the customer's responsibility. AWS is responsible for the security of the cloud—ensuring the physical host, hypervisor layer, and underlying network hardware function properly. The customer is responsible for security in the cloud, which includes configuring guest operating systems, firewall rules, and virtual network routing patterns.

To diagnose and resolve this access issue, the customer should review the following components:

• EC2 Security Groups: Verify that the instance's firewall rules allow inbound HTTP traffic on port 80 (and HTTPS on port 443) from all sources (0.0.0.0/0).
• Network Access Control Lists (NACLs): Check the subnet's network ACLs to confirm they do not contain explicit Deny rules blocking traffic on ports 80 or 443, and ensure ephemeral port ranges are open for return traffic.
• VPC Routing Tables: Ensure the subnet hosting the EC2 instance has a valid routing path (0.0.0.0/0) directed to an attached VPC Internet Gateway.

What is the difference between horizontal scaling and vertical scaling in cloud environments?

Vertical scaling (scaling up) means adding more power to an existing server, such as upgrading an instance from 4 vCPUs and 16GB of RAM to 16 vCPUs and 64GB of RAM. Horizontal scaling (scaling out) means adding more servers to your infrastructure pool to distribute the workload across multiple machines. Horizontal scaling allows you to leverage the cloud's true elasticity by automatically provisioning or de-provisioning instances as demand changes.

What does the term "Elasticity" mean in cloud computing?

Elasticity is the cloud's ability to automatically scale computing resources up or down in real time to match actual demand. This differs from standard scalability, which refers to a system's ability to handle growing workloads by adding capacity. Elasticity focuses on the automated adaptation of resources, allowing a system to expand during traffic surges and shrink during low-activity periods to minimize unnecessary costs.

Why is AWS IAM considered a core security component under the Shared Responsibility Model?

AWS Identity and Access Management (IAM) is the gatekeeper for your AWS account, managing who can access your resources and what actions they can perform. Under the Shared Responsibility Model, AWS provides a secure IAM framework, but the customer is responsible for configuring identity policies safely. Enforcing strong password rules, requiring Multi-Factor Authentication (MFA), and applying least-privilege access permissions helps prevent unauthorized access and data breaches.

What is an AWS Edge Location, and how does it differ from an Availability Zone?

An Availability Zone is a physical cluster of data centers designed to host your core computing resources, databases, and network configurations within a specific Region. An Edge Location is a smaller, specialized site located in major metropolitan areas globally. Edge Locations do not run core applications; instead, they work with services like Amazon CloudFront to cache static files and media content closer to end-users to reduce network latency.

What are the primary differences between On-Demand and Spot Instances?

On-Demand Instances provide predictable compute capacity with flat utility pricing and no long-term commitments, making them ideal for standard production workloads. Spot Instances allow you to bid on spare AWS compute capacity at discounts of up to 90% off On-Demand rates. However, Spot instances can be reclaimed by AWS with a 2-minute warning if they need the capacity back, making them best suited for flexible, fault-tolerant tasks like batch data processing.

What is the difference between a Public Cloud and a Private Cloud deployment model?

A public cloud model provides computing resources over the public internet from shared, multi-tenant hardware owned and managed by a third-party provider like AWS. A private cloud model uses virtualization technologies to manage dedicated hardware owned and operated exclusively by a single organization within their private data center. Public clouds offer superior scaling and cost efficiencies, while private clouds offer maximum physical isolation and data control.