Cloud Computing Models

Choose how much of the system you want to operate

The same product catalog could run on virtual machines, a managed application platform, or functions behind an API. Each can work. The useful question is which responsibilities and constraints your team should take on.

You will compare service and deployment models, choose an approach from concrete requirements, and inspect short code examples without assuming that “managed” means “nothing left to manage.” The scenarios are architectural exercises, not a specific certification exam syllabus. AWS details were checked 14 September 2026.

1. Three service models, one continuing responsibility

These are models of abstraction, not a complete classification of every product. EC2 is a clear IaaS example. Elastic Beanstalk is a useful platform example, while RDS is specifically a managed database service. S3 supplies managed object storage; it is not a customer-managed operating system. A service can combine characteristics rather than fit one exclusive box. AWS cloud models

As you move toward a managed service, some infrastructure work shifts to the provider. Your accountability for access and appropriate data use does not disappear. With RDS, for example, AWS operates the database infrastructure, while you choose access, encryption settings, appropriate backup retention and recovery procedures. With a self-managed database on EC2, the guest OS and database administration add more work. Shared responsibility

Elastic Beanstalk is not a promise of zero platform maintenance. It can provision resources, configure load balancing, expose health information and manage supported platform updates. Customers still need a supported platform version, suitable update settings, dependency maintenance and testing. The underlying EC2 capacity and other resources also have costs while running. Beanstalk maintenance responsibilities

For SaaS, think of a provider-operated email or collaboration application, rather than “all AWS managed services.” Amazon WorkMail is a valid service-model example from existing systems, but AWS has announced end of support on 31 March 2027; it is used here for classification, not as a recommendation for a new deployment. Service lifecycle belongs in a real choice. WorkMail notice

2. Serverless removes server provisioning, not engineering

Serverless describes services where customers do not provision and manage the underlying servers for the workload. Servers still exist. Lambda provides function execution, Fargate provides managed container compute, and DynamoDB provides a managed NoSQL database with different capacity modes. They do not share one universal billing formula or scaling behavior.

For standard Lambda functions, AWS operates the execution infrastructure and scales within applicable limits. You still configure memory, timeout, concurrency, permissions, dependencies and error handling. Standard managed runtimes shift runtime maintenance work; customer code and packaged dependencies still require attention. Container-image deployments add image-maintenance responsibilities. Lambda operating model, Lambda shared responsibility

A single standard invocation has a maximum timeout of 900 seconds, or 15 minutes. That does not mean every serverless workflow must finish within 15 minutes: Lambda durable functions can checkpoint and suspend/resume across invocations, and orchestration services can coordinate longer workflows. A continuous loop cannot escape its invocation timeout just by being called serverless. Lambda quotas, durable invocation behavior

For Lambda's usual on-demand execution pricing, requests and duration are major inputs; memory affects duration charges. Provisioned concurrency, storage, network traffic and connected services can add costs. Running Fargate tasks also incur charges even when the application is idle. DynamoDB offers on-demand and provisioned capacity choices. “Serverless” therefore does not prove “zero idle cost” or “always cheaper.” Lambda pricing, Fargate pricing, DynamoDB capacity modes

A small function you can reason about locally

This Python handler expects a direct test event, for example {"name": "Sam"}. It does not parse an API Gateway request body or implement authentication. The response has the familiar status/body shape used by many proxy integrations:

import json

def lambda_handler(event, context):
    name = event.get('name', 'World')
    if not isinstance(name, str) or not name.strip():
        return {'statusCode': 400, 'body': json.dumps({'error': 'name must be a nonempty string'})}
    return {'statusCode': 200, 'body': json.dumps({'message': f'Hello, {name.strip()}!'})}

Predict: {"name": " Sam "} returns a JSON body containing Hello, Sam!; {} uses World; {"name": 42} returns status 400. The function body alone does not demonstrate deployed scaling or security—it is code that could run in the Lambda service.

3. Choose from requirements, not a fixed winner

Consider these five workload requirements:

Model hosting has the same tradeoff: managed inference can reduce hosting work, but latency, accelerators, model size, scaling policy and utilization determine the fit. No service model is universally best for ML inference. Likewise, serverless does not require a microservices architecture, and a WebSocket requirement alone does not rule out every serverless design.

Capacity is a configuration choice

Suppose a teaching scenario asks for a minimum of 2 instances, a maximum of 20, and a target of 70% average CPU utilization. Its values can be written as a local planning object:

plan = {'minimum': 2, 'maximum': 20, 'target_cpu_percent': 70}
assert 0 <= plan['minimum'] <= plan['maximum']
assert 0 < plan['target_cpu_percent'] <= 100

This object is not an AWS API request. An actual Auto Scaling group and target-tracking policy are configured through their appropriate operations. These values come from the scenario, not a universal best practice. Two instances can still be in one AZ; a 70% target is useful only if CPU is a suitable load signal and the remaining headroom is sufficient. Target tracking

Time check: a loop that waits 60 seconds for each of 1,000 chunks spends 60,000 seconds = 1,000 minutes = 16 hours 40 minutes waiting, before counting processing time. It cannot finish inside a single 900-second standard Lambda invocation. Split genuinely independent work or choose a suitable long-running compute service; do not merely increase retries on the same oversized task.

