Over-Engineering — AWS Machine Learning (MLS-C01)

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 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.

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 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 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.

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.

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 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.

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.

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.