Skip to content

Cloud Services

Cloud services deliver computing resources (servers, storage, networking, databases, etc.) on demand over the internet. Unlike traditional on-premises data centers, cloud services allow users to access virtually unlimited computing power over the network without purchasing or maintaining physical hardware. This section provides a systematic overview of core cloud concepts, network architecture, security mechanisms, deployment practices, and more.

1. Introduction to Cloud Computing

1.1 What Is Cloud Computing

At its core, cloud computing is about resource pooling and on-demand allocation. Cloud providers build large-scale data centers around the world and use virtualization to abstract physical servers, storage devices, and networking equipment into dynamically allocatable resource pools. Users access these resources over the internet and pay based on usage.

The five essential characteristics of cloud computing (as defined by NIST):

  • On-demand Self-service: Users can provision computing resources at any time without requiring human interaction with the provider.
  • Broad Network Access: Cloud resources are accessible from a variety of client devices via standard network protocols.
  • Resource Pooling: Providers aggregate resources into pools and dynamically assign them to different users through a multi-tenant model.
  • Rapid Elasticity: Resources can be quickly scaled up or down based on demand, appearing virtually unlimited to the user.
  • Measured Service: Resource usage is monitored and metered, and users pay only for what they actually consume.

1.2 Cloud Computing Service Models

Cloud computing is divided into three primary service models based on the level of abstraction provided:

IaaS (Infrastructure as a Service)

Provides the lowest-level computing resources: virtual machines, networking, and storage. Users have maximum control and are responsible for managing the operating system, middleware, and applications.

  • Typical services: AWS EC2, Google Compute Engine, Oracle Cloud Compute, Azure Virtual Machines
  • Use cases: Applications requiring full control over the runtime environment, such as self-managed databases or custom network architectures
  • User-managed scope: Operating system, runtime environment, applications, data

PaaS (Platform as a Service)

Provides an application runtime platform. Users only need to focus on code and data without managing the underlying infrastructure.

  • Typical services: Google App Engine, Azure App Service, Heroku, Cloud Foundry
  • Use cases: Web application development, API services, microservices architectures
  • User-managed scope: Application code, data

SaaS (Software as a Service)

Delivers ready-to-use software applications. Users interact through a browser or client application without worrying about any technical details.

  • Typical services: Gmail, Google Docs, Salesforce, Slack, Dropbox
  • Use cases: Day-to-day productivity, collaboration, email, etc.
  • User-managed scope: Data and user configuration only

An analogy to understand the relationship among the three:

  • IaaS: Renting a plot of land and building materials — you build the house, do the interior, and move in your furniture
  • PaaS: Renting a fully furnished apartment — just bring your belongings and move in
  • SaaS: Staying at a hotel — everything is ready; just check in
User-managed scope decreases; provider-managed scope increases:

┌─────────────────────────────────────────────────┐
│                    SaaS                         │
│         User only uses; everything else managed │
├─────────────────────────────────────────────────┤
│                    PaaS                         │
│         User manages applications and data      │
├─────────────────────────────────────────────────┤
│                    IaaS                         │
│         User manages OS, runtime, apps, data    │
├─────────────────────────────────────────────────┤
│          Physical Infrastructure (provider)      │
│       Servers, storage, network, data center,   │
│       power                                     │
└─────────────────────────────────────────────────┘

1.3 Other Service Models

Beyond the classic three-layer model, several more specialized models have emerged in recent years:

  • FaaS (Function as a Service): Serverless computing — users write function code, and the platform automatically manages the execution environment. Typical services: AWS Lambda, Google Cloud Functions, Azure Functions.
  • CaaS (Container as a Service): Provides container orchestration and management services. Typical services: Google Kubernetes Engine (GKE), Amazon EKS, Azure AKS.
  • DBaaS (Database as a Service): Provides managed database services. Typical services: Amazon RDS, Google Cloud SQL, Azure SQL Database.
  • BaaS (Backend as a Service): Provides backend services for mobile and web applications. Typical services: Firebase, AWS Amplify.

1.4 Cloud Deployment Models

