AWS Fundamentals

Cloud Computing Fundamentals

Traditional IT Infrastructure

Client–Server Model in Web Applications

• A client application (such as a web browser) sends a request over the internet (a network of interconnected systems) to a remote server (for example, a Gmail server)
• The server continuously waits for incoming client requests; once a request is received, it can process it and establish communication with the requesting client
• Both clients and servers recognize each other using their IP addresses

Physical Servers and Hardware (HW)

Core Components of a Computer/Server

1. COMPUTE: responsible for executing instructions and processing data
   • Hardware includes CPU (Central Processing Unit) and GPU (Graphics Processing Unit)
   • GPUs typically deliver higher performance than CPUs but come at a higher cost; they are commonly used for graphics rendering, large-scale data processing, machine learning, and generative AI
2. MEMORY: temporarily holds data that is actively being used or accessed frequently, enabling fast retrieval
   • Data stored here is temporary (volatile) and can be lost or overwritten (e.g., during restarts or when running new programs)
   • Hardware component: RAM (Random Access Memory)
3. STORAGE: retains data persistently, although access speeds are slower compared to memory
   • Hardware includes SSD (Solid State Drive) and HDD (Hard Disk Drive)
   • Data can be organized in different formats such as block, object, or file storage
   • Databases (DBs): add structure and logic to stored data, making it easier to search, retrieve, and process compared to basic storage
4. NETWORK (NW): enables communication between systems by sending and receiving data
   • Hardware includes cables, Network Interface Cards (NICs), routers (Layer 3), switches (Layer 2), and DNS servers
   • Data transmission may pass through multiple devices to reach its destination accurately

• Physical hardware can be simulated using technologies like virtualization and containerization, allowing virtual servers and components to run more efficiently on shared physical resources

Challenges of On-Premises Physical Servers

• Traditionally, organizations deployed servers within their own facilities or in data centers

• Common challenges include:
  • Uncertain scaling needs: difficult to estimate how many users will access the application or how usage patterns will change over time
  • Underutilized resources: purchasing large-capacity servers in advance often leads to unused resources, especially early on
  • Operational burden: teams must handle software updates, continuous monitoring, and hardware upgrades or replacements
  • Ongoing maintenance expenses: costs include physical space, electricity, cooling systems, and security personnel
  • Limited geographic distribution and resilience: systems are often centralized, making them vulnerable to disruptions like natural disasters or physical damage
  • High initial investment: setting up infrastructure requires significant upfront capital
• Cloud computing addresses these limitations by allowing users to lease infrastructure resources and avoid the complexities of managing physical hardware

What is Cloud Computing?

Cloud Computing

• Definition: A framework that provides widely accessible, easy, and on-demand network access to a shared pool of configurable IT resources (such as servers, networks, storage, applications, and services)
  • These resources can be quickly created and removed with minimal effort or need for direct interaction with the provider
• Cloud computing has significantly transformed how organizations and individuals use computing services
  • Key benefits include greater scalability, improved flexibility, reduced maintenance, and less reliance on physical infrastructure

Five Key Characteristics of a Cloud Platform

• The five core characteristics are:
  • On-Demand Self-Service
  • Broad Network Access
  • Resource Pooling
  • Rapid Elasticity
  • Measured Service

On-Demand Self-Service

• Users can allocate resources whenever needed without requiring assistance from the provider
  • Management is typically done through interfaces like web consoles, command-line tools, or APIs

Broad Network Access

• Services are delivered over the network and can be accessed using standard methods and devices
  • There is no need for specialized hardware or uncommon protocols

Resource Pooling

• Provider resources are shared among multiple users using a multi-tenant approach
• Users generally do not know the exact physical location of their resources, creating location independence
• This setup allows providers to achieve economies of scale, which leads to lower costs for customers

Rapid Elasticity

• Resources can be scaled up or down quickly depending on demand
  • Helps avoid both over-allocation (waste) and under-allocation (performance issues)
• From the user’s perspective, available resources often seem virtually unlimited
• This is considered one of the most valuable features of cloud computing

Measured Service

