The Big Cloud Providers (AWS, Azure, Alibaba Cloud, and Google Cloud)

Why this matters for Univa

Univa's default stack (Cloudflare Pages/Workers + Supabase + Vercel, per the app-building philosophy) covers the vast majority of SME work, and it should stay the default. But three things make the hyperscalers worth understanding even so:

1. Client conversations. SME clients, bigger corporate clients, and government-adjacent tenders occasionally ask "can this run on our AWS/Azure account" or "is this hosted securely enough." Knowing the landscape lets Ahnaf answer credibly instead of guessing, and lets him tell the difference between a real requirement and a buzzword.
2. Indirect exposure. Vercel and Supabase are themselves built on top of AWS infrastructure. Ahnaf is already, several layers down, an AWS customer. Understanding the underlying layer explains where certain limits, outages, and pricing quirks (like egress fees) come from.
3. Scoping and pricing. Hyperscaler work is genuinely more expensive to build and maintain than the freemium stack. Knowing when it is actually required (versus when a client just assumes "enterprise" means AWS) protects margins and prevents over-engineering a five-page SME site.

The goal of this module is not to become an AWS-certified architect. It is to build a correct mental model fast, know the flagship services by name, and know the decision rule for when a hyperscaler is worth the overhead.

Quick map: who are these companies, in one line each

These labels are rough mental hooks, not verdicts. All four are full-featured clouds capable of running nearly anything; the differences that matter for Univa are pricing, regional presence, and which ecosystem a specific client is already locked into.

---

Core concepts

These ideas are shared across every major cloud provider. Learn them once and they transfer everywhere, regardless of which logo is on the invoice.

1. Region

A region is a specific geographic location where a provider runs a cluster of data centers, for example AWS ap-southeast-1 (Singapore) or Alibaba Cloud's Kuala Lumpur region. Choosing a region close to your users cuts latency. Choosing a region that satisfies a data residency requirement (data must physically stay in Malaysia, for example) can matter more than latency for certain clients.

2. Availability Zone (AZ)

A region is made up of two or more Availability Zones: physically separate data centers within that region, each with independent power, cooling, and networking, connected by fast low-latency links. Spreading a workload across AZs protects against a single data center going down. This is the first layer of redundancy in every hyperscaler's design, and it is why "multi-AZ" is a phrase that shows up on almost every managed database's pricing page as a paid upgrade.

3. IAM (Identity and Access Management)

Every hyperscaler has a permission system controlling exactly who, or what service, can do what, to which resource. This is also the single most commonly misconfigured thing in cloud setups: leaked S3 buckets and over-permissioned service accounts are almost always an IAM mistake, not a platform flaw. The core principle to hold onto: grant the least privilege needed, nothing broader "just in case."

4. VPC (Virtual Private Cloud)

A VPC is your own isolated slice of the provider's network, inside their data center, where you place your resources and control what can talk to what: subnets, firewall rules (security groups), routing between them. Think of it as renting a private, walled-off network inside someone else's building. Nothing inside talks to the public internet unless you explicitly allow it.

5. Managed services vs raw compute

This is a spectrum, not a binary choice:

The further down this table you go, the less you manage and the more the provider's pricing model (pay per request, not per hour) starts to matter.

6. The shared responsibility model

Every hyperscaler draws the same line: the provider secures "of the cloud" (physical data centers, hardware, the network backbone, the hypervisor), and the customer secures "in the cloud" (your data, your IAM permissions, your application code, whether your S3 bucket is public or private). Almost every major cloud security breach in the news is a customer-side failure inside this line, not a provider-side one. This matters for Univa because it means "we host on AWS" is never, by itself, a security guarantee to give a client. The configuration on top of AWS is what determines whether the app is actually secure.

7. Global edge network vs regions

Regions and AZs are where your actual compute and database live. A separate, much larger layer, the CDN/edge network, caches static content (images, JS bundles, HTML) at hundreds of points of presence close to end users, independent of which region your backend runs in. AWS CloudFront, Azure Front Door, and Cloudflare's global network all do this. This is why a Vercel or Cloudflare Pages site can feel instant worldwide even though the actual server-side logic runs in only one or two regions: the edge network is doing the geographic work, not the region choice.

8. Load balancers and DNS