Based on resource ownership and scope of use, cloud computing is classified into the following deployment models:

  • Public Cloud: Owned and operated by a cloud provider; resources are made available to the public over the internet. Examples: AWS, Google Cloud, Azure.
  • Private Cloud: Exclusively used by a single organization; can be deployed in the organization's own data center or hosted by a third party. Examples: OpenStack, VMware vSphere.
  • Hybrid Cloud: A combination of public and private clouds, allowing data and applications to move between them.
  • Multi-Cloud: Using services from multiple public cloud providers simultaneously to avoid vendor lock-in.

2. Major Cloud Providers

2.1 AWS (Amazon Web Services)

The cloud provider with the largest global market share, offering the most comprehensive range of services.

  • Core compute services: EC2 (virtual machines), Lambda (serverless), ECS/EKS (containers)
  • Storage services: S3 (object storage), EBS (block storage), Glacier (archive storage)
  • Database services: RDS (relational), DynamoDB (NoSQL), ElastiCache (caching)
  • AI/ML services: SageMaker (machine learning platform), Bedrock (large model service)
  • Global infrastructure: 30+ Regions, 100+ Availability Zones
  • Free tier: 12-month free trial + Always Free tier (with usage limits on select services)

2.2 Google Cloud Platform (GCP)

Known for its strengths in data analytics and AI/ML, with deep integration into the Google ecosystem.

  • Core compute services: Compute Engine (virtual machines), Cloud Functions (serverless), GKE (Kubernetes)
  • Storage services: Cloud Storage (object storage), Persistent Disk (block storage)
  • Data analytics: BigQuery (data warehouse), Dataflow (stream processing), Pub/Sub (messaging)
  • AI/ML services: Vertex AI (machine learning platform), TPU (dedicated AI chips)
  • Free tier: $300 free trial credit (90 days) + Always Free tier
  • Highlights: One of the fastest global network infrastructures, native Kubernetes support

2.3 Microsoft Azure

Deeply integrated with the Microsoft ecosystem (Windows, Office 365, Active Directory).

  • Core compute services: Virtual Machines, Azure Functions, AKS (Kubernetes)
  • Enterprise services: Azure Active Directory (identity management), Microsoft 365 integration
  • AI/ML services: Azure OpenAI Service (GPT-series models), Azure Machine Learning
  • Hybrid cloud: Azure Arc (hybrid cloud management), Azure Stack (on-premises deployment)
  • Free tier: $200 free credit (30 days) + Always Free services

2.4 Oracle Cloud Infrastructure (OCI)