• Usage of resources is tracked, managed, and reported, and most importantly, charged accordingly
• With proper setup, users follow a pay-as-you-go pricing model, paying only for what they use
  • However, unused resources should be removed to avoid unexpected charges

Six Advantages of Cloud Computing (AWS Whitepaper)

1. Shift from capital expenses (CAPEX) to operational expenses (OPEX)
   • Reduces overall ownership and operational costs
   • No need to purchase or maintain physical hardware
2. Leverage large-scale economies
   • Cloud providers can lower prices due to operating at massive scale
3. Eliminate capacity guesswork
   • Resources can be adjusted based on actual usage, reducing idle capacity
4. Improve speed and agility
   • Infrastructure can be deployed or removed quickly compared to traditional setups
   • Enables faster experimentation and development
5. Reduce data center management
   • Less need to handle infrastructure maintenance, allowing focus on core business activities
6. Deploy globally with ease
   • Applications can be launched in multiple regions within minutes
   • Global infrastructure helps reduce latency and enhance user experience

Public vs Private vs Multi vs Hybrid Cloud

Types of Cloud Computing

Public Cloud

• Definition: A cloud environment that is open for use by the general public
  • Users access and control their resources through the internet
• Major public cloud providers include:
  • Amazon Web Services (AWS)
  • Microsoft Azure
  • Google Cloud

Multi-Cloud

• Definition: The practice of using more than one public cloud provider to run applications
• Examples:
  • Deploying different parts of an application across separate cloud platforms
  • Mirrored setup: running the same full application in multiple clouds (e.g., AWS and Azure)
    • If one provider experiences failure, the other can continue operating, improving availability
• Recommendation: Avoid relying on single-pane management tools for multi-cloud
  • These tools hide provider-specific features, making it harder to understand each platform’s strengths
  • They typically only expose features that are common across all providers, limiting functionality

Private Cloud

• Definition: A cloud setup that is dedicated to a single organization, usually hosted on-premises
• Major providers also offer solutions for private deployments, such as:
  • AWS Outposts
  • Azure Stack
  • Google Anthos
• To qualify as a true private cloud, the system must still satisfy the five essential cloud characteristics
  • Traditional virtualization platforms (e.g., VMware, Hyper-V, XenServer) may offer similar capabilities but do not fully meet all cloud criteria

Hybrid Cloud

• Definition: A combination of public cloud and private cloud working together as a unified system
  • Both environments are managed using consistent tools, processes, and interfaces
• Important distinction:
  • Simply connecting on-premises infrastructure to a public cloud is considered a hybrid environment or networking setup, not hybrid cloud
  • For it to be classified as hybrid cloud, it must involve both a true private cloud and a public cloud working together

Summary Diagram: Types of Cloud Computing

Cloud Service Models (XaaS)

Infrastructure Stack (or Application Stack)

• Layers of infrastructure involved when running a software application:
  1. Application
  2. Data → databases, data stores
  3. Runtime Environment (RTE) → code libraries, frameworks
  4. Container → Docker, Kubernetes
  5. Operating System (OS) → Linux, Windows, MacOS
  6. Virtualization
  7. Server → physical machine or hardware
  8. Infrastructure → server racks, network devices
  9. Facilities → buildings, power, security, real estate
• Unit of consumption = what the customer pays for and uses
  • Everything below the unit of consumption is handled by the provider
  • The unit itself and everything above is managed by the customer
  • Each cloud service model defines its own unit of consumption
• On-premises deployment → Customers take responsibility for the entire stack
  • More expensive, higher administrative workload, increased risk
  • Offers maximum control and flexibility
• Data Center (DC)-hosted → Customers pay for access to the facilities and manage everything else
  • Common model before widespread cloud adoption

Common Cloud Service Models

IaaS (Infrastructure-as-a-Service)

• Unit of consumption:Operating System (OS)
  • Typically provides virtual machines (VMs)
• Pricing: pay-as-you-go
  • Charged for VM usage by time (seconds, minutes, hours)
  • No charges when the VM is inactive
