Deployment and Inference on Amazon SageMaker

Training produces an artifact; inference is where the model meets a caller and where the bill starts. On the AIF-C01 exam this is Domain 2 territory, "Task 2.1: select the appropriate deployment option for an AI/ML solution", and it is the single most service-selection-heavy task in the whole guide. The failure mode is never "you did not know SageMaker can host a model". It is that you picked serverless for an 800 MB payload, batch for a sub-second chat UI, real-time for a job that runs twice a night, or you configured a canary at 60% of the green fleet and never noticed the number is capped.

By the end of this lesson you will be able to:

• name the exactly four inference options and recite each one's payload, run-time and endpoint ceiling;
• walk the object model CreateModel → CreateEndpointConfig → CreateEndpoint and say what each field does;
• pick among the five topologies behind one endpoint (single-model, multi-model, multi-container, serial pipeline, inference components) with their container and variant limits;
• configure auto scaling on the right scalable dimension, including the metric targets AWS itself documents;
• run A/B tests, shadow variants and guardrailed blue/green rollouts, including the canary and linear percentage bounds;
• explain data capture and the four Model Monitor types, and the 2026 availability change that closes them to new customers;
• compute the real cost of a real-time endpoint, a serverless endpoint and a Provisioned Concurrency setup from AWS's own worked examples;
• wire SageMaker Projects, EKS operators and Neo into a CI/CD and edge story;
• defend a comparative verdict across real-time vs serverless vs batch vs async vs edge;
• answer ten exam-style questions written in the official voice, including two arithmetic items.

---

1. The object model: three calls and one optional fourth

1.1 What each API call owns

Deployment on SageMaker is not a single button. It is a chain of three API calls, each of which owns a different decision, plus an optional fourth for components. The exam loves the "which of these is configured where" shape, so learn the ownership table cold.

Two follow-up calls matter as much as the three above:

• UpdateEndpointWeightsAndCapacities re-weights live variants without replacing the endpoint; this is the A/B lever;
• UpdateEndpoint + DeploymentConfig swaps the whole fleet behind the endpoint using a guardrailed traffic-routing configuration.

1.2 The deployment architecture

1.3 Where the async switch lives

Presence of AsyncInferenceConfig inside the endpoint config is what makes an endpoint asynchronous-only. That field carries S3OutputPath, optional SuccessTopic/ErrorTopic SNS topics, ClientConfig (MaxConcurrentInvocationsPerInstance) and the request TTL. An endpoint created with it accepts InvokeEndpointAsync only: synchronous Invoke calls are not the contract.

• 📚 Did you know? The async request queue is backed by Amazon SQS with a documented TTL of 6 hours (RequestTTLSeconds max 21,600), and the invocation itself times out at 900 seconds by default with a maximum of 3,600 seconds. That is why AWS describes async as "queued, near real-time" rather than as a batch substitute: the queue forgets your request at the 6-hour mark even if your model would have eventually finished.

---

2. The four inference options

2.1 Real-time endpoints

A real-time endpoint is a persistent REST endpoint with millisecond latency, meant for sustained, predictable traffic. You choose the instance type and count, you enable auto scaling, you get data capture, Model Monitor, shadow variants and guardrailed rollouts. You also pay for it every second it exists: real-time billing is the instance-hour while running, metered per second with a one-minute minimum, plus EBS volume and data transfer.

2.2 Serverless Inference

Serverless removes the instance choice: you give a memory setting (1024, 2048, 3072, 4096, 5120 or 6144 MB, with vCPU scaling alongside it) and AWS scales the endpoint from traffic down to zero. Max container image is 10 GB, and each container runs 1 worker with 1 copy of the model. Idle costs nothing; the first request after an idle period pays a cold start that AWS describes only as "a few extra seconds".

The exclusions are the exam's favourite list, because each one kills a plausible-sounding option:

Worked example 1, the serverless monthly bill (AWS pricing example). 10,000,000 requests × 100 ms = 1,000,000 seconds of compute × $0.00004/second = $40.00; 10 GB of data transfer × $0.016/GB = $0.16 → $40.16 per month, and $0.00 while idle. The same traffic on a real-time endpoint bills identically whether it serves 10 requests or 10 million, which is the whole argument for serverless on intermittent load.

