Cloud Service and Deployment Models Questions

Direct answer

A repeatable Total Cost of Ownership (TCO) approach for a 3-year cloud migration is: fix a small set of cost categories, build a low, base, and high estimate per category per year rather than a single number, sum to a 3-year total, and present the range together with the one or two assumptions that actually drive it, instead of a single, falsely precise figure.

Cost categories

• Cloud: compute and storage run rate.
• Networking: data-transfer and egress cost, easy to under-budget because it scales with usage in a way that's less visible than compute.
• Staff: both steady-state operations after migration and the migration labor itself, which is usually front-loaded into year one and often underestimated.
• Licensing: existing software licenses that may be retired or kept during a transition period, plus any new cloud-native tooling now paid for separately.
• Migration: one-time cost of assessment, refactoring, data transfer, and a dual-run period where both the old and new environments are paid for simultaneously.

Handling uncertainty and sensitivity

Treat each category as a range, not a point estimate, and weight the range asymmetrically toward the high side for anything without direct historical data, since migrations of this shape run over more often than under. Rather than sensitivity-testing every category equally, identify the one or two most likely to actually swing the total, usually the one-time migration cost and the ongoing infrastructure run rate, and spend the analysis effort there.

Worked example

For a hypothetical mid-sized application migration (illustrative figures, not derived from any real deal), assume a steady-state post-migration run rate of $180k a year in cloud compute and storage plus $20k a year in networking, $90k a year in steady-state operations staff, and $40k a year in licensing. Year one additionally carries a $120k one-time migration cost and elevated staff cost of $150k, migration labor plus ramping operations, while cloud and networking only reach about half the steady-state rate as workloads cut over gradually through the year.

Base-case 3-year TCO: $410k + $330k + $330k = $1,070k (about $1.07 million).

For sensitivity, apply a downside of minus 10 percent to the one-time migration cost and minus 15 percent to the combined cloud-and-networking line (the two most estimate-sensitive items), and an asymmetric upside of plus 30 percent to migration and plus 15 percent to cloud-and-networking, reflecting that migrations more often overrun than underrun.

Low case: migration $120k times 0.9 is $108k; cloud-and-networking $100k times 0.85 is $85k in year one and $200k times 0.85 is $170k in years two and three. Year 1 low = 108 + 85 + 150 + 40 = $383k; Year 2 and Year 3 low = 170 + 90 + 40 = $300k each. 3-year low = 383 + 300 + 300 = $983k.

High case: migration $120k times 1.3 is $156k; cloud-and-networking times 1.15 is $115k in year one and $230k in years two and three. Year 1 high = 156 + 115 + 150 + 40 = $461k; Year 2 and Year 3 high = 230 + 90 + 40 = $360k each. 3-year high = 461 + 360 + 360 = $1,181k.

The presented range is roughly $983k to $1,181k around a base case of $1,070k, about plus or minus 10 percent, and the two line items that drive nearly all of the spread are the migration cost and the cloud-and-networking run rate.

Trade-offs and pitfalls

The most common mistake is budgeting only the recurring run rate and forgetting the one-time migration and dual-run overlap cost, which routinely turns out to be one of the largest single-year line items. A second mistake is ignoring networking, since data-transfer and egress cost is often billed separately and can quietly become a meaningful recurring cost that a "compute and storage" estimate alone misses. A third is presenting a single-point TCO number as if it were precise; a 3-year infrastructure estimate carries enough real uncertainty, demand growth, price changes, migration scope creep, that a range with named drivers is both more honest and more useful for a budget decision than false precision.

Direct answer

Serverless functions, also called Function as a Service (FaaS: AWS Lambda, Azure Functions, Google Cloud Run functions, the platform formerly known as Cloud Functions), are best understood as a further point along the PaaS spectrum rather than a wholesale new category or a step toward SaaS. The provider takes over everything PaaS already took over (OS, runtime, middleware) plus two things classic PaaS still leaves you: capacity planning and idle cost. What makes serverless feel distinct is a difference of granularity and billing, not a different responsibility layer.

Why not SaaS, and why "further along PaaS"

SaaS gives you a finished application. Serverless gives you a place to run your application code, so it fails the core SaaS test immediately: does the provider own the application logic? No, you still write the function.