• Trade some flexibility for reduced cost and lower operational risk
• Highly adopted cloud service model
• Example: Amazon Elastic Compute Cloud (EC2)

PaaS (Platform-as-a-Service)

• Unit of consumption: Runtime Environment (RTE)
• Designed for developers who want to deploy and run applications without managing infrastructure
• Examples: Heroku, AWS Elastic Beanstalk

SaaS (Software-as-a-Service)

• Unit of consumption:Application
  • No need to manage underlying layers
• The software itself is the service
  • Limited customization or control
  • Minimal operational costs and responsibilities
• Pricing: subscription-based
  • Pay monthly or yearly for usage
  • Free tiers or trial versions are often available
• Examples: Netflix, Dropbox, Gmail

Other Cloud Service Models

• FaaS (Function-as-a-Service) → e.g., AWS Lambda
• DBaaS (Database-as-a-Service) → e.g., MongoDB Atlas
• CaaS (Container-as-a-Service) → e.g., Amazon ECS

Key Concept Diagram

AWS Accounts

What is AWS?

Amazon Web Services (AWS)

• Amazon: a major technology company, part of the FAANG group
• Web: services that are accessible over the internet using standard web protocols
• Services: offerings that customers can use for a period of time, usually billed based on actual usage (pay-as-you-go)
  • Example: your Internet Service Provider (ISP) provides internet as a service—you pay a monthly fee for access at a certain speed and can start or stop the service as needed
  • Other examples: Netflix subscription, utility services for your home, charging an electric vehicle at a public station
  • Difference between a service and a product: a product is purchased once and kept (e.g., a lunchbox), whereas a service is ongoing and billed for as long as you use it (e.g., HelloFresh delivering meals regularly)

AWS Cloud Use Cases

• Enables the development and deployment of scalable software applications across any industry
• Applications can optionally reach a global audience
• Common use cases include:
  • Hosting websites or web applications
  • Backing up or storing data in the cloud
  • Performing analytics on large datasets
  • Running gaming servers
  • And many more

AWS Cloud Pricing Model

• Pay-as-you-go is the standard pricing approach
  • Discounts may be available for reserving resources or committing to long-term usage
  • Reduces the high upfront costs of traditional IT infrastructure
• AWS pricing is based on three main categories:
  1. Compute – billed for actual compute time used
  2. Storage – billed for the amount of data stored in AWS
  3. Network –
     • Data transferred into AWS is free
     • Data transferred out of AWS is billed

AWS Shared Responsibility Model & AWS Acceptable Use Policy

AWS Shared Responsibility Model for Security

• Official AWS reference: Shared Responsibility Model

• AWS uses this model to define who handles which aspects of security:
  • Security OF the cloud → managed by AWS
  • Security IN the cloud → managed by the customer
• Related to the concept of the infrastructure stack in different cloud service models (IaaS, PaaS, etc.), which splits responsibilities between vendor and customer. Key differences:
  • Applies across all AWS services
  • Focuses specifically on security
• Useful as a reference while learning AWS—having a visual nearby can help reinforce the concept

AWS Acceptable Use Policy (AUP)

• Covers expected behavior when using AWS services:
  • No illegal, harmful, or offensive activity or content
  • No security violations
  • No network abuse
  • No abuse of email or other messaging services

AWS Accounts – The Basics

AWS Account – Key Concepts

• AWS account = container for identities and resources
  • Important: An AWS account is not the same as a user within the account.
  • Identity: a user, application, or entity that can log in to an AWS account
    • Note: IAM groups are an exception (explained later)
  • AWS resource: software, hardware, or data that exists in AWS and belongs to an account
    • Examples: EC2 virtual machine, S3 bucket with images
    • AWS defines a resource as “an entity you can work with”
    • Resources are created inside AWS services (e.g., S3 bucket is a resource in S3)
  • Simple systems may run from a single account, but complex setups often require multiple accounts (AWS Organizations can help manage multiple accounts)
  • AWS accounts should be treated as disposable; avoid placing all business operations in a single account