2.3 Batch transform

Batch transform has no endpoint. You point a transform job at data already at rest, it spins up instances, writes results to S3 as <input>.out (for example input.csv.out), and the compute disappears with the job. Payload is per batch via MaxPayloadInMB (up to 100 MB), the job ceiling is 3,600 seconds, and it is the correct answer whenever the data is available up front and nobody is waiting.

Worked example 7, batch payload arithmetic. The documented rule is MaxConcurrentTransforms × MaxPayloadInMB ≤ 100 MB: 4 × 25 MB = 100 MB is legal, 4 × 50 MB = 200 MB is rejected. Setting MaxPayloadInMB: 0 switches to chunked streaming, which the built-in algorithms do not support, so the default path is the bounded one.

2.4 Asynchronous inference

Async inference takes a large request, queues it, and lets the caller either poll S3 or receive an SNS message. It is the option with the biggest payload (1 GB) and the longest processing window (60 minutes default 900 s, maximum 3,600 s), it scales to zero between bursts, and it is the only option whose success path is asynchronous by construction.

Worked example 3: when only async fits. A video model must accept an 800 MB file, may run 40 minutes, and the caller wants an SNS notification. Real-time stops at 25 MB / 60 s; serverless stops at 4 MB; batch caps per-batch payload at 100 MB. Async at 1 GB / 60 min with S3OutputPath and SuccessTopic is the only configuration that clears all three requirements.

2.5 The ceilings side by side

Sources: deploy-model-options, hosting-faqs, async-inference-troubleshooting, batch-transform (2026).

• 📚 Did you know? AWS never publishes an exact cold-start figure. The developer guide says a request after a scale-to-zero period pays "a few extra seconds" for model download and container start, while Provisioned Concurrency units are documented as "ready within milliseconds". Any exam option that quotes a precise p95 cold-start number in seconds is inventing it.

---

3. Choosing an option: the decision matrix

The four options are only half the story. Once you know when the traffic arrives, the remaining question is how many models and how they share compute. This matrix is the exam's Task 2.1 in table form.

Check your option selection:

---

4. Endpoint topologies: five ways to share one endpoint

A single endpoint DNS name can front far more than one model. AWS documents five topologies, and the exam tests them as "which topology, which selector, which limit".

Sources: model-deploy-feature-matrix, multi-model-endpoints, multi-container-create (2026). The phrase "multi-access endpoint" appears nowhere in AWS documentation: the three real names are multi-model, multi-container and inference component.

4.1 Multi-model endpoints

An MME puts one shared serving container behind the endpoint and loads/unloads models from S3 on invoke, so you can add or retire models by uploading an object: without an endpoint update. The models must share a framework; GPU use requires NVIDIA Triton. The cost is the cold start on the first hit of a model that is not resident, and the constraint is that a serial pipeline may contain at most one MME.

4.2 Multi-container endpoints

An MCE puts up to 15 containers behind one endpoint. Mode=Direct routes with the TargetContainerHostname request header (and the IAM key sagemaker:TargetContainerHostname); Mode=Serial chains them as a pipeline. Direct mode has no GPU support, and AWS's ML Blog claims up to 90% cost saving versus running a separate endpoint per container.

4.3 Inference components

The modern answer for "several models, different resource needs, on one fleet": each component declares NumberOfCpuCoresRequired, MinMemoryRequiredInMb and CopyCount, autoscales on its own dimension (DesiredCopyCount) and may scale its copies to zero. This is also the topology that lets a foundation model and a small classifier share capacity without either one owning the instance count.

4.4 The deployment architecture under one endpoint

• 📚 Did you know? The ~10 production variants ceiling comes from an AWS Machine Learning Blog post (2022), not from a quota page: AWS publishes it as guidance rather than as a service quota. Treat it as "roughly ten, do not design past it", and remember that each variant carries its own instance type, count, weight and CloudWatch dimension.

---