PaaS gives you a managed runtime you deploy a service into and typically leave running continuously; you still think in terms of "how many instances" and pay for a provisioned server whether or not it's handling a request. Serverless removes the instance concept from your mental model entirely: the platform decides how many copies of your function to run, scales all the way to zero when idle, and bills per invocation and execution duration rather than per hour of a running server. That is a difference in degree along the same "who manages what" ladder PaaS is already on, not a new category.

The three responsibilities the question names

• Runtime: entirely the provider's. It picks the execution environment, patches the language runtime, and you only choose a supported version and keep your code compatible with it.
• Scaling: entirely the provider's, and automatic. It scales per invocation, including to zero, and the levers you get are reserved concurrency (a cap that both guarantees and limits how many copies of your function can run at once, useful for protecting a downstream dependency like a database connection pool, at no extra charge) and, on some platforms, provisioned concurrency (an additional-cost option that keeps a guaranteed number of copies pre-initialized and ready, so a request doesn't have to wait for a fresh one to start) to reduce cold starts.
• Application code: yours, same as PaaS. You still own business logic, dependencies, and any bugs in your function.

Worked example

Contrast two workloads. An internal admin dashboard that gets hit sporadically all day is a natural PaaS fit: a provisioned instance sits warm between requests, and you pay for that idle time regardless of traffic. An event-driven job that resizes an uploaded image whenever one lands in storage is a natural serverless fit: the function runs for, say, a few hundred milliseconds per image and you pay only for that time, at the cost of a cold-start penalty the first time an idle function wakes up to handle a request.

Trade-offs and pitfalls

Serverless trades away two things PaaS still gives you. First, statelessness: nothing reliably persists in memory between invocations, so any state the workload needs has to live in an external database or cache. Second, a hard maximum execution duration, which makes serverless a poor fit for long-running or streaming work. The common pitfall is treating "serverless" as free of operational burden entirely; in practice you trade server-patching burden for observability burden, since tracing a request across many short-lived, independently scaling function instances is genuinely harder to reason about than reading one long-lived process's logs.

Direct answer

The shared responsibility model says the cloud provider is responsible for the security and correctness of everything below the layer you're consuming, and you're responsible for everything you build and configure on top of it and for how you use the pieces the provider gives you. For a 3-tier application, a load balancer, application servers, and a managed database, that line falls in a different place at each tier, because each tier is effectively a different service model in practice.

flowchart TD
  U["User traffic"] --> LB["Load balancer (managed service)"]
  LB --> APP["Application servers (customer-managed OS)"]
  APP --> DB["Managed database"]

Responsibilities, tier by tier

Worked example

Suppose a security review finds that customer records were briefly readable by an unauthorized internal service account. At the load-balancer tier, that's not the provider's issue, since the load balancer correctly routed the traffic it was configured to route. At the application-server tier, it's a customer issue if the application code granted that service account more permission than it needed. At the database tier, it's a customer issue if the database access-control configuration allowed the account to read the table in the first place. Tracing the same incident through all three tiers, at no point was the provider's own responsibility, physical security, hypervisor isolation, database engine patching, actually implicated. This is exactly why a compliance audit asks "which model are you on for each tier" before assigning blame.

Trade-offs and pitfalls

The main pitfall is assuming that because the database is "managed," data-access misconfiguration becomes the provider's problem; managed means the provider keeps the engine patched and running, not that the provider decides who your application should let read what. A second pitfall specific to this 3-tier shape: teams often harden the load balancer and database carefully, since they clearly feel like "cloud things," while under-investing in the application-server tier's OS patching and host-level monitoring, precisely because it's the one tier here that still looks and feels like "our own server," even though the shared-responsibility line places real, non-optional obligations there too.

Direct answer

For a 4-person team with limited operations experience hosting an application around 10,000 daily active users, I would recommend PaaS as the primary model, a managed application platform plus a managed database, reserving IaaS only for any piece that genuinely needs it, and treating SaaS as a source of building blocks to buy, such as authentication or transactional email, rather than as the hosting model for the core app itself.

Comparing the three for a small team

IaaS gives full control and potentially the cheapest per-unit compute, but the team would own OS patching, scaling configuration, and monitoring, which competes directly with the very small number of engineering hours available for the actual product. Wrong default here.

PaaS gives up some control, but a 4-person team gets a production-grade deployment, managed scaling, managed database, automated patching, without hiring or becoming operations specialists. That is exactly the trade a resource-constrained team should make.