Known for its database services and enterprise applications, with a generous free tier.

  • Core compute services: Compute (virtual machines), Container Engine for Kubernetes
  • Database services: Autonomous Database (self-managing database — Oracle's core strength)
  • Always Free tier (permanently free, ideal for learning):
    • 2 AMD Compute instances (1/8 OCPU, 1 GB RAM)
    • Up to 4 Arm Compute instances (totaling 4 OCPU, 24 GB RAM — very generous)
    • 2 Autonomous Databases
    • 200 GB block storage, 10 GB object storage
  • Highlights: The most generous free tier among major cloud providers

2.5 Other Cloud Providers

  • Alibaba Cloud: The largest market share in China, well-suited for businesses targeting Chinese users
  • Tencent Cloud: Integrated with the WeChat ecosystem, strong in gaming and social scenarios
  • Huawei Cloud: Strong presence in government and enterprise markets
  • DigitalOcean: Developer-focused, clean interface, transparent pricing
  • Vultr / Linode: Cost-effective VPS providers

3. Cloud Network Architecture

Cloud networking is the foundation of cloud computing. Understanding cloud network architecture is essential for properly configuring and using cloud services.

3.1 Virtual Cloud Network (VCN / VPC)

Different cloud providers use different names for virtual networks:

  • Oracle Cloud: VCN (Virtual Cloud Network)
  • AWS / Google Cloud: VPC (Virtual Private Cloud)
  • Azure: VNet (Virtual Network)

They are fundamentally the same concept: a logically isolated private network space created in the cloud.

An intuitive analogy for the core concepts within a VCN/VPC:

Concept Full Name Analogy Description
VCN/VPC Virtual Cloud Network Company office building Your dedicated private network space in the cloud
Subnet Subnet Department areas within the building Logical partitions within the VCN, e.g., R&D, Marketing
Instance Instance A computer A virtual machine placed in a subnet
Internet Gateway Internet Gateway The building's main entrance The channel between the VCN and the public internet
NAT Gateway NAT Gateway The building's back door (exit only) Allows private subnets to access the internet while preventing inbound access
Route Table Route Table Directional signs in the building Defines traffic forwarding rules

3.2 Subnets

A subnet is a logical partition within a VCN, used to isolate different types of resources. Subnets come in two types:

Public Subnet

  • Instances in the subnet can be assigned public IP addresses
  • Communicates directly with the internet via the Internet Gateway
  • Suitable for web servers, load balancers, and other resources that need to be publicly accessible

Private Subnet

  • Instances in the subnet have no public IP and cannot be directly accessed from the internet
  • Can proactively access the internet (e.g., to download updates) through a NAT Gateway
  • Suitable for databases, application servers, and other resources that should not be publicly exposed
                    ┌─ Internet ─┐
                         │
                  ┌──────┴──────┐
                  │Internet GW  │
                  └──────┬──────┘
                         │
         ┌───────────────┼───────────────┐
         │          VCN / VPC            │
         │                               │
         │  ┌─────────────────────────┐  │
         │  │   Public Subnet         │  │
         │  │  ┌─────┐  ┌─────┐      │  │
         │  │  │Web  │  │LB   │      │  │
         │  │  └─────┘  └─────┘      │  │
         │  └─────────────────────────┘  │
         │                               │
         │  ┌─────────────────────────┐  │
         │  │   Private Subnet        │  │
         │  │  ┌─────┐  ┌─────┐      │  │
         │  │  │DB   │  │App  │      │  │
         │  │  └─────┘  └─────┘      │  │
         │  └─────────────────────────┘  │
         │                               │
         └───────────────────────────────┘

3.3 IP Addresses

Private IP

  • Used for communication within the VCN
  • Analogy: An internal employee ID or office number within a company
  • Follows the RFC 1918 private address ranges:
    • 10.0.0.0/8 (10.0.0.0 – 10.255.255.255)
    • 172.16.0.0/12 (172.16.0.0 – 172.31.255.255)
    • 192.168.0.0/16 (192.168.0.0 – 192.168.255.255)

Public IP

  • The address used to access an instance from the outside
  • Analogy: The street address of a company building
  • Comes in two types:
    • Ephemeral Public IP: Released when the instance is stopped; may change upon restart
    • Reserved Public IP: Not released even when the instance is stopped; can be reassigned to another instance

Elastic IP / Floating IP

  • AWS calls it Elastic IP; OpenStack calls it Floating IP
  • Same concept as Oracle Cloud's Reserved Public IP
  • Can be flexibly migrated between instances; suitable for scenarios requiring a fixed IP

The complete path for accessing an instance via a public IP:

User request → Public IP → Internet Gateway → Route Table → Subnet
→ Security Rules → Private IP → VNIC (Virtual NIC) → Instance

Steps to set up a Public IP (Oracle Cloud example):

  1. Search for Attached VNICs and locate the corresponding VNIC
  2. Go to IP Administration
  3. In the IP settings, select Reserved Public IP Address

3.4 CIDR and Subnet Design

CIDR (Classless Inter-Domain Routing) is an IP address allocation method that uses the notation IP/prefix length to represent a network range:

CIDR Notation Subnet Mask Available IPs Description
10.0.0.0/8 255.0.0.0 16,777,214 Very large network
10.0.0.0/16 255.255.0.0 65,534 Large network, commonly used for VCNs
10.0.0.0/24 255.255.255.0 254 Medium network, commonly used for subnets
10.0.0.0/28 255.255.255.240 14 Small network

When creating a VCN, you specify a CIDR block (e.g., 10.0.0.0/16), then carve out subnets within it (e.g., 10.0.1.0/24, 10.0.2.0/24).

3.5 Route Tables

A route table defines traffic forwarding rules. Each route rule contains:

  • Destination CIDR: The target network range the traffic is destined for
  • Target: The next hop to which the traffic should be forwarded

Common route rules:

Destination CIDR Target Description
0.0.0.0/0 Internet Gateway All external traffic goes through the internet gateway
10.0.0.0/16 Local Internal VCN traffic is routed locally
0.0.0.0/0 NAT Gateway Private subnet accesses the internet via NAT

3.6 DNS and Domain Names

Cloud services typically provide built-in DNS services:

  • Internal DNS: Instances within a VCN can reach each other by hostname
  • Public DNS: Resolves domain names to an instance's public IP

To allow users to access a cloud-hosted website via a domain name (e.g., www.example.com), you need to:

  1. Purchase a domain name (through a registrar such as GoDaddy, Cloudflare, Alibaba Cloud Wanwang, etc.)
  2. Add an A record in the DNS settings, pointing the domain to the instance's public IP
  3. (Optional) Use a CNAME record to point www.example.com to example.com

4. Security Mechanisms

Cloud security is a critically important topic. Cloud providers offer multiple layers of security mechanisms to protect resources.

4.1 Security Groups / Security Lists

Different cloud providers use different names:

  • AWS / Google Cloud / Azure: Security Group
  • Oracle Cloud: Security List + Network Security Group (NSG)

Security groups / security lists are essentially virtual firewalls that control network traffic flowing in and out of instances.

Ingress Rules: Control which external traffic is allowed to reach an instance.

Port Protocol Purpose Security Recommendation
22 TCP SSH remote login Restrict to your own IP; do not open to 0.0.0.0/0
80 TCP HTTP web access Can be opened to everyone
443 TCP HTTPS encrypted web access Can be opened to everyone
3306 TCP MySQL database Internal network only; do not expose publicly
5432 TCP PostgreSQL database Internal network only
6379 TCP Redis cache Internal network only
8080 TCP Common application port Decide based on requirements
3389 TCP Windows Remote Desktop (RDP) Restrict to your own IP

Egress Rules: Control outbound traffic from an instance. The default (allow all outbound) is usually sufficient.

Configuration path (Oracle Cloud): VCN Settings → Security → Open the corresponding VCN → Rules

Security best practices:

  • Principle of least privilege: Only open the ports you need
  • Restrict source IPs: Management ports such as SSH should be restricted to specific IPs, not 0.0.0.0/0 (open to all)
  • Use NSGs over Security Lists: NSGs can be attached to specific instances for finer granularity
  • Review rules regularly: Remove rules that are no longer needed

4.2 SSH Key Authentication

Cloud instances typically use SSH key pairs for authentication, which is more secure than password-based login.

How key pairs work:

  1. Generate a key pair: a public key and a private key
  2. Place the public key on the server (~/.ssh/authorized_keys)
  3. Keep the private key locally; it is used for identity verification when connecting
  4. The server uses the public key to verify the client's private key signature; if they match, login is permitted
Local Machine                      Cloud Instance
┌──────────┐                    ┌──────────┐
│ Private  │  ── SSH conn ──→  │ Public   │
│ Key      │  ← Verified  ──   │ Key      │
│ (key)    │                    │ (lock)   │
└──────────┘                    └──────────┘

Generating an SSH key pair:

# Generate an ED25519 key pair (recommended — more secure and faster)
ssh-keygen -t ed25519 -C "your_email@example.com"

# Or generate an RSA key pair (better compatibility)
ssh-keygen -t rsa -b 4096 -C "your_email@example.com"

This produces two files:

  • ~/.ssh/id_ed25519: The private key (must never be disclosed)
  • ~/.ssh/id_ed25519.pub: The public key (safe to distribute)

Private key security:

  • The private key file permissions must be set to 600 (owner read/write only): chmod 600 ~/.ssh/id_ed25519
  • Do not transmit private keys over insecure channels
  • It is recommended to set a passphrase for the private key

4.3 IAM (Identity and Access Management)

IAM is the cloud platform's identity and access management system, controlling who can perform what actions on which resources.

Core concepts:

  • User: The identity of a person or an application
  • Group: A collection of users, making it easier to manage permissions in bulk
  • Role: A set of permissions that can be assigned to users, groups, or services
  • Policy: A rule defining permissions, describing which actions are allowed or denied

Best practices:

  • Do not use the root account for day-to-day operations
  • Create a separate IAM account for each user
  • Use groups to manage permissions rather than assigning them directly to users
  • Enable multi-factor authentication (MFA)
  • Rotate access keys regularly

4.4 Other Security Mechanisms

  • WAF (Web Application Firewall): Protects web applications from attacks such as SQL injection and XSS
  • DDoS Protection: Services like AWS Shield and Google Cloud Armor defend against distributed denial-of-service attacks
  • Encryption:
    • Encryption in transit (TLS/SSL): Protects data during network transmission
    • Encryption at rest: Protects data stored on disk
  • VPN (Virtual Private Network): Securely connects on-premises networks to cloud networks via encrypted tunnels
  • Audit Logs: Record all API calls and resource changes, e.g., AWS CloudTrail, Google Cloud Audit Logs

5. Compute Services

5.1 Virtual Machine Instances

Virtual machines are the most fundamental cloud computing service. When creating an instance, you need to select the following configurations:

Instance Shape / Instance Type

Resource Description Examples
vCPU Number of virtual CPU cores 1, 2, 4, 8, 16...
Memory RAM size 1 GB, 4 GB, 16 GB...
Architecture CPU architecture x86 (AMD/Intel) or ARM (Ampere)

ARM architecture (such as Oracle Cloud's Ampere A1) typically offers better cost-performance and provides more resources in the Always Free tier.

Operating System Image

  • Linux distributions: Ubuntu, CentOS, Oracle Linux, Debian, Amazon Linux
  • Windows Server: Requires additional licensing fees
  • Custom images: You can create custom images from existing instances for batch deployment

Storage

  • Boot Volume: The disk where the operating system is installed, typically starting at 50 GB
  • Block Volume: Additional disks that can be attached, similar to an external USB hard drive
  • Object Storage: Stores files and unstructured data, accessed via API

5.2 Instance Lifecycle

Provisioning → Running → Stopped → Terminated
                  ↑          │
                  └── Start ─┘
  • Running: The instance is active and billed based on uptime
  • Stopped: The instance is halted; compute charges stop (storage charges still apply)
  • Terminated: The instance is permanently deleted and all data is lost (unless backed up)

5.3 Containers and Kubernetes

Containers are a more lightweight compute unit than virtual machines:

  • Container: Packages an application along with its dependencies, ensuring consistent execution across any environment
  • Docker: The most popular container runtime
  • Kubernetes (K8s): A container orchestration platform that automates deployment, scaling, and failure recovery

Managed Kubernetes services by cloud provider:

Cloud Provider Managed K8s Service
AWS EKS (Elastic Kubernetes Service)
Google Cloud GKE (Google Kubernetes Engine)
Azure AKS (Azure Kubernetes Service)
Oracle Cloud OKE (Oracle Container Engine)

5.4 Serverless Computing

Serverless does not mean there are no servers — it means users do not need to manage servers. Users simply write function code, and the platform automatically allocates resources and handles execution.

Key characteristics:

  • Pay per invocation: No charges when not in use
  • Automatic scaling: Instances scale up or down automatically based on request volume
  • No operations overhead: No need to manage the operating system or runtime
  • Cold start issue: If a function has not been invoked for a while, the first request may experience latency

6. Storage Services

6.1 Storage Type Comparison

Type Characteristics Use Cases Cloud Service Examples
Block Storage Low latency, high performance, attached to instances Databases, OS disks EBS, Persistent Disk
Object Storage Unlimited scalability, HTTP access Files, images, backups, static websites S3, Cloud Storage
File Storage Shared file system, NFS protocol Shared files across multiple instances EFS, Cloud Filestore
Archive Storage Extremely low cost, slower retrieval Compliance data, long-term backups Glacier, Archive Storage

6.2 Object Storage

Object storage is the most commonly used storage method in the cloud. Each object consists of:

  • Data: The file content itself
  • Metadata: Descriptive information about the file (size, type, creation time, etc.)
  • Key: The unique identifier / access path for the object

Object storage organizes data in Buckets, analogous to top-level directories in a file system.

# Common AWS S3 operations
aws s3 ls                           # List all Buckets
aws s3 cp file.txt s3://my-bucket/  # Upload a file
aws s3 sync ./local s3://my-bucket/ # Sync a directory

7. Remote Access and Management

7.1 SSH Connection

Basic SSH connection command:

# General SSH connection
ssh -i /path/to/private_key username@public_ip

# Oracle Cloud (Ubuntu instance)
ssh -i ~/.ssh/oracle_key.key ubuntu@129.xxx.xxx.xxx

# Oracle Cloud (Oracle Linux instance)
ssh -i ~/.ssh/oracle_key.key opc@129.xxx.xxx.xxx

Google Cloud SSH connection:

# Using gcloud CLI (recommended — automatically manages keys)
gcloud compute ssh --zone "us-east1-c" "instance-name" --project "project-id"

SSH config file (~/.ssh/config):

Simplify connection commands with a config file:

Host my-oracle-server
    HostName 129.xxx.xxx.xxx
    User ubuntu
    IdentityFile ~/.ssh/oracle_key.key
    Port 22

Host my-gcp-server
    HostName 35.xxx.xxx.xxx
    User username
    IdentityFile ~/.ssh/google_compute_engine
    Port 22

After configuration, simply run ssh my-oracle-server to connect.

7.2 VS Code Remote Connection

VS Code provides an excellent remote development experience:

  1. Install the Remote - SSH extension
  2. Click the green icon >< in the lower-left corner (Open a Remote Window)
  3. Select "Connect to Host..."
  4. Choose the desired host from the list (read from ~/.ssh/config)
  5. Once connected, VS Code operates on the remote server as if it were local

7.3 SCP File Transfer

Use SCP (Secure Copy Protocol) to transfer files between your local machine and a cloud instance:

# Upload a file to the cloud instance
scp -i ~/.ssh/key.pem local_file.txt ubuntu@public_ip:/home/ubuntu/

# Download a file from the cloud instance
scp -i ~/.ssh/key.pem ubuntu@public_ip:/home/ubuntu/remote_file.txt ./

# Upload an entire directory
scp -r -i ~/.ssh/key.pem ./local_dir ubuntu@public_ip:/home/ubuntu/

7.4 Cloud Platform CLI Tools

Each cloud provider offers a command-line tool:

Cloud Provider CLI Tool Installation
AWS aws pip install awscli
Google Cloud gcloud Google Cloud SDK
Azure az pip install azure-cli
Oracle Cloud oci pip install oci-cli

8. Web Server Deployment

Deploying a website on a cloud instance is one of the most common introductory exercises.

8.1 Web Server Software

A web server receives HTTP requests and returns web page content. Common web server software:

Software Features Use Cases
Nginx High performance, low memory footprint, reverse proxy Static websites, reverse proxy, load balancing
Apache Feature-rich, modular Traditional web applications, .htaccess support
Caddy Automatic HTTPS, simple configuration Small websites, automatic certificate management

8.2 Nginx Deployment in Practice

Installing Nginx:

# Ubuntu / Debian
sudo apt update
sudo apt install nginx

# CentOS / Oracle Linux
sudo yum install nginx

Starting and managing:

sudo systemctl start nginx    # Start
sudo systemctl stop nginx     # Stop
sudo systemctl restart nginx  # Restart
sudo systemctl enable nginx   # Enable on boot
sudo systemctl status nginx   # Check status

Configuration file structure:

/etc/nginx/
├── nginx.conf              # Main configuration file
├── sites-available/        # Available site configurations
│   └── default             # Default site
├── sites-enabled/          # Enabled sites (symlinks)
│   └── default → ../sites-available/default
└── conf.d/                 # Additional configuration files

Default web root directory: /var/www/html/

Creating a web page file:

sudo nano /var/www/html/index.html

<!DOCTYPE html>
<html lang="zh-CN">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>My Cloud Website</title>
</head>
<body>
    <h1>Hello from Cloud!</h1>
    <p>这是部署在云服务器上的网站。</p>
</body>
</html>

8.3 Configuring a Reverse Proxy

If an application is running on the cloud instance (e.g., Node.js on port 3000), Nginx can be used as a reverse proxy:

server {
    listen 80;
    server_name example.com;

    location / {
        proxy_pass http://localhost:3000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }
}

8.4 HTTPS Configuration (Let's Encrypt)

Use Certbot to obtain a free SSL certificate:

# Install Certbot
sudo apt install certbot python3-certbot-nginx

# Automatically obtain a certificate and configure Nginx
sudo certbot --nginx -d example.com -d www.example.com

# Test automatic certificate renewal (Certbot sets up a cron job automatically)
sudo certbot renew --dry-run

8.5 Deployment Checklist

After deployment, verify the following:

  • [ ] Security group / security list has ports 80 (HTTP) and 443 (HTTPS) open
  • [ ] Web server is running and enabled to start on boot
  • [ ] Firewall (e.g., iptables, firewalld) allows traffic on the corresponding ports
  • [ ] The website is accessible in a browser via the public IP
  • [ ] (Optional) Domain name DNS resolution is configured
  • [ ] (Optional) HTTPS certificate is configured

9. Regions and Availability Zones

9.1 Regions

A region is a cluster of data centers deployed by a cloud provider at a specific geographic location. When choosing a region, consider:

  • Latency: Choose the region closest to your users to minimize network latency
  • Compliance: Some data must be stored in specific countries or regions (e.g., GDPR requires EU data to remain in the EU)
  • Service availability: Not all services are available in every region
  • Pricing: Prices may vary across regions

9.2 Availability Zones (AZ)

Each region contains multiple availability zones. Each AZ is an independent data center (or cluster of data centers) with its own power, networking, and cooling systems.

  • AZs within the same region are connected by high-speed, low-latency networks
  • Distributing resources across multiple AZs achieves high availability (a failure in one AZ does not affect the others)
Region: us-east-1 (US East)
├── AZ: us-east-1a  ← Data Center A
├── AZ: us-east-1b  ← Data Center B
└── AZ: us-east-1c  ← Data Center C

10. High Availability and Auto Scaling

10.1 Load Balancing

A load balancer distributes traffic across multiple backend instances to achieve high availability and horizontal scaling:

  • Layer 4 Load Balancing (TCP/UDP): Forwards based on IP and port; high performance
  • Layer 7 Load Balancing (HTTP/HTTPS): Forwards based on URL, headers, and other content; feature-rich
                 User Request
                    │
             ┌──────┴──────┐
             │ Load Balancer│
             └──────┬──────┘
            ┌───────┼───────┐
            ↓       ↓       ↓
        Instance  Instance  Instance
         (AZ-a)   (AZ-b)    (AZ-c)

10.2 Auto Scaling

Automatically increases or decreases the number of instances based on load:

  • Scale-out policy: Add instances when CPU utilization exceeds 70%
  • Scale-in policy: Remove instances when CPU utilization drops below 30%
  • Min/Max instance count: Set upper and lower bounds for scaling

10.3 High Availability Architecture Design

A typical highly available web application architecture:

                        User
                         │
                    ┌────┴────┐
                    │  CDN    │  ← Static resource caching
                    └────┬────┘
                         │
                    ┌────┴────┐
                    │   WAF   │  ← Web Application Firewall
                    └────┬────┘
                         │
                    ┌────┴────┐
                    │   LB    │  ← Load Balancer
                    └────┬────┘
                   ┌─────┼─────┐
                   ↓     ↓     ↓
                 Web   Web   Web    ← Stateless web servers (multi-AZ)
                   │     │     │
                   └─────┼─────┘
                         ↓
                    ┌────┴────┐
                    │  Cache  │  ← Redis / Memcached
                    └────┬────┘
                         ↓
                    ┌────┴────┐
                    │   DB    │  ← Primary-replica database (multi-AZ)
                    │ Primary │
                    │    ↓    │
                    │ Replica │
                    └─────────┘

11. Billing and Cost Optimization

11.1 Billing Models

Model Description Discount Use Cases
On-demand Billed per hour/second, start and stop anytime None Short-term tasks, test environments
Reserved Instances Prepay for 1–3 years 30%–60% Long-running, stable services
Spot Instances Use idle resources; may be reclaimed at any time 60%–90% Interruptible batch processing tasks
Free Tier Specific resources available at no cost 100% Learning, small projects

11.2 Cost Optimization Tips

  • Take advantage of free tiers: Oracle Cloud's Always Free tier is the most generous
  • Choose the right instance size: Avoid over-provisioning; select based on actual needs
  • Use spot instances: Ideal for interruptible training jobs or batch processing
  • Set up budget alerts: Avoid unexpected large bills
  • Clean up resources promptly: Delete unused instances, storage, and snapshots
  • Leverage auto scaling: Dynamically adjust instance counts based on load
  • Choose the right storage tier: Use archive storage for infrequently accessed data

12. Cloud Practice: Getting Started with Oracle Cloud

Below is a complete walkthrough for setting up a web server from scratch on Oracle Cloud:

Step 1: Create a VCN

  1. Log in to the Oracle Cloud Console
  2. Search for "Virtual Cloud Networks" and click Create
  3. Select "Start VCN Wizard" → "Create VCN with Internet Connectivity"
  4. Set the VCN name and CIDR block (the default 10.0.0.0/16 works fine)
  5. The wizard will automatically create a public subnet, private subnet, Internet Gateway, NAT Gateway, route tables, and security lists

Step 2: Configure the Security List

  1. Go to VCN → Security Lists → Default Security List
  2. Add Ingress Rules:
    • Port 22 (SSH): Set Source CIDR to your IP (e.g., 123.45.67.89/32)
    • Port 80 (HTTP): Set Source CIDR to 0.0.0.0/0
    • Port 443 (HTTPS): Set Source CIDR to 0.0.0.0/0

Step 3: Create an Instance

  1. Search for "Instances" and click Create
  2. Select a Shape (the Always Free Ampere A1 is recommended — up to 4 OCPU + 24 GB RAM)
  3. Select an operating system image (Ubuntu recommended)
  4. Select the VCN and public subnet
  5. Upload or generate an SSH public key
  6. Download the private key file (.key) and store it securely

Step 4: Assign a Public IP

  1. Go to Instance Details → Attached VNICs → click the VNIC
  2. Go to IPv4 Addresses
  3. Edit and select "Reserved Public IP"

Step 5: SSH Connection

# Set private key permissions
chmod 600 ~/oracle_key.key

# Connect to the instance
ssh -i ~/oracle_key.key ubuntu@<public_ip>

Step 6: Deploy the Web Server

# Update the system
sudo apt update && sudo apt upgrade -y

# Install Nginx
sudo apt install nginx -y

# Start and enable on boot
sudo systemctl start nginx
sudo systemctl enable nginx

# Open firewall ports (Ubuntu iptables)
sudo iptables -I INPUT 6 -m state --state NEW -p tcp --dport 80 -j ACCEPT
sudo iptables -I INPUT 6 -m state --state NEW -p tcp --dport 443 -j ACCEPT
sudo netfilter-persistent save

Step 7: Verify

Open http://<public_ip> in your browser. If you see the Nginx welcome page, the deployment was successful.

Relations to Other Topics

  • See System Design for how cloud resources support availability, elasticity, and multi-tier architecture
  • See Distributed Systems for replication, messaging, elasticity, and fault tolerance in cloud environments
  • See Version Control and CI/CD for image build, deployment pipeline, and infrastructure automation
  • See IoT Systems for the coordination between devices, edge nodes, and cloud platforms

References

评论 #