• Provisioning an AWS account requires:
  1. Account Name – e.g., “mywebapp-PROD”
  2. Unique email address – used to create the root user
     • Cannot be shared between accounts
     • Gmail trick: add + to make unique (user@gmail.com vs user+aws@gmail.com)
  3. Credit card – used for billing; can be shared between accounts
     • AWS bills based on actual usage (pay-as-you-go)
     • Free tier: some services include free usage each month, useful for learning
• Root User = default account identity
  • Full control of the account, cannot be restricted
  • First and only identity initially created
  • Should be used only for account setup, emergencies, or account closure
  • Daily administration should use a separate IAM identity (e.g., iamadmin)
• IAM (Identity and Access Management)
  • AWS service for creating additional account identities
  • IAM identities include users, groups, and roles
  • Start with no permissions by default and can be granted full or partial access
• Account boundary
  • Everything in the account is isolated by default
  • External access must be explicitly granted
  • Using multiple accounts reduces risk from errors or attacks
    • Example: separate accounts for DEV, TEST, PROD, or different teams/products

Free vs Paid AWS Accounts

• AWS historically offered service free tiers, but no fully free accounts
• Since 2025: AWS offers Free accounts for new customers
  • Free for 6 months, up to $200 in AWS credits
  • After expiration or credit usage, workloads stop until upgraded
  • Not all services/features available in Free accounts

• Free accounts are strictly limited:
  • Each customer can only use one Free account
  • Customer credentials cannot be shared
  • Gmail + trick does not work for Free accounts

• Recommendation: use a Paid account from the start
  • Full access to all services/features
  • No sudden interruptions of workloads
  • Learn responsible usage and budgeting early
  • Paying a small amount while learning AWS prepares you for real-world scenarios

Demo: Creating an AWS Account

• Recommended setup: MFA enabled, budget alarms, and iamadmin identity
• Sign up: AWS Signup Portal
  1. Enter personal details
  2. Prefer Paid account, but Free account possible if eligible
  3. Choose “Basic support – Free”
  4. Activate IAM Access to Billing Information under “Account”

◦ Without this, IAM identities cannot see billing information

• Region recommendation: Northern Virginia (us-east-1)
  • Ensures full service access
  • Optionally, use region closest to you for better performance

MFA (Multi-Factor Authentication)

Why MFA is Important

• Web-based logins typically rely on usernames and passwords
  • If these credentials are exposed, an attacker can easily gain access by pretending to be the user
• Authentication factors are different types of evidence used to verify identity
  • Common categories:
    1. Knowledge – something you know (e.g., username and password)
    2. Possession – something you own (e.g., phone, MFA app, hardware key)
    3. Inherence – something you are (e.g., fingerprint, facial recognition)
    4. Location – where you are (e.g., IP address, geographic location)
  • There is a balance between security and usability:
    • Adding more factors increases protection and makes impersonation harder
    • However, it also adds more steps and effort during login
  • Authentication types based on factors used:
    • SFA (Single-Factor Authentication) – uses only one factor
    • 2FA (Two-Factor Authentication) – uses two different factors
    • MFA (Multi-Factor Authentication) – uses multiple factors

MFA in AWS

• MFA can be enabled for any user, such as the root user or an IAM administrator
  • AWS provides a secret key and setup details, usually in the form of a QR code
  • This information is configured in an MFA application or device (e.g., Google Authenticator, Authy, password managers)
• After setup, the MFA device generates temporary codes that update at regular intervals
• During login, users must provide:
  • Their primary credentials (username and password)
  • The current MFA code from their device
• This adds an extra layer of protection beyond just passwords

Demo: Enabling MFA in an AWS Account

• Go to: Account menu → Security credentials → Assign MFA
• Choose Authenticator App as the MFA method and follow the setup instructions
  • Any standard authenticator app can be used (e.g., Google Authenticator, Authy, 1Password)

Creating a Budget

AWS Free Tier

• More information about the AWS Free Tier: https://aws.amazon.com/free/
  • Some services offer limited-time free trials, others provide a certain amount of free usage each month, and some include always-free options
  • As mentioned in Free vs Paid accounts, eligible users can sign up for a Free account, but it comes with limitations on available services/features and typically lasts for 6 months
