Multi-Service Tradeoff — AWS Machine Learning (MLS-C01)

Choose cost-effective schema-flexible object storage with a governed access layer (S3 + Lake Formation) over an analytics warehouse (Redshift) that forces structured ingestion and incurs compute-bound cost at training-data volume.

Whether the stated 60-second delivery latency tolerance and explicit operational-overhead constraint are satisfied by Amazon Data Firehose's built-in buffering, format conversion, and auto-scaling — without writing or managing a custom consumer application as Kinesis Data Streams would require.

Whether to build an S3-backed data lake governed by AWS Lake Formation for tag-based, per-team data-residency-compliant access control, or to consolidate training data in Amazon Redshift on the assumption that its column-level and row-level security satisfies the residency and access-control compliance requirement.

Whether the stated 90-second latency tolerance and simple format-conversion requirement justify deploying Kinesis Data Streams with a custom consumer application, or whether Amazon Data Firehose's built-in buffering, Glue-schema-based format conversion, and managed S3 delivery fully satisfies all three constraints with materially lower operational burden.

Whether to store ML training data in a cost-effective S3-backed lake with Lake Formation tag-based access control, or route it through an analytics-optimized warehouse that adds per-node cost, structured-schema requirements, and unnecessary query infrastructure for bulk sequential training data reads.

Whether the data volume and transform complexity require a managed Spark cluster (EMR) or whether serverless/managed job services (AWS Glue or SageMaker Processing) satisfy both the data-quality threshold and inference-reuse requirement at materially lower operational cost.

When text feature engineering requires domain-specific NLP extraction AND inference-time reproducibility inside a SageMaker pipeline, prefer a managed NLP service (Comprehend) invoked from a SageMaker Processing step over a general serverless ETL service that requires custom NLP scripting and cannot natively participate in SageMaker pipeline inference.

Whether the interactive latency and non-technical audience requirements are best satisfied by a fully serverless query-plus-BI stack (Athena + QuickSight SPICE) or by a provisioned columnar warehouse (Redshift) that meets query performance but introduces cluster management overhead the team cannot absorb.

Whether to use serverless managed services (AWS Glue for ETL sanitization plus SageMaker Processing for inference-reusable transforms) versus a self-managed Spark cluster (Amazon EMR) when the dataset volume is within serverless thresholds, the team has no Spark expertise, and the transforms must be reproducible at inference time.

Whether HIPAA Safe Harbor compliance in a feature engineering pipeline is satisfied by PHI de-identification before feature storage (Comprehend Medical redaction upstream of SageMaker transforms) or by encryption-at-rest plus scoped IAM access controls on the S3 output bucket.

Whether GDPR pseudonymization must be enforced at the Athena query layer (a view that hashes or nullifies PII columns, backed by the Glue Data Catalog) so that raw PII never appears in query results surfaced to QuickSight, versus whether enabling QuickSight field-level access controls or row-level security constitutes valid pseudonymization under GDPR Article 4(5).

Whether the data volume and transform complexity justify a managed Spark cluster (EMR) versus a serverless, inference-pipeline-compatible preprocessing option (SageMaker Processing or AWS Glue) given explicit team expertise and transform-reuse constraints.

Whether to persist engineered NLP features in a per-record-deletable store (SageMaker Feature Store with data-subject-keyed record identifiers) versus append-only partitioned object storage (S3 Parquet with SSE-KMS), where GDPR Article 17 requires individual feature record deletion within 30 days — not merely regional confinement and encryption.

Whether the stated interactivity, audience type, and operational-overhead constraint is satisfied by a managed BI service querying S3 directly (QuickSight + Athena) or requires standing up a self-managed compute cluster (EMR), where the cluster adds no capability the scenario demands.

Whether the inference-reuse constraint — fitted imputation and scaling transformers must be serialized as SageMaker-compatible model artifacts and reapplied identically at inference — eliminates EMR and standalone Glue in favor of SageMaker Processing, which natively serializes sklearn-compatible transformers and integrates them into SageMaker Pipelines for both training and inference.

Whether to use Amazon Comprehend's managed batch NLP API — which satisfies data-quality-fidelity and zero-infrastructure-overhead for standard entity and sentiment tasks — or deploy a custom distributed NLP pipeline on EMR that adds cluster management complexity without measurable feature-quality gain given the standard task scope.

Whether to pair serverless Athena with QuickSight for managed, shareable interactive visualization or to over-provision an EMR or Redshift cluster that adds unnecessary cluster lifecycle management when the stated constraint is audience accessibility and operational simplicity, not iterative distributed computation.

Whether to implement preprocessing with SageMaker Processing jobs (Python-native, inference-reusable as SageMaker Pipeline steps, no cluster administration) versus EMR Spark (operationally heavy, Spark-expertise-dependent, not natively composable in a SageMaker inference pipeline) when both the no-Spark-expertise constraint and the reuse-at-inference constraint are simultaneously active.

