Cloud Computing

Five NIST Essential Characteristics:

1. On-Demand Self-Service: Consumers provision computing capabilities automatically without requiring human interaction with service providers.
2. Broad Network Access: Capabilities are available over the network and accessed through standard mechanisms (phones, tablets, laptops).
3. Resource Pooling: Multi-tenant physical and virtual resources dynamically assigned according to demand.
4. Rapid Elasticity: Capabilities provisioned and released elastically to scale outward or inward commensurate with demand.
5. Measured Service: Resource usage monitored, controlled, and billed transparently based on actual consumption (pay-as-you-go).

Type-1 vs. Type-2 Hypervisors:

• Type-1 (Bare-Metal): Runs directly on the host server’s physical hardware without any underlying host operating system (e.g. VMware ESXi, Microsoft Hyper-V, KVM). Delivers superior performance, enterprise stability, and direct I/O control.
• Type-2 (Hosted): Runs as an application layer on top of a conventional host operating system (e.g. Oracle VirtualBox, VMware Workstation). Slower performance due to OS overhead; used primarily for local developer workstations.

Shared Responsibility Model:

A security framework dividing operational security between the Cloud Service Provider (CSP) and the customer:

• Security OF the Cloud (CSP Responsibility): Physical security of data centers, host hardware, virtualization hypervisors, and global network infrastructure.
• Security IN the Cloud (Customer Responsibility): Customer data encryption, Identity & Access Management (IAM), guest OS patching (in IaaS), network firewall rules, and application logic.

Security Groups vs. NACLs:

• Security Group: Operates at the instance (ENI) level; Stateful (return traffic is automatically allowed regardless of inbound rules); supports Allow rules only; evaluates all rules before deciding.
• NACL: Operates at the subnet level; Stateless (outbound return traffic must be explicitly permitted); supports both Allow and Deny rules; evaluates rules in numbered numerical order.

Serverless Computing (Function-as-a-Service - FaaS):

An execution model where the cloud provider dynamically manages the allocation and provisioning of server compute infrastructure to run discrete event-driven blocks of code (e.g. AWS Lambda, Google Cloud Functions).

• Benefits:
  1. Zero Server Management: No OS configuration, patching, or scaling group administration.
  2. True Pay-per-Execution: Billing is calculated strictly per millisecond of compute runtime; zero cost when idle.

Cloud Service Models Comparison:

Kubernetes Architecture:

1. Control Plane (Master Node Components):

   • kube-apiserver: Central gateway exposing the RESTful Kubernetes API; intercepts and authenticates all cluster commands.
   • etcd: Distributed, consistent key-value store containing cluster configuration and state.
   • kube-scheduler: Watches newly created Pods and assigns them to optimal worker nodes based on resource capacity and constraints.
   • kube-controller-manager: Runs controller loops (Node controller, Deployment controller, ReplicaSet controller) to ensure actual state matches desired state.

2. Worker Node Components:

   • kubelet: Agent running on each node ensuring that containers are running inside Pods as specified.
   • kube-proxy: Manages network routing rules on nodes, enabling service abstraction and Pod-to-Pod communication across subnets.
   • Container Runtime (Containerd / CRI-O): Underlying software executing container images.

Cloud Storage Comparison:

1. Block Storage (AWS EBS):

   • Stores data in fixed raw blocks with no metadata; accessible only when mounted to a single operating system instance as a virtual hard drive.
   • Performance: Ultra-low latency, high IOPS; ideal for relational database files (PostgreSQL/MySQL) and OS boot volumes.

2. Object Storage (AWS S3):

   • Stores unstructured data as distinct objects (Data + Custom Metadata + Globally Unique Key) in a flat namespace accessed via HTTP REST APIs.
   • Performance: Massive petabyte scalability, 99.999999999% (11 9s) durability; ideal for static web assets, video streaming media, backups, and data lake archives.

3. File Storage (AWS EFS / NFS):

   • Traditional hierarchical folder and file directory system supporting POSIX file permissions.
   • Performance: Elastic shared storage concurrently accessible by hundreds of compute nodes; ideal for shared web application media and container persistent volumes.

Auto Scaling & Elastic Load Balancing (ELB) Synergy:

• Elastic Load Balancer (ELB): Automatically distributes incoming application network traffic evenly across a dynamic pool of backend compute instances in multiple Availability Zones, performing automated health checks and routing around unhealthy instances.
• Auto Scaling Group (ASG): Monitors operational metrics (e.g. CPU utilization $> 75\%$, request counts) via cloud alarms and dynamically adjusts the number of active server instances between configured minimum and maximum limits.

How They Work Together:

1. When traffic surges, average CPU exceeds thresholds; ASG launches new compute instances automatically.
2. The ASG registers these newly launched instances with the Load Balancer target group.
3. The Load Balancer starts routing traffic to the expanded fleet once health checks pass.
4. When traffic subsides, ASG terminates surplus instances, ensuring high availability under load while minimizing cloud infrastructure expenditure during off-peak hours.

Disaster Recovery Strategies:

FinOps (Cloud Financial Operations):

An evolving cultural discipline and cloud management practice that combines engineering, finance, and business teams to drive financial accountability and maximize business value from variable cloud expenditure.

Three Enterprise Cost Optimization Strategies:

1. Rightsizing Compute Instances: Continuously analyzing utilization metrics (AWS Compute Optimizer) to downsize over-provisioned virtual machine instances and migrate idle development servers to automated shutdown schedules outside business hours.
2. Commitment Discounts (Savings Plans & Reserved Instances): Committing to steady-state baseline usage for 1- or 3-year periods to achieve discounts of up to 60-72% compared to on-demand pricing.
3. Storage Lifecycle Management: Configuring automated bucket lifecycle policies on S3 to transition cold data from Standard to Infrequent Access (S3-IA) and eventually to Glacier Deep Archive, slashing long-term storage costs by up to 90%.