• AWS includes detailed cost tracking tools to monitor resource usage (e.g., AWS Cost Explorer)
• Navigate to: Drop-down menu → Billing and Cost Management → Bills
  • Displays previous invoices and current monthly charges
• Under Billing Preferences, enable all available options for better visibility and notifications

Creating a Cost Budget

• AWS Budgets help you track spending and send alerts when usage approaches defined limits
• Navigate to: Billing Dashboard → Budgets → Create a Budget
• A “zero spend budget” is useful if you want to remain fully within the Free Tier
• Labs and demos are typically designed to stay within free usage limits, but unexpected charges can still occur
  • Setting a budget ensures you receive alerts if costs begin to accumulate
  • This allows you to take action, such as deleting resources that are generating charges

AWS IAM 101

Identity and Access Management (IAM) Service

• AWS IAM is a fundamental AWS service used to manage identities and access
  • It performs three primary functions:
    1. Identity management → acts as an Identity Provider (IdP)
    2. Authentication → verifies that an identity is legitimate
    3. Authorization → controls access using policies (allow or deny actions)
  • IAM is free to use
  • It is a global service, meaning it operates across all AWS regions with built-in resilience
• IAM has broad administrative capability, but it only applies to identities within its own account
  • It does not directly manage identities from other AWS accounts
  • Each AWS account has its own isolated IAM system and database
  • An account fully relies on its own IAM instance
• IAM can control nearly all aspects of an account, except:
  • Billing-related actions
  • Closing the account (root user only)
• IAM also supports:
  • Multi-Factor Authentication (MFA)
  • Identity Federation
    • External identities (e.g., from Google, Facebook, or corporate directories) can be used to access AWS resources indirectly

Account Root User

• The root user is the initial identity tied to the AWS account
  • Linked to the account’s email address
  • Has complete and unrestricted access
  • The account inherently trusts the root user
• The root user is not managed by IAM
  • IAM cannot limit or control it
• Best practices:
  • Avoid using the root user for routine activities
  • Reserve it for critical or one-time tasks only (e.g., account recovery or closure)
• Principle of least privilege:
  • Grant users only the permissions they need to perform their roles
  • Restrict all unnecessary access

IAM Identities and Policies

• IAM allows creation of additional identities within an account:
  1. IAM Users
     • Represent individuals or applications needing long-term access
     • Use permanent credentials (username/password and/or access keys)
  2. IAM Groups
     • Collections of users with similar access needs
     • Example: developers, finance team
  3. IAM Roles
     • Used by AWS services or external entities
     • Suitable when multiple or unknown users need access
     • Provide temporary credentials
• IAM Policy
  • A document that defines permissions
  • Attached to users, groups, or roles
  • Specifies which actions are allowed or denied on resources
  • Written in JSON format
  • The account trusts permissions granted through these policies

Demo: Creating an IAM Admin User in an AWS Account

• IAM users access the account through a sign-in URL:
  https://<account-id>.signin.aws.amazon.com/console
  • The account ID is a numeric identifier
  • You can define an account alias to make the URL easier to remember
    • Must be globally unique
    • Provides a cleaner login link:
      https://<account-alias>.signin.aws.amazon.com/console
• In this example, a new IAM user named iamadmin is created with administrator-level permissions
  • This reduces reliance on the root user
  • The root user cannot be restricted, removed, or recreated, making it unsafe for routine tasks
• Steps to create the IAM user:
  • Go to IAM → Users → Add Users
  • Enter a username (iamadmin)
    • Only needs to be unique within the account
  • Assign permissions during setup
    • Attach the AdministratorAccess policy
      • Grants full access to the account, except for actions limited to the root user (such as closing the account)
• After logging in with the new IAM user:
  • The username appears in the top-right corner of the AWS console

• For better security, enable MFA for the iamadmin user

Image Sources

• IAM policy concepts and examples:
  Salesforce Trailhead IAM Policies Module
• IAM policy structure and practical examples:
  MSP360 IAM Policy Guide