SaaS is the right model for well-defined, already-solved problems adjacent to the product, using a SaaS product for email delivery, a SaaS-provided authentication service, or a support-ticketing tool for customer service, rather than for the core application, since the core app is presumably the team's actual differentiated product and isn't something an off-the-shelf SaaS product would be.

The recommendation

A managed application platform for the app tier plus a managed database for storage, with a couple of SaaS building blocks glued in for auth and transactional email rather than built from scratch. This keeps the team's operations surface down to "watch a dashboard and occasionally adjust a scaling policy" instead of "own a fleet."

A hybrid approach, and when it makes sense

A hybrid here would mean keeping the core app on a managed platform while running one specific piece on IaaS, for example a background job that needs a software dependency the managed platform doesn't support, or a steady, cost-sensitive batch workload where a small reserved virtual machine is genuinely cheaper at this scale than the managed equivalent. This makes sense once the team has one clear, isolated piece of the system with a requirement PaaS can't satisfy, or a cost delta large enough to justify the added operational surface for that one piece, not as a blanket decision to control more of the stack.

The analytics variant: a different lock-in calculus

If the workload were analytics or business intelligence (BI) flavored instead of a general customer-facing app, for instance this same 4-person team standing up internal reporting dashboards, the PaaS-first instinct needs an extra check. A fully SaaS BI tool gets a working dashboard fastest, but it usually couples the team's reporting logic and data tightly to that vendor's proprietary query language and connectors, a much larger vendor lock-in exposure than picking a managed application platform for a general web app, where the exit path (redeploy the same container elsewhere) is comparatively cheap. A PaaS-level option, a managed data warehouse queried with standard SQL, costs the team a bit more setup and ongoing responsibility, someone has to model the data and maintain the queries, but keeps the exit path open, since standard SQL and exported data are portable in a way a BI SaaS product's proprietary dashboard definitions typically are not. For a 4-person team specifically, that's worth naming explicitly rather than defaulting to "SaaS is always right for a small team," because the team's limited operations capacity has to be weighed against how expensive it would be for that same small team to unwind a deep SaaS BI dependency two years later if the vendor's pricing or roadmap stops fitting.

Trade-offs and pitfalls

The first pitfall is treating "small team, limited ops" as an automatic vote for SaaS everywhere; SaaS for your core differentiated product usually means you're not actually building a product anymore, just configuring someone else's. The second is over-indexing on cost-per-unit-compute when comparing IaaS to PaaS at this scale: at 10,000 daily active users, the labor cost of even a fraction of one engineer's time spent on operations very likely exceeds the sticker-price premium of PaaS, so the "PaaS costs more per server" argument that matters at large scale mostly doesn't apply yet.

Direct answer

Service-model choice does not change whether you can meet an EU data-residency requirement; it changes how much of the compliance burden is technical, something you configure and verify yourself, versus contractual, something you have to get in writing and trust. That split tracks the shared-responsibility boundary that governs every service model: IaaS gives you the most levers to pull yourself, SaaS gives you the fewest and pushes the burden toward contract terms.

Controls by model

Worked example

A company running an EU customer database on IaaS provisions its own virtual machines and database engine in an EU region and configures backup jobs to write only to EU storage, verifiable by inspecting their own infrastructure. On PaaS, they pick a managed database's EU region, but must additionally check the vendor's documentation for whether that service's automated backups, diagnostic logs, or support-access tooling are also EU-scoped, since providers have historically kept some metadata in a home region by default. On SaaS, for example a customer-support ticketing product, residency depends entirely on whether the vendor sells an EU-residency tier; if it does not, the technical option may not exist at all, and the choice becomes either avoiding that vendor for EU personal data or accepting a contractual transfer mechanism with legal sign-off.

Trade-offs and pitfalls

The biggest pitfall is assuming "I picked the EU region in the console" fully discharges the requirement above IaaS: managed-service metadata, provider support access, and third-party sub-processors can each independently violate residency even when the primary data store is correctly pinned. On SaaS specifically, pin down what the underlying regulation actually requires, for example the EU's General Data Protection Regulation (GDPR) if that is the driver, since "data must remain in the EU" and "a transfer of personal data outside the EU needs a valid transfer mechanism" are two different, commonly conflated obligations. Treating a residency requirement as absolute when the real rule permits a properly documented transfer mechanism can lead you to reject an otherwise workable vendor for no real compliance benefit.