A load balancer sits in front of multiple copies of your app and spreads incoming traffic across them, so no single instance gets overwhelmed and a failed instance can be quietly removed from rotation. Every hyperscaler has one (AWS Elastic Load Balancing, Azure Load Balancer, Google Cloud Load Balancing, Alibaba Cloud's SLB). DNS (the system that turns a domain name like univa.my into an IP address) is the layer above that, deciding which load balancer or edge network a request even reaches in the first place. On the freemium stack, Cloudflare and Vercel handle both of these automatically; on a raw hyperscaler build, configuring them correctly is a manual, easy-to-get-wrong step.

9. Buzzwords decoded

Client and job-listing language that sounds impressive but maps to simple ideas:

10. Compliance and certifications

Enterprise and government-adjacent clients sometimes ask about specific certifications rather than the cloud provider itself. The two that come up most: SOC 2 (an audit of a company's security controls, common in B2B SaaS due diligence) and ISO 27001 (an international information security management standard). All four hyperscalers hold both. For Malaysia specifically, PDPA (Personal Data Protection Act) governs how personal data must be handled, and it is a legal requirement on Univa and its clients regardless of which cloud is used, not something a cloud provider certificate substitutes for. If a client asks "are you PDPA compliant," the honest answer is about how the application handles personal data (consent, storage location, retention, access control), not simply which hosting provider is used underneath.

---

The landscape (comparison tables)

Flagship services, side by side

Watch out for this naming trap: "ECS" means two completely different things depending on the provider. AWS ECS is Elastic Container Service (for running containers, covered in Module 4). Alibaba Cloud ECS is Elastic Compute Service (for running virtual machines, the equivalent of AWS EC2). If a client or a job description mentions "ECS," always ask which cloud they mean.

Alibaba Cloud's relevance in Asia and Malaysia

Alibaba Cloud is worth knowing specifically because of geography and timing, not because it competes head to head with AWS on global scale:

• Alibaba Cloud has operated a Malaysia (Kuala Lumpur) region since around 2018, backed by an MDEC partnership, years before AWS or Azure opened a local Malaysian region.
• AWS's own Kuala Lumpur region (ap-southeast-5) only launched in September 2024, and Azure's first Malaysia region (Malaysia West) went live in May 2025. Google Cloud has announced a Malaysia investment and region but has not confirmed an operational launch date as of this writing.
• Alibaba Cloud is the natural fit for clients selling into China, integrating with Alipay/Lazada-adjacent commerce infrastructure, or needing data to sit physically in Malaysia without paying Singapore-region latency or dealing with cross-border data transfer questions.
• It generally has lower brand recognition among Malaysian SME decision-makers than AWS, but often comes with competitive list pricing and occasional presence on government or MDEC digitalization vendor panels.

Multi-cloud and vendor lock-in, briefly

Every hyperscaler makes it easy to move data in and expensive to move data out (see egress fees below), and every managed service (RDS, DynamoDB, BigQuery) locks your application logic into that provider's specific API to some degree. "Multi-cloud" (running across two or more providers at once) is sometimes pitched as the solution, but for a team Univa's size it usually adds operational complexity without a matching benefit. The practical lock-in mitigation for Univa is simpler: prefer open, portable primitives (Postgres over a proprietary database, S3-compatible object storage over a proprietary blob format, Docker containers over a provider-specific packaging format) so that switching later, if it is ever needed, is a redeploy rather than a rewrite.

---

Pricing mental models

Every hyperscaler prices compute along a similar spectrum:

The classic trap: egress fees. Data moving into a cloud provider is almost always free. Data moving out to the public internet (egress) is billed per gigabyte, and it adds up fast for anyone serving images, video, or large API responses. This is the single most common "surprise cloud bill" story.

Worked example (approximate figures, always check the current pricing page before quoting a client): imagine an SME e-commerce client with 5 GB of product images and 50 GB of monthly egress serving those images to shoppers.

At this small scale the dollar difference looks trivial, which is exactly the trap: it looks trivial until the client's traffic grows 20x, at which point the egress-based setup grows its bill roughly linearly while the zero-egress setup barely moves. This is why Cloudflare R2 markets itself specifically on zero egress fees: it directly undercuts the classic hyperscaler pricing trap, and it is why Univa should default to R2 or a CDN-fronted setup for anything media-heavy rather than serving straight out of S3 or OSS.

Rough always-on small VM, one region, on-demand pricing (order-of-magnitude only, changes constantly, always re-check):

The number itself matters less than the shape of the comparison: raw VM pricing across the big three US hyperscalers converges to roughly the same ballpark, so the deciding factor for Univa is almost never "which VM is cheaper," it is which managed services, regional presence, and integration requirements the project actually needs.

---

How indie-friendly platforms sit relative to the hyperscalers

This distinction matters more than it looks:

• Cloudflare runs its own global network of data centers. Workers execute on Cloudflare's own edge compute (V8 isolates), not as a thin wrapper over AWS. Cloudflare is a genuine alternative infrastructure layer, not just a friendlier UI bolted onto a hyperscaler. This is why its pricing (especially R2's zero egress) can structurally undercut AWS/Azure/GCP rather than just repackaging them.
• Vercel builds its serverless function execution and much of its hosting on top of AWS (historically AWS Lambda under the hood, with its own edge network layered on top). You get git-push deploys and zero server management, but several layers down you are still an AWS customer, and AWS-level limits and outages can surface through Vercel.
• Supabase runs its managed Postgres, Auth, Storage, and Edge Functions primarily on top of AWS infrastructure. You get a nice API, dashboard, and auth layer, but underneath it is the same building blocks (managed Postgres, object storage) you would get provisioning AWS RDS and S3 directly, plus Supabase's convenience layer and margin.

The practical takeaway: Vercel and Supabase are "hyperscaler plus a much better developer experience," while Cloudflare is a genuinely separate network that competes on its own terms. Both routes are valid; Univa uses both together, and neither requires touching an AWS console directly.

---

How to choose (decision rules)

• If a client's IT policy or contract explicitly mandates a specific hyperscaler (common with banks, government-adjacent bodies, or large corporates), use it, and price the extra setup and ongoing patching time into the quote as a distinct line item.
• If the workload needs GPU-based ML training at scale, deep enterprise SSO/Active Directory integration, or existing AWS/Azure VPC peering with the client's other systems, a hyperscaler is genuinely needed.
• If the project is a marketing site, booking system, lightweight POS, dashboard, or chatbot for an SME with well under 100k monthly visits, a hyperscaler is overkill. Cloudflare/Vercel plus Supabase ships faster, costs less, and is maintainable solo.
• If the hard requirement is data residency in Malaysia specifically, check whether Supabase or Vercel already offer a nearby region first; only reach for AWS ap-southeast-5, Azure Malaysia West, or Alibaba Cloud's Kuala Lumpur region if the managed platforms cannot satisfy the requirement.
• If a client is already running on a specific hyperscaler for other systems, integrating with what they have is usually cheaper for everyone than migrating them onto Univa's default stack purely for consistency.
• Rule of thumb: never introduce hyperscaler-level complexity (IAM policies, VPC networking, multi-service architecture) unless a specific, named requirement forces it. The complexity has an ongoing maintenance cost even when the monthly bill is close to zero.

Mini case study to anchor the rule

A prospective client, a mid-size logistics company, asks Univa to "build it on AWS because that's what our IT team trusts." Two different underlying situations produce two different right answers:

• If IT trust means "we already run other systems on AWS and want this one to sit in the same VPC so it can talk to our internal API," that is a real integration requirement: quote it as an AWS build, scope the extra IAM/VPC time.
• If IT trust actually means "AWS sounds safe and enterprise-grade, we don't have a specific integration need," the honest answer is to explain that Vercel/Supabase already run on hyperscaler-grade infrastructure, and that a dedicated AWS setup would cost more to build and maintain for the same result. Most of the time this second situation is the real one, and saying so directly builds more trust than quietly agreeing and over-charging for unnecessary infrastructure.

Common mistakes to avoid if a project does end up on a hyperscaler

• Granting broad permissions (AdministratorAccess or equivalent) to a service account "temporarily" and never narrowing it afterward.
• Making a storage bucket public to fix an access error quickly, then forgetting to lock it back down.
• Forgetting to enable multi-AZ on a production database, discovering the gap only after a single data center outage takes the whole app down.
• Not checking the egress pricing page before choosing where media assets live, then getting an unpleasant bill once traffic grows.
• Provisioning resources directly through the console for a "quick fix" instead of updating infrastructure-as-code, so the next person (or future Ahnaf) has no record of what changed or why.

---

Univa playbook

• Default stack stays the default. Cloudflare Pages/Workers plus Supabase plus Vercel covers essentially all current Univa client work. No direct AWS, Azure, or Alibaba Cloud account is needed for most projects.
• Treat "put it on our AWS/Azure" as a scoped, billable add-on, not something folded into a normal freemium-stack quote. It brings IAM setup, VPC configuration, and ongoing patching responsibility that the default stack does not have.
• Keep a personal free-tier AWS (or similar) account for learning only, separate from client production work, so the concepts in this module stay hands-on without touching a client's bill.
• Keep Alibaba Cloud on the radar, not in the default toolkit. It becomes relevant specifically for China-facing e-commerce clients or MDEC/government panel opportunities, nothing else.
• Prefer portable primitives even inside the default stack (Postgres via Supabase, S3-compatible storage via R2) so a future move to or from a hyperscaler, if it is ever forced by a client, is a redeploy rather than a rewrite.
• Push back diplomatically on "enterprise-grade cloud" requests that do not fit the project. The strongest argument: Vercel and Supabase already run on hyperscaler-grade infrastructure underneath, so the client is not sacrificing reliability by using the simpler stack, only unnecessary complexity.
• When PDPA comes up, answer with application-level controls, not a cloud provider's name. Data residency, consent flows, retention policy, and access control are the actual answer; the cloud logo is not.

---

Hands-on exercise

Pick one real (or hypothetical) Univa client asset, for example a 5 GB folder of product photos and short videos for an SME e-commerce site. Using the AWS Pricing Calculator and Cloudflare's R2 pricing page, estimate the monthly cost of:

1. Storing 5 GB and serving 50 GB of egress per month via S3 Standard + CloudFront.
2. Storing the same 5 GB and serving the same 50 GB via Cloudflare R2 + Cloudflare's CDN.

Write down both totals side by side and note, in one sentence, which pricing trap you would have hit if you had not checked egress costs before choosing a storage provider for a media-heavy client. Then repeat the math assuming traffic grows 20x, and note how differently the two totals scale.

Stretch goal (optional, same evening): sign up for a free-tier AWS account if you do not already have one, open the IAM console, and create a single new IAM user with a custom policy scoped to read-only access on one S3 bucket. This ten-minute exercise makes the abstract "least privilege" principle concrete: notice how many clicks it takes to grant a narrow permission versus how tempting it is to just tick "AdministratorAccess" instead.

---

Self-check

1. What is the difference between a region and an Availability Zone?
2. Name the flagship object storage service for AWS, Azure, Google Cloud, and Alibaba Cloud.
3. Why is "AWS ECS" versus "Alibaba Cloud ECS" a common point of confusion?
4. What is the classic hyperscaler pricing trap, and how does Cloudflare R2 avoid it?
5. Give one concrete reason a Univa SME project would justify moving to a hyperscaler instead of the default Cloudflare/Supabase/Vercel stack.

Answers

1. A region is a geographic location; an Availability Zone is one of two or more physically separate, independently powered data centers within that region, used for redundancy.
2. S3 (AWS), Blob Storage (Azure), Cloud Storage (Google Cloud), OSS (Alibaba Cloud).
3. AWS ECS means Elastic Container Service (runs containers); Alibaba Cloud ECS means Elastic Compute Service (runs virtual machines, like AWS EC2). Same acronym, unrelated meaning.
4. Data egress (outbound transfer to the internet) fees, billed per gigabyte and easy to underestimate; Cloudflare R2 charges zero egress fees.
5. Any of: an explicit client IT/compliance mandate, a need for GPU-based ML training at scale, or a hard in-country data residency requirement that Supabase, Vercel, and Cloudflare's existing regions cannot satisfy.

---

A note on how fast this landscape changes

Regions open, pricing tiers shift, and free-tier limits get revised every few months across every provider covered here. The mental model (regions, AZs, IAM, VPC, managed-vs-raw spectrum, egress traps) is stable and worth memorizing. The specific numbers (which Malaysia regions are live, exact per-GB pricing) are not: always re-check the provider's own pricing and region pages before quoting a client, rather than relying on this module's snapshot.

---

Further reading

• AWS, what is cloud computing: https://aws.amazon.com/what-is-cloud-computing/
• AWS global infrastructure (regions and AZs): https://aws.amazon.com/about-aws/global-infrastructure/
• AWS shared responsibility model: https://aws.amazon.com/compliance/shared-responsibility-model/
• AWS Pricing Calculator: https://calculator.aws/
• Azure architecture fundamentals: https://learn.microsoft.com/en-us/azure/architecture/guide/
• Azure global infrastructure map: https://azure.microsoft.com/en-us/explore/global-infrastructure/geographies
• Google Cloud locations: https://cloud.google.com/about/locations
• Alibaba Cloud global infrastructure: https://www.alibabacloud.com/en/global-locations
• Cloudflare R2 pricing and docs: https://developers.cloudflare.com/r2/pricing/
• Vercel edge network and regions: https://vercel.com/docs/edge-network/regions
• Supabase documentation: https://supabase.com/docs
• AWS Malaysia region announcement: https://aws.amazon.com/about-aws/whats-new/2023/11/aws-region-malaysia/
• Azure Malaysia region overview: https://azure.microsoft.com/en-us/explore/global-infrastructure/geographies/malaysia