Accessing AWS Accounts

3 Ways to Access AWS Accounts, Services, and Resources

1. AWS Management Console UI
2. AWS CLI (Command Line Interface)
3. AWS SDK (Software Development Kit)

AWS Management Console (Commonly called: AWS Console UI)

• A web-based interface accessed through a browser
• Requires login using a valid identity (root user, IAM user, or IAM role)
  • Secured with a password and optionally MFA
• Often referred to as “ClickOps” since actions are performed through the interface
  • In contrast, Infrastructure as Code (IaC) and DevOps practices rely on automation, scripts, and code instead of manual interaction

AWS CLI (Command Line Interface)

• Allows interaction with AWS services by running commands in a terminal or shell
• Communicates with AWS through its public APIs
• Must be installed locally before use
  • Installation guide: https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html
• Open-source tool: https://github.com/aws/aws-cli
• Requires IAM access keys for authentication

AWS SDK (Software Development Kit)

• Provides language-specific libraries for developers
  • Enables applications and scripts to interact with AWS programmatically
  • Supports multiple programming languages
• Requires IAM access keys
• The AWS CLI itself is built using an AWS SDK (Python-based)

AWS CloudShell

• A browser-based terminal environment available within the AWS Console
  • Runs inside a selected AWS region
  • Comes preconfigured with AWS CLI, credentials, and region settings
• Includes a small persistent storage space for saving files
• Not available in all AWS regions
  • Supported regions list: https://docs.aws.amazon.com/cloudshell/latest/userguide/supported-aws-regions.html

IAM Access Keys

Long-Term and Short-Term Credentials

• Credentials are pieces of information used by AWS to verify identity (i.e., enable login to an account)
  • Long-term credentials remain valid until manually changed
    • Examples: username and password, IAM access keys
    • The user must update or rotate them when needed
  • Short-term credentials are temporary and expire after a set duration
    • Systems using them must regularly request new credentials to maintain access
• The root user and IAM users rely on long-term credentials, while IAM roles provide short-term credentials
• Credentials typically include:
  • A public component (e.g., username, access key ID)
  • A private component (e.g., password, secret key)
  • MFA acts as an additional private verification factor

IAM Access Keys

• Access to AWS via the CLI or APIs is commonly done using IAM access keys
• IAM access keys are a type of long-term credential consisting of two parts:
  1. Access Key ID (public) – e.g., AKIAIOSF0DNN7EXAMPLE
  2. Secret Access Key (private) – a longer, confidential string shown only once during creation

• Key characteristics:
  • Can be created, deactivated, reactivated, or deleted
  • Cannot be modified once created
    • Instead, they must be rotated (deleted and replaced with new keys)
  • By default, newly created keys are active
• Limits per IAM user:
  • Up to one username/password pair
  • Up to two active access key sets (useful for rotation)
• Although root users can generate access keys, this is strongly discouraged
  • Root access should not be used for routine CLI or API operations

Demo: Creating Access Keys and Configuring AWS CLI v2

• Create access keys:
  • Go to: Account menu → Security Credentials → Create Access Key
  • Download and store the keys securely (e.g., CSV file)
• Install AWS CLI v2:
  • https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html
  • Verify installation:
    • Run aws to see help output
    • Run aws --version to confirm version 2 or higher
• Configure AWS CLI profiles:
  • aws configure → sets up the default profile
  • aws configure --profile iamadmin-general → creates a named profile
    • Provide access key ID, secret key, default region (us-east-1), and output format
• Test access:
  • aws s3 ls → lists S3 buckets
  • If using a named profile:
    • aws s3 ls --profile iamadmin-general
• After successful configuration, it is good practice to remove downloaded credential files from your local system

AWS Fundamentals

AWS Public vs Private Services

AWS Networking Ecosystem

• AWS networking is divided into three main zones:

1. AWS Private Zone

• Defined by customer-controlled private networks (VPCs – Virtual Private Clouds)
  • VPCs are isolated by default, even from other VPCs