5. Auto scaling, warm capacity and scale-to-zero

5.1 The standard three steps

AWS documents the same sequence for every SageMaker scaling target: register the scalable target (namespace sagemaker) → define the policy → PutScalingPolicy with either TargetTrackingScaling or StepScaling. Target tracking is the recommended policy type for production variants.

Sources: endpoint-auto-scaling-policy, endpoint-auto-scaling-add-code-define, endpoint-auto-scaling-zero-instances (2026).

5.2 Scale-to-zero and the recovery path

Scale-to-zero applies to serverless, asynchronous and inference-component copies. On a real-time variant the console enforces a minimum instance count of ≥ 1, and burstable T2 instances cannot be auto scaled at all. Recovery from zero is not instantaneous: CloudWatch emits NoCapacityInvocationFailures, the step scaling policy reacts, and AWS documents the recovery as taking "several minutes".

Worked example 6, target tracking arithmetic. Target tracking on SageMakerVariantInvocationsPerInstance with TargetValue = 70 holds each instance near 70 invocations per minute; ScaleOutCooldown 300 s and ScaleInCooldown 600 s stop the fleet from thrashing. Registering MinCapacity = 1, MaxCapacity = 8 caps spend at 8 × $0.204/h = $1.63/h for compute, the cheapest legal real-time configuration, and still infinitely more expensive than a serverless endpoint sitting at zero.

---

6. Testing and rollout: A/B, shadow variants and guardrails

6.1 A/B testing with production variants