Whether PCI-DSS compliance requires custom model hosting with full infrastructure ownership (compliance misconception) or whether a purpose-built managed AI service with native PCI-DSS coverage satisfies the constraint while also matching the specific ML problem type — making the custom pipeline unjustifiable under problem-fit-validation.

Choose a purpose-built managed forecasting service with native item-level interpretability over a custom deep learning training pipeline when the dominant constraints are forecast explainability and minimal operational burden.

Whether to run SageMaker managed training on CPU-optimized instances or provision GPU-backed EC2 instances with DLAMI, when the algorithm is CPU-optimized and a cost ceiling — not raw throughput — is the dominant constraint.

Whether the observed high-variance symptom (validation loss diverging from training loss) unambiguously maps to a targeted regularization hyperparameter adjustment on the existing training job, or whether launching a SageMaker Automatic Model Tuning job to search the broader hyperparameter space is the correct response given the time and infrastructure constraints.

Whether to evaluate model quality using offline accuracy on a held-out S3 test set, or to deploy via SageMaker shadow testing and measure precision/recall against delayed ground-truth labels captured from live traffic — when both severe class imbalance and an online-impact measurement requirement are simultaneously present.

When the business problem maps directly to a supported ML problem type (probabilistic time-series demand forecasting) and the team lacks ML engineering capacity within a fixed timeline, a purpose-built managed AI service satisfies the problem-fit-validation and model-complexity-proportionality constraints; a custom SageMaker training pipeline over-engineers by imposing model selection, feature pipeline construction, hyperparameter tuning, and inference hosting overhead that is disproportionate to those constraints.

Whether the selected model and service combination produces mathematically auditable per-prediction feature attributions (SHAP values via SageMaker Clarify) versus natural-language or aggregate explanations that appear interpretable but fail the audit-visibility dimension of the compliance mandate.

Enabling SageMaker VPC mode is necessary but not sufficient for HIPAA no-internet-egress compliance — an S3 VPC Gateway Endpoint must also be provisioned so training-data traffic never traverses the public internet; additionally, XGBoost is CPU-optimized, so GPU instance selection violates the cost ceiling without improving throughput.

Whether routing SageMaker AMT trial metrics to CloudWatch with extended retention satisfies the PCI-DSS tamper-evident audit trail requirement for HPO trial records, or whether SageMaker Experiments trial metadata must be persisted to an S3 bucket with Object Lock (WORM) to meet the immutability and two-year retrievability mandate.

Whether offline evaluation using AUC-ROC on a held-out test set satisfies the SR 11-7 model validation mandate, or whether the team must additionally configure a SageMaker Clarify post-training bias report plus a shadow-mode production comparison baseline stored in S3 to satisfy the framework's offline-online parity and demographic fairness audit requirements simultaneously.

Whether to use Amazon Forecast (managed time-series service requiring no ML code) or a custom SageMaker DeepAR training pipeline when the business problem is standard demand forecasting, the team lacks ML engineering expertise, and the production deadline is fixed.

Whether model selection should be governed by maximizing validation AUC or by the SR 11-7 interpretability mandate requiring feature-level explainability for model risk validators — specifically whether SageMaker XGBoost with Clarify SHAP values or a higher-accuracy neural network ensemble satisfies the conceptual soundness requirement.

Because XGBoost is CPU-optimized and not GPU-accelerated, the correct architecture uses SageMaker managed training with c5 compute-optimized instances rather than GPU instances or self-managed EC2 plus DLAMI, which add cost and operational burden without proportional throughput gain.

Whether to resolve observed high variance by directly increasing a regularization hyperparameter (e.g., alpha or lambda) in the existing training script and re-running the SageMaker job, or by launching a SageMaker Automatic Model Tuning job to search the full hyperparameter space.

When the dominant constraint is real-world business impact measured on live production traffic with minimal deployment risk, online evaluation via SageMaker production variants is required — offline batch evaluation with imbalance-aware metrics is disqualified regardless of metric sophistication, because it cannot satisfy the offline-online-evaluation-parity constraint.

Whether the demand forecasting business problem should be framed as a managed forecasting task delegated entirely to Amazon Forecast, or as a custom time-series model task built on SageMaker, given that team ML expertise and production timeline — not algorithmic flexibility — are the binding constraints.

Whether to adopt a fully managed fraud ML service that natively produces audit-ready reason codes (Amazon Fraud Detector) or to build a custom SageMaker model augmented with a separate SageMaker Clarify explainability pipeline, when interpretability is compliance-mandated and operational overhead must be minimized.

Whether to use GPU-class instances (p3 family) or CPU-optimized instances (c5/m5 family) for a SageMaker XGBoost training job when a per-run cost ceiling is the binding constraint.