• External connectivity must be explicitly configured, such as:
  • Connecting to on-premises environments via VPN or Direct Connect
  • Accessing AWS public services through an Internet Gateway (IGW)
  • Enabling communication with the public internet using an IGW
• Similar to a private network (e.g., a VPN on a laptop), communication only happens when properly configured
• Many AWS services require a VPC to run resources
  • Example: EC2 instances are launched inside a VPC

2. AWS Public Zone

• A network layer managed by AWS that connects VPCs to the public internet
• Hosts public AWS services, such as IAM, Route 53, and S3
  • These services are accessed through public endpoints
  • They do not require a VPC to function
• Communication between a VPC and a public AWS service can occur via an IGW without necessarily traversing the open internet

3. Public Internet

• The global public network used worldwide
• External systems and users interact with AWS through this layer

Key Clarification

• The distinction between AWS private and public services relates only to networking design
  • It does not determine access permissions
• Even if a service has a public endpoint, access is still controlled
  • Proper authentication and authorization are required
  • By default, only the root user has full access
  • Other identities must be granted permissions through IAM

Summary Diagram

High-Availability (HA), Fault Tolerance (FT) & Disaster Recovery (DR)

High Availability (HA)

• A high availability (HA) system is designed to maintain a defined level of performance, typically uptime, for a longer-than-usual duration
  • In simple terms, HA focuses on maximizing system availability
    • If a failure occurs, components can be quickly repaired or replaced, often through automated processes
  • This approach generally costs more than standard systems
    • Requires thoughtful system design and automation
    • Often involves redundant components
• Examples:
  • Keeping a backup physical server ready to take over if the primary one fails
  • Automatic failover mechanisms that switch to standby or replica systems when a failure is detected
• Important: HA does not eliminate failures or prevent outages entirely
  • Downtime can still occur, but it is minimized in duration
  • Temporary disruption to users is acceptable as long as the system recovers quickly
    • Systems may briefly go offline during component replacement
    • Users may need to reconnect
• Summary: HA emphasizes rapid and automated recovery from failures
  • Real-world analogy: carrying a spare tire in a vehicle—you may still stop to fix a flat, but recovery is much faster than waiting for external help

HA Summary Diagram

Fault Tolerance (FT)

• A fault-tolerant (FT) system is built to continue functioning correctly even when one or more components fail
  • The system can operate despite existing faults
    • Failures are handled while the system remains operational
    • Faulty components are isolated, and traffic is automatically redirected
  • FT goes beyond HA and is significantly more expensive
    • Designed for zero downtime
    • Requires a higher level of redundancy
• Example:
  • A hospital heart monitoring system where continuous operation is critical
    • Any interruption could have life-threatening consequences
• Real-world analogy:
  • An aircraft equipped with multiple redundant systems
    • It must remain operational even if a component fails
    • Repairs cannot be performed mid-flight

FT Summary Diagram

Disaster Recovery (DR)

• Disaster Recovery (DR) refers to a combination of strategies, tools, and procedures used to restore or maintain critical systems and infrastructure after a disaster
  • Essentially, it addresses what happens when both HA and FT are insufficient
  • Involves planning for events that can disrupt entire systems
    • Before a disaster: preparation and planning
    • After a disaster: execution of recovery procedures
  • Modern DR processes are often automated to reduce human error
  • Business Continuity (BC) ensures operations continue during a disruption, while DR focuses on restoring systems and data afterward
• During disasters, stress and confusion can lead to poor decisions, making preparation essential
• Key elements of an effective DR strategy:
  1. Develop a clear plan with defined priorities
     • Protect critical assets to enable system rebuilding
  2. Strengthen infrastructure resilience
     • Use additional hardware, servers, or instances
     • Maintain regular backups
       • Backups should be stored offsite, not in the primary location
       • This prevents loss if the main site is affected
  3. Build organizational knowledge
     • Maintain detailed documentation (e.g., access credentials for backup systems)
     • Conduct staff training and regular DR drills
• Real-world analogy:
  • An emergency evacuation system (like parachutes) in an aircraft
    • Equipment can be replaced, but human life cannot

DR Summary Diagram