4. Separate the business calculation from the cloud trigger

Imagine CSV files with numeric status and response_time_ms columns. The input is already validated and small enough to process in memory. This local function makes the calculation testable without an AWS account:

def summarize(rows):
    count = len(rows)
    if count == 0:
        return {'total_requests': 0, 'error_rate': None, 'avg_response_time_ms': None}
    errors = sum(1 for row in rows if int(row['status']) >= 400)
    mean_ms = sum(float(row['response_time_ms']) for row in rows) / count
    return {'total_requests': count, 'error_rate': errors / count, 'avg_response_time_ms': mean_ms}

Here error deliberately means status 400 or higher. For statuses [200, 404, 503] with response times [100, 200, 300] milliseconds, the result is 3 requests, an error rate of 2/3, and a mean of 200 ms. Empty input returns None for the undefined rate and mean rather than dividing by zero. Other definitions of an error are possible; the metric's definition must be explicit.

An S3-triggered deployment adds work beyond that calculation:

• Configure the event notification and Lambda invocation permission; a function declaration alone does not connect S3 to it.
• Decode the object key from the event, handle the event's records and validate expected input.
• Prevent a trigger loop by separating input and output buckets or filtering input prefixes appropriately.
• Make processing safe to repeat. S3 event notifications can be duplicated and are not guaranteed to arrive in order.
• Bound memory and execution time; arrange failure handling, monitoring and appropriate retries.

For versioned input, a stable input-version identifier can help track repeat processing. Merely replacing a result file at the same key does not make payments, notifications or every other side effect idempotent. S3 event notifications, event message format

Recognize the serverless database boundary

This JavaScript module illustrates a Lambda handler writing one item to DynamoDB using AWS SDK for JavaScript v3. Package @aws-sdk/client-dynamodb and @aws-sdk/lib-dynamodb with the application. It assumes an existing Users table with string partition key id, a configured Region, an execution role permitted to write it, and a validated trusted test event. It is not a public signup API or an authorization design.

import { DynamoDBClient } from '@aws-sdk/client-dynamodb';
import { DynamoDBDocumentClient, PutCommand } from '@aws-sdk/lib-dynamodb';

const db = DynamoDBDocumentClient.from(new DynamoDBClient({}));
export const handler = async (event) => {
  await db.send(new PutCommand({
    TableName: 'Users',
    Item: { id: event.id, name: event.name }
  }));
  return { stored: true };
};

Lambda operates the function infrastructure and DynamoDB operates the database infrastructure. You still define the data model, permission boundary and overwrite behavior: this PutCommand can replace an existing item with the same key. An on-demand table's billing/scaling differs from provisioned capacity. DynamoDB document client

For an asynchronous Lambda.Invoke call, InvocationType='Event' asks Lambda to queue the event. A successful acceptance is not proof that processing completed successfully. The caller can respond before processing finishes, after the invocation request itself succeeds. Retry, failure-destination and duplicate-handling choices remain part of the application. Asynchronous invocation

5. Deployment location is a separate axis

Consider an existing factory system connected to AWS, where Lambda handles short events and a supported managed database stores cloud-side data. It is a hybrid architecture in common AWS usage and contains several service models. Adding another provider makes it multicloud too; it does not turn Lambda into IaaS.

A private cloud serves one organization exclusively; it is not just any ordinary data center. Public cloud does not imply public access to your records. NIST's four deployment models are public, private, community and hybrid; its strict hybrid definition joins distinct cloud infrastructures. AWS also uses hybrid to describe integration with traditional on-premises systems. NIST definition, AWS hybrid cloud

Direct Connect can provide dedicated connectivity, but it is not automatically end-to-end encryption. Choose supported encryption mechanisms and verify both endpoints and the route where required. Data-location and compliance goals require checking the complete data flow; “private” is not a compliance certificate. Direct Connect encryption

Multicloud may meet a business or technical requirement, but it adds identity, networking, operating and data-consistency work. Containers can help package application code; they do not automatically make databases, event contracts, permissions or operating procedures portable.

6. Compare costs without assuming the outcome

A workload that is idle most of the day might benefit from on-demand function execution. A consistently busy workload might use committed or provisioned capacity efficiently. Include request/duration charges, provisioned capacity, storage, networking, observability and staff time. Benchmark representative traffic and failure cases. A higher abstraction can reduce operational effort while still costing more in some usage patterns.

For a purely illustrative compute rate of $1.53/hour, 20 units running for 24 hours cost $734.40 before other charges. If the same workload could safely run on two units for the same period, that line would be $73.44. The arithmetic does not establish equivalent throughput, redundancy or latency. These are invented comparison inputs, not a current instance quote.

Defend a choice

Pick one workload above. State its duration, traffic pattern, OS/control needs, data requirements and acceptable recovery behavior. Then explain a service choice, one retained responsibility and one cost assumption to test.

A good answer uses constraints: “This job needs a custom OS component, so EC2 is a plausible fit; we will automate patching and measure fleet utilization.” Another can favor Lambda for short retryable events with bursty demand, while explicitly checking concurrency and downstream limits. A model name alone is not a design justification.