What is cloud computing?
Cloud computing delivers computing resources—servers, storage, databases, networking, software, and analytics—over the Internet on demand. Instead of keeping files and programs only on a local hard drive, users and organizations store and run them on remote servers (the “cloud”) and access them through a network connection. This model shifts responsibility for maintaining physical infrastructure from the user to a cloud provider and enables access from any Internet-connected device.
How cloud data is managed and stored
Cloud providers run large pools of servers in data centers. Data is stored on those remote machines and served to users when requested. Providers handle backups, replication, and scaling so applications can expand or shrink capacity quickly. This remote model reduces the need for local storage and lets organizations update software centrally rather than distributing discs or USB drives.
Types of cloud deployment
– Public cloud: Services are offered over the Internet to anyone who subscribes or pays. Resources are shared among multiple customers.
– Private cloud: Infrastructure is dedicated to a single organization and typically restricted to approved users.
– Hybrid cloud: A combination that connects private and public clouds, letting organizations keep some data on-premises while using public services for other workloads.
Core service models (definitions)
– Software as a Service (SaaS): Software delivered over the Internet. Users run applications in a web browser or thin client while the vendor operates the underlying infrastructure and software. Examples: email and web-based productivity tools.
– Infrastructure as a Service (IaaS): Basic building blocks such as virtual machines, storage, and networking are provided so customers can install and run arbitrary software. Customers control the OS and applications; the provider maintains the hardware.
– Platform as a Service (PaaS): A managed platform for developing, testing, and deploying applications. The vendor manages the runtime environment and developer tools while the customer supplies application code.
Common uses and examples
– Personal file storage and backup (e.g., Google Drive, Dropbox, OneDrive, Box).
– Streaming media, where media files reside on remote servers and stream to devices.
– Enterprise applications and analytics.
– Real-time services such as fraud detection—Amazon Web Services (AWS) is an example provider used for such workloads.
Security and risks
Cloud security refers to measures that protect data and services hosted in the cloud. Common protections include two-factor authentication (2FA), virtual private networks (VPNs), security tokens, encryption of data at rest and in transit, and firewalls. Risks include system outages, software bugs, natural disasters affecting data centers, and the possibility that a single user error can propagate across shared systems.
What is cloud hacking?
Cloud hacking is any cyberattack aimed at cloud-hosted platforms, services, or data. Attackers may try to steal credentials, exploit misconfigurations, or compromise the provider’s systems to access customer data. Security practices and regulations aim to reduce these risks, but no system is perfectly immune.
Pros and cons (high level)
Pros:
– Lower upfront capital expense; pay-as-you-go pricing.
– Faster deployment and scalability.
– Reduced need for on-site infrastructure and maintenance.
– Centralized software updates and easier collaboration.
Cons:
– Ongoing security and compliance responsibilities.
– Dependency on network connectivity and provider reliability.
– Potential data residency and regulatory constraints.
– Risk of outages or cascading errors.
Leading providers (examples)
– Amazon Web Services (AWS): Widely used public cloud platform with many services and a pay-as-you-go model.
– Microsoft Azure: Offers public cloud services and options to keep some data on-premises.
– Alibaba Cloud: Provider within Alibaba Group, offering public cloud solutions in various regions.
Checklist for evaluating a cloud provider (quick)
– Data residency and compliance: Does the provider meet regulatory requirements for your data?
– Security features: Does it support encryption, 2FA, identity management, and auditing?
– Pricing model: Pay-as-you-go, reserved capacity, or subscription—how does that fit your budget?
– Reliability and SLAs: Uptime guarantees and historical performance.
– Scalability: How easily can you expand or reduce resources?
– Integration: Can it connect with your existing systems and applications?
– Support and documentation: Is technical support available at the needed level?
– Exit strategy: How easy is it to migrate data and workloads away?
Worked numeric example (hypothetical pay-as-you-go storage)
Assume a cloud provider charges $0.02 per GB per month (this is an illustrative, hypothetical price; actual rates vary by provider and region).
– Monthly cost for 500 GB: 500 GB × $0.02/GB = $10.00 per month.
– Annual cost for 500 GB: $10.00 × 12 = $120.00 per year.
– Monthly cost for 2 TB (2,000 GB): 2,000 × $0.02 = $40.00 per month; annually = $480.00.
Use this type of calculation to compare providers, remembering to include other potential fees (egress/data transfer, snapshots, access requests).
Bottom line
Cloud computing replaces local infrastructure with remotely hosted services that offer scale, flexibility, and centralized management. It suits many personal and business needs but requires careful attention to security, compliance, cost structure, and reliability. Evaluate
Evaluate the following factors when choosing and operating cloud services:
Checklist for evaluating cloud providers
– Workload fit. Classify each application by sensitivity to latency, statefulness, scaling pattern (steady vs. spiky), and compliance needs. Use that to decide IaaS (infrastructure as a service), PaaS (platform as a service), or SaaS (software as a service).
– Cost structure. Compare on a total-cost-of-ownership (TCO) basis including compute, storage, egress (outbound data transfer), licensing, support, and management. Don’t focus only on list prices—model realistic utilization and discounts (reserved capacity, committed use, spot/interruptible instances).
– Security and compliance. Check provider certifications (eg, ISO 27001, SOC 2), encryption options, identity and access management (IAM), and data residency controls.
– Reliability and SLAs. Review service-level agreements for uptime, what counts as downtime, and the remedies (service credits). Evaluate historical outage reports and architecture for fault domains/regions.
– Ecosystem and support. Look at managed services, partner tools, marketplace, developer experience, and available professional support levels.
– Exit strategy and lock-in. Understand data export formats, egress costs, and how hard it is to migrate away (APIs, proprietary services).
– Networking and latency. Evaluate region placement, peering options, direct-connect equivalents, and edge/CDN capabilities.
Basic cost formulas and worked example
– Monthly cost (approx) = compute_cost + storage_cost + egress_cost + licensing + support + management.
– Compute_cost = sum(instance_hours × hourly_rate) across instances.
– Storage_cost = average_storage_GB × storage_rate_per_GB.
– Egress_cost = egress_GB × egress_rate_per_GB.
Worked numeric example (hypothetical)
– One small web service running continuously on one instance for a month (720 hours) at $0.05/hour: compute = 720 × $0.05 = $36.00.
– Storage average 500 GB at $0.02/GB/month: storage = 500 × $0.02 = $10.00.
– Outbound data 200 GB at $0.09/GB: egress = 200 × $0.09 = $18.00.
– Monthly subtotal = $36 + $10 + $18 = $64. Add support/managed services (say $20) → total ≈ $84/month.
Note: Replace these illustrative unit prices with actual provider rates and include any minimums, snapshot costs, or API request charges.
Security and compliance checklist (practical steps)
– Inventory sensitive data and map to provider regions that meet data residency rules.
– Apply least-privilege IAM roles; enable multi-factor authentication for all privileged users.
– Encrypt data at rest and in transit; manage keys with a hardware security module (HSM) or cloud KMS (key management service) depending on control needs.
– Automate vulnerability scanning and patch management.
– Log and centralize audit trails; set retention consistent with compliance.
– Define incident-response runbooks that include provider contact/communication channels.
Migration steps (high level)
1. Discover and classify workloads and dependencies.
2. Estimate costs and define success metrics (performance, cost, compliance).
3. Choose a migration pattern: rehost (lift-and-shift), replatform (lift-tinker-and-shift), refactor, rebuild, or replace (SaaS).
4. Pilot with noncritical workloads; validate performance and monitoring.
5. Cut over in phases; run rollback plans.
6. Optimize after migration (rightsizing, committed discounts, autoscaling).
Operational best practices
– Tag resources for cost allocation and governance; enforce budgets and alerts.
– Use autoscaling for variable workloads; use reserved/committed pricing for steady-state capacity.
– Implement backups and a tested disaster-recovery (DR) plan; rehearse restores.
– Monitor costs, performance, and security with centralized dashboards and alerts.
– Regularly review architecture for single points of failure and consider multi-region replication where required.
Workload placement examples (rules of thumb)
– Latency-sensitive user-facing apps: deploy close to user populations or on edge/CDN.
– Large-scale batch jobs: consider spot/interruptible instances for cost savings and tolerate interruptions.
– Regulated or legacy apps with low change tolerance: consider private/hybrid cloud or managed hosting.
– Databases with high data gravity (large datasets): be mindful of egress charges when separating compute and storage across providers.
Multi-cloud and hybrid considerations
– Use multi-cloud for redundancy or to leverage best-of-breed services,
… but be aware of the added operational, networking, and governance complexity that comes with running across multiple control planes.
Practical pros and cons (concise)
– Pros: redundancy and resilience; ability to use best-of-breed managed services from different vendors; geopolitical and compliance flexibility; bargaining power versus a single provider.
– Cons: operational overhead (multiple APIs, consoles, and IAM models); data-transfer (egress) costs and latency; higher requirements for networking and identity federation; increased testing burden for backups, DR, and upgrades.
– Typical use cases: disaster-recovery (DR) targets, regulatory separation (data residency), vendor-lock-in mitigation for strategic workloads, and polyglot service mixes (e.g., ML on Provider A, SaaS DB on Provider B).
Key technical patterns and tools
– Containerization and orchestration: use containers (packaged runtime units) and Kubernetes (container orchestrator) to increase portability across clouds.
– Infrastructure as Code (IaC): manage resources with declarative tools (Terraform, Pulumi) to reduce manual drift and enable repeatable deployments across providers.
– Service mesh and API gateways: standardize service-to-service connectivity, security, and observability across clusters (e.g., Istio, Linkerd).
– Identity federation: use federated identity (SAML/OIDC) and a centralized identity provider to avoid disparate user-management models.
– Networking: use VPN/Direct Connect equivalents or SD‑WAN to secure and stabilize cross-cloud links; plan for multi-region latency and routing.
– Centralized logging/monitoring: consolidate metrics, traces, and logs into an observability platform that can ingest from all clouds.
Operational checklist before adopting multi-cloud/hybrid
1. Inventory: catalog apps, dependencies, data volumes, throughput, and latency needs.
2. Data gravity assessment: quantify how much data is read/written in place and the cost/latency of moving it.
3. Compliance mapping: identify regulatory controls per workload and per region.
4. Staff skills: ensure SRE/DevOps teams understand each cloud’s primitives and the cross-cloud tools you plan to use.
5. Networking plan: design connectivity (private links/VPNs), IP addressing, and bandwidth requirements.
6. Cost model: build expected monthly cost estimates, including egress, interconnects, and duplicate standby resources.
7. Security baseline: define a single security policy (IAM, encryption, key management, vulnerability scanning) implemented consistently.
8. Testing schedule: plan regular DR, failover, and restore rehearsals that include cross-cloud scenarios.
Worked numeric example — estimating egress cost
Assumption: You expect to move 100 TB of data per month from Cloud Provider A to Provider B. Use a sample egress rate of $0.09 per GB (common ballpark for public cloud egress tiers; actual rates vary).
Step 1 — convert: 100 TB ≈ 100,000 GB (decimal TB; check provider definitions).
Step 2 — multiply: 100,000 GB × $0.09/GB = $9,000 per month.
Step 3 — annualize: $9,000 × 12 = $108,000 per year.
Interpretation: Large, persistent cross-cloud data transfers can be a major cost and should drive architecture decisions (e.g., colocate compute with storage, use read replicas, or transfer only deltas).
Step-by-step for a staged multi-cloud adoption
1. Proof of concept (PoC): pick a non-critical stateless service, containerize it, deploy across two clouds using the same IaC template.
2. Connectivity: establish secure network connections and test latency/throughput under expected load.
3. Observability: route logs/metrics/traces into a single pane and validate alerting.
4. Failover tests: simulate the failure of one cloud and exercise automated failover procedures.
5. Data strategy: implement replication, snapshotting, or streaming architectures that minimize cross-cloud egress (e.g., active-passive with DR snapshots).
6. Expand iteratively: onboard more services as runbooks, automation, and governance mature.
Governance, security, and compliance suggestions
– Centralize policy enforcement: use policy-as-code (e.g., Open Policy Agent) to enforce IAM, encryption, and network rules across clouds.
– Secret and key management: avoid storing secrets in multiple cloud-native secret stores; consider a centralized KMS or a replicated key strategy with strict rotation.
– Least privilege: implement least-privilege IAM roles and log all cross-cloud access for auditability.
– Regular audits: automate compliance checks and schedule periodic control reviews across environments.
Cost and people considerations
– Total cost of ownership (TCO): include staff overhead, training, duplicated tooling, and extra monitoring when comparing to single-cloud options.
– Skill diversity: expect longer onboarding times and higher recruiting/training needs for multi-cloud skill sets.
– Contract negotiation: multi-cloud strategies can increase negotiating leverage, but also increase management complexity.
When to avoid multi-cloud
– Small teams or early-stage projects where simplicity and speed are critical.
– Workloads with extremely high internal data transfer requiring colocated compute and storage.
– When a single vendor offers a materially better integrated capability you need and dependency risk is acceptable.
Summary checklist (quick)
– Inventory and map data gravity.
– Estimate egress/network costs with conservative assumptions.
– Standard
-standardize on a common operational baseline: infrastructure-as-code (IaC) templates, CI/CD pipelines, monitoring/alerting, identity and access management (IAM) models, tagging and metadata standards. This reduces friction and audit complexity.
-automate repeatable tasks: provisioning, policy enforcement, backups, and patching. Manual processes scale poorly across clouds.
-define clear governance: roles, owner responsibilities, naming conventions, compliance controls, and an escalation path for incidents.
-set cost guardrails: budgets, alerts, automated shutdowns for noncritical dev/test resources, and regular chargeback/showback reports.
-plan for data locality and latency: colocate compute with primary data stores where possible; use caching or edge services to reduce cross-cloud traffic.
-create a migration/pilot roadmap: choose low-risk workloads first to validate tools, measure costs, and refine runbooks.
-regularly reassess vendor services: revisit decisions about managed services vs. building portable alternatives as product features and prices change.
Step-by-step pilot plan (practical)
1) Pick one low-risk workload (e.g., a stateless web front end) and a single objective: cost parity, latency target, or portability proof.
2) Define acceptance criteria: SLOs (latency, uptime), max monthly cost, and data transfer limits.
3) Build unified IaC for both clouds and document differences. Keep templates minimal and parameterized.
4) Deploy, run simulated load tests, and measure: CPU, memory, network egress, and end-to-end latency.
5) Analyze costs and operations for a minimum of one billing cycle; refine based on findings.
6) Decide: expand incrementally, standardize, or roll back.
Worked numeric example — egress cost sensitivity
Assume a service transfers 10 TB/month from Cloud A to users (egress to internet).
– 10 TB = 10 × 1,024 GB = 10,240 GB.
– If the egress price is $0.09/GB (illustrative), monthly egress = 10,240 × $0.09 = $921.60.
If you move 30% of requests to Cloud B, inter-cloud egress (A→B) of the same volume would be billed at similar rates in many cases, so plan for roughly the same magnitude. Small changes in per-GB charges or traffic volume quickly multiply—model worst-case and sensitivity scenarios.
Security & compliance checklist
– Enforce least privilege via centralized IAM where possible.
– Encrypt data at rest and in transit; manage keys with an auditable KMS (key management service).
– Centralize logging and retain logs per regulatory requirements; use immutable storage for audit trails.
– Standardize vulnerability scanning, patch management, and incident response runbooks across clouds.
– Document data flows and classify data to enforce residency and compliance constraints.
Cost-control checklist (practical)
– Tag everything with owner, cost center, and environment.
– Set hard monthly budgets per team with automated alerts at 50%, 80%, 95%.
– Apply autoscaling and rightsizing tools; run quarterly reserved/commitment reviews.
– Use a cloud cost model spreadsheet: list resources, units, price/unit, hours/month, and compute monthly totals. Recalculate with +/-20% traffic to test sensitivity.
When multi-cloud makes sense (short checklist)
– You need best-of-breed managed services from different vendors that materially improve outcomes.
– Regulatory or data-residency rules force geographic or vendor diversity.
– You want contractual leverage or resilience at the platform level and can accept increased operational complexity.
When to avoid multi-cloud (short checklist)
– Small team or early-stage product where speed and simplicity matter.
– Workloads with extreme internal data transfer that require tight locality.
– When a single vendor’s integrated offering is materially superior for your core use case and vendor lock-in risk is acceptable.
Operational metrics to track (minimum set)
– Cost per transaction, cost per active user.
– Network egress by direction (to internet, cross-cloud).
– Mean time to recovery (MTTR) for incidents.
– Deployment frequency and lead time for changes.
– Utilization and rightsizing ratios.
Quick decision flow (two questions)
1) Is cross-cloud data movement minimal or easily cached? If no → favor single-cloud or colocated architecture.
2) Do different clouds provide unique capabilities you cannot replicate cost-effectively? If yes → pilot multi-cloud with strict governance.
Further reading
– Investopedia — Cloud Computing: definition and overview
https://www.investopedia.com/terms/c/cloud-computing.asp
– NIST Special Publication 800-145 — The NIST Definition of Cloud Computing
https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-145.pdf
– Amazon Web Services — What is Cloud Computing?
https://aws.amazon.com/what-is-cloud-computing/
– Microsoft
– Microsoft Azure — What is cloud computing? https://azure.microsoft.com/en-us/overview/what-is-cloud-computing/
– Google Cloud — What is cloud computing? https://cloud.google.com/learn/what-is-cloud-computing
– Cloud Security Alliance — Guidance and best practices for cloud security https://cloudsecurityalliance.org/
How to use these further readings
– Start with NIST for the core, vendor-neutral definition and essential characteristics.
– Use vendor pages (AWS, Microsoft, Google) to compare service models, pricing structure, and examples of managed services.
– Consult the Cloud Security Alliance for frameworks, controls, and risk guidance when designing governance and compliance programs.
Educational disclaimer
This content is educational only and not professional, legal, or investment advice. Evaluate services and costs against your own technical requirements and business constraints before making architecture or procurement decisions.
Sources
– Investopedia — Cloud Computing: definition and overview https://www.investopedia.com/terms/c/cloud-computing.asp
–
– NIST — NIST Cloud Computing Definition (Special Publication 800-145) https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-145.pdf
– Amazon Web Services (AWS) — What is Cloud Computing? https://aws.amazon.com/what-is-cloud-computing/
– Microsoft Azure — What is cloud computing? https://azure.microsoft.com/en-us/overview/what-is-cloud-computing/
– Google Cloud — What is cloud computing? https://cloud.google.com/learn/what-is-cloud-computing
– Cloud Security Alliance — Guidance and best practices for cloud security https://cloudsecurityalliance.org/
– ISO/IEC — Cloud Computing Reference Architecture (ISO/IEC 17788, 17789) https://www.iso.org/standard/62534.html
Brief educational disclaimer: This content is for educational purposes only and not professional, legal, or investment advice. Use these sources to inform your own research and consult qualified professionals for decisions that affect your business, finances, or compliance responsibilities.