(a) 3-Tier Multi-AZ Architecture:

• Tier 1 - Presentation (Web) Tier: Public Subnets across Availability Zones AZ-1a and AZ-1b. Hosts an Application Load Balancer (ALB) and public bastion hosts / NAT Gateways. Direct public internet access.
• Tier 2 - Application Tier: Private Subnets across AZ-1a and AZ-1b. Hosts auto-scaled microservices containerized inside ECS/EKS clusters or EC2 instances. Accessible only via requests routed through the Web ALB.
• Tier 3 - Data (Database) Tier: Isolated Database Subnets across AZ-1a and AZ-1b. Hosts Amazon Aurora Multi-AZ MySQL/PostgreSQL with primary read-write replica in AZ-1a and synchronous standby replica in AZ-1b. Zero internet routing.

---

(b) VPC CIDR Network Topology:

• VPC CIDR Block: 10.0.0.0/16 (65,536 private IP addresses).
• Public Subnet AZ-1a (10.0.1.0/24) & AZ-1b (10.0.2.0/24): Route table routes 0.0.0.0/0 to Internet Gateway (igw-xxxx).
• Private App Subnet AZ-1a (10.0.11.0/24) & AZ-1b (10.0.12.0/24): Route table routes 0.0.0.0/0 outbound through NAT Gateways located in Public Subnets for secure software package updates.
• Isolated DB Subnet AZ-1a (10.0.21.0/24) & AZ-1b (10.0.22.0/24): Route table contains local VPC routes only (10.0.0.0/16 $\rightarrow$ local).

---

(c) Defense-in-Depth Security Controls:

1. Perimeter Edge: AWS WAF inspects inbound HTTPS traffic for OWASP Top 10 vulnerabilities (SQLi, XSS) and rate-limits volumetric DDoS attacks with AWS Shield.
2. Network Segmentation via Security Groups:
   • ALB SG: Inbound HTTPS (Port 443) allowed from 0.0.0.0/0.
   • App SG: Inbound HTTP (Port 8080) allowed ONLY from ALB SG.
   • DB SG: Inbound MySQL (Port 3306) allowed ONLY from App SG.
3. Data Protection: All EBS volumes, Aurora DB storage, and S3 audit logs encrypted at rest using customer-managed keys in AWS KMS (AES-256). In-transit encryption enforced via TLS 1.3.
4. Least Privilege IAM: Applications leverage IAM Roles with temporary STS credentials; zero long-term access keys stored in application source code.

---

(d) High-Availability Failover Mechanism:

• If primary compute instance in AZ-1a experiences physical hardware degradation, ALB health checks fail and traffic automatically shifts to healthy instances in AZ-1b within 5 seconds.
• If primary Aurora DB crashes, Amazon Aurora executes automatic synchronous failover to the standby replica in AZ-1b within 30 seconds without data loss (RPO = 0), updating DB cluster DNS endpoints transparently.

1. The ‘6 Rs’ Cloud Migration Framework (Gartner / AWS):

1. Rehost (Lift and Shift): Moving applications from on-premise to cloud virtual machines without modifying underlying code or architecture. Fastest migration with minimal risk.
2. Replatform (Lift, Tinker, and Shift): Making targeted optimizations (e.g. migrating self-hosted MySQL to managed Amazon RDS) without changing core application logic.
3. Repurchase (Drop and Shop): Decommissioning legacy software and replacing it with modern SaaS solutions (e.g. replacing on-premise CRM with Salesforce).
4. Refactor / Re-architect: Completely rewriting application codebase into cloud-native microservices, containers, and serverless architectures to exploit maximum elasticity.
5. Retain (Revisit): Keeping applications on-premise due to regulatory, data sovereignty, or deprecation reasons.
6. Retire: Identifying and shutting down redundant, obsolete servers and databases.

---

2. Phase-by-Phase Enterprise Migration Roadmap:

1. Phase 1: Assessment & Discovery: Inventory all physical servers, network dependencies, application configurations, and database sizes using tools like AWS Application Discovery Service.
2. Phase 2: Cloud Foundation & Landing Zone Setup: Configure multi-account AWS Organizations, transit gateways, consolidated billing, and IAM identity federation with corporate Active Directory.
3. Phase 3: Migration Pilot: Execute a low-risk pilot migration (e.g. secondary internal reporting service) using AWS Application Migration Service (MGN) to test migration automation.
4. Phase 4: Database & Core Workload Cutover: Replicate on-premise databases to cloud RDS instances in near real-time using AWS Database Migration Service (DMS). Execute final application DNS cutover during scheduled off-peak maintenance windows.
5. Phase 5: Cloud Optimization & Modernization: Transition from VM-based hosting to Docker containers managed by EKS, adopting automated FinOps governance.

---

3. Data Residency and Compliance under Nepalese Law:

• Nepal Rastra Bank (NRB) IT Guidelines: BFIs are required to maintain core customer transaction records and identifiable data within the territorial boundaries of Nepal, or establish localized mirrored failovers.
• Privacy Act 2075 & National Cyber Security Policy 2080: Critical national information infrastructure (banking, citizen biometric records) must not be transferred outside Nepal without explicit statutory approval.
• Hybrid Cloud Solution: Deploy a hybrid architecture where customer PII and core transactional databases reside on-premise in local Tier-III data centers in Nepal, while stateless compute engines, analytical dashboards, and global web applications leverage the scalability of international public clouds.