A/B testing is just variant weights: InitialVariantWeight splits traffic (AWS's own walk-through starts at 1 / 1 = 50/50), TargetVariant pins a specific caller to a specific variant regardless of weight, and UpdateEndpointWeightsAndCapacities re-weights the split live, without replacing the endpoint. Per-variant metrics land in CloudWatch under the variant dimension.

Worked example 5: the weight walk-through. Two variants at InitialVariantWeight 1/1 → 50/50. Variant 2 wins the comparison → UpdateEndpointWeightsAndCapacities sets 25/75, moving 75% of traffic to Variant 2. Final step 0/1 gives Variant 2 everything, and Variant 1 is deleted. TargetVariant overrides the weights for a pinned caller.

6.2 Shadow deployments

ShadowProductionVariants in the endpoint config sends a sampled copy of live traffic to the candidate. The critical behaviour, and the exam's favourite single sentence on this topic, is that only the production variant's response reaches the caller; the shadow's output is logged or discarded. Shadow updates themselves are blue/green: the endpoint config changes behind the scenes.

6.3 Deployment guardrails

Guardrails are how you ship a model without betting the endpoint on it. Blue/green is the default for model updates, rolling replaces capacity in batches, and the traffic-routing type is an explicit enum.

Sources: deployment-guardrails, deployment-guardrails-blue-green-canary, deployment-guardrails-blue-green-linear (2026). Knobs: WaitIntervalInSeconds, MaximumExecutionTimeoutInSeconds, AutoRollbackConfiguration.Alarms[].

Worked example 3 (rollout): canary timing. Type: CANARY, CanarySize: 30%, WaitIntervalInSeconds: 600, TerminationWaitInSeconds: 600, MaximumExecutionTimeoutInSeconds: 1800: 30% of the green fleet takes traffic for 10 minutes, the rest shifts only if no alarm trips, the blue fleet dies 10 minutes after cutover, and the whole deployment aborts at 30 minutes. 30% is valid because the cap is ≤ 50%.

Worked example 4 (rollout), the linear floor. LinearStepSize: 20% with WaitIntervalInSeconds: 300 means 100 / 20 = 5 steps × 5 minutes = at least 25 minutes of baking, comfortably inside a one-hour MaximumExecutionTimeoutInSeconds. A step outside 10 to 50% is invalid, 5% and 60% are both rejected.

• 📚 Did you know? A canary is measured against the green fleet, not against total traffic: AWS's bound is "no more than 50% of the green fleet", which is why a question about an 8-instance green fleet accepts CAPACITY_PERCENT 50 and rejects 60 and 80. It is a two-step percentage: first of green, then of the whole endpoint.

---

7. Monitoring: data capture, Model Monitor and the drift loop

7.1 Data capture is the precondition

DataCaptureConfig lives on the endpoint config and has three fields: EnableCapture, InitialSamplingPercentage (0 to 100) and DestinationS3Uri. The SDK default sampling is 20%, records are written as JSONL under s3://…/{endpoint}/{variant}/yyyy/mm/dd/hh/, and capture halts above 75% of disk usage. No capture, no monitoring: Model Monitor reads what capture wrote.

7.2 The four monitor types

Sources: model-monitor, clarify-model-monitor-feature-attribution-drift (2026).

7.3 The 2026 availability change

7.4 The drift-to-retrain loop

Drift is not an alert you read; it is a trigger you wire. The documented path: a violation raises a CloudWatch alarm → SNS notifies → EventBridge matches the alarm and invokes Lambda or starts a CodePipeline → a SageMaker Pipeline retrains → QualityCheck / ClarifyCheck steps compare the candidate against the baselines stored in the Model Registry (DriftCheckBaselines) → a human approves → a guardrailed update ships.

• 📚 Did you know? Feature attribution drift is scored with NDCG over SHAP rankings and AWS's documented alert threshold is NDCG < 0.90: a value of 0.69 means live feature importance has diverged materially from training. Model Monitor itself only produces tabular metrics, so a model whose features are text embeddings falls outside its statistical engine entirely.

7.5 2025 to 2026 Updates

Sections 7.1 to 7.4 describe what Model Monitor does; this subsection describes what AWS did to it, because the two no longer move together. AWS's SageMaker AI end-of-support notice lists Model Monitor and Clarify, together with Mechanical Turk, Ground Truth, Augmented AI (A2I), Studio Lab, Debugger, Role Manager, Geospatial and Profiler, among the features "no longer open to new customers starting 30 July 2026". The status AWS assigns them is maintenance: existing customers keep them, no new features ship, nothing is shut down and nothing is rebranded.

Sources: the SageMaker AI features page, model-monitor-availability-change, clarify-availability-change, the AWS What's New service-availability announcements of June and September 2026, and the AWS General Reference service-lifecycle page (24 Sep 2026). The 29 vs 30 September conflict on Mechanical Turk is AWS's own and is not resolved here.

AWS defines the lifecycle vocabulary in exactly one document, and the exam tests the words more often than the dates:

Where the change bites an exam answer:

• "Create a Model Monitor schedule for a new account" → unavailable from 30 Jul 2026; the documented direction is CloudWatch metrics and anomaly detection, Amazon Evidently, an EventBridge + Lambda loop and SHAP baselines you compute yourself;
• "Evaluate a candidate's quality and bias for a new project" → Bedrock Model Evaluations is the pairing AWS now writes into objective 4.2.2 of the exam guide, with SHAP and Bedrock Guardrails named alongside Clarify;
• "Route low-confidence predictions to a human" → A2I sits on the same notice, so a new build reaches for a queue plus a review app, or Ground Truth, instead of Augmented AI;
• "Existing customer, 2026, keeps its Model Monitor schedules" → correct: maintenance means supported, and only new sign-ups are blocked.

What did not change: every mechanic memorized above still behaves as written, DataCaptureConfig with its 20 % SDK default sampling, the JSONL layout under {endpoint}/{variant}/…, the halt above 75 % disk, the four monitor types and their engines (statistics and constraints, metric constraints, Clarify bootstrap intervals, NDCG < 0.90), the drift loop through EventBridge into a SageMaker Pipeline and the Model Registry DriftCheckBaselines, and the tabular-only limitation of Model Monitor's statistical engine. The 2026 notice changes who may sign up, not what the software does, which is the entire distinction between maintenance and shutdown.

Exam-guide wording you will now meet (v1.1, published 30 Apr 2026):

• objective 1.1.3 changed its worked examples to async and serverless inference, two of this lesson's four options, so the deployment vocabulary now appears earlier in the guide than it did before v1.1;
• objective 4.2.2 reads Clarify plus Bedrock Model Evaluations, and objective 1.3.4 lists Bedrock, Amazon Quick, Kiro and SageMaker AI as the service set;
• the guide's change history states that updates reach the exam about one month after publication, and the exam is still called AIF-C01 (65 questions, 90 minutes, pass at 700/1000).

Finally, the product name: since 3 December 2024 AWS documents that "the current Amazon SageMaker has been renamed to Amazon SageMaker AI", with next-gen SageMaker (Unified Studio, Catalog, Lakehouse, zero-ETL) sitting beside it. Every API call in section 1 is untouched, CreateModel, CreateEndpointConfig and CreateEndpoint still live under the sagemaker namespace, but the console, the service page and the exam's service list say SageMaker AI.

• 📚 Did you know? AWS defines the three lifecycle states in exactly one place, the AWS General Reference service-lifecycle page, last updated 24 September 2026, and Model Monitor sits in the softest state, Maintenance. A Sunset feature already carries a published end date (SageMaker Profiler, 30 Jun 2027), while Full Shutdown means the API is gone from the portfolio. That is why "Model Monitor is discontinued" and "Model Monitor was rebranded as Bedrock Model Evaluations" are both wrong: it is closed to new customers, unchanged for existing ones, and the Bedrock pairing lives in the exam guide's wording rather than in a rename.

---

8. Sizing, cost and Inference Recommender

8.1 What the bill is made of

Prices are AWS's own worked examples and are Region-specific examples, not a rate card. Savings Plans (1-year or 3-year, $/hour commitments) cover real-time endpoints, batch transform, training and processing.

Worked example 2: the real-time monthly bill. 2 × ml.c5.xlarge × 24 h × 31 d = 1,488 instance-hours × $0.204 = $303.52; a Model Monitor job at 2.5 h × $0.922 = $2.31; data 3,100 MB in + 310 MB out ≈ $0.06 → ≈ $305.88 per month. Monitoring is under 1% of the bill; idle compute is about 99% of it. Compare that with the $40.16 serverless example and you have the entire cost argument in two numbers.

Worked example 8, cold start versus Provisioned Concurrency. Idle → scale to zero → the next request pays model download and container start ("a few extra seconds"). Buying determinism instead: Provisioned Concurrency $144 + PC compute $0.000023/s + on-demand $6 after the 150,000 free seconds = $173.20 per month, roughly 4× the on-demand compute line, and worth it only when a cold start would break an SLA.

8.2 Inference Recommender

Before you guess at an instance, run a recommendation job. A Default job takes up to 45 minutes and starts from a Model Package ARN; an Advanced job runs about 2 hours with load tests. Output: recommended instance type and count, latency, cost per hour and cost per inference, plus CPU and memory utilization: exactly the evidence a sizing question wants.

• 📚 Did you know? Real-time endpoints bill per second with a one-minute minimum while they exist, which is why the exam treats an unscaled, always-on endpoint as a cost problem rather than a performance problem. An endpoint serving nothing at 03:00 still pays instance-hours, EBS and data, and that is the sentence behind every "which option avoids idle cost" question: serverless, async and inference-component copies are the three that can reach zero.

---

9. MLOps: CI/CD, Kubernetes and the edge

9.1 SageMaker Projects and the CI/CD path

SageMaker Projects ship templates that provision AWS CodePipeline (or Jenkins), Git integration through CodeConnections and a CloudFormation stack. The canonical flow is source → build (a SageMaker Pipeline runs training and evaluation) → staging endpoint → manual approval → production endpoint, with an EventBridge rule on the Model Registry status transition PendingManualApproval → Approved. Container images follow CodeBuild → ECR → ImageVersion → EventBridge.

Check the order of the gated pipeline:

9.2 Kubernetes

The supported path is ACK-based SageMaker Operators: kubectl apply of a HostingDeployment custom resource creates or updates an endpoint, AWS documents the reconcile taking up to 15 minutes, while Kubeflow components drive training, tuning and batch transform jobs. This is the answer when the question says "the team already runs Kubernetes and wants SageMaker endpoints managed from it".

9.3 Edge: Neo, and the Edge Manager discontinuation

Neo compiles a trained model for a target with CreateCompilationJob, where TargetDevice and TargetPlatform are mutually exclusive. Cloud targets include ml_c5; edge targets include jetson_nano, rasp3b / rasp4b and coreml. Compilation survives; the managed fleet around it does not.

• 📚 Did you know? CreateCompilationJob returns a model artifact you can host either in the cloud or on a device: the same compilation job family covers ml_c5 inference instances and rasp4b boards. That symmetry is why Neo shows up in both a cloud-sizing question and an IoT question, and why TargetDevice XOR TargetPlatform is a real API rule rather than documentation prose.

---

10. Comparative verdict

---

11. Worked AWS examples with numbers

---

12. Conflicting, unverified and non-examinable facts

Separate what AWS documents from what third parties repeat. Keep this table out of your memorization set except where it says "use for the exam".

Primary sources for this lesson: the SageMaker developer guide pages deploy-model-options, model-deploy-feature-matrix, hosting-faqs, realtime-endpoints-deploy-models, serverless-endpoints, batch-transform, async-inference, multi-model-endpoints, multi-container-create, multi-container-endpoints, endpoint-auto-scaling-policy, endpoint-auto-scaling-add-code-define, endpoint-auto-scaling-zero-instances, model-ab-testing, model-shadow-deployment, deployment-guardrails*, model-monitor, model-monitor-availability-change, clarify-model-monitor-feature-attribution-drift, model-monitor-data-capture-endpoint, pipelines-quality-clarify-baseline-lifecycle, inference-recommender-recommendation-jobs, sagemaker-projects-templates-sm, kubernetes-sagemaker-operators, edge, neo-supported-devices-edge-devices; the API reference CreateEndpointConfig, InvokeEndpointAsync, DataCaptureConfig; AWS's What's New service availability announcement of June 2026; and the SageMaker pricing pages.

---

13. Real-World Case Studies

Sections 1 to 12 take their ceilings from AWS documentation. This section adds the other half of the evidence: what AWS customers published about serving models in production with those same services. Every figure below is an AWS-published customer claim, retrieved 6 October 2026 from aws.amazon.com/solutions/case-studies/* and aws.amazon.com/blogs/machine-learning/*, and each one is unaudited: "up to" is a ceiling, not an average.

13.1 Five deployment cases: services, numbers, sources

Case file 1: Forethought: do-it-yourself inference is a tax you can quote.

• Context: SupportGPT handles 30 million interactions per year with several models per customer, run by a 3-person team that also had to operate Amazon EKS through memory exceptions and outages.
• Deployment move: off its own EKS onto SageMaker multi-model endpoints (one shared container, models added by S3 upload without an endpoint update) plus Serverless Inference for the small classifiers.
• Numbers: −66 % on MME with better latency, ≈ −80 % on serverless, headline up to −80 %, and >80 % of GPU inference now on SageMaker.
• Maps to: §4.1 for the topology, §2.2 for scale-to-zero, and §8 for the cost argument: an always-on endpoint is billed whether or not traffic arrives.
• Source: aws.amazon.com/solutions/case-studies/forethought-technologies-case-study (no year is published on the page).

Case file 2: HAYAT HOLDING: an edge pattern that outlived its product name.

• Context: MDF panel manufacturing; the customer called its self-built ML environments "time-consuming and cumbersome".
• Pipeline: 194 sensors over OPC-UA → SiteWise Edge Gateway inside AWS IoT Greengrass → SageMaker Model Training with Automatic Model Tuning → Model Deployment with SageMaker Edge Manager running the model on the device.
• Numbers: $300,000 per year saved, with higher panel quality and optimised output: automatic tuning replaced manual hyperparameter sweeps across 194 inputs.
• Maps to: §9.3: the pattern (managed training, automatic tuning, compile and ship to the device) is current, but Edge Manager was discontinued on 26 April 2024, so the product name inside a 2023 case is a distractor for a 2026 build while Neo compilation survives.
• Source: AWS Machine Learning Blog, hayat-holding-uses-amazon-sagemaker-to-increase-product-quality-and-optimize-manufacturing-output-saving-300000-annually (2023).

Case file 3: Prime Focus Technologies: latency decided the placement before the option matrix ran.

• Context: the CLEAR platform holds 14 million+ assets (Disney Star, CBS, Lionsgate) and covers localization plus live cricket tagging.
• Numbers: localization cost −20 to 30 %, accuracy +20 to 30 %, turnaround −30 to 40 %.
• The deployment sentence: the first attempt used external LLM APIs whose latency was too high for live tagging, and latency "dropped dramatically" once the workload ran on AWS behind Amazon Bedrock and AWS Lambda agents.
• Maps to: the first question of §2; who is waiting? A live tagger is a sub-second caller, so any placement outside the latency budget is eliminated before real-time, serverless, async and batch are ever compared.
• Source: aws.amazon.com/solutions/case-studies/prime-focus-case-study (2025).

Case file 4: Epilot: an event-driven chain where the queue is the architecture.

• Context: energy software from Cologne, summarising long customer-email chains across 170+ utility customers.
• Pipeline: API → Amazon SQS → AWS Lambda → Amazon Bedrock (Claude Sonnet); the model was chosen with Amazon Bedrock Evaluations (human ratings across prompt versions), and a later agent writes records with humans verifying: no agent writes unattended.
• Numbers: handling time −87 %, 55,000 summaries per month at a negligible failure rate, 80 % of users say it simplifies their work, MVP in 2 months, processed data kept in an EU Region.
• Maps to: the queue logic of §2.4 in a serverless setting: decouple the caller from the work with SQS, keep the cold-tolerant piece on Lambda, and treat residency and evaluation as pre-deployment gates rather than afterthoughts.
• Source: aws.amazon.com/solutions/case-studies/epilot-genai-case-study (indexed July 2026).

Case file 5: Chronomics: the monitoring tail you must decide before you deploy.

• Context: a COVID test-result reader for which 4 months of in-house custom computer vision never reached target.
• Move: Amazon Rekognition Custom Labels (AutoML) shipped in 3 to 4 weeks at 96.5 % accuracy / 97.9 % F1, scored by DetectCustomLabels.
• The monitoring decision: threshold 0.99 → 99.6 % with 5 % of predictions discarded, threshold 0.999 → 99.87 % with 27 % discarded: precision is bought with coverage, and somebody must own the discarded tail.
• Maps to: §7, where a violation threshold is likewise a precision-versus-coverage choice, and the documented human path, A2I (GA 2020, 60+ workflows), is itself closed to new customers from 30 July 2026 (§7.5).
• Source: AWS Machine Learning Blog, chronomics-detects-covid-19-test-results-with-amazon-rekognition-custom-labels (13 Dec 2022).

13.2 Before and after, side by side

13.3 What each case proves for Task 2.1

Five rules you can carry into the exam from these files:

• Topology before instance type. Forethought saved two-thirds of its bill by changing how models share compute (multi-model, serverless), not by negotiating a better instance price;

• Idle cost is the default failure mode. Every published saving above comes from removing capacity that was running for nobody: the same arithmetic as §8's $305.88 against $40.16;

• Placement precedes option selection. Prime Focus could not evaluate any of the four options until the model ran somewhere fast enough; latency is a filter, not a score;

• A published architecture can predate a retirement. HAYAT's pipeline is correct as a pattern and stale as a product list: check the availability notice before quoting a case's service names;

• Every percentage needs a baseline and a human tail. Chronomics bought 3.1 points of precision by discarding 5 % of predictions, and Sun Finance's own first attempt scored only 61.8 % before the pipeline was split.

• 📚 Did you know? AWS's Generative AI Innovation Center publishes the only project-outcome rate in its whole case corpus: 65 % of its generative AI projects reached production in 2025 (some in as little as 45 days) out of more than 1,000 implementations, assessed with AWS's Five V's framework: Value → Visualize → Validate → Verify → Venture. The other 35 % did not ship, so plan for iteration rather than for a straight line from pilot to production.

---

Practice Questions

---