AWS MLA-C01 备考练习

Scaling parameters (for example, mean and standard deviation) must be learned only from the training set and then applied unchanged to validation/test and inference. Computing them using all splits introduces data leakage, which can make offline evaluation look better than it will in production and can destabilize retraining comparisons. The other statements describe standard, generally safe transformations and their typical benefits. The core issue is data leakage: any transformation that learns parameters from data (normalization, standardization, target encoding, learned embeddings, etc.) must be fit on the training split only. If you compute scaling statistics using validation/test data, the model indirectly “sees” distribution information it would not have at training time, which can inflate evaluation results and make performance look less stable across retrains. A safe SageMaker pattern is: - Split data (or define splits) - Fit transformers on the training split - Persist transformer artifacts (for example, in S3/Model package) - Apply the same transformer to validation/test and to the inference input path Log transforms often stabilize skewed features, and binning can reduce sensitivity to outliers (with a potential loss of granularity). - Train-only fitting is the correct practice to avoid leakage and keep training/inference consistent. - Log transform skew is commonly used to reduce skew and improve stability for some models. - Binning for robustness can reduce outlier impact and help simple models capture nonlinear effects. - All-splits statistics is unsafe because it contaminates evaluation with test/validation information.

缩放参数（例如平均值和标准差）必须仅从训练集中学习，然后不变地应用于验证/测试和推理。使用所有分割来计算它们会引入 data leakage，这可以使离线评估看起来比生产中更好，并且可能会破坏再训练比较的稳定性。其他陈述描述了标准的、通常安全的转换及其典型好处。 核心问题是 data leakage：任何从数据中学习参数的转换（归一化、标准化、目标编码、学习嵌入等）都必须仅适合训练分割。如果使用验证/测试数据计算缩放统计数据，模型会间接“看到”训练时不会有的分布信息，这可能会夸大评估结果，并使重新训练时的性能看起来不太稳定。 安全的 SageMaker 模式是： - 分割数据（或定义分割） - 在训练中安装变形金刚 - 保留变压器工件（例如，在 S3/Model 包中） - 将相同的变压器应用于验证/测试和推理输入路径 对数变换通常会稳定倾斜的特征，而分箱可以降低对异常值的敏感性（可能会损失粒度）。 - 仅训练拟合是避免泄漏并保持训练/推理一致的正确做法。 - 对数变换倾斜通常用于减少倾斜并提高某些模型的稳定性。 - 稳健性分箱可以减少异常值影响并帮助简单模型捕捉非线性效应。 - 所有分割统计数据是不安全的，因为它会污染测试/验证信息的评估。

スケーリング パラメーター (平均値や標準偏差など) はトレーニング セットからのみ学習し、変更せずに検証/テストおよび推論に適用する必要があります。すべての分割を使用してそれらを計算すると、data leakage が導入され、オフライン評価が本番環境よりも良く見える可能性があり、再トレーニング比較が不安定になる可能性があります。他のステートメントでは、標準的で一般に安全な変換とその一般的な利点について説明します。 中心的な問題は data leakage です。データからパラメーターを学習する変換 (正規化、標準化、ターゲット エンコーディング、学習された埋め込みなど) は、トレーニング スプリットにのみ適合する必要があります。検証/テスト データを使用してスケーリング統計を計算する場合、モデルはトレーニング時には存在しない分布情報を間接的に「認識」するため、評価結果が膨らみ、再トレーニング後のパフォーマンスの安定性が低下する可能性があります。 安全な SageMaker パターンは次のとおりです。 - データを分割する (または分割を定義する) - トレーニングスプリットに変圧器を取り付けます - トランスフォーマーのアーティファクトを保持します (たとえば、S3/Model パッケージ内) - 同じトランスフォーマーを検証/テストと推論入力パスに適用します 対数変換は多くの場合、偏った特徴を安定させ、ビニングは外れ値に対する感度を下げることができます (粒度が失われる可能性があります)。 - トレーニングのみのフィッティングは、漏れを防ぎ、トレーニングと推論の一貫性を保つための正しい方法です。 - 対数変換スキューは、スキューを削減し、一部のモデルの安定性を向上させるために一般的に使用されます。 - ロバスト性を高めるためのビニングにより、外れ値の影響を軽減し、単純なモデルが非線形効果を捉えるのに役立ちます。 - 全分割統計は、テスト/検証情報による評価が汚染されるため、安全ではありません。

Because the endpoint has no outbound internet and needs proprietary compiled dependencies, the inference environment must be fully self-contained. Packaging the required OS libraries and tokenizer into a custom Docker image in Amazon ECR satisfies the private, auditable image requirement. That image can then be deployed to an autoscaling SageMaker real-time endpoint inside the VPC to meet the latency SLA. The core decision is whether a SageMaker provided container can satisfy the runtime requirements without modification. When inference needs proprietary binaries, custom system packages, or nonstandard runtime components that cannot be safely installed at startup (especially with no outbound internet), you should use a bring-your-own container (BYOC). In this scenario, a custom image built with the compiled tokenizer and required OS packages can be stored in private Amazon ECR for auditability and deployed as a SageMaker real-time endpoint with VPC configuration and autoscaling to meet the p95 latency and throughput requirements. SageMaker provided deep learning containers are best when your dependencies can be expressed through supported mechanisms (and network access/policy allows installation). - Startup pip installs conflicts with the no-outbound-internet requirement and proprietary binary dependency. - Batch Transform is not intended for low-latency, always-on real-time SLAs. - EKS deployment can work technically but adds operational overhead and is not the best fit for the stated preference for an AWS-native managed endpoint.

由于 endpoint 没有出站互联网并且需要专有的编译依赖项，因此推理环境必须完全独立。将所需的操作系统库和分词器打包到 Amazon ECR 中的自定义 Docker 映像中可以满足私有、可审核的映像要求。然后，可以将该映像部署到 VPC 内的 autoscaling SageMaker 实时 endpoint 以满足延迟 SLA。 核心决定是 SageMaker 提供的容器是否可以在不修改的情况下满足运行时要求。当推理需要专有二进制文件、自定义系统包或无法在启动时安全安装的非标准运行时组件（尤其是没有出站互联网）时，您应该使用自带容器 (BYOC)。 在此场景中，使用编译的标记生成器和所需操作系统包构建的自定义映像可以存储在私有 Amazon ECR 中以实现可审核性，并部署为具有 VPC 配置和 autoscaling 的 SageMaker 实时 endpoint，以满足 p95 延迟和吞吐量要求。当您的依赖项可以通过支持的机制（并且网络访问/策略允许安装）表达时，SageMaker 提供的 Deep Learning Containers 是最好的。 - 启动 pip 安装与无出站互联网要求和专有二进制依赖项冲突。 - Batch Transform 不适用于低延迟、始终在线的实时 SLA。 - EKS 部署在技术上可以工作，但会增加运营开销，并且不是最适合 AWS 原生托管 endpoint 的规定首选项。

endpoint には送信インターネットがなく、独自にコンパイルされた依存関係が必要なため、推論環境は完全に自己完結型である必要があります。必要な OS ライブラリとトークナイザーを Amazon ECR のカスタム Docker イメージにパッケージ化すると、プライベートで監査可能なイメージの要件が満たされます。その後、そのイメージを VPC 内の autoscaling SageMaker リアルタイム endpoint にデプロイして、レイテンシー SLA を満たすことができます。 重要な決定は、SageMaker が提供するコンテナが変更せずに実行時の要件を満たすことができるかどうかです。推論に独自のバイナリ、カスタム システム パッケージ、または起動時に安全にインストールできない非標準のランタイム コンポーネントが必要な場合 (特に送信インターネットがない場合)、Bring Your Own Container (BYOC) を使用する必要があります。 このシナリオでは、コンパイルされたトークナイザーと必要な OS パッケージで構築されたカスタム イメージを監査可能にするためにプライベート Amazon ECR に保存し、VPC 構成および autoscaling を備えた SageMaker リアルタイム endpoint としてデプロイして、p95 のレイテンシとスループットの要件を満たすことができます。SageMaker が提供する Deep Learning Containers は、サポートされているメカニズムを通じて依存関係を表現できる (ネットワーク アクセス/ポリシーによってインストールが許可されている) 場合に最適です。 - 起動時の pip インストールは、アウトバウンドインターネット要件および独自のバイナリ依存関係と競合します。 - Batch Transform は、低遅延の常時オンのリアルタイム SLA を目的としていません。 - EKS デプロイメントは技術的には機能しますが、運用上のオーバーヘッドが追加されるため、AWS ネイティブで管理される endpoint の指定された設定には最適ではありません。

The errors indicate three distinct failure modes: GPU out-of-memory, input parsing errors, and unstable optimization (NaN loss). The best mitigations are to reduce GPU memory pressure in the training loop, validate/clean input data before it reaches the training container, and adjust optimization settings to improve numerical stability and convergence. Troubleshooting training failures in SageMaker starts by mapping the error to the resource or pipeline stage that causes it. CUDA OOM is almost always driven by model size and per-step memory (batch size/sequence length/activations), so you mitigate by reducing memory use in the training code rather than changing unrelated storage settings. Parser errors indicate malformed or inconsistent input (schema/field count/quoting), which is best handled by adding an explicit validation/cleaning step (for example, a SageMaker Processing job or AWS Glue job) that produces a known-good dataset for training. NaN loss typically indicates divergence or numeric instability, so mitigation is to adjust optimizer hyperparameters (lower learning rate) and add stabilizers such as gradient clipping. Key takeaway: pick mitigations that directly address the failure signal (GPU memory, data validity, optimization stability) and fit stated constraints. - OK (GPU OOM) Reducing batch size or using gradient accumulation lowers GPU memory per step. - OK (Input errors) A preprocessing validation/cleaning step prevents malformed rows from crashing the loader. - OK (Convergence) Lower learning rate and gradient clipping help avoid divergence that yields NaNs. - NO (Wrong resource) Increasing EBS volume affects disk capacity, not GPU memory or CSV parsing. - NO (Violates constraint) Switching to a larger GPU instance conflicts with the fixed instance-type budget control. - NO (Different goal) Managed Spot Training reduces cost but does not resolve OOM, parsing, or NaN loss.

这些错误表明三种不同的故障模式：GPU 内存不足、输入解析错误和不稳定的优化（NaN loss）。最好的缓解措施是减少训练循环中的 GPU 内存压力，在输入数据到达训练容器之前验证/清理输入数据，并调整优化设置以提高数值稳定性和收敛性。 对 SageMaker 中的训练失败进行故障排除首先将错误映射到导致错误的资源或管道阶段。 CUDA OOM 几乎总是由模型大小和每步内存（批量大小/序列长度/激活）驱动，因此您可以通过减少训练代码中的内存使用而不是更改不相关的存储设置来缓解。解析器错误表示输入格式错误或不一致（架构/字段计数/引用），最好的处理方法是添加显式验证/清理步骤（例如，SageMaker 处理作业或 AWS Glue 作业），生成已知良好的训练数据集。 NaN 损失通常表示发散或数值不稳定，因此缓解方法是调整优化器超参数（较低的学习率）并添加稳定器（例如梯度裁剪）。 关键要点：选择直接解决故障信号（GPU 内存、数据有效性、优化稳定性）并符合规定约束的缓解措施。 - 确定（GPU OOM）减少批量大小或使用梯度累积会降低每步的 GPU 内存。 - OK（输入错误）预处理验证/清理步骤可防止格式错误的行导致加载程序崩溃。 - OK（收敛）较低的学习率和梯度裁剪有助于避免产生 NaN 的发散。 - 否（资源错误）增加 EBS 卷会影响磁盘容量，而不是 GPU 内存或 CSV 解析。 - 否（违反约束）切换到更大的 GPU 实例与固定实例类型预算控制冲突。 - 否（不同目标）托管 Spot Training 降低了成本，但无法解决 OOM、解析或 NaN loss问题。

エラーは、GPU のメモリ不足、入力解析エラー、不安定な最適化 (NaN 損失) という 3 つの異なる障害モードを示します。最善の緩和策は、トレーニング ループでの GPU メモリの負荷を軽減し、入力データがトレーニング コンテナに到達する前に検証/クリーンアップし、最適化設定を調整して数値の安定性と収束を向上させることです。 SageMaker でのトレーニング失敗のトラブルシューティングは、エラーをその原因となっているリソースまたはパイプライン ステージにマッピングすることから始まります。CUDA OOM は、ほとんどの場合、モデル サイズとステップごとのメモリ (バッチ サイズ/シーケンスの長さ/アクティベーション) によって左右されるため、無関係なストレージ設定を変更するのではなく、トレーニング コードでのメモリ使用量を減らすことで軽減します。パーサー エラーは、不正な形式または一貫性のない入力 (スキーマ/フィールド数/引用符) を示します。これは、トレーニング用に既知の良好なデータセットを生成する明示的な検証/クリーニング ステップ (SageMaker 処理ジョブや AWS Glue ジョブなど) を追加することで最もよく処理されます。NaN 損失は通常、発散または数値の不安定性を示しているため、オプティマイザーのハイパーパラメーターを調整し (学習率を下げる)、勾配クリッピングなどのスタビライザーを追加することで軽減します。 重要なポイント: 障害シグナル (GPU メモリ、データの有効性、最適化の安定性) に直接対処する緩和策を選択し、規定の制約に適合させます。 - OK (GPU OOM) バッチ サイズを減らすか、勾配累積を使用すると、ステップごとの GPU メモリが減少します。 - OK (入力エラー) 前処理の検証/クリーニング手順により、不正な行によってローダーがクラッシュするのを防ぎます。 - OK (収束) 低い学習率と勾配クリッピングにより、NaN を生成する発散を回避できます。 - NO (間違ったリソース) EBS ボリュームを増やすと、GPU メモリや CSV 解析ではなく、ディスク容量に影響します。 - NO (制約に違反) より大きな GPU インスタンスへの切り替えは、固定インスタンス タイプのバジェット制御と競合します。 - NO (目標が異なる) マネージド Spot Training はコストを削減しますが、OOM、解析、または NaN 損失は解決しません。

The best fit is the principle of least privilege: explicitly allow only the approved Region and the specific S3 locations that may be used. An AWS Organizations SCP can prevent using services in disallowed Regions, and an allow-list policy limits where identities can read/write data, reducing the chance of accidental noncompliant storage or processing. The core principle is least privilege: identities should be permitted to operate only within the minimum set of Regions and storage locations required for the workflow. To enforce data residency, use preventive guardrails that block actions rather than only detecting them after the fact. Practically, this means: - Use an AWS Organizations SCP to deny API calls when aws:RequestedRegion is not eu-west-1 (for Regional services such as SageMaker). - Use IAM and/or S3 bucket policies to allow access only to the approved S3 buckets/prefixes used for the ML pipeline. This combination reduces the permitted “blast radius” so data cannot be easily processed or written outside approved boundaries, which is stronger than monitoring-only or encryption-only approaches. - Monitoring-only alarms can detect noncompliant activity but do not prevent it. - Encryption-only with KMS does not stop copying or processing data in other Regions. - Data minimization (dropping PII) reduces sensitivity but does not enforce residency controls.

最适合的是最小特权原则：明确允许仅批准的区域和可能使用的特定 S3 位置。 AWS Organizations SCP 可以防止在不允许的区域中使用服务，并且允许列表策略限制身份可以读取/写入数据的位置，从而减少意外不合规存储或处理的可能性。 核心原则是最小特权：应仅允许身份在工作流所需的最小区域和存储位置集内运行。为了强制执行数据驻留，请使用预防性护栏来阻止操作，而不是仅在事后检测它们。 实际上，这意味着： - 当 aws:RequestedRegion 不是 eu-west-1 时，使用 AWS Organizations SCP 拒绝 API 调用（对于 SageMaker 等区域服务）。 - 使用 IAM 和/或 S3 存储桶策略仅允许访问用于 ML 管道的已批准的 S3 存储桶/前缀。 这种组合减少了允许的“爆炸半径”，因此数据无法在批准的边界之外轻松处理或写入，这比仅监控或仅加密的方法更强。 - 仅监控警报可以检测不合规活动，但不能阻止它。 - 仅使用 KMS 加密不会停止在其他区域复制或处理数据。 - 数据最小化（删除 PII）会降低敏感度，但不会强制执行驻留控制。

最適なのは、最小特権の原則です。承認されたリージョンと、使用できる特定の S3 の場所のみを明示的に許可します。AWS Organizations SCP は、許可されていないリージョンでのサービスの使用を防ぐことができ、許可リスト ポリシーにより、ID がデータの読み取り/書き込みを行える場所を制限し、偶発的に非準拠のストレージや処理が発生する可能性を減らします。 基本原則は最小限の特権です。ID は、ワークフローに必要な最小限のリージョンと保管場所のセット内でのみ操作を許可される必要があります。データの常駐を強制するには、アクションを事後的に検出するのではなく、アクションをブロックする予防的なガードレールを使用します。 実際には、これは次のことを意味します。 - aws:RequestedRegion が eu-west-1 ではない場合 (SageMaker などの地域サービスの場合)、AWS Organizations SCP を使用して API コールを拒否します。 - IAM および/または S3 バケット ポリシーを使用して、ML パイプラインに使用される承認済みの S3 バケット/プレフィックスへのアクセスのみを許可します。 この組み合わせにより、許可される「爆発範囲」が減少するため、承認された境界外でデータを簡単に処理したり書き込んだりすることができなくなります。これは、監視のみや暗号化のみのアプローチよりも強力です。 - 監視のみのアラームは、非準拠のアクティビティを検出できますが、それを防止することはできません。 - KMS による暗号化のみでは、他のリージョンでのデータのコピーや処理は停止されません。 - データの最小化 (PII の削除) により機密性は低下しますが、居住地の制御は強制されません。

This approach externalizes configuration from the built artifact so the same container image can be promoted across environments without modification. Environment-specific values are supplied at deploy time through environment variables and managed secrets, which reduces configuration drift between dev, test, and prod. That directly supports reproducible, consistent deployments. The core concept is reproducibility: build once, deploy many. When you keep the container image identical across dev/test/prod and inject environment-specific settings at deployment time, you can reliably reproduce the same workload behavior in each environment and promote releases without rebuilding. In AWS ML deployments, this is typically achieved by: - Passing non-secret configuration as environment variables (or parameter references). - Storing secrets in Secrets Manager (or SSM Parameter Store SecureString) and retrieving them at runtime with the endpoint’s IAM role. This pattern also improves security, but the primary principle demonstrated is that deployments remain consistent and repeatable because configuration is separated from the artifact. - Least privilege is about scoping IAM permissions, not primarily about externalizing configuration for consistent promotion. - Defense in depth focuses on layered controls (network, encryption, detection) rather than repeatable build/promote mechanics. - Separation of duties is about splitting responsibilities (for example, deploy vs approve) rather than how configuration values are supplied.

这种方法从构建的工件中外部化配置，因此可以在不进行修改的情况下跨环境提升相同的容器映像。特定于环境的值在部署时通过环境变量和托管机密提供，这减少了开发、测试和生产之间的配置偏差。这直接支持可重复、一致的部署。 核心概念是可重复性：构建一次，部署多次。当您在开发/测试/生产中保持容器映像相同并在部署时注入特定于环境的设置时，您可以在每个环境中可靠地重现相同的工作负载行为，并在无需重建的情况下升级版本。 在 AWS ML 部署中，这通常通过以下方式实现： - 将非秘密配置作为环境变量（或参数引用）传递。 - 将机密存储在 Secrets Manager（或 SSM 参数存储 SecureString）中，并在运行时使用 endpoint 的 IAM 角色检索它们。 此模式还提高了安全性，但演示的主要原则是部署保持一致和可重复，因为配置与工件分离。 - 最小权限是关于确定 IAM 权限的范围，而不是主要关于外部化配置以实现一致升级。 - 深度防御侧重于分层控制（网络、加密、检测），而不是可重复的构建/升级机制。 - 职责分离是指职责的划分（例如，部署与批准），而不是如何提供配置值。

このアプローチでは、構築されたアーティファクトから構成が外部化されるため、同じコンテナー イメージを変更せずに環境間で昇格できます。環境固有の値は、デプロイ時に環境変数と管理シークレットを通じて提供されるため、開発、テスト、本番間の構成のずれが軽減されます。これにより、再現可能で一貫性のある展開が直接サポートされます。 中心となる概念は再現性です。つまり、一度構築すれば、何度もデプロイできます。開発/テスト/本番全体でコンテナー イメージを同一に保ち、デプロイメント時に環境固有の設定を挿入すると、各環境で同じワークロードの動作を確実に再現し、再構築することなくリリースを促進できます。 AWS ML デプロイメントでは、これは通常、次の方法で実現されます。 - 非シークレット設定を環境変数 (またはパラメーター参照) として渡します。 - Secrets Manager (または SSM Parameter Store SecureString) にシークレットを保存し、endpoint の IAM ロールを使用して実行時にシークレットを取得します。 このパターンではセキュリティも向上しますが、実証されている主な原理は、構成が成果物から分離されているため、デプロイメントの一貫性と反復性が維持されるということです。 - 最小権限は IAM 権限のスコープに関するものであり、主に一貫したプロモーションのための構成の外部化に関するものではありません。 - 多層防御では、反復可能なビルド/プロモートの仕組みではなく、階層化された制御 (ネットワーク、暗号化、検出) に焦点を当てます。 - 職務の分離とは、構成値の提供方法ではなく、責任の分割 (たとえば、デプロイと承認) に関するものです。

A repeatable Data Wrangler workflow depends on persisting the flow definition (the .flow file) as the source of truth for the transformation graph. Exports (Processing job/Pipelines) use that flow to apply the same steps on new data, and validation artifacts can be saved for traceability. Deleting the flow undermines reruns and auditability. In SageMaker Data Wrangler, the .flow file is the durable, declarative definition of your feature engineering steps (imports, transforms, joins, encodings, etc.). When you export a Data Wrangler workflow (for example, to a SageMaker Processing job or a SageMaker Pipelines step), the runtime uses the flow definition to reproduce the same transformations on future datasets. To make the workflow repeatable and auditable: - Version and retain the .flow file (for example, in S3 with versioning). - Use Data Wrangler’s data quality/insights to validate assumptions and store the generated artifacts. - Parameterize inputs/outputs (such as S3 URIs) so the same flow runs across different partitions or dates. Keeping the flow artifact is a core requirement for reproducibility; export alone is not a substitute for the flow definition. - Keep flow as source of truth is valid because versioned .flow captures the exact transform graph. - Validate and persist reports is valid because saved artifacts support repeatable checks and audits. - Export with parameterized S3 URIs is valid because it enables rerunning the same transforms on new data. - Delete the .flow after export is unsafe because the export relies on the flow definition to reproduce transforms.

可重复的 Data Wrangler 工作流程取决于将流定义（.flow 文件）保留为转换图的真实来源。导出（处理作业/Pipelines）使用该流程对新数据应用相同的步骤，并且可以保存验证工件以进行跟踪。删除流程会破坏重新运行和可审核性。 在 SageMaker Data Wrangler 中，.flow 文件是特征工程步骤（导入、转换、连接、编码等）的持久的声明性定义。当您导出 Data Wrangler 工作流程（例如，导出到 SageMaker 处理作业或 SageMaker Pipelines 步骤）时，运行时将使用流程定义在未来数据集上重现相同的转换。 为了使工作流程可重复且可审核： - 版本并保留 .flow 文件（例如，在具有版本控制的 S3 中）。 - 使用 Data Wrangler 的数据质量/见解来验证假设并存储生成的工件。 - 参数化输入/输出（例如 S3 URI），以便同一流程跨不同分区或日期运行。 保持流动伪影是再现性的核心要求；单独的导出并不能替代流定义。 - 保持流作为事实来源是有效的，因为版本化的 .flow 捕获了精确的转换图。 - 验证和保留报告是有效的，因为保存的工件支持可重复的检查和审计。 - 使用参数化 S3 URI 导出是有效的，因为它允许对新数据重新运行相同的转换。 - 导出后删除 .flow 是不安全的，因为导出依赖于流定义来重现转换。

反復可能な Data Wrangler ワークフローは、変換グラフの信頼できるソースとしてフロー定義 (.flow ファイル) を永続化することに依存します。エクスポート (処理ジョブ/Pipelines) では、そのフローを使用して新しいデータに同じ手順を適用し、検証アーティファクトをトレーサビリティのために保存できます。フローを削除すると、再実行と監査可能性が損なわれます。 SageMaker Data Wrangler では、.flow ファイルは、特徴エンジニアリング ステップ (インポート、変換、結合、エンコードなど) の耐久性のある宣言的な定義です。Data Wrangler ワークフローを (たとえば、SageMaker Processing ジョブまたは SageMaker Pipelines ステップに) エクスポートすると、ランタイムはフロー定義を使用して、今後のデータセットで同じ変換を再現します。 ワークフローを反復可能かつ監査可能にするには: - .flow ファイルをバージョン管理して保持します (たとえば、バージョン管理を備えた S3 など)。 - Data Wrangler のデータ品質/洞察を使用して仮説を検証し、生成されたアーティファクトを保存します。 - 入力/出力 (S3 URI など) をパラメータ化して、同じフローが異なるパーティションまたは日付にわたって実行されるようにします。 フロー アーティファクトを維持することは、再現性の中核となる要件です。エクスポートだけではフロー定義の代わりにはなりません。 - バージョン管理された .flow は正確な変換グラフをキャプチャするため、フローを信頼できる情報源として保持することが有効です。 - 保存されたアーティファクトは反復可能なチェックと監査をサポートしているため、レポートの検証と永続化は有効です。 - パラメータ化された S3 URI を使用したエクスポートは、新しいデータに対して同じ変換を再実行できるため有効です。 - エクスポートは変換を再現するためにフロー定義に依存しているため、エクスポート後に .flow を削除するのは安全ではありません。

The exhibit shows the CodeBuild role can fetch a production database secret and can directly promote a model package and assume a production deploy role. The best security improvement is to separate duties: keep the build role restricted to building artifacts and use a tightly scoped, gated promotion/deploy role for production changes. Securing ML CI/CD pipelines relies on least privilege, separation of duties, and controlled promotion of artifacts. In the exhibit, the same CodeBuild role can retrieve a production secret (line 2 with a prod secret ARN on line 3) and can also promote artifacts and reach production permissions (it can call sagemaker:UpdateModelPackage on * in lines 4–5 and can sts:AssumeRole into ProdDeployRole in lines 6–7). A safer approach is to: - Limit the build role to training/build steps and non-prod resources. - Remove access to production secrets from the build role. - Perform model approval/promotion and production deployment using a separate, tightly scoped role (often behind a manual approval or controlled pipeline stage). Key takeaway: the risky capability is explicitly visible in lines 2–7, so the fix is to restrict roles and promotion permissions, not just add encryption or logging. - KMS key rotation only doesn’t remove the build role’s ability to read the prod secret shown in lines 2–3. - Putting secrets in S3 is not an improvement over Secrets Manager and still wouldn’t address the overbroad promotion/deploy permissions in lines 4–7. - More logging can help detect misuse but does not prevent the build role from using the permissions shown in the exhibit.

图表显示 CodeBuild 角色可以获取生产数据库机密，并且可以直接升级模型包并承担生产部署角色。最好的安全改进是分离职责：将构建角色限制为构建工件，并为生产更改使用范围严格、门控的升级/部署角色。 确保 ML CI/CD Pipelines 的安全依赖于最小特权、职责分离和受控的工件提升。在图中，相同的 CodeBuild 角色可以检索生产密钥（第 2 行，第 3 行有生产密钥 ARN），还可以升级工件并获得生产权限（它可以在第 4-5 行 * 上调用 sagemaker:UpdateModelPackage，并可以在第 6-7 行将 sts:AssumeRole 放入 ProdDeployRole 中）。 更安全的方法是： - 将构建角色限制为培训/构建步骤和非产品资源。 - 从构建角色中删除对生产机密的访问权限。 - 使用单独的、范围严格的角色执行模型批准/升级和生产部署（通常位于手动批准或受控管道阶段之后）。 关键要点：有风险的能力在第 2-7 行中明确可见，因此解决方案是限制角色和升级权限，而不仅仅是添加加密或日志记录。 - KMS 密钥轮换仅不会消除构建角色读取第 2-3 行中所示的产品机密的能力。 - 将机密放入 S3 并不是对 Secrets Manager 的改进，并且仍然无法解决第 4-7 行中过于宽泛的升级/部署权限问题。 - 更多日志记录可以帮助检测误用，但不会阻止构建角色使用图中所示的权限。

この展示では、CodeBuild ロールが実稼働データベースのシークレットをフェッチし、モデル パッケージを直接プロモートして実稼働展開ロールを引き受けることができることを示しています。最善のセキュリティ改善は、職務を分離することです。つまり、ビルド ロールをアーティファクトの構築に限定し、本番環境の変更に対しては、厳密に範囲を限定してゲート制御されたプロモーション/デプロイ ロールを使用します。 ML CI/CD Pipelines のセキュリティは、最小限の特権、職務の分離、およびアーティファクトの制御されたプロモーションに依存しています。展示では、同じ CodeBuild ロールがプロダクション シークレットを取得でき (行 2、行 3 にプロダクション シークレット ARN が含まれています)、アーティファクトをプロモートしてプロダクション アクセス許可に到達することもできます (行 4 ～ 5 の * で sagemaker:UpdateModelPackage を呼び出すことができ、行 6 ～ 7 で sts:AssumeRole を ProdDeployRole に呼び出すことができます)。 より安全なアプローチは次のとおりです。 - ビルドの役割をトレーニング/ビルド ステップおよび本番以外のリソースに制限します。 - プロダクション シークレットへのアクセスをビルド ロールから削除します。 - 個別の厳密に範囲が限定された役割 (多くの場合、手動承認または制御されたパイプライン ステージの背後で) を使用して、モデルの承認/プロモーションおよび運用展開を実行します。 重要なポイント: 危険な機能は 2 ～ 7 行目に明示されているため、暗号化やログ記録を追加するだけでなく、ロールと昇格権限を制限することが修正です。 - KMS キーのローテーションのみでは、2 ～ 3 行目に示されている prod シークレットを読み取るビルド ロールの機能は削除されません。 - S3 にシークレットを置くことは Secrets Manager の改善ではなく、行 4 ～ 7 の広範なプロモーション/デプロイ許可にはまだ対応していません。 - より多くのログ記録は不正使用の検出に役立ちますが、ビルド ロールが展示に示されている権限を使用することを妨げるものではありません。

When policies require no internet access, SageMaker training and inference must run in private subnets without internet routes and rely on private connectivity (VPC endpoints) for AWS service access. Allowing internet egress (even via NAT) breaks network isolation because the container can reach external networks. The core principle is enforcing network isolation by preventing any internet egress path for training and inference while still allowing access to required AWS services over private networking. In SageMaker, this typically means placing jobs/endpoints in private subnets, removing routes to an internet gateway/NAT gateway, and using VPC endpoints to reach services such as S3 (Gateway endpoint), ECR (Interface endpoints), and CloudWatch Logs (Interface endpoint). If additional packages or artifacts are needed, they must be pre-packaged into the container image or stored in S3 and accessed through those endpoints. Allowing a NAT gateway so containers can fetch dependencies at runtime is an anti-pattern because it reintroduces outbound internet connectivity. - Private subnets supports isolation when there is no IGW/NAT route. - VPC endpoints provide private access to S3/ECR/CloudWatch without internet egress. - Packaged dependencies avoids needing public package repositories during startup.

当策略不需要互联网访问时，SageMaker 训练和推理必须在没有互联网路由的私有子网中运行，并依赖私有连接（VPC 终端节点）来访问 AWS 服务。允许互联网出口（甚至通过 NAT）会破坏网络隔离，因为容器可以访问外部网络。 核心原则是通过阻止任何用于训练和推理的互联网出口路径来实施网络隔离，同时仍然允许通过专用网络访问所需的 AWS 服务。在 SageMaker 中，这通常意味着将作业/端点放置在私有子网中，删除到互联网网关/NAT 网关的路由，以及使用 VPC 端点访问 S3（网关 endpoint）、ECR（接口端点）和 CloudWatch Logs（接口 endpoint）等服务。如果需要其他包或工件，则必须将它们预先打包到容器映像中或存储在 S3 中并通过这些端点进行访问。 允许 NAT 网关以便容器可以在运行时获取依赖项是一种反模式，因为它重新引入了出站互联网连接。 - 私有子网在没有 IGW/NAT 路由时支持隔离。 - VPC 端点提供对 S3/ECR/CloudWatch 的私有访问，无需互联网出口。 - 打包依赖项避免在启动期间需要公共包存储库。

ポリシーがインターネット アクセスを必要としない場合、SageMaker のトレーニングと推論は、インターネット ルートのないプライベート サブネットで実行し、AWS サービス アクセスのためにプライベート接続 (VPC エンドポイント) に依存する必要があります。インターネット下りを (NAT 経由であっても) 許可すると、コンテナーが外部ネットワークに到達できるため、ネットワークの分離が破壊されます。 基本的な原則は、プライベート ネットワーク経由で必要な AWS サービスへのアクセスを許可しながら、トレーニングと推論のためのインターネット下りパスを防止することでネットワーク分離を強化することです。SageMaker では、これは通常、プライベート サブネットにジョブ/エンドポイントを配置し、インターネット ゲートウェイ/NAT ゲートウェイへのルートを削除し、VPC エンドポイントを使用して S3 (ゲートウェイ endpoint)、ECR (インターフェイス エンドポイント)、CloudWatch Logs (インターフェイス endpoint) などのサービスに到達することを意味します。追加のパッケージまたはアーティファクトが必要な場合は、それらをコンテナー イメージに事前にパッケージ化するか、S3 に保存し、それらのエンドポイントを通じてアクセスする必要があります。 コンテナが実行時に依存関係を取得できるように NAT ゲートウェイを許可することは、アウトバウンドのインターネット接続を再導入するため、アンチパターンです。 - プライベート サブネットは、IGW/NAT ルートがない場合の分離をサポートします。 - VPC エンドポイントは、インターネット下りなしで S3/ECR/CloudWatch へのプライベート アクセスを提供します。 - パッケージ化された依存関係により、起動時にパブリック パッケージ リポジトリが必要なくなります。

ROC AUC summarizes a model’s ability to discriminate between classes across all possible classification thresholds. Because Model A’s AUC is higher than Model B’s on the same test set, Model A is the better overall discriminator in a threshold-independent sense. This does not guarantee it will be best at a specific operating threshold or metric like precision. ROC curves plot true positive rate against false positive rate as the decision threshold varies, and AUC compresses that curve into a single, threshold-independent number. Interpreting AUC at a high level: it reflects how well the model separates (ranks) positive examples above negative examples across all thresholds. Therefore, when two models are evaluated on the same dataset, the model with the higher AUC (0.91 vs. 0.87) has better overall discriminative performance. AUC alone does not guarantee better performance at any particular threshold, nor does it directly determine threshold-dependent metrics such as accuracy, precision, or recall; those depend on the chosen operating point and class prevalence. The key takeaway is that higher AUC means better overall ranking/separation, not universal superiority for every threshold or metric. - Any-threshold accuracy is incorrect because accuracy depends on a specific threshold and class balance. - Precision guarantee is incorrect because precision is threshold- and prevalence-dependent and is better assessed with a PR curve. - Dominates ROC everywhere is incorrect because a higher AUC does not require one ROC curve to be better at every point.

ROC AUC 总结了模型在所有可能的分类阈值之间区分类别的能力。由于在相同测试集上模型 A 的 AUC 高于模型 B，因此从阈值无关的意义上来说，模型 A 是更好的整体判别器。这并不能保证它在特定的操作阈值或类似精度的指标下是最好的。 ROC 曲线绘制了随着决策阈值变化而变化的真阳性率与假阳性率的关系，而 AUC 将该曲线压缩为单个与阈值无关的数字。从高层次解释 AUC：它反映了模型在所有阈值中将正例与负例分开（排名）的程度。因此，当在同一数据集上评估两个模型时，具有较高 AUC（0.91 vs. 0.87）的模型具有更好的整体判别性能。 AUC 本身并不能保证在任何特定阈值下有更好的性能，也不能直接确定与阈值相关的指标，例如准确度、精确度或召回率；这些取决于所选的工作点和类别流行率。关键要点是，较高的 AUC 意味着更好的整体排名/分离，而不是每个阈值或指标都具有普遍优势。 - 任何阈值精度都是不正确的，因为精度取决于特定阈值和类别平衡。 - 精度保证不正确，因为精度取决于阈值和患病率，并且可以通过 PR 曲线更好地进行评估。 - 到处支配 ROC 是不正确的，因为更高的 AUC 并不需要一条 ROC 曲线在每一点都更好。

ROC AUC は、考えられるすべての分類しきい値にわたってクラスを区別するモデルの能力を要約しています。同じテスト セットではモデル A の AUC がモデル B よりも高いため、しきい値に依存しないという意味では、モデル A の方が総合的な識別器として優れています。これは、特定の動作しきい値や精度などの指標で最適であることを保証するものではありません。 ROC 曲線は、判定しきい値が変化するにつれて真陽性率と偽陽性率をプロットし、AUC はその曲線をしきい値に依存しない単一の数値に圧縮します。AUC の高レベルの解釈: すべてのしきい値にわたって、モデルが肯定的な例を否定的な例よりもどの程度分離 (ランク付け) しているかを反映します。したがって、2 つのモデルが同じデータセットで評価される場合、AUC (0.91 対 0.87) が高いモデルの方が全体的な識別パフォーマンスが優れています。 AUC だけでは、特定のしきい値でのパフォーマンスの向上を保証するものではなく、精度、精度、再現率などのしきい値に依存するメトリクスを直接決定するものでもありません。これらは、選択した操作点とクラスの普及率によって異なります。重要な点は、AUC が高いということは、すべてのしきい値やメトリクスに対する普遍的な優位性ではなく、全体的なランキング/分離が優れていることを意味するということです。 - 精度は特定のしきい値とクラスのバランスに依存するため、任意のしきい値の精度は不正確です。 - 精度は閾値と有病率に依存しており、PR 曲線を使用して評価する方が適切であるため、精度の保証は不正確です。 - AUC が高くても、すべての点で 1 つの ROC 曲線が優れている必要はないため、どこでも ROC を優先するのは不正確です。

Amazon Textract is the AWS-managed service purpose-built for OCR on scanned documents, forms, and tables, so custom modeling is unnecessary here. Data minimization means collecting and retaining only what is needed for the stated purpose. Storing only the extracted text (and not the source scans) best matches that principle. The key decision is matching the computer vision need to the appropriate managed service and then applying the stated principle. For OCR of scanned documents (including forms and tables) where specialized customization is not required, Amazon Textract is the high-level, fit-for-purpose choice. Data minimization means limiting both the data you collect/process and the data you retain. In this scenario, the business output is the extracted text, so minimizing retained data favors persisting the Textract results while avoiding unnecessary long-term storage of the original scanned images. By contrast, custom modeling (for example, training an OCR model in SageMaker) is warranted when managed OCR does not meet accuracy, language/layout, or domain-specific extraction requirements. - Custom training is unnecessary overhead and retains extra sensitive raw data. - Wrong service: Rekognition Custom Labels targets image classification/object detection, not document OCR. - Self-managed OCR can work, but archiving all raw images violates minimization under the stated need.

Amazon Textract 是专门为扫描文档、表单和表格进行 OCR 构建的 AWS 托管服务，因此此处无需自定义建模。数据最小化意味着仅收集和保留既定目的所需的数据。仅存储提取的文本（而不存储源扫描）最符合该原则。 关键决策是将计算机视觉需求与适当的托管服务相匹配，然后应用规定的原则。对于不需要专门定制的扫描文档（包括表格和表格）的 OCR，Amazon Textract 是高级、适合用途的选择。 数据最小化意味着限制您收集/处理的数据和您保留的数据。在这种情况下，业务输出是提取的文本，因此最大限度地减少保留数据有利于保留 Textract 结果，同时避免不必要的长期存储原始扫描图像。 相比之下，当托管 OCR 不满足准确性、语言/布局或特定于域的提取要求时，需要自定义建模（例如，在 SageMaker 中训练 OCR 模型）。 - 定制培训是不必要的开销，并保留额外敏感的原始数据。 - 错误服务：Rekognition 自定义标签的目标是图像分类/对象检测，而不是文档 OCR。 - 自我管理的 OCR 可以工作，但归档所有原始图像违反了规定需求下的最小化。

Amazon Textract は、スキャンされたドキュメント、フォーム、テーブルの OCR 専用に構築された AWS マネージド サービスであるため、ここではカスタム モデリングは必要ありません。データの最小化とは、指定された目的に必要なものだけを収集して保持することを意味します。抽出されたテキストのみを保存する (ソース スキャンは保存しない) ことが、その原則に最もよく適合します。 重要な決定は、コンピューター ビジョンのニーズを適切なマネージド サービスに適合させ、規定された原則を適用することです。特殊なカスタマイズが必要ない、スキャンされたドキュメント (フォームや表を含む) の OCR には、Amazon Textract が高レベルで目的に適した選択肢です。 データの最小化とは、収集/処理するデータと保持するデータの両方を制限することを意味します。このシナリオでは、ビジネス出力は抽出されたテキストであるため、保持されるデータを最小限に抑えると、元のスキャン画像の不必要な長期保存を回避しながら、Textract の結果を永続化することができます。 対照的に、マネージド OCR が精度、言語/レイアウト、またはドメイン固有の抽出要件を満たさない場合は、カスタム モデリング (SageMaker での OCR モデルのトレーニングなど) が保証されます。 - カスタム トレーニングには不要なオーバーヘッドがあり、非常に機密性の高い生データが保持されます。 - 間違ったサービス: Rekognition Custom Labels は、ドキュメント OCR ではなく、画像分類/オブジェクト検出をターゲットとしています。 - 自己管理型 OCR は機能しますが、すべての RAW 画像をアーカイブすると、規定のニーズに基づく最小化に違反します。

Amazon MSK is AWS’s fully managed service for running Apache Kafka, allowing teams to keep Kafka APIs and client libraries while ingesting streaming data at scale. This directly matches the requirement to preserve Kafka-specific constructs like topics and partitions with minimal application changes. Use Amazon Managed Streaming for Apache Kafka (Amazon MSK) when you need a managed Kafka control plane and data plane but want to keep the Kafka protocol, client libraries, and operational model (topics, partitions, consumer groups). This is a common choice for streaming ingestion when teams already have Kafka-based applications and want to reduce operational burden (broker management, patching, scaling) without rewriting producers/consumers. A close alternative is Amazon Kinesis Data Streams, which is also for streaming ingestion at scale, but it uses Kinesis APIs and shard-based scaling rather than Kafka APIs and partitions, so it typically requires application changes. - Kinesis vs Kafka compatibility Kinesis Data Streams ingests streams but is not Kafka-protocol compatible. - Delivery service confusion Kinesis Data Firehose is primarily for loading streams into destinations (like S3/Redshift) with limited custom consumer patterns. - Feature management, not ingestion SageMaker Feature Store stores and serves features; it is not a streaming ingest service.

Amazon MSK 是 AWS 用于运行 Apache Kafka 的完全托管服务，允许团队保留 Kafka API 和客户端库，同时大规模提取流数据。这直接符合以最少的应用程序更改保留 Kafka 特定结构（例如主题和分区）的要求。 当您需要托管 Kafka 控制平面和数据平面但希望保留 Kafka 协议、客户端库和操作模型（主题、分区、消费者组）时，请使用 Amazon Managed Streaming for Apache Kafka (Amazon MSK)。当团队已经拥有基于 Kafka 的应用程序并希望在不重写生产者/消费者的情况下减轻运营负担（代理管理、修补、扩展）时，这是流式摄取的常见选择。 一个接近的替代方案是 Amazon Kinesis Data Streams，它也用于大规模流式摄取，但它使用 Kinesis API 和基于分片的扩展，而不是 Kafka API 和分区，因此通常需要更改应用程序。 - Kinesis 与 Kafka 兼容性 Kinesis 数据流摄取流，但与 Kafka 协议不兼容。 - 交付服务混乱 Kinesis Data Firehose 主要用于将流加载到具有有限自定义消费者模式的目的地（如 S3/Redshift）。 - 特征管理，而不是摄取 SageMaker Feature Store 存储和提供特征；它不是流媒体摄取服务。

Amazon MSK は、Apache Kafka を実行するための AWS のフルマネージド サービスで、チームがストリーミング データを大規模に取り込みながら、Kafka API とクライアント ライブラリを維持できるようにします。これは、アプリケーションの変更を最小限に抑えて、トピックやパーティションなどの Kafka 固有の構造を保持するという要件に直接一致します。 マネージド型 Kafka コントロールプレーンとデータプレーンが必要だが、Kafka プロトコル、クライアントライブラリ、および運用モデル (トピック、パーティション、コンシューマーグループ) を維持したい場合は、Amazon Managed Streaming for Apache Kafka (Amazon MSK) を使用します。これは、チームがすでに Kafka ベースのアプリケーションを持っていて、プロデューサー/コンシューマーを書き換えることなく運用上の負担 (ブローカー管理、パッチ適用、スケーリング) を軽減したい場合のストリーミング インジェストの一般的な選択です。 近い代替案は Amazon Kinesis Data Streams です。これも大規模なストリーミング取り込み用ですが、Kafka API とパーティションではなく Kinesis API とシャードベースのスケーリングを使用するため、通常はアプリケーションの変更が必要です。 - Kinesis と Kafka の互換性 Kinesis データ ストリームはストリームを取り込みますが、Kafka プロトコルとの互換性はありません。 - 配信サービスの混乱 Kinesis Data Firehose は主に、限られたカスタム コンシューマ パターンでストリームを宛先に (S3/Redshift など) ロードするためのものです。 - 取り込みではなく機能管理 SageMaker Feature Store は機能を保存して提供します。ストリーミング取り込みサービスではありません。

Amazon SageMaker Experiments is designed to organize and track ML runs so they can be reproduced and compared. It captures run metadata such as parameters (including seeds), metrics, and references to inputs and outputs (like dataset and model artifact locations). This makes it the most direct managed feature for reproducible experimentation in SageMaker. Reproducible ML experiments require consistent capture of what was run and what data/artifacts were used: training parameters (including any random seeds), evaluation metrics, and the specific input and output artifacts for each run. Amazon SageMaker Experiments provides this experiment tracking by grouping runs into trials and recording each run’s parameters, metrics, and artifact references (for example, S3 locations for datasets, code bundles, and model artifacts). This lets you reliably compare results across runs and re-run the same configuration later using the recorded metadata. Operational logs and API audit trails can support debugging and governance, but they are not purpose-built to structure experiment metadata for repeatable model development. - Operational logging via CloudWatch can store stdout/stderr, but it doesn’t structure experiment parameters and artifacts for comparison. - Model lifecycle control with Model Registry focuses on approved model versions and deployments, not tracking every training run. - API auditing with CloudTrail records SageMaker API calls, but not the curated experiment metadata needed for reproducibility.

Amazon SageMaker Experiments 旨在组织和跟踪 ML 运行，以便可以重现和比较它们。它捕获运行元数据，例如参数（包括种子）、指标以及对输入和输出的引用（例如数据集和模型工件位置）。这使其成为 SageMaker 中可重复实验的最直接的管理特征。 可重现的 ML Experiments 需要一致捕获运行的内容以及使用的数据/工件：训练参数（包括任何随机种子）、评估指标以及每次运行的特定输入和输出工件。 Amazon SageMaker Experiments 通过将运行分组为试验并记录每次运行的参数、指标和工件引用（例如，数据集、代码包和模型工件的 S3 位置）来提供此实验跟踪。这使您可以可靠地比较不同运行的结果，并在以后使用记录的元数据重新运行相同的配置。 操作日志和 API 审计跟踪可以支持调试和治理，但它们并不是专门为构建可重复模型开发的实验元数据而构建的。 - 通过 CloudWatch 的操作日志记录可以存储 stdout/stderr，但它不会构建实验参数和工件以进行比较。 - Model Registry 的模型生命周期控制侧重于批准的模型版本和部署，而不是跟踪每次训练运行。 - 使用 CloudTrail 进行 API 审核记录 SageMaker API 调用，但不记录再现性所需的策划实验元数据。

Amazon SageMaker Experiments は、ML 実行を整理して追跡し、再現して比較できるように設計されています。パラメーター (シードを含む)、メトリック、入力と出力への参照 (データセットやモデル アーティファクトの場所など) などの実行メタデータをキャプチャします。これにより、SageMaker で再現可能な実験を行うための最も直接的に管理される機能になります。 再現可能な ML Experiments では、何が実行され、どのデータ/アーティファクトが使用されたか、つまりトレーニング パラメーター (ランダム シードを含む)、評価メトリクス、各実行の特定の入力および出力アーティファクトを一貫してキャプチャする必要があります。Amazon SageMaker Experiments は、実行をトライアルにグループ化し、各実行のパラメータ、メトリクス、アーティファクト参照 (データセット、コードバンドル、モデルアーティファクトの S3 の場所など) を記録することで、この実験の追跡を提供します。これにより、実行間で結果を確実に比較し、記録されたメタデータを使用して後で同じ構成を再実行できます。 操作ログと API 監査証跡はデバッグとガバナンスをサポートできますが、再現可能なモデル開発のための実験メタデータを構造化することを目的として構築されたものではありません。 - CloudWatch を介した操作ログは stdout/stderr を保存できますが、比較のための実験パラメータとアーティファクトを構造化することはできません。 - Model Registry によるモデルのライフサイクル管理は、すべてのトレーニングの実行を追跡するのではなく、承認されたモデルのバージョンと展開に重点を置いています。 - CloudTrail を使用した API 監査は、SageMaker API 呼び出しを記録しますが、再現性に必要な厳選された実験メタデータは記録しません。

Efficient SageMaker training input typically comes from balanced sharding: enough files to allow parallel reads without creating pathological tiny-object overhead. A single very large file forces serial or limited parallel reads and makes retries and partial re-reads expensive, which can reduce overall training throughput. The core concept is to shape S3 training data for high-throughput, parallel ingestion by the training cluster. For distributed training, you generally want multiple reasonably sized shards (often tens to hundreds of MB up to a few GB depending on the pipeline) so each worker can read different files concurrently; one monolithic file tends to cap parallelism and can become a hotspot. Compression can improve effective I/O and reduce network transfer, but only helps when decompression CPU cost does not become the bottleneck. Conversely, extremely small files can overwhelm the input pipeline with per-object overhead (listing/opens/metadata and request management), even if S3 can scale requests. Key takeaway: optimize for parallel reads with sensible shard sizes, not single giant objects. - Many small objects can increase parallelism but risks tiny-file overhead; it is not inherently unsafe. - Sharding into medium files is a standard way to improve parallel reads during distributed training. - Compression when CPU allows can reduce I/O and speed up input when decompression isn’t the limiting factor. - Single huge file is the problematic pattern because it limits parallel ingestion and makes retries costly.

高效的 SageMaker 训练输入通常来自平衡分片：足够的文件允许并行读取，而不会产生病态的小对象开销。单个非常大的文件会强制串行或有限的并行读取，并使重试和部分重读成本高昂，这会降低总体训练吞吐量。 核心概念是塑造 S3 训练数据，以供训练集群进行高吞吐量、并行摄取。对于分布式训练，您通常需要多个合理大小的分片（通常是数十到数百 MB 到几 GB，具体取决于管道），以便每个工作线程可以同时读取不同的文件；一个整体文件往往会限制并行性并可能成为热点。 压缩可以提高有效 I/O 并减少网络传输，但仅在解压 CPU 成本不成为瓶颈时才有帮助。相反，即使 S3 可以扩展请求，极小的文件也会因每个对象的开销（列出/打开/元数据和请求管理）而压垮输入管道。 关键要点：优化具有合理分片大小的并行读取，而不是单个巨型对象。 - 许多小对象可以提高并行性，但存在小文件开销的风险；它本质上并不是不安全的。 - 分片为中等文件是在分布式训练期间改进并行读取的标准方法。 - 当解压缩不是限制因素时，CPU 允许的压缩可以减少 I/O 并加快输入速度。 - 单个大文件是有问题的模式，因为它限制并行摄取并使重试成本高昂。

効率的な SageMaker トレーニング入力は通常、バランスの取れたシャーディングから得られます。つまり、病的な小さなオブジェクトのオーバーヘッドを発生させることなく並列読み取りを可能にする十分なファイルです。1 つの非常に大きなファイルにより、シリアル読み取りまたは限定された並列読み取りが強制され、再試行や部分的な再読み取りのコストが高くなり、全体のトレーニング スループットが低下する可能性があります。 中心的なコンセプトは、トレーニング クラスターによる高スループットの並列取り込みのために S3 トレーニング データを形成することです。分散トレーニングの場合、通常、各ワーカーが異なるファイルを同時に読み取れるように、適切なサイズの複数のシャード (パイプラインに応じて数十、数百 MB、最大で数 GB) が必要です。1 つのモノリシック ファイルは並列処理に上限を設ける傾向があり、ホットスポットになる可能性があります。 圧縮により I/O の効率が向上し、ネットワーク転送が削減されますが、圧縮解除の CPU コストがボトルネックにならない場合にのみ役立ちます。逆に、S3 がリクエストをスケーリングできる場合でも、非常に小さいファイルはオブジェクトごとのオーバーヘッド (リスト/オープン/メタデータおよびリクエスト管理) により入力パイプラインを圧倒する可能性があります。 重要なポイント: 単一の巨大なオブジェクトではなく、適切なシャード サイズで並列読み取りを最適化します。 - 多くの小さなオブジェクトは並列処理を向上させることができますが、小さなファイルのオーバーヘッドの危険性があります。本質的に安全ではありません。 - 媒体ファイルへのシャーディングは、分散トレーニング中の並列読み取りを向上させる標準的な方法です。 - CPU が許可する場合に圧縮すると、解凍が制限要因ではない場合、I/O が削減され、入力が高速化されます。 - 単一の巨大なファイルは、並列取り込みを制限し、再試行のコストが高くなるため、問題のあるパターンです。

Least privilege means granting only the minimum permissions needed for a specific job. In S3, that commonly requires restricting access by prefix so principals can only list and read the specific dataset paths they are authorized to use. This directly prevents access to the raw/ PII data while still enabling work on curated/. The core principle being tested is least privilege: each identity should receive only the permissions (actions) and scope (resources) required to perform its tasks. For S3-hosted ML datasets, the practical way to enforce least privilege is to limit s3:GetObject (and s3:ListBucket with an s3:prefix condition) to the exact prefixes that the persona needs, such as curated/*, and avoid granting broad bucket-wide access. This reduces the blast radius of accidental misuse or credential compromise and helps ensure PII-containing raw/* objects remain inaccessible to data scientists. A common pitfall is using controls that improve auditing or role separation without actually constraining which objects can be accessed; those are valuable, but they do not satisfy the “only this prefix” requirement by themselves. - Auditing vs restriction Versioning and CloudTrail help trace changes and access but don’t prevent reads of raw/. - Separation of duties Using separate roles is good practice, but it doesn’t inherently enforce prefix-level access for data scientists. - Over-aggressive minimization Deleting datasets after every run is not required to meet the access constraint and can harm traceability and repeatability.

最小权限意味着仅授予特定作业所需的最小权限。在 S3 中，通常需要通过前缀限制访问，以便主体只能列出和读取他们有权使用的特定数据集路径。这直接阻止了对原始/ PII 数据的访问，同时仍然允许对 curated/ 进行工作。 正在测试的核心原则是最小特权：每个身份应该仅接收执行其任务所需的权限（操作）和范围（资源）。对于 S3 托管的 ML 数据集，强制实施最低权限的实用方法是将 S3:GetObject（以及具有 S3:prefix 条件的 S3:ListBucket）限制为角色所需的确切前缀，例如 curated/*，并避免授予广泛的存储桶范围的访问权限。这减少了意外误用或凭证泄露的影响范围，并有助于确保数据科学家无法访问包含 PII 的原始/* 对象。 一个常见的陷阱是使用改进审核或角色分离的控件，但实际上并未限制可以访问哪些对象；这些很有价值，但它们本身并不能满足“仅此前缀”的要求。 - 审核与限制版本控制和 CloudTrail 有助于跟踪更改和访问，但不会阻止读取 raw/。 - 职责分离使用单独的角色是一种很好的做法，但它本质上并不强制数据科学家进行前缀级别的访问。 - 过度的最小化不需要每次运行后删除数据集来满足访问限制，并且可能会损害可追溯性和可重复性。

最小権限とは、特定のジョブに必要な最小限の権限のみを付与することを意味します。S3 では、通常、プレフィックスによるアクセスの制限が必要となるため、プリンシパルは使用を許可されている特定のデータセット パスのみを一覧表示して読み取ることができます。これにより、curated/ での作業が可能になりながら、生の PII データへのアクセスが直接阻止されます。 テストされる中心的な原則は、最小特権です。各 ID は、そのタスクを実行するために必要なアクセス許可 (アクション) とスコープ (リソース) のみを受け取る必要があります。S3 でホストされる ML データセットの場合、最小権限を強制する実際的な方法は、S3:GetObject (および S3:prefix 条件付きの S3:ListBucket) を、curated/* などのペルソナが必要とする正確なプレフィックスに制限し、バケット全体にわたる広範なアクセスを許可しないようにすることです。これにより、偶発的な誤用や認証情報の漏洩の影響範囲が縮小され、PII を含む raw/* オブジェクトがデータ サイエンティストにアクセスできない状態を保つことができます。 よくある落とし穴は、実際にアクセスできるオブジェクトを制限することなく、監査や役割の分離を改善するコントロールを使用することです。これらは価値がありますが、それ自体では「このプレフィックスのみ」という要件を満たしません。 - 監査と制限 バージョニングと CloudTrail は、変更とアクセスの追跡に役立ちますが、raw/ の読み取りは妨げません。 - 職務の分離 別々の役割を使用することは良い習慣ですが、本質的にデータ サイエンティストにプレフィックス レベルのアクセスを強制するものではありません。 - 過剰な最小化 アクセス制約を満たすために毎回の実行後にデータセットを削除する必要はなく、トレーサビリティと再現性を損なう可能性があります。

The log indicates an authorization failure when the team account tries to pull a Docker image from an ECR repository in a different account. The right sharing strategy is to keep the image centralized in one ECR repository and explicitly grant cross-account pull access through an ECR repository policy, along with the necessary ECR read actions on the SageMaker execution role. The core issue is cross-account authorization to a centrally managed ECR image. The exhibit explicitly shows an AccessDeniedException and the denied action ecr:BatchGetImage against the repository ARN in account 123456789012 (see the lines stating not authorized to perform: ecr:BatchGetImage and the arn:aws:ecr:...:123456789012:repository/ml-train). To share reusable training containers across accounts while keeping one source of truth: - Keep the image versioned in a central ECR repository. - Add an ECR repository resource policy that allows the consuming account (or its IAM roles) to perform pull actions. - Ensure the SageMaker execution role in the consuming account has the corresponding ECR permissions (for example, authorization token plus read/pull actions). Network endpoints can help connectivity, but they do not fix an IAM/ECR authorization error. - S3 image shuttling adds operational overhead and breaks the “single centrally managed image” goal. - Built-in algorithm switch doesn’t address the reuse requirement for a standard custom training container. - VPC endpoints affect network routing; the exhibit shows an IAM authorization denial (AccessDeniedException), not a connectivity failure.

当团队帐户尝试从其他帐户中的 ECR 存储库提取 Docker 映像时，该日志指示授权失败。正确的共享策略是将映像集中在一个 ECR 存储库中，并通过 ECR 存储库策略显式授予跨账户拉取访问权限，以及对 SageMaker 执行角色执行必要的 ECR 读取操作。 核心问题是对集中管理的 ECR 镜像的跨账户授权。该图表明确显示了 AccessDeniedException 和针对账户 123456789012 中的存储库 ARN 的拒绝操作 ECR:BatchGetImage（请参阅声明未授权执行的行：ECR:BatchGetImage 和 arn:aws:ECR:...:123456789012:repository/ml-train）。 要跨帐户共享可重复使用的培训容器，同时保留一个事实来源： - 将映像版本保存在中央 ECR 存储库中。 - 添加 ECR 存储库资源策略，允许使用帐户（或其 IAM 角色）执行拉取操作。 - 确保使用账户中的 SageMaker 执行角色具有相应的 ECR 权限（例如，授权令牌加上读取/拉取操作）。 网络端点可以帮助连接，但它们不能修复 IAM/ECR 授权错误。 - S3 图像穿梭增加了运营开销并打破了“单一集中管理图像”的目标。 - 内置算法开关无法满足标准自定义训练容器的重用要求。 - VPC 端点影响网络路由；该图示显示 IAM 授权拒绝 (AccessDeniedException)，而不是连接故障。

ログには、チーム アカウントが別のアカウントの ECR リポジトリから Docker イメージをプルしようとしたときに認証が失敗したことが示されています。適切な共有戦略は、イメージを 1 つの ECR リポジトリに一元管理し、SageMaker 実行ロールで必要な ECR 読み取りアクションとともに、ECR リポジトリ ポリシーを通じてクロスアカウント プル アクセスを明示的に許可することです。 中心的な問題は、集中管理された ECR イメージに対するクロスアカウント認証です。この展示では、AccessDeniedException と、アカウント 123456789012 のリポジトリ ARN に対する拒否されたアクション ECR:BatchGetImage が明示的に示されています (実行が許可されていないことを示す行: ECR:BatchGetImage とarn:aws:ECR:...:123456789012:リポジトリ/ml-train)。 信頼できる情報源を 1 つ維持しながら、再利用可能なトレーニング コンテナをアカウント間で共有するには: - イメージのバージョン管理を中央の ECR リポジトリに保持します。 - 使用アカウント (またはその IAM ロール) がプル アクションを実行できるようにする ECR リポジトリ リソース ポリシーを追加します。 - 使用アカウントの SageMaker 実行ロールに、対応する ECR 権限 (たとえば、承認トークンと読み取り/プル アクション) があることを確認します。 ネットワーク エンドポイントは接続に役立ちますが、IAM/ECR 認証エラーは修正されません。 - S3 イメージの往復は運用上のオーバーヘッドを追加し、「単一の集中管理イメージ」という目標を破ります。 - 組み込みのアルゴリズム スイッチは、標準のカスタム トレーニング コンテナの再利用要件に対応していません。 - VPC エンドポイントはネットワーク ルーティングに影響します。この展示では、接続障害ではなく、IAM 認証拒否 (AccessDeniedException) が示されています。

To protect sensitive training data and inference payloads, access should be limited to the minimum set of identities, resources, and network paths required. Overbroad IAM permissions create unnecessary blast radius and make it easier for unauthorized principals to read training data or misuse KMS keys. Using encryption, private connectivity, and auditing supports secure operations without blocking legitimate workflows. The core control for preventing unauthorized access at scale is least-privilege authorization combined with encrypted storage/transport and auditable access. In SageMaker workflows, that typically means scoping IAM roles to specific S3 prefixes and required KMS keys, limiting network paths (for example, VPC endpoints) so traffic stays on the AWS network, and logging access for investigation and compliance. A single shared execution role with s3:* and kms:* on * is an anti-pattern because it: - Makes it difficult to enforce separation between teams/environments - Expands the impact of credential leakage or misconfiguration - Increases the chance of unintended access to unrelated datasets or keys The key takeaway is to minimize permissions and scope access, then layer encryption, private connectivity, and auditing around that foundation. - SSE-KMS + restrictive bucket policy is a standard control to protect sensitive S3 training data and limit who can read it. - VPC + VPC endpoints helps keep training and inference traffic private and reduces exposure to the public internet. - CloudTrail auditing supports detection and investigation of unauthorized access attempts and changes. - One shared broad role breaks separation of duties and least privilege, increasing blast radius.

为了保护敏感的训练数据和推理有效负载，访问应仅限于所需的最少身份、资源和网络路径集。过于宽泛的 IAM 权限会产生不必要的爆炸半径，并使未经授权的主体更容易读取训练数据或滥用 KMS 密钥。使用加密、专用连接和审核支持安全操作，而不会阻止合法的工作流程。 防止大规模未经授权访问的核心控制是最小权限授权与加密存储/传输和可审核访问的结合。在 SageMaker 工作流程中，这通常意味着将 IAM 角色的范围限定为特定的 S3 前缀和所需的 KMS 密钥、限制网络路径（例如 VPC 终端节点）以使流量保留在 AWS 网络上，并记录访问以进行调查和合规性。 * 上带有 S3:* 和 KMS:* 的单个共享执行角色是一种反模式，因为它： - 难以强制执行团队/环境之间的分离 - 扩大了凭证泄露或配置错误的影响 - 增加意外访问不相关数据集或密钥的机会 关键要点是最大限度地减少权限和范围访问，然后围绕该基础进行分层加密、私有连接和审计。 - SSE-KMS + 限制性存储桶策略是一种标准控制，用于保护敏感的 S3 训练数据并限制谁可以读取它。 - VPC + VPC 端点有助于保持训练和推理流量的私密性，并减少对公共互联网的暴露。 - CloudTrail 审核支持检测和调查未经授权的访问尝试和更改。 - 一个共享的广泛角色打破了职责分离和最小特权，增加了爆炸半径。

機密のトレーニング データと推論ペイロードを保護するには、アクセスを必要な ID、リソース、ネットワーク パスの最小限のセットに制限する必要があります。IAM 権限が広すぎると、不必要な爆発範囲が生じ、権限のないプリンシパルがトレーニング データを読み取ったり、KMS キーを悪用したりすることが容易になります。暗号化、プライベート接続、監査を使用すると、正当なワークフローをブロックすることなく安全な操作がサポートされます。 大規模な不正アクセスを防止するための中核となる制御は、暗号化されたストレージ/転送および監査可能なアクセスと組み合わせた最小権限の承認です。SageMaker ワークフローでは、これは通常、IAM ロールの範囲を特定の S3 プレフィックスと必要な KMS キーに設定し、トラフィックが AWS ネットワーク上に留まるようにネットワーク パス (VPC エンドポイントなど) を制限し、調査とコンプライアンスのためにアクセスをログに記録することを意味します。 * 上に S3:* および KMS:* を含む単一の共有実行ロールは、次の理由からアンチパターンです。 - チーム/環境間の分離を強制することが困難になる - 認証情報の漏洩または構成ミスの影響が拡大する - 無関係なデータセットまたはキーへの意図しないアクセスの可能性が高くなります。 重要な点は、アクセス許可とスコープ アクセスを最小限に抑え、その基盤に基づいて層暗号化、プライベート接続、監査を行うことです。 - SSE-KMS + 制限的バケット ポリシーは、機密性の高い S3 トレーニング データを保護し、読み取りできるユーザーを制限するための標準制御です。 - VPC + VPC エンドポイントは、トレーニングと推論のトラフィックをプライベートに保ち、公共のインターネットへの露出を減らすのに役立ちます。 - CloudTrail 監査は、不正なアクセスの試みと変更の検出と調査をサポートします。 - 広範な役割を共有することで、職務の分離と最小限の特権が破壊され、攻撃範囲が拡大します。

To validate consistency across subpopulations, evaluate model quality and errors separately by group, not only in aggregate. A high-level fairness check also requires computing group-based bias metrics on predictions and verifying that scores are similarly calibrated across groups. These analyses can surface disparate error rates, selection rates, or miscalibration that may create unfair outcomes. Fairness and consistency checks start by slicing evaluation results by protected or sensitive subpopulations (or their proxies) and comparing metrics that drive decisions. Aggregate metrics can hide large gaps when one group dominates the test set. Useful high-level checks include: - Per-group performance and error rates (for example AUC, FPR, TPR) to find disparity. - Standard bias metrics (for example disparate impact, equal opportunity difference) computed on predictions; SageMaker Clarify can generate these post-training. - Per-group score calibration/distribution analysis to ensure a score means the same risk level across groups and that a single threshold doesn’t create unintended disparities. The key takeaway is to evaluate by subgroup using both predictive performance and bias metrics, rather than relying on overall scores or “fairness by omission.” - OK Compare FPR/TPR and AUC across groups: directly tests consistency and disparity. - OK SageMaker Clarify post-training bias report: computes common group fairness metrics. - OK Per-subgroup calibration curves: finds unequal score meaning across groups. - NO Overall ROC-AUC only: can mask large subgroup performance gaps. - NO Remove gender and assume fairness: proxies can still encode bias. - NO Optimize one global threshold for overall F1: ignores subgroup impacts.

为了验证亚群体之间的一致性，请按组单独评估模型质量和错误，而不仅仅是总体评估。高级公平性检查还需要计算基于组的预测偏差指标，并验证各组之间的分数是否经过类似校准。这些分析可以揭示不同的错误率、选择率或可能产生不公平结果的错误校准。 公平性和一致性检查首先按受保护或敏感的子群体（或其代理）划分评估结果，并比较推动决策的指标。当一组在测试集中占主导地位时，聚合指标可能会隐藏巨大的差距。 有用的高级检查包括： - 每组的性能和错误率（例如 AUC、FPR、TPR）以查找差异。 - 根据预测计算的标准偏差指标（例如不同影响、平等机会差异）； SageMaker Clarify 可以生成这些后训练。 - 每组分数校准/分布分析，以确保分数意味着各组之间具有相同的风险水平，并且单个阈值不会造成意外的差异。 关键要点是使用预测性能和偏差指标按小组进行评估，而不是依赖总体分数或“遗漏公平性”。 - OK 跨组比较 FPR/TPR 和 AUC：直接测试一致性和差异。 - OK SageMaker Clarify 训练后偏差报告：计算常见的群体公平性指标。 - OK 每子组校准曲线：发现各组之间得分不相等的含义。 - 否 仅总体 ROC-AUC：可以掩盖较大的子组性能差距。 - 否 删除性别并假设公平：代理仍然可以编码偏见。 - NO 优化整体 F1 的一个全局阈值：忽略子组影响。

部分母集団間の一貫性を検証するには、モデルの品質とエラーを集合的にだけでなく、グループごとに個別に評価します。高レベルの公平性チェックでは、予測に関するグループベースのバイアスメトリクスを計算し、スコアがグループ間で同様に調整されていることを検証することも必要です。これらの分析により、不公平な結果を生み出す可能性のある、異なるエラー率、選択率、または誤ったキャリブレーションが表面化する可能性があります。 公平性と一貫性のチェックは、保護対象または機密性の高い部分母集団 (またはその代替集団) ごとに評価結果をスライスし、意思決定を促進する指標を比較することから始まります。1 つのグループがテスト セットを支配している場合、集計メトリクスによって大きなギャップが隠れる可能性があります。 有用な高レベルのチェックには次のものがあります。 - グループごとのパフォーマンスとエラー率 (AUC、FPR、TPR など) を調べて不均衡を見つけます。 - 予測に基づいて計算された標準バイアス指標 (異種影響、機会均等差など)。SageMaker Clarify はこれらのポストトレーニングを生成できます。 - グループごとのスコア調整/分布分析により、スコアがグループ全体で同じリスクレベルを意味し、単一のしきい値が意図しない格差を生じないことを確認します。 重要なポイントは、全体のスコアや「省略による公平性」に依存するのではなく、予測パフォーマンスとバイアス指標の両方を使用してサブグループごとに評価することです。 - OK グループ間で FPR/TPR と AUC を比較します。一貫性と不一致を直接テストします。 - OK SageMaker Clarify トレーニング後のバイアス レポート: 共通のグループ公平性メトリクスを計算します。 - OK サブグループごとの検量線: グループ間で不等なスコアの意味を検出します。 - いいえ 全体的な ROC ～ AUC のみ: サブグループの大きなパフォーマンス ギャップをマスクできます。 - いいえ 性別を削除し、公平性を前提とします。プロキシは依然としてバイアスをエンコードする可能性があります。 - NO F1 全体の 1 つのグローバルしきい値を最適化します。サブグループの影響を無視します。

For time-evolving customer snapshots, a random stratified split across all dates is a leakage anti-pattern because it can place later snapshots for the same customer in training while evaluating earlier snapshots in test (or vice versa). That breaks the intended “predict the future from the past” setup and inflates metrics. A leakage-safe split should respect time and/or keep entities isolated across splits while maintaining label distribution as appropriate. The core principle is to design splits that match the real inference setting and prevent information from the evaluation set from “bleeding” into training. With customer snapshots over time, randomly splitting rows across the full year can put the same customer_id into multiple splits and mix future and past observations, which introduces temporal/entity leakage (the model indirectly learns customer-specific patterns that won’t generalize). Leakage-safe approaches typically: - Use a chronological split (train on older data, test on newer data). - Or split by entity (e.g., customer_id) so each entity appears in only one split. - Apply stratification only when it doesn’t violate the time/entity boundaries. The key takeaway is that stratification is useful for class imbalance, but it must not override boundaries that prevent leakage. - Chronological holdout is acceptable because it preserves the “past predicts future” distribution shift. - Group/entity split is acceptable because it prevents the same customer from appearing in multiple splits. - Stratify within time windows can be acceptable when done without mixing time boundaries, helping keep churn prevalence comparable.

对于随时间变化的客户快照，跨所有日期的随机分层分割是一种泄漏反模式，因为它可以在训练中放置同一客户的后续快照，同时在测试中评估早期快照（反之亦然）。这打破了预期的“从过去预测未来”的设置并夸大了指标。泄漏安全的分割应该尊重时间和/或保持实体在分割之间隔离，同时保持适当的标签分布。 核心原则是设计与真实推理设置相匹配的分割，并防止评估集中的信息“渗透”到训练中。随着时间的推移，通过客户快照，在全年中随机拆分行可以将相同的 customer_id 放入多个拆分中，并混合未来和过去的观察结果，这会引入时间/实体泄漏（模型间接学习不会泛化的客户特定模式）。 防漏电方法通常： - 使用时间顺序分割（对旧数据进行训练，对新数据进行测试）。 - 或按实体（例如 customer_id）拆分，以便每个实体仅出现在一个拆分中。 - 仅在不违反时间/实体边界时应用分层。 关键要点是分层对于 class imbalance 很有用，但它不能覆盖防止泄漏的边界。 - 按时间顺序保留是可以接受的，因为它保留了“过去预测未来”的分布变化。 - 组/实体拆分是可以接受的，因为它可以防止同一客户出现在多个拆分中。 - 在不混合时间边界的情况下，在时间窗口内进行分层是可以接受的，有助于保持客户流失率的可比性。

時間の経過とともに変化する顧客スナップショットの場合、すべての日付にわたるランダムな階層化分割は、テストで以前のスナップショットを評価している間に同じ顧客の後のスナップショットをトレーニングに配置する可能性があるため (またはその逆)、漏洩の防止パターンとなります。これにより、意図した「過去から未来を予測する」という設定が崩れ、指標が膨らみます。漏れのない分割では、ラベルの配布を適切に維持しながら、時間を尊重し、エンティティを分割間で隔離しておく必要があります。 中心的な原則は、実際の推論設定に一致する分割を設計し、評価セットからの情報がトレーニングに「滲む」のを防ぐことです。長期にわたる顧客スナップショットの場合、通年を通じて行をランダムに分割すると、同じ customer_id が複数の分割に分割され、将来と過去の観測が混在する可能性があり、これにより一時的/エンティティ漏洩が発生します (モデルは、一般化されない顧客固有のパターンを間接的に学習します)。 漏洩に対する安全なアプローチは通常次のとおりです。 - 時系列分割を使用します (古いデータでトレーニングし、新しいデータでテストします)。 - または、エンティティ (customer_id など) ごとに分割して、各エンティティが 1 つの分割のみに表示されるようにします。 - 階層化は、時間/エンティティの境界に違反しない場合にのみ適用します。 重要な点は、層別化は class imbalance にとって便利ですが、漏れを防ぐ境界をオーバーライドしてはいけないということです。 - 時系列的なホールドアウトは、「過去が将来を予測する」分布の変化を維持するため、許容されます。 - グループ/エンティティの分割は、同じ顧客が複数の分割に現れることを防ぐため、許容されます。 - 時間枠内での階層化は、時間境界を混在させずに実行すれば許容できるため、チャーンの発生率を同等に保つことができます。

To troubleshoot an evaluation pipeline, the team should eliminate leakage and ensure the evaluation procedure is repeatable and correctly measured. Actions that fit transformations only on training data, lock down split determinism, and verify metric configuration improve evaluation fidelity. Computing features across the full dataset before splitting is a classic leakage anti-pattern that can produce unrealistically high offline metrics. The core principle is to keep the test set isolated so it represents unseen data. Any operation that learns from data (feature scaling, encoding, aggregations that depend on label/time, imputation statistics) must be fit using only the training split, then applied to validation/test using the saved artifacts. In SageMaker Pipelines, this typically means producing and passing preprocessing artifacts between steps and making the split deterministic (seeded random split or time-based split) so evaluation is consistent across runs. Separately, the evaluation step must compute the intended metric (and any thresholds) correctly; a miswired metric can also create misleading “great” results. The key takeaway: improve reproducibility and metric correctness without introducing train-test contamination. - Train-only preprocessing helps prevent leakage by reusing fitted artifacts on test. - Deterministic split makes evaluations comparable across pipeline runs and reduces accidental overlap. - Metric verification addresses misconfiguration (wrong metric, label mapping, or threshold) in the evaluation step. - Full-dataset feature generation is risky because it can encode test-set information into training features.

为了对评估流程进行故障排除，团队应消除泄漏并确保评估程序可重复且测量正确。仅适合训练数据的转换、锁定分割确定性并验证指标配置的操作可提高评估保真度。在分割之前计算整个数据集的特征是一种经典的泄漏反模式，可能会产生不切实际的高离线指标。 核心原则是保持测试集隔离，使其代表不可见的数据。任何从数据中学习的操作（特征缩放、编码、依赖于标签/时间的聚合、插补统计）都必须仅使用训练分割进行拟合，然后使用保存的工件应用于验证/测试。在 SageMaker Pipelines 中，这通常意味着在步骤之间生成和传递预处理工件并使分割具有确定性（种子随机分割或基于时间的分割），因此评估在运行中保持一致。另外，评估步骤必须正确计算预期指标（以及任何阈值）；错误的指标也会产生误导性的“伟大”结果。关键要点：提高可重复性和度量正确性，而不引入训练测试污染。 - 仅训练预处理有助于通过在测试中重复使用安装的工件来防止泄漏。 - 确定性分割使评估在管道运行中具有可比性，并减少意外重叠。 - 指标验证解决了评估步骤中的错误配置（错误的指标、标签映射或阈值）。 - 全数据集特征生成是有风险的，因为它可以将测试集信息编码为训练特征。

評価パイプラインのトラブルシューティングを行うには、チームは漏れを排除し、評価手順が再現可能で正しく測定されていることを確認する必要があります。トレーニング データのみに変換を適合させ、分割決定論をロックダウンし、メトリック構成を検証するアクションにより、評価の忠実度が向上します。分割する前にデータセット全体にわたって特徴を計算することは、非現実的に高いオフライン メトリクスを生成する可能性がある古典的な漏洩アンチパターンです。 基本的な原則は、テスト セットを分離して、目に見えないデータを表すようにすることです。データから学習する操作 (特徴量のスケーリング、エンコード、ラベル/時間に依存する集計、代入統計) は、トレーニング分割のみを使用して適合し、保存されたアーティファクトを使用して検証/テストに適用する必要があります。SageMaker Pipelines では、これは通常、ステップ間で前処理アーティファクトを生成して渡し、分割を決定論的 (シードされたランダム分割または時間ベースの分割) にして、実行間で評価が一貫していることを意味します。これとは別に、評価ステップでは、目的のメトリック (およびしきい値) を正しく計算する必要があります。指標の配線が間違っていると、誤解を招く「素晴らしい」結果が生じる可能性もあります。重要なポイント: トレインテストの汚染を引き起こすことなく、再現性と測定基準の正確性を向上させます。 - トレーニングのみの前処理は、テストでフィットしたアーティファクトを再利用することで漏れを防ぐのに役立ちます。 - 決定論的な分割により、パイプライン実行全体で評価を比較できるようになり、偶発的な重複が減少します。 - メトリック検証により、評価ステップでの構成ミス (間違ったメトリック、ラベル マッピング、またはしきい値) が解決されます。 - 完全なデータセット特徴生成は、テストセット情報をトレーニング特徴にエンコードする可能性があるため、危険です。

CloudWatch metrics and logs are the primary tools to monitor inference endpoint health at runtime. Alarming on latency percentiles, 4XX/5XX errors, and throttling provides fast detection, and shipping container logs to CloudWatch Logs provides the context needed to troubleshoot. This meets the 5-minute alerting goal with low overhead and no model or client changes. For SageMaker endpoints, health monitoring is best implemented with CloudWatch metrics for fast, quantitative signals (latency, error rates, throttling) and CloudWatch Logs for qualitative diagnostics (stack traces, timeouts, upstream dependency errors). In this scenario, creating CloudWatch alarms on ModelLatency, Invocation4XXErrors, Invocation5XXErrors, and InvocationThrottles (and routing notifications through SNS/on-call tooling) reduces time-to-detect while keeping costs low. Enabling the endpoint/container logs in CloudWatch Logs lets the team correlate alarm spikes with specific error messages and request patterns. The key tradeoff is some additional log ingestion/storage cost, but it is typically modest compared with the operational benefit of rapid detection and troubleshooting. Options focused on drift detection, audit logging, or changing the endpoint type do not directly meet the stated 5-minute endpoint health alerting requirement under the constraints. - Model Monitor for drift helps with data/model drift over hours/days, not rapid detection of endpoint errors/latency/throttling. - CloudTrail for invocations is for API audit events and does not provide the needed runtime latency/throttling health signals. - Switching to async inference can change client integration patterns and is unnecessary when the requirement is improved monitoring and alerting.

CloudWatch 指标和日志是在运行时监控推理 endpoint 运行状况的主要工具。针对延迟百分位、4XX/5XX 错误和限制发出警报可提供快速检测，并将容器日志发送到 CloudWatch Logs 提供故障排除所需的上下文。这满足了 5 分钟警报目标，且开销较低，且无需更改模型或客户端。 对于 SageMaker 端点，最好使用用于快速定量信号（延迟、错误率、限制）的 CloudWatch 指标和用于定性诊断（堆栈跟踪、超时、上游依赖性错误）的 CloudWatch Logs 来实施运行状况监控。在此场景中，在 ModelLatency、Invocable4XXErrors、Initation5XXErrors 和 InvocableThrottles 上创建 CloudWatch 警报（并通过 SNS/on-call 工具路由通知）可缩短检测时间，同时保持较低的成本。 在 CloudWatch Logs 中启用 endpoint/容器日志，团队可以将警报峰值与特定错误消息和请求模式关联起来。关键的权衡是一些额外的日志摄取/存储成本，但与快速检测和故障排除的操作优势相比，它通常是适度的。 专注于漂移检测、审核日志记录或更改 endpoint 类型的选项不能直接满足限制条件下规定的 5 分钟 endpoint 运行状况警报要求。 - 用于漂移的 Model Monitor 有助于数据/模型在数小时/天内的漂移，而不是快速检测 endpoint 错误/延迟/限制。 - 用于调用的 CloudTrail 用于 API 审计事件，不提供所需的运行时延迟/限制运行状况信号。 - 切换到异步推理可以改变客户端集成模式，并且当要求改进监控和警报时，这是不必要的。

CloudWatch メトリクスとログは、実行時に推論 endpoint の健全性を監視するための主要なツールです。レイテンシ パーセンタイル、4XX/5XX エラー、スロットルに関するアラームにより迅速な検出が可能になり、コンテナ ログを CloudWatch Logs に送信することでトラブルシューティングに必要なコンテキストが提供されます。これにより、オーバーヘッドが低く、モデルやクライアントを変更することなく、5 分間のアラート目標を達成できます。 SageMaker エンドポイントの場合、健全性モニタリングは、高速で定量的なシグナル (レイテンシー、エラー率、スロットリング) の場合は CloudWatch メトリクスを、定性的な診断 (スタック トレース、タイムアウト、アップストリームの依存関係エラー) の場合は CloudWatch Logs を使用して実装するのが最適です。このシナリオでは、ModelLatency、Invocation4XXErrors、Invocation5XXErrors、InvocationThrottles で CloudWatch アラームを作成する (および SNS/オンコール ツールを介して通知をルーティングする) ことで、コストを低く抑えながら検出までの時間を短縮します。 CloudWatch Logs で endpoint/コンテナ ログを有効にすると、チームはアラームのスパイクを特定のエラー メッセージおよびリクエスト パターンと関連付けることができます。主なトレードオフは、追加のログ取り込み/保存コストですが、通常、迅速な検出とトラブルシューティングによる運用上のメリットに比べればそれほど大きくありません。 ドリフト検出、監査ログ、または endpoint タイプの変更に重点を置いたオプションは、制約の下で規定されている 5 分間の endpoint ヘルス アラート要件を直接満たしていません。 - ドリフト用の Model Monitor は、endpoint エラー/遅延/スロットルの迅速な検出ではなく、数時間/数日にわたるデータ/モデルのドリフトに役立ちます。 - 呼び出し用の CloudTrail は、API 監査イベント用であり、必要な実行時レイテンシー/スロットリングの健全性信号を提供しません。 - 非同期推論に切り替えるとクライアント統合パターンが変更される可能性がありますが、監視とアラートの向上が必要な場合は不要です。

The metrics indicate the endpoint is CPU-bound and constrained by a very low autoscaling max capacity, so it cannot add enough replicas during the spike. Increasing the maximum instance count and scaling out sooner reduces per-instance CPU pressure and request queueing, which lowers p95 latency and timeouts. Because capacity scales back down after the spike, cost outside the spike window stays low. For SageMaker real-time endpoints, spike latency commonly comes from insufficient concurrency (too few instances) and autoscaling that reacts too late or is capped. Here, CPU is near saturation while memory is low, and the current max capacity of 2 prevents the endpoint from adding enough replicas to handle the spike. A high-level fix is to tune endpoint autoscaling so the variant scales out earlier and is allowed to scale higher: - Increase maxCapacity to cover the spike. - Lower the target for SageMakerVariantInvocationsPerInstance (or similar target-tracking metric) so scale-out starts before CPU saturates. - Reduce scale-out cooldown to react faster, while keeping scale-in conservative to avoid thrashing. This typically improves p95 latency and reliability during spikes while keeping costs low the rest of the day because you only pay for extra instances when they are needed. - Oversize instances only increases hourly cost and still leaves the endpoint capped at 2 instances during spikes. - Fixed high capacity can meet the SLA but wastes money during the long off-peak period. - Batch inference swap breaks the stated real-time response requirement.

这些指标表明 endpoint 受 CPU 限制，并受到非常低的 autoscaling 最大容量的限制，因此它无法在峰值期间添加足够的副本。增加最大实例计数并更快地扩展可减少每个实例的 CPU 压力和请求排队，从而降低 p95 延迟和超时。由于容量在峰值后会缩减，因此峰值窗口外的成本保持较低水平。 对于 SageMaker 实时端点，峰值延迟通常来自并发不足（实例太少）以及 autoscaling 反应太晚或受到限制。此处，CPU 接近饱和，而内存较低，当前最大容量为 2，导致 endpoint 无法添加足够的副本来处理峰值。 高级修复是调整 endpoint autoscaling，以便变体更早地扩展并允许扩展得更高： - 增加 maxCapacity 以覆盖尖峰。 - 降低 SageMakerVariantInitationsPerInstance（或类似的目标跟踪指标）的目标，以便在 CPU 饱和之前开始横向扩展。 - 减少横向扩展冷却时间以加快反应速度，同时保持横向收缩保守以避免抖动。 这通常会改善 p95 在峰值期间的延迟和可靠性，同时使 REST 保持较低的成本，因为您只需在需要时为额外的实例付费。 - 超大实例只会增加每小时成本，并且在峰值期间 endpoint 的实例数仍上限为 2 个。 - 固定高容量可以满足 SLA，但在长时间的非高峰期间会浪费金钱。 - 批量推理交换打破了规定的实时响应要求。

メトリクスは、endpoint が CPU に依存しており、非常に低い autoscaling 最大容量によって制約されているため、スパイク中に十分なレプリカを追加できないことを示しています。最大インスタンス数を増やし、より早くスケールアウトすると、インスタンスごとの CPU プレッシャーとリクエスト キューが軽減され、p95 のレイテンシーとタイムアウトが減少します。スパイク後に容量が元に戻るため、スパイク ウィンドウ外のコストは低く抑えられます。 SageMaker リアルタイム エンドポイントの場合、スパイク レイテンシは一般に、同時実行性の不足 (インスタンスが少なすぎる) と、反応が遅すぎるか制限されている autoscaling によって発生します。ここでは、CPU が飽和状態に近く、メモリが不足しており、現在の最大容量 2 では、endpoint がスパイクに対処するのに十分なレプリカを追加できません。 大まかな修正は、バリアントがより早くスケールアウトし、より高いスケールが可能になるように endpoint autoscaling を調整することです。 - スパイクをカバーするには maxCapacity を増やします。 - CPU が飽和する前にスケールアウトが開始されるように、SageMakerVariantInvocationsPerInstance (または同様のターゲット追跡メトリクス) のターゲットを下げます。 - スラッシングを避けるためにスケールインを控えめに保ちながら、スケールアウトのクールダウンを短縮してより速く反応します。 これにより通常、追加インスタンスが必要な場合にのみ料金を支払うため、コストを当時の REST よりも低く抑えながら、スパイク時の p95 のレイテンシと信頼性が向上します。 - サイズ超過のインスタンスは時間当たりのコストを増加させるだけで、スパイク中も endpoint の上限は 2 インスタンスのままです。 - 固定大容量は SLA を満たすことができますが、長いオフピーク期間にはコストが無駄になります。 - バッチ推論スワップは、規定されたリアルタイム応答要件を破ります。

With only 40 total trials and 2-hour trainings, the priority is finding a strong configuration with as few evaluations as possible. For a low-dimensional, mostly continuous, smooth search space, Bayesian optimization can use results from prior trials to choose more promising next trials than random sampling. The main tradeoff is less effective scaling to massive parallelism and potential sensitivity to noisy objectives. This is a “limited budget, expensive trial” tuning problem: each evaluation costs hours and the team can only afford 40 total trials. When the hyperparameter space is relatively small in dimensionality and largely continuous, and the objective behaves reasonably smoothly, Bayesian optimization is usually preferred because it is sample-efficient (it learns from earlier trials to choose better next candidates). Random search is often better when you can afford many trials, want easy parallelism at large scale, or have very high-dimensional spaces with many irrelevant parameters or lots of discrete/categorical choices. Here, parallelism is already limited (4 at a time), so Bayesian’s more sequential, guided exploration is not a major drawback. Key takeaway: choose Bayesian optimization to maximize performance under a tight trial budget; choose random search when you need broad, parallel exploration or the space is awkward for surrogate modeling. - More random trials violates the stated cap of 40 total training jobs. - Grid search is inefficient as dimensions grow and wastes trials on unpromising combinations. - One-at-a-time tuning misses interactions between hyperparameters and usually underperforms.

总共只有 40 次试验和 2 小时的培训，首要任务是找到一个强大的配置，并进行尽可能少的评估。对于低维、大部分连续、平滑的搜索空间，贝叶斯优化可以使用先前试验的结果来选择比随机抽样更有希望的下一个试验。主要的权衡是大规模并行性的扩展效率较低以及对噪声目标的潜在敏感性。 这是一个“预算有限，试验成本高昂”的调优问题：每次评估都需要花费数小时，而且团队总共只能承担 40 次试验。当 hyperparameter 空间维数相对较小且基本连续，并且目标表现得相当平滑时，通常首选贝叶斯优化，因为它具有样本效率（它从早期试验中学习以选择更好的下一个候选）。 当您可以负担多次试验、想要大规模的轻松并行性、或者具有包含许多不相关参数或大量离散/分类选择的非常高维空间时，随机搜索通常会更好。在这里，并行性已经受到限制（一次 4 个），因此贝叶斯更加顺序、引导的探索并不是主要缺点。要点：选择贝叶斯优化以在紧张的试验预算下最大限度地提高性能；当您需要广泛的并行探索或者空间不适合代理建模时，请选择随机搜索。 - 更多随机试验违反了 40 个总训练作业的规定上限。 - 随着维度的增长，网格搜索效率低下，并且浪费了对没有希望的组合的尝试。 - 一次一个的调整会错过超参数之间的交互，并且通常表现不佳。

合計 40 回のトライアルと 2 時間のトレーニングしかないため、最優先事項はできるだけ少ない評価で強力な構成を見つけることです。低次元でほぼ連続的な滑らかな検索空間の場合、ベイジアン最適化では、以前のトライアルの結果を使用して、ランダム サンプリングよりも有望な次のトライアルを選択できます。主なトレードオフは、大規模な並列処理に対するスケーリングの効率が低下することと、ノイズの多いオブジェクトに対する潜在的な感度が低下することです。 これは「限られた予算、高価なトライアル」のチューニングの問題です。各評価には何時間もかかり、チームは合計 40 回のトライアルしか余裕がありません。hyperparameter 空間の次元が比較的小さく、大部分が連続で、目的が適度にスムーズに動作する場合、サンプル効率が高い (以前の試行から学習して、より良い次の候補を選択する) ため、ベイズ最適化が通常好まれます。 多くの試行を行う余裕がある場合、大規模な並列処理を容易にしたい場合、または無関係なパラメーターや離散/カテゴリの選択肢が多数ある非常に高次元の空間がある場合は、ランダム検索の方が優れていることがよくあります。ここでは、並列処理はすでに制限されている (一度に 4 つ) ため、ベイジアンのより順次的なガイド付き探索は大きな欠点ではありません。重要なポイント: 限られたトライアル予算の下でパフォーマンスを最大化するには、ベイズ最適化を選択してください。広範囲の並行探索が必要な場合、またはサロゲート モデリングには扱いにくい空間がある場合は、ランダム検索を選択します。 - ランダムなトライアルを増やすと、トレーニング ジョブの合計 40 件という規定の上限に違反します。 - グリッド検索は次元が大きくなると非効率になり、見込みのない組み合わせでの試行が無駄になります。 - 一度に 1 つずつ調整すると、ハイパーパラメータ間の相互作用が見逃され、通常はパフォーマンスが低下します。

The symptom (great offline RMSE but poor post-deployment accuracy) is typical of time-series leakage caused by random shuffling. For forecasting, validation must simulate the real use case: predicting future values from past data with the required horizon. Using a chronological holdout (often with a horizon-sized gap) produces a realistic estimate and trains without peeking into the future. Time series forecasting requires splits that preserve time order and match the prediction horizon. With shuffle=True, examples from the future can end up in the training set while earlier timestamps land in validation, especially when labels are shifted to predict 7 days ahead. This “future peek” makes offline RMSE artificially low while the deployed model performs poorly on truly future periods, triggering Model Monitor accuracy violations. A minimal, high-impact fix is to change to a temporal split that mirrors production: - Sort by timestamp (per series/store if applicable). - Use the latest period as the validation set. - Add a gap of 7 days between train and validation so no training row can use information that overlaps the 7-day-ahead target window. This preserves the existing model approach while aligning evaluation and training with the 7-day horizon. - Bigger instances address resource limits, not leakage-driven accuracy collapse. - More tuning optimizes within a flawed evaluation setup and won’t correct the optimistic validation signal. - More shuffling makes temporal leakage worse by further mixing future and past observations.

这种症状（离线 RMSE 很好，但部署后精度很差）是典型的随机洗牌导致的时间序列泄漏。对于预测，验证必须模拟真实用例：根据过去的数据在所需范围内预测未来值。使用时间顺序保留（通常具有地平线大小的间隙）可以产生切合实际的估计并进行训练，而无需窥视未来。 时间序列预测需要保留时间顺序并匹配预测范围的分割。使用 shuffle=True 时，未来的示例可以最终出现在训练集中，而较早的时间戳则进入验证，尤其是当标签被转移以预测未来 7 天时。这种“未来窥视”使得离线 RMSE 人为地降低，而部署的模型在真正的未来时期表现不佳，从而触发 Model Monitor 准确性违规。 一个最小的、高影响力的解决方案是更改为反映生产的时间分割： - 按时间戳排序（每个系列/商店，如果适用）。 - 使用最新时期作为验证集。 - 在训练和验证之间添加 7 天的间隔，这样训练行就不能使用与 7 天前目标窗口重叠的信息。 这保留了现有的模型方法，同时使评估和培训与 7 天的时间范围保持一致。 - 更大的实例解决了资源限制，而不是泄漏驱动的精度崩溃。 - 在有缺陷的评估设置中进行更多调整优化，并且不会纠正乐观的验证信号。 - 更多的改组会进一步混合未来和过去的观察结果，从而使时间泄漏变得更糟。

この症状 (オフライン RMSE は良好ですが、展開後の精度が低い) は、ランダム シャッフルによって引き起こされる時系列リークの典型的なものです。予測の場合、検証では実際の使用例、つまり必要な期間を使用して過去のデータから将来の値を予測することをシミュレートする必要があります。時系列のホールドアウト (多くの場合地平線サイズのギャップがある) を使用すると、現実的な推定が生成され、将来を覗くことなくトレーニングが行われます。 時系列予測には、時間の順序を保持し、予測期間と一致する分割が必要です。shuffle=True を指定すると、特に 7 日先を予測するためにラベルがシフトされた場合、以前のタイムスタンプが検証に到達する一方で、将来のサンプルがトレーニング セットに含まれる可能性があります。この「将来のピーク」により、オフラインの RMSE が人為的に低くなり、デプロイされたモデルの実際の将来の期間のパフォーマンスが低下し、Model Monitor の精度違反が引き起こされます。 最小限で大きな影響を与える修正は、本番環境を反映する一時的な分割に変更することです。 - タイムスタンプ順に並べ替えます (該当する場合、シリーズ/ストアごと)。 - 最新の期間を検証セットとして使用します。 - トレーニング行と検証の間に 7 日間のギャップを追加し、トレーニング行が 7 日前のターゲット ウィンドウと重複する情報を使用できないようにします。 これにより、評価とトレーニングを 7 日間の期間に合わせて調整しながら、既存のモデルのアプローチが維持されます。 - インスタンスを大きくすると、リークによる精度の低下ではなく、リソースの制限に対処できます。 - さらなるチューニングは、欠陥のある評価設定内で最適化され、楽観的な検証信号は修正されません。 - シャッフルを増やすと、将来と過去の観測がさらに混合されるため、時間的漏れが悪化します。

Use Amazon SageMaker Clarify as an automated processing step in the pipeline to detect bias in the training data and to compute high-level bias metrics before model approval. This improves operability and auditability because the report is produced consistently every run and stored centrally. It also reduces cost compared with running manual analyses on always-on notebook instances. Amazon SageMaker Clarify is designed to identify potential bias and compute bias-related metrics at a high level, including pre-training (dataset) bias and post-training (model) bias. Embedding Clarify as a SageMaker Processing job inside SageMaker Pipelines makes the check repeatable and gateable (for example, fail or stop the pipeline if metrics exceed agreed thresholds) and produces artifacts (reports/metrics) that can be stored in S3 and attached to model approval workflows. This is typically implemented as: - Clarify processing step that reads the training dataset from S3 - Computes bias metrics for the specified sensitive feature and label - Writes a bias report/metrics to S3 (and optionally records them with the model package) The main tradeoff is added pipeline runtime and per-run processing cost, but it removes manual steps and avoids always-on cost while improving governance. - Auto scaling improves availability/cost for inference capacity, not training-data bias measurement. - Data Wrangler can transform/prepare data, but it is not the standard service for bias metrics and reporting. - Athena SQL could produce custom aggregates, but it lacks Clarify’s bias metrics/reporting and is harder to standardize and audit in ML workflows.

使用 Amazon SageMaker Clarify 作为管道中的自动化处理步骤，以检测训练数据中的偏差并在模型批准之前计算高级偏差指标。这提高了可操作性和可审计性，因为每次运行都会一致地生成报告并集中存储。与在始终在线的笔记本实例上运行手动分析相比，它还降低了成本。 Amazon SageMaker Clarify 旨在识别潜在偏差并在高级别计算与偏差相关的指标，包括训练前（数据集）偏差和训练后（模型）偏差。将 Clarify 作为 SageMaker 处理作业嵌入到 SageMaker Pipelines 中，使检查可重复且可门控（例如，如果指标超过商定的阈值，则失败或停止管道），并生成可存储在 S3 中并附加到模型审批工作流程的工件（报告/指标）。 这通常实现为： - Clarify 处理步骤，从 S3 读取训练数据集 - 计算指定敏感特征和标签的偏差指标 - 将偏差报告/指标写入 S3（并可选择将其与模型包一起记录） 主要的权衡是增加了管道运行时间和每次运行的处理成本，但它消除了手动步骤并避免了始终在线的成本，同时改进了治理。 - 自动缩放提高了推理能力的可用性/成本，而不是训练数据偏差测量。 - Data Wrangler 可以转换/准备数据，但它不是偏差指标和报告的标准服务。 - Athena SQL 可以生成自定义聚合，但它缺乏 Clarify 的偏差指标/报告，并且在 ML 工作流程中更难标准化和审核。

パイプラインの自動処理ステップとして Amazon SageMaker Clarify を使用して、トレーニング データのバイアスを検出し、モデルの承認前に高レベルのバイアス メトリクスを計算します。これにより、レポートが実行のたびに一貫して生成され、一元的に保存されるため、操作性と監査可能性が向上します。また、常時稼働のノートブック インスタンスで手動分析を実行する場合と比較してコストも削減されます。 Amazon SageMaker Clarify は、潜在的なバイアスを特定し、トレーニング前 (データセット) のバイアスやトレーニング後 (モデル) のバイアスなど、バイアス関連のメトリクスを高レベルで計算するように設計されています。Clarify を SageMaker Processing ジョブとして SageMaker Pipelines 内に埋め込むと、チェックが反復可能かつゲート可能になり (たとえば、メトリクスが合意されたしきい値を超えた場合にパイプラインを失敗または停止する)、S3 に保存してモデル承認ワークフローに添付できるアーティファクト (レポート/メトリクス) が生成されます。 これは通常、次のように実装されます。 - S3 からトレーニング データセットを読み取る Clarify 処理ステップ - 指定された機密機能とラベルのバイアス メトリックを計算します - バイアス レポート/メトリクスを S3 に書き込みます (オプションでモデル パッケージとともに記録します)。 主なトレードオフは、パイプラインの実行時間と実行ごとの処理コストの追加ですが、手動の手順が不要になり、常時稼働のコストが回避され、ガバナンスが向上します。 - 自動スケーリングにより、トレーニング データのバイアス測定ではなく、推論容量の可用性とコストが向上します。 - Data Wrangler はデータを変換/準備できますが、バイアス メトリックとレポートの標準サービスではありません。 - Athena SQL はカスタム集計を生成できますが、Clarify のバイアス メトリクス/レポート機能が欠如しており、ML ワークフローでの標準化と監査が困難です。

Use SageMaker managed Spot training and configure checkpointing to S3. This captures progress so the job can continue after Spot interruptions, preserving reliability while benefiting from Spot discounts. The main tradeoff is potential longer wall-clock time due to interruptions and checkpoint overhead. The core concept is using discounted Spot capacity for training while maintaining reliability through checkpointing. With SageMaker managed Spot training, you enable Spot for the training job and configure an S3 checkpoint location so SageMaker can restore the latest checkpoint if the instance is reclaimed. To keep the workflow reliable within the nightly window: - Enable managed Spot training for the training job. - Configure CheckpointConfig to an S3 path and ensure the script saves checkpoints regularly. - Set runtime/wait settings so occasional interruptions still allow completion before 7:00 AM. This improves cost without changing the model or pipeline stages; the main tradeoff is that interruptions can increase end-to-end training time compared to stable On-Demand capacity. - Right-size blindly can break the 7:00 AM deadline if training slows significantly. - Spot without checkpoints risks losing progress and missing the nightly delivery if interrupted. - Inference optimization (multi-model endpoints) doesn’t reduce training cost for the nightly job. Questions 26-50

使用 SageMaker Managed Spot Training 并将检查点配置为 S3。这可以捕获进度，以便在 Spot 中断后作业可以继续进行，保持可靠性，同时受益于 Spot 折扣。主要的权衡是由于中断和检查点开销而可能导致挂钟时间更长。 核心概念是使用打折的 Spot 容量进行训练，同时通过检查点保持可靠性。使用 SageMaker Managed Spot Training，您可以为训练作业启用 Spot 并配置 S3 检查点位置，以便 SageMaker 在实例被回收时可以恢复最新的检查点。 为了在夜间窗口内保持工作流程的可靠性： - 为训练作业启用托管 Spot Training。 - 将 CheckpointConfig 配置为 S3 路径并确保脚本定期保存检查点。 - 设置运行时间/等待设置，以便偶尔的中断仍允许在上午 7:00 之前完成。 这在不改变模型或管道阶段的情况下提高了成本；主要的权衡是，与稳定的按需容量相比，中断会增加端到端训练时间。 - 如果训练速度显着减慢，盲目调整规模可能会超出早上 7:00 的截止时间。 - 如果中断，没有检查点的地点可能会失去进度并错过夜间送货。 - 推理优化（多模型端点）不会降低夜间作业的培训成本。 问题 26-50

SageMaker Managed Spot Training を使用し、チェックポイントを S3 に設定します。これにより進行状況がキャプチャされるため、スポットの中断後もジョブを続行でき、スポット割引の恩恵を受けながら信頼性を維持できます。主なトレードオフは、中断とチェックポイントのオーバーヘッドにより実測時間が長くなる可能性があることです。 中心となるコンセプトは、チェックポイント設定を通じて信頼性を維持しながら、割引価格のスポット容量をトレーニングに使用することです。SageMaker Managed Spot Training を使用すると、トレーニング ジョブのスポットを有効にし、S3 チェックポイントの場所を設定して、インスタンスが再利用された場合に SageMaker が最新のチェックポイントを復元できるようにします。 夜間の時間枠内でワークフローの信頼性を維持するには、次の手順を実行します。 - トレーニング ジョブに対して管理対象 Spot Training を有効にします。 - CheckpointConfig を S3 パスに構成し、スクリプトがチェックポイントを定期的に保存するようにします。 - 実行時間/待機設定を設定して、時折の中断があっても午前 7:00 前に完了できるようにします。 これにより、モデルやパイプラインのステージを変更することなくコストが向上します。主なトレードオフは、安定したオンデマンド容量と比較して、中断によりエンドツーエンドのトレーニング時間が増加する可能性があることです。 - トレーニングが大幅に遅くなった場合、やみくもに適切なサイズを設定すると、午前 7 時の締め切りを破ってしまう可能性があります。 - チェックポイントのないスポットでは、中断された場合に進行状況が失われ、夜間の配信を逃すリスクがあります。 - 推論の最適化 (マルチモデル エンドポイント) では、夜間ジョブのトレーニング コストは削減されません。 質問 26 ～ 50

Applying class weights during training addresses imbalance by penalizing fraud misclassification more heavily, typically improving fraud recall with little to no increase in training cost. It also preserves auditability because it does not fabricate new customer records. The main tradeoff is a higher false-positive rate and the need to re-tune thresholds and calibration. When the positive class is rare, many algorithms optimize overall loss by prioritizing the majority class. A cost-effective, auditable way to counter this is to use class weights (or per-example weights) so fraud errors contribute more to the training objective. In SageMaker (for example, the built-in XGBoost), setting scale_pos_weight (often near ,\(\frac{\#\text{negative}}{\#\text{positive}}\),) can improve fraud recall without increasing the number of training rows, so it typically stays within tight cost constraints and avoids synthetic-record governance issues. The tradeoff is that emphasizing the minority class can increase false positives and affect probability calibration, so you usually need to re-evaluate precision/recall tradeoffs and choose an operating threshold that meets business requirements. - Oversampling cost/overfit increases effective dataset size and can overfit duplicates, often raising training/tuning cost. - Downsampling loses signal can drop important majority-class patterns, hurting stability and overall generalization. - Synthetic data prohibited violates the stated auditability constraint against creating synthetic customer records.

在训练期间应用类别权重，通过更严厉地惩罚欺诈错误分类来解决不平衡问题，通常可以在几乎不增加训练成本的情况下提高欺诈召回率。它还保留了可审计性，因为它不会伪造新的客户记录。主要的权衡是较高的误报率以及需要重新调整阈值和校准。 当正类很少时，许多算法通过优先考虑多数类来优化整体损失。解决这个问题的一种经济高效、可审计的方法是使用类别权重（或每个示例权重），这样欺诈错误对训练目标的贡献更大。在 SageMaker（例如，内置 XGBoost）中，设置 scale_pos_weight（通常接近 ,\(\frac{\#\text{负}}{\#\text{正}}\),）可以在不增加训练行数的情况下提高欺诈召回率，因此它通常保持在严格的成本限制内并避免合成记录治理问题。 权衡是强调少数类别会增加误报并影响概率校准，因此您通常需要重新评估精度/召回率权衡并选择满足业务要求的操作阈值。 - 过采样成本/过拟合会增加有效数据集大小，并且可能会过拟合重复项，通常会提高训练/调整成本。 - 下采样丢失信号可能会丢失重要的多数类模式，从而损害稳定性和整体泛化能力。 - 禁止合成数据违反了针对创建合成客户记录的规定的可审核性限制。

トレーニング中にクラスの重みを適用すると、不正の誤分類に対してより重くペナルティが課せられるため、不均衡が解消され、通常はトレーニング コストをほとんど増加させることなく不正の再現率が向上します。また、新しい顧客記録を捏造しないため、監査可能性も維持されます。主なトレードオフは、誤検知率が高くなることと、しきい値とキャリブレーションを再調整する必要があることです。 ポジティブなクラスがまれな場合、多くのアルゴリズムは多数のクラスを優先して全体の損失を最適化します。これに対抗するコスト効率が高く、監査可能な方法は、クラスの重み (または例ごとの重み) を使用して、不正エラーがトレーニング目標により多く寄与するようにすることです。SageMaker (たとえば、組み込みの XGBoost) では、scale_pos_weight (多くの場合、 ,\(\frac{\#\text{negative}}{\#\text{positive}}\) の近く) を設定すると、トレーニング行の数を増やさずに不正行為の再現率を向上させることができるため、通常は厳しいコスト制約内に収まり、合成レコードのガバナンスの問題を回避できます。 トレードオフとして、少数派クラスを強調すると誤検知が増加し、確率の調整に影響を与える可能性があるため、通常は精度と再現率のトレードオフを再評価し、ビジネス要件を満たす動作しきい値を選択する必要があります。 - オーバーサンプリング コスト/オーバーフィットにより、有効なデータセット サイズが増加し、重複がオーバーフィットされる可能性があり、多くの場合、トレーニング/チューニング コストが増加します。 - ダウンサンプリングにより信号が失われると、重要な多数派クラスのパターンが失われ、安定性と全体的な一般化が損なわれる可能性があります。 - 禁止された合成データは、合成顧客レコードの作成に対する規定の監査可能性の制約に違反します。

Hyperparameter tuning is a search procedure that evaluates many hyperparameter configurations by running multiple training jobs. Because it multiplies the number of training runs, it can significantly increase training cost and extend time-to-train compared with training a single model once. In SageMaker, this is commonly performed with Automatic Model Tuning. Hyperparameter tuning is the process of selecting the best hyperparameter values (for example, learning rate, tree depth, or regularization strength) by training and evaluating multiple candidate models. In Amazon SageMaker, Automatic Model Tuning orchestrates this by creating a tuning job that runs many underlying training jobs, each with a different hyperparameter configuration. This is why tuning is a key cost-and-schedule consideration: more trials typically mean more compute time and higher training spend. Regularization is often confused with tuning, but it is a modeling technique applied within a single training run to reduce overfitting by adding a penalty to the objective; it does not inherently require multiple training jobs. The key takeaway is that tuning scales training cost roughly with the number of trials you run. - Regularization vs. tuning regularization changes the loss/constraints inside one training job, while tuning runs many jobs to search values. - Model drift is a post-deployment change in data/model performance, not a training-time search procedure. - Data leakage is unintended use of future/target information during training, affecting validity rather than cost planning.

hyperparameter 调整是一个搜索过程，通过运行多个训练作业来评估许多 hyperparameter 配置。由于它增加了训练运行的次数，因此与训练单个模型一次相比，它可以显着增加训练成本并延长训练时间。在 SageMaker 中，这通常使用 Automatic Model Tuning 执行。 hyperparameter 调优是通过训练和评估多个候选模型来选择最佳 hyperparameter 值（例如，学习率、树深度或正则化强度）的过程。在 Amazon SageMaker 中，Automatic Model Tuning 通过创建一个运行许多底层训练作业的调优作业来协调这一过程，每个作业都具有不同的 hyperparameter 配置。这就是为什么调优是关键的成本和进度考虑因素：更多的试验通常意味着更多的计算时间和更高的训练支出。 正则化经常与调整混淆，但它是一种在单次训练运行中应用的建模技术，通过向目标添加惩罚来减少 overfitting；它本身并不需要多个培训工作。关键的一点是，调整可以根据您运行的试验数量大致调整训练成本。 - 正则化与调整正则化会改变一项训练作业中的损失/约束，而调整会运行许多作业来搜索值。 - 模型漂移是数据/模型性能的部署后变化，而不是训练时搜索过程。 - data leakage 是在训练期间无意使用未来/目标信息，影响有效性而不是成本规划。

hyperparameter チューニングは、複数のトレーニング ジョブを実行して多くの hyperparameter 構成を評価する検索手順です。トレーニングの実行回数が増えるため、単一のモデルを 1 回トレーニングする場合と比較して、トレーニング コストが大幅に増加し、トレーニング時間が長くなる可能性があります。SageMaker では、これは通常 Automatic Model Tuning を使用して実行されます。 hyperparameter チューニングは、複数の候補モデルをトレーニングおよび評価することによって、最適な hyperparameter 値 (学習率、ツリーの深さ、正則化強度など) を選択するプロセスです。Amazon SageMaker では、Automatic Model Tuning が、それぞれが異なる hyperparameter 構成を持つ多くの基礎となるトレーニング ジョブを実行するチューニング ジョブを作成することでこれを調整します。これが、チューニングがコストとスケジュールの重要な考慮事項である理由です。通常、トライアルが増えると、コンピューティング時間が増加し、トレーニング費用も増加します。 正則化はチューニングとよく混同されますが、目的にペナルティを追加することで overfitting を削減するために 1 回のトレーニング実行内で適用されるモデリング手法です。本質的に複数のトレーニング ジョブは必要ありません。重要な点は、チューニングのトレーニング コストは、実行するトライアルの数にほぼ比例するということです。 - 正則化とチューニング 正則化では 1 つのトレーニング ジョブ内の損失/制約が変更されますが、チューニングでは値を検索するために多くのジョブが実行されます。 - モデルのドリフトは、データ/モデルのパフォーマンスにおける展開後の変化であり、トレーニング時の検索手順ではありません。 - data leakage はトレーニング中の将来/ターゲット情報の意図しない使用であり、コスト計画ではなく有効性に影響します。

Use anonymization and masking that change the data content before it reaches training. Deterministic tokenization (with a secret key) removes direct identifiers while keeping a consistent surrogate key for joins. PHI redaction on clinician notes masks sensitive entities in unstructured text so the model does not learn or expose them. To protect PII/PHI in ML datasets, apply data classification to locate sensitive fields and then apply anonymization/masking so sensitive attributes are not present in the training data. For structured identifiers, replace values like name/SSN/patient ID with a deterministic, keyed token (for example, HMAC) so the same person maps to the same surrogate key across tables, while the original identifier is removed. For unstructured notes, run an NLP de-identification step (such as Amazon Comprehend Medical PHI detection) and redact or replace detected entities before writing the curated training dataset to S3. Controls like encryption, network isolation, and access permissions reduce exposure but do not remove sensitive attributes from the dataset itself. - OK Tokenize identifiers with deterministic keyed hashing; drop raw fields — anonymizes direct identifiers while preserving joinability. - OK Detect and redact PHI in notes using Amazon Comprehend Medical — masks PHI in unstructured text before training. - NO Encrypt the S3 buckets and SageMaker volumes with SSE-KMS — protects at rest but leaves PII/PHI unchanged in the dataset. - NO Enable Amazon Macie on the S3 buckets and review findings — classifies/discovers sensitive data but does not anonymize or mask it. - NO Use Lake Formation to deny access to columns containing PII — access control helps governance, but PII still exists in the stored dataset. - NO Run training jobs in private subnets and use VPC endpoints for S3 — reduces network exposure but does not transform sensitive attributes.

使用匿名化和屏蔽，在数据到达训练之前更改数据内容。确定性标记化（使用密钥）删除直接标识符，同时保持连接的一致代理键。对临床医生笔记的 PHI 编辑会掩盖非结构化文本中的敏感实体，因此模型不会学习或暴露它们。 要保护 ML 数据集中的 PII/PHI，请应用数据分类来定位敏感字段，然后应用匿名化/屏蔽，以便敏感属性不会出现在训练数据中。对于结构化标识符，请将姓名/SSN/患者 ID 等值替换为确定性的密钥令牌（例如 HMAC），以便同一个人跨表映射到相同的代理键，同时删除原始标识符。对于非结构化笔记，在将策划的训练数据集写入 S3 之前，运行 NLP 去识别步骤（例如 Amazon Comprehend 医疗 PHI 检测）并编辑或替换检测到的实体。 加密、网络隔离和访问权限等控制措施可减少暴露，但不会从数据集本身中删除敏感属性。 - OK Tokenize 具有确定性键控哈希的标识符；删除原始字段 - 匿名化直接标识符，同时保留可连接性。 - OK 使用 Amazon Comprehend Medical 检测并编辑笔记中的 PHI — 在训练前屏蔽非结构化文本中的 PHI。 - 否 使用 SSE-KMS 加密 S3 存储桶和 SageMaker 卷 — 在 REST 处提供保护，但在数据集中保持 PII/PHI 不变。 - 否 在 S3 存储桶上启用 Amazon Macie 并查看结果 — 对敏感数据进行分类/发现，但不会对其进行匿名化或屏蔽。 - 否 使用 Lake Formation 拒绝访问包含 PII 的列 — 访问控制有助于治理，但 PII 仍然存在于存储的数据集中。 - 否 在私有子网中运行训练作业并将 VPC 端点用于 S3 — 减少网络暴露，但不会转换敏感属性。

匿名化とマスキングを使用して、トレーニングに達する前にデータの内容を変更します。決定論的なトークン化 (秘密キーを使用) は、結合の一貫した代理キーを維持しながら、直接識別子を削除します。臨床医のメモに対する PHI 編集では、非構造化テキスト内の機密エンティティがマスクされるため、モデルはそれらを学習したり公開したりしません。 ML データセット内の PII/PHI を保護するには、データ分類を適用して機密フィールドを見つけてから、匿名化/マスキングを適用して、機密属性がトレーニング データに存在しないようにします。構造化識別子の場合、名前/SSN/患者 ID などの値を決定的なキー付きトークン (HMAC など) に置き換えます。これにより、元の識別子は削除されますが、同じ人物がテーブル全体で同じ代理キーにマップされます。非構造化メモの場合は、厳選されたトレーニング データセットを S3 に書き込む前に、NLP 匿名化ステップ (Amazon Comprehend 医療 PHI 検出など) を実行し、検出されたエンティティを編集または置換します。 暗号化、ネットワーク分離、アクセス許可などの制御により露出は軽減されますが、データセット自体から機密属性は削除されません。 - OK 決定論的なキー付きハッシュを使用して識別子をトークン化します。raw フィールドを削除 — 結合可能性を維持しながら直接識別子を匿名化します。 - OK Amazon Comprehend Medical を使用してメモ内の PHI を検出して編集します — トレーニング前に非構造化テキスト内の PHI をマスクします。 - いいえ S3 バケットと SageMaker ボリュームを SSE-KMS で暗号化します — REST で保護しますが、データセット内の PII/PHI は変更されません。 - いいえ S3 バケットで Amazon Macie を有効にし、結果を確認します — 機密データを分類/検出しますが、匿名化またはマスクしません。 - いいえ Lake Formation を使用して、PII を含む列へのアクセスを拒否します。アクセス制御はガバナンスに役立ちますが、保存されたデータセットには PII がまだ存在します。 - いいえ プライベート サブネットでトレーニング ジョブを実行し、S3 の VPC エンドポイントを使用します。ネットワークへの露出は軽減されますが、機密属性は変換されません。

Define the deployment as infrastructure as code and use a managed progressive delivery mechanism for SageMaker endpoints. Pair canary/linear traffic shifting with CloudWatch alarms to automatically roll back when latency or error rates regress. Use SageMaker model/version artifacts with encryption and AWS audit logs to satisfy governance requirements. The core need is maintainable, reliable ML infrastructure: repeatable configuration, safe rollouts, and observability hooks that can trigger rollback. An AWS-native pattern is to use infrastructure as code (AWS CDK or CloudFormation) to define SageMaker models/endpoints and supporting IAM/KMS/VPC settings, then run CI/CD with CodePipeline. For safe rollout, use CodeDeploy’s blue/green (canary or linear) deployment for SageMaker by shifting traffic between endpoint production variants while watching CloudWatch alarms (for p95 latency and 5xx), and automatically rolling back on alarm. Governance is met by using encrypted artifacts (S3/KMS, ECR/KMS as applicable) and auditable change history (CodePipeline/CodeDeploy events and AWS CloudTrail). The key takeaway is to combine IaC + progressive delivery + monitoring-driven rollback for SageMaker endpoints. - Manual console updates violates the repeatable, parameterized infrastructure requirement. - ECS rolling update does not provide SageMaker-native variant traffic shifting with CloudWatch-alarm rollback for this endpoint. - Batch Transform to S3 violates the real-time inference latency/SLA requirement.

将部署定义为基础设施即代码，并为 SageMaker 端点使用托管渐进式交付机制。将金丝雀/线性流量转移与 CloudWatch 警报配对，以便在延迟或错误率下降时自动回滚。使用具有加密和 AWS 审核日志的 SageMaker 模型/版本工件来满足治理要求。 核心需求是可维护、可靠的机器学习基础设施：可重复配置、安全部署以及可以触发回滚的可观察性挂钩。 AWS 原生模式是使用基础设施即代码（AWS CDK 或 CloudFormation）来定义 SageMaker 模型/终端节点并支持 IAM/KMS/VPC 设置，然后使用 CodePipeline 运行 CI/CD。为了安全推出，请使用 CodeDeploy 的 SageMaker 蓝/绿（金丝雀或线性）部署，在 endpoint 生产变体之间转移流量，同时观看 CloudWatch 警报（针对 p95 延迟和 5xx），并在警报时自动回滚。通过使用加密工件（S3/KMS、ECR/KMS（如适用））和可审核的更改历史记录（CodePipeline/CodeDeploy 事件和 AWS CloudTrail）来满足治理。 关键要点是将 IaC + 渐进式交付 + SageMaker 端点的监控驱动回滚相结合。 - 手动控制台更新违反了可重复、参数化的基础设施要求。 - ECS 滚动更新不为此 endpoint 提供带有 CloudWatch 警报回滚的 SageMaker 本机变体流量转移。 - Batch Transform 至 S3 违反了实时推理延迟/SLA 要求。

コードとしてのインフラストラクチャとしてデプロイメントを定義し、SageMaker エンドポイントの管理されたプログレッシブ配信メカニズムを使用します。カナリア/リニア トラフィック シフトと CloudWatch アラームを組み合わせて、レイテンシやエラー率が低下したときに自動的にロールバックします。ガバナンス要件を満たすために、暗号化および AWS 監査ログを備えた SageMaker モデル/バージョン アーティファクトを使用します。 主なニーズは、保守可能で信頼性の高い ML インフラストラクチャです。つまり、反復可能な構成、安全なロールアウト、ロールバックをトリガーできる可観測性フックです。AWS ネイティブのパターンは、コードとしてのインフラストラクチャ (AWS CDK または CloudFormation) を使用して SageMaker モデル/エンドポイントを定義し、IAM/KMS/VPC 設定をサポートしてから、CodePipeline で CI/CD を実行することです。安全なロールアウトを実現するには、CloudWatch アラーム (p95 レイテンシと 5xx) を監視しながら、endpoint 実稼働バリアント間でトラフィックをシフトし、アラームで自動的にロールバックすることで、SageMaker 用の CodeDeploy のブルー/グリーン (カナリアまたはリニア) デプロイメントを使用します。ガバナンスは、暗号化されたアーティファクト (S3/KMS、ECR/KMS 該当する場合) と監査可能な変更履歴 (CodePipeline/CodeDeploy イベントおよび AWS CloudTrail) を使用することによって満たされます。 重要な点は、IaC + プログレッシブ配信 + SageMaker エンドポイントのモニタリング主導のロールバックを組み合わせるということです。 - コンソールの手動更新は、反復可能でパラメータ化されたインフラストラクチャ要件に違反します。 - ECS ローリング アップデートでは、この endpoint の CloudWatch アラーム ロールバックによる SageMaker ネイティブのバリアント トラフィック シフトは提供されません。 - Batch Transform から S3 は、リアルタイム推論レイテンシ/SLA 要件に違反します。

To prevent catastrophic forgetting, fine-tuning should preserve performance on the original distribution while adapting to the new task. Strategies such as including representative replay data, constraining weight updates (freezing layers or PEFT), and monitoring performance on both old and new evaluation sets help maintain prior capabilities. Fine-tuning only on new-task data with a large learning rate is unsafe because it accelerates overwriting previously learned representations. Catastrophic forgetting happens when fine-tuning shifts the model parameters too far toward the new task, reducing performance on previously learned behaviors. High-level mitigation is to (1) keep the fine-tuning data representative of both old and new distributions and (2) limit how much the pretrained weights can change. Common, practical approaches include: - Rehearsal/replay: mix in a subset of original-domain examples (or synthetic proxies) stored in S3. - Constrained updates: freeze most layers, or use parameter-efficient fine-tuning (for example, LoRA/adapters) so only a small set of parameters changes. - Continuous evaluation: track metrics on an old-task holdout set and the new-task set to detect regressions early. In contrast, training only on new-task data with an aggressive learning rate tends to overwrite prior representations and increases forgetting risk. - Replay data helps retain prior behavior by keeping gradients anchored to the original distribution. - Freeze/PEFT limits parameter drift, reducing overwriting of pretrained knowledge. - High learning rate + new-only data accelerates drift toward the new task and is unsafe for retention. - Dual evaluation sets are needed to detect regressions on the original capabilities while improving the new task.

为了防止灾难性遗忘，微调应该在适应新任务的同时保留原始分布的性能。包括代表性重播数据、限制权重更新（冻结层或 PEFT）以及监控新旧评估集的性能等策略有助于维持先前的能力。仅对具有较大学习率的新任务数据进行微调是不安全的，因为它会加速覆盖先前学习的表示。 当微调使模型参数过于偏向新任务时，就会发生灾难性遗忘，从而降低先前学习行为的性能。高级别缓解措施是（1）保持微调数据代表新旧分布，以及（2）限制预训练权重可以改变的程度。 常见、实用的方法包括： - 排练/重播：混合存储在 S3 中的原始域示例（或合成代理）的子集。 - 受限更新：冻结大多数层，或使用参数高效的微调（例如 LoRA/适配器），因此只有一小部分参数发生变化。 - 持续评估：跟踪旧任务保留集和新任务集的指标，以尽早检测回归。 相反，仅对具有激进学习率的新任务数据进行训练往往会覆盖先前的表示并增加遗忘风险。 - 重播数据通过保持梯度锚定到原始分布来帮助保留先前的行为。 - 冻结/PEFT 限制参数漂移，减少预训练知识的覆盖。 - 高学习率+仅限新数据会加速向新任务的漂移，并且对于保留来说不安全。 - 需要双重评估集来检测原始能力的回归，同时改进新任务。

致命的な忘れを防ぐために、微調整により、新しいタスクに適応しながら元のディストリビューションのパフォーマンスを維持する必要があります。代表的なリプレイ データの組み込み、重み更新の制限 (レイヤーのフリーズまたは PEFT)、新旧両方の評価セットでのパフォーマンスの監視などの戦略は、以前の機能を維持するのに役立ちます。学習率が高い新しいタスク データのみを微調整すると、以前に学習した表現の上書きが加速されるため、安全ではありません。 壊滅的な忘却は、微調整によってモデルのパラメーターが新しいタスクに偏りすぎて、以前に学習した動作のパフォーマンスが低下したときに発生します。高レベルの緩和策は、(1) 新旧両方の分布を表す微調整データを維持し、(2) 事前トレーニングされた重みが変更できる量を制限することです。 一般的な実践的なアプローチには次のようなものがあります。 - リハーサル/リプレイ: S3 に保存されているオリジナル ドメインのサンプル (または合成プロキシ) のサブセットをミックスします。 - 制約された更新: ほとんどのレイヤーをフリーズするか、パラメーター効率の良い微調整 (LoRA/アダプターなど) を使用して、少数のパラメーターのみが変更されるようにします。 - 継続的評価: 古いタスクのホールドアウト セットと新しいタスク セットのメトリクスを追跡して、回帰を早期に検出します。 対照的に、学習率が高い新しいタスク データのみでトレーニングすると、以前の表現が上書きされる傾向があり、忘れるリスクが増加します。 - リプレイ データは、勾配を元の分布に固定したままにすることで、以前の動作を保持するのに役立ちます。 - フリーズ/PEFT はパラメータのドリフトを制限し、事前トレーニングされた知識の上書きを減らします。 - 高い学習率 + 新しいデータのみにより、新しいタスクへの移行が加速され、保持するのは安全ではありません。 - 新しいタスクを改善しながら、元の機能の回帰を検出するには、デュアル評価セットが必要です。

Because scoring happens only once per day and can run for hours, the team should use batch-oriented compute that is provisioned only for the job duration. Keeping a real-time endpoint running continuously adds unnecessary always-on instance cost without improving required latency. The violated principle is selecting always-on infrastructure when the workload is offline and periodic. The core tradeoff is paying for reserved/continuous inference capacity versus provisioning compute only when you need it. For periodic, offline scoring from S3 to S3 with a multi-hour SLA, batch patterns (Batch Transform, Processing, or a containerized batch job on ECS/Fargate) are cost-efficient because they spin up resources for the run and then terminate. A real-time SageMaker endpoint is designed for low-latency, on-demand requests and charges for provisioned instances while the endpoint is up. Using it for a once-per-day batch job typically wastes money on idle capacity between runs and adds endpoint operations you do not need. The key takeaway is to match the deployment pattern to the access pattern: batch for scheduled bulk inference, endpoints for interactive latency-sensitive inference. - Batch Transform fits S3-to-S3 offline scoring and avoids always-on capacity. - Processing job is acceptable for custom batch inference logic with job-scoped compute. - ECS/Fargate batch task is acceptable when you want containerized batch compute that runs only during the scoring window. - Always-on endpoint is the exception because it incurs ongoing cost for unused capacity in this scenario.

由于评分每天仅发生一次，并且可能运行数小时，因此团队应使用仅在作业持续时间内配置的面向批处理的计算。保持实时 endpoint 持续运行会增加不必要的始终在线实例成本，而不会改善所需的延迟。违反的原则是当工作负载离线且周期性时选择始终在线的基础设施。 核心权衡是为预留/连续推理能力付费，而不是仅在需要时配置计算。对于具有多小时 SLA 的从 S3 到 S3 的定期离线评分，批处理模式（Batch Transform、处理或 ECS/Fargate 上的容器化批处理作业）非常经济高效，因为它们会为运行启动资源，然后终止。 实时 SageMaker endpoint 专为低延迟、按需请求而设计，并在 endpoint 启动时对预配置实例收费。将其用于每天一次的批处理作业通常会在运行之间的空闲容量上浪费金钱，并添加您不需要的 endpoint 操作。关键要点是将部署模式与访问模式相匹配：用于计划批量推理的批处理、用于交互式延迟敏感推理的端点。 - Batch Transform 适合 S3 至 S3 离线评分并避免始终开启容量。 - 处理作业对于具有作业范围计算的自定义批量推理逻辑是可接受的。 - 当您希望仅在评分窗口期间运行容器化批量计算时，ECS/Fargate 批处理任务是可接受的。 - 始终开启的 endpoint 是例外，因为在这种情况下，它会因未使用的容量而产生持续成本。

スコアリングは 1 日に 1 回だけ行われ、数時間にわたって実行される可能性があるため、チームはジョブ期間中にのみプロビジョニングされるバッチ指向のコンピューティングを使用する必要があります。リアルタイム endpoint を継続的に実行し続けると、必要なレイテンシを改善することなく、不必要な常時オンのインスタンス コストが追加されます。違反している原則は、ワークロードがオフラインで定期的な場合に常時オンのインフラストラクチャを選択することです。 重要なトレードオフは、予約済み/継続的推論キャパシティーに対して料金を支払うことと、必要な場合にのみコンピューティングをプロビジョニングすることです。複数時間の SLA を伴う S3 から S3 までの定期的なオフライン スコアリングの場合、バッチ パターン (Batch Transform、処理中、または ECS/Fargate 上のコンテナ化されたバッチ ジョブ) は、実行のためにリソースをスピンアップしてから終了するため、コスト効率が高くなります。 リアルタイム SageMaker endpoint は、低レイテンシのオンデマンド リクエスト向けに設計されており、endpoint の稼働中にプロビジョニングされたインスタンスに料金が発生します。1 日 1 回のバッチ ジョブに使用すると、通常、実行間のアイドル容量にコストが無駄になり、不要な endpoint 操作が追加されます。重要なポイントは、展開パターンをアクセス パターンに一致させることです。スケジュールされた一括推論にはバッチ、対話型の遅延に敏感な推論にはエンドポイントを使用します。 - Batch Transform は、S3 から S3 のオフライン スコアリングに適合し、常時オンの容量を回避します。 - ジョブの処理は、ジョブ スコープのコンピューティングを使用したカスタム バッチ推論ロジックで受け入れられます。 - ECS/Fargate バッチ タスクは、スコアリング ウィンドウ中にのみ実行されるコンテナ化されたバッチ コンピューティングが必要な場合に使用できます。 - 常時オンの endpoint は例外です。このシナリオでは、未使用の容量に対して継続的なコストが発生するためです。

The join is multiplying fact rows because the dimension side is not unique on the join key. The exhibit shows customer_attributes has more rows than distinct customer_id, and the joined output row count is greater than the fact table row count. Ensuring a single record per customer_id in the dimension (or otherwise enforcing the intended join cardinality) prevents unintended duplication. Join correctness depends on the expected key cardinality. Here, transactions should not grow after a left join unless the right-side table has multiple matches per key. The exhibit indicates this exact problem: - customer_attributes: rows=12,300 distinct(customer_id)=9,500 shows multiple rows per customer_id. - joined_output ... rows=12,940 being greater than transactions: rows=10,000 confirms row multiplication. To preserve correctness, make the dimension deterministic at one row per customer_id before the join (for example, pick the latest effective record with a window function, or aggregate to a single row). This keeps the join one-to-one (or the intended one-to-many) instead of unintentionally many-to-many. - Inner vs left join changes which facts are retained; it doesn’t address duplicated matches on the right. - Tuning shuffle partitions can improve performance but won’t change the number of matched rows. - String normalization helps prevent missed matches; it typically reduces matches rather than increasing row counts.

连接将事实行相乘，因为连接键上的维度边不是唯一的。该图显示 customer_attributes 的行数多于不同的 customer_id，并且联接的输出行数大于事实表行数。确保维度中每个 customer_id 有一条记录（或以其他方式强制执行预期的连接基数）可防止意外重复。 连接正确性取决于预期的键基数。在这里，除非右侧表的每个键有多个匹配项，否则事务在左连接后不应增长。 图表表明了这个确切的问题： - customer_attributes: rows=12,300 unique(customer_id)=9,500 显示每个 customer_id 多行。 - join_output ... rows=12,940 大于 transactions: rows=10,000 确认行乘法。 为了保持正确性，请在连接之前将维度确定为每个 customer_id 一行（例如，使用窗口函数选择最新的有效记录，或聚合到单行）。这使连接保持一对一（或预期的一对多），而不是无意的多对多。 - 内连接与左连接改变了哪些事实被保留；它不解决右侧重复的匹配问题。 - 调整 shuffle 分区可以提高性能，但不会改变匹配行的数量。 - 字符串规范化有助于防止错过匹配；它通常会减少匹配而不是增加行数。

ディメンション側が結合キーで一意ではないため、結合ではファクト行が乗算されます。この図は、customer_attributes に個別の customer_id よりも多くの行があり、結合された出力行数がファクト テーブルの行数よりも大きいことを示しています。ディメンション内の customer_id ごとに 1 つのレコードを確保する (または、意図した結合カーディナリティを強制する) と、意図しない重複が防止されます。 結合の正確性は、予期されるキーのカーディナリティによって異なります。ここで、右側のテーブルにキーごとに複数の一致がない限り、左結合後にトランザクションが増加することはありません。 展示物はまさにこの問題を示しています。 - customer_attributes: rows=12,300 unique(customer_id)=9,500 は、customer_id ごとに複数の行を表示します。 - join_output ... rows=12,940 は、transactions: rows=10,000 よりも大きいため、行の乗算が確認されます。 正確さを保つには、結合の前に customer_id ごとに 1 行でディメンションを決定的にします (たとえば、ウィンドウ関数を使用して最新の有効なレコードを選択するか、単一の行に集計します)。これにより、結合が意図せず多対多になるのではなく、1 対 1 (または意図した 1 対多) に保たれます。 - 内部結合と左結合により、どのファクトが保持されるかが変わります。右側の重複した一致には対処しません。 - シャッフル パーティションを調整するとパフォーマンスが向上しますが、一致する行の数は変わりません。 - 文字列の正規化は、一致の見逃しを防ぐのに役立ちます。通常、行数を増やすのではなく、一致を減らします。

A common scalability bottleneck in S3-backed pipelines is uneven request distribution (a hot prefix), which can limit effective parallel throughput for reads/writes. Spreading objects and requests across multiple prefixes increases parallelism and reduces hot-spotting risk. The other statements correctly describe common throughput ceilings and mitigations for Kinesis and AWS Glue. Scalability bottlenecks in ML ingestion/storage pipelines often come from constrained parallelism (too few partitions/shards) or skew (hot partitions). For S3-backed datasets, request patterns that concentrate activity on a small keyspace (for example, a single heavily used prefix) can reduce effective throughput; distributing objects across multiple prefixes and enabling readers to parallelize across those prefixes is a standard mitigation. Similarly, Kinesis Data Streams ingest/read throughput scales with shard count, but a poor partition-key strategy can cause one shard to become a hot spot even when overall shard capacity looks sufficient. For transformation/ETL, AWS Glue can reduce runtime by scaling out workers/DPUs and increasing parallelism, assuming the job is not bottlenecked by a single hot partition or external system. The key takeaway is to look for throughput ceilings and hot partitions, then increase parallelism and improve key/partition distribution. - S3 prefix distribution is a valid mitigation for request hot spots and improves parallelism. - Kinesis hot shards are commonly caused by partition-key skew and require key/reshard mitigation. - Glue scale-out is a normal approach when the job is limited by available parallel workers.

S3 支持的 Pipelines 中常见的可扩展性瓶颈是请求分布不均匀（热前缀），这可能会限制读/写的有效并行吞吐量。跨多个前缀传播对象和请求可以提高并行性并降低热点风险。其他语句正确描述了 Kinesis 和 AWS Glue 的常见吞吐量上限和缓解措施。 ML 摄取/存储 Pipelines 中的可扩展性瓶颈通常来自受限并行性（分区/分片太少）或倾斜（热分区）。对于 S3 支持的数据集，将活动集中在小键空间上的请求模式（例如，单个频繁使用的前缀）可能会降低有效吞吐量；跨多个前缀分布对象并使读取器能够跨这些前缀并行化是一种标准的缓解措施。 同样，Kinesis 数据流摄取/读取吞吐量随着分片数量的增加而变化，但糟糕的分区键策略可能会导致一个分片成为热点，即使整体分片容量看起来足够。对于转换/ETL，假设作业不受单个热分区或外部系统的瓶颈影响，AWS Glue 可以通过扩展工作线程/DPU 和增加并行性来减少运行时间。 关键要点是寻找吞吐量上限和热分区，然后增加并行性并改善键/分区分布。 - S3 前缀分配是对请求热点的有效缓解并提高了并行性。 - Kinesis 热分片通常是由分区键偏差引起的，需要密钥/重新分片缓解。 - 当作业受到可用并行工作人员限制时，Glue 横向扩展是一种正常方法。

S3 をサポートする Pipelines の一般的なスケーラビリティのボトルネックは、不均一なリクエスト分散 (ホット プレフィックス) であり、これにより読み取り/書き込みの有効な並列スループットが制限される可能性があります。オブジェクトとリクエストを複数のプレフィックスに分散すると、並列性が向上し、ホットスポットのリスクが軽減されます。他のステートメントは、Kinesis および AWS Glue の一般的なスループットの上限と緩和策を正しく説明しています。 ML の取り込み/ストレージ Pipelines におけるスケーラビリティのボトルネックは、多くの場合、制約された並列処理 (パーティション/シャードが少なすぎる) またはスキュー (ホット パーティション) に起因します。S3 ベースのデータセットの場合、小さなキースペース (たとえば、頻繁に使用される単一のプレフィックス) にアクティビティが集中するリクエスト パターンにより、実効スループットが低下する可能性があります。オブジェクトを複数のプレフィックスに分散し、リーダーがそれらのプレフィックス間で並列処理できるようにするのが標準的な緩和策です。 同様に、Kinesis データ ストリームの取り込み/読み取りスループットはシャード数に応じて調整されますが、パーティション キー戦略が不十分だと、シャード全体の容量が十分に見えても 1 つのシャードがホット スポットになる可能性があります。変換/ETL の場合、ジョブが単一のホット パーティションまたは外部システムによってボトルネックになっていないことを前提として、AWS Glue はワーカー/DPU をスケールアウトし、並列処理を増やすことで実行時間を短縮できます。 重要なポイントは、スループットの上限とホット パーティションを探してから、並列処理を増やし、キー/パーティションの分散を改善することです。 - S3 プレフィックス配布は、リクエスト ホット スポットの有効な軽減策であり、並列処理が向上します。 - Kinesis ホット シャードは通常、パーティション キーのスキューによって発生するため、キー/リシャードの軽減が必要です。 - Glue スケールアウトは、ジョブが利用可能な並列ワーカーによって制限されている場合の通常のアプローチです。

To ensure feature parity, transformation logic and feature definitions should be reusable and applied consistently in both training and inference. Manually re-implementing preprocessing separately for inference creates two sources of truth, making it easy for the online path to diverge from the training pipeline as code and schemas evolve. The core principle is to keep training and inference on a single, versioned source of truth for feature definitions and transformation logic. If the team hand-codes preprocessing separately for inference, even small differences (category ordering, missing-value handling, scaling parameters, new columns) can change the feature vector and degrade predictions or break the endpoint. Acceptable patterns include: - Reusing the same preprocessing code artifact in both pipelines and deployment. - Persisting fit-time artifacts (encoders/scalers) and loading them for inference. - Centralizing feature definitions/transformations in a feature store so online/offline retrieval stays consistent. The key takeaway is to avoid duplicated, independently maintained transformation implementations across training and inference. - Reusable preprocessing is aligned with feature parity because the same logic runs in both paths. - Persisted encoders/scalers helps ensure inference uses identical fitted parameters from training. - Feature Store definitions supports consistent offline/online feature computation and reuse.

为了确保特征一致性，转换逻辑和特征定义应该可重用，并在训练和推理中一致应用。单独手动重新实现推理预处理会创建两个事实来源，使得在线路径很容易随着代码和模式的发展而偏离训练管道。 核心原则是在特征定义和转换逻辑的单一版本化事实来源上进行训练和推理。如果团队手动编码预处理以进行推理，即使很小的差异（类别排序、缺失值处理、缩放参数、新列）也可能会更改特征向量并降低预测或破坏 endpoint。 可接受的模式包括： - 在 Pipelines 和部署中重复使用相同的预处理代码工件。 - 保留调整时间工件（编码器/缩放器）并加载它们以进行推理。 - 将特征定义/转换集中在 Feature Store 中，以便在线/离线检索保持一致。 关键要点是避免在训练和推理过程中重复、独立维护的转换实现。 - 可重用预处理与特征一致性保持一致，因为相同的逻辑在两条路径中运行。 - 持久编码器/缩放器有助于确保推理使用来自训练的相同拟合参数。 - Feature Store 定义支持一致的离线/在线特征计算和重用。

機能の同等性を確保するには、変換ロジックと機能定義が再利用可能であり、トレーニングと推論の両方で一貫して適用される必要があります。推論用の前処理を個別に手動で再実装すると、2 つの真実の情報源が作成され、コードやスキーマの進化に応じてオンライン パスがトレーニング パイプラインから分岐しやすくなります。 中心となる原則は、機能定義と変換ロジックについて、バージョン管理された単一の真実のソース上でトレーニングと推論を継続することです。チームが推論用に前処理を個別に手作業でコーディングした場合、たとえ小さな違い (カテゴリの順序付け、欠損値の処理、スケーリング パラメーター、新しい列) によっても特徴ベクトルが変化し、予測が低下したり、endpoint が壊れたりする可能性があります。 許容されるパターンは次のとおりです。 - Pipelines と展開の両方で同じ前処理コード アーティファクトを再利用します。 - フィットタイム アーティファクト (エンコーダー/スケーラー) を永続化し、推論のためにロードします。 - 機能の定義/変換を Feature Store に一元化することで、オンライン/オフラインの取得の一貫性が保たれます。 重要な点は、トレーニングと推論の間で、重複して独立して維持される変換実装を避けることです。 - 同じロジックが両方のパスで実行されるため、再利用可能な前処理は機能のパリティに合わせて調整されます。 - 永続化されたエンコーダー/スケーラーは、推論がトレーニングからの同一の適合パラメーターを使用することを保証するのに役立ちます。 - Feature Store 定義は、一貫したオフライン/オンライン特徴量の計算と再利用をサポートします。

This workload is pure batch scoring with an S3 output requirement and no need for low-latency online inference. SageMaker Batch Transform provisions compute only for the job duration and can use multiple instances for throughput, eliminating always-on endpoint cost while reducing throttling risk during the nightly peak. The core issue is a deployment selection mismatch: a real-time endpoint is designed for interactive, low-latency requests and is billed continuously, but the team’s pattern is a scheduled, high-throughput batch job. Moving inference to SageMaker Batch Transform improves both cost and reliability because it uses ephemeral compute sized for the batch window and avoids per-request endpoint throttling. A high-level corrective approach is: - Trigger a Batch Transform job on a schedule (for example, EventBridge). - Read input from S3 and write predictions back to S3. - Size instance count/type for the 2-hour SLA and monitor job status/metrics. The main tradeoff is that inference becomes job-based (not interactive), but that aligns with the stated requirements. - Autoscaling an endpoint still pays for baseline capacity and can still bottleneck under bursty, highly parallel invocations. - Serverless endpoint keeps the per-request invocation pattern and does not address batch orchestration or peak-concurrency bottlenecks as directly. - Multi-model endpoint is for hosting many models behind one endpoint, not for scheduled high-throughput batch scoring.

此工作负载是纯批量评分，具有 S3 输出要求，不需要低延迟在线推理。 SageMaker Batch Transform 规定仅针对作业持续时间进行计算，并且可以使用多个实例来提高吞吐量，从而消除始终在线的 endpoint 成本，同时降低夜间高峰期间的限制风险。 核心问题是部署选择不匹配：实时 endpoint 专为交互式、低延迟请求而设计，并且持续计费，但团队的模式是计划的、高吞吐量的批处理作业。将推理转移到 SageMaker Batch Transform 可以提高成本和可靠性，因为它使用批处理窗口大小的临时计算，并避免了每个请求的 endpoint 限制。 高层次的纠正方法是： - 按计划触发 Batch Transform 作业（例如，EventBridge）。 - 从 S3 读取输入并将预测写回 S3。 - 调整 2 小时 SLA 的实例计数/类型并监控作业状态/指标。 主要的权衡是推理变得基于工作（而不是交互式），但这符合规定的要求。 - autoscaling 和 endpoint 仍然需要支付基准容量费用，并且在突发、高度并行的调用下仍然可能成为瓶颈。 - 无服务器 endpoint 保留每个请求的调用模式，并且不直接解决批量编排或峰值并发瓶颈。 - Multi-model endpoint 用于在一个 endpoint 后面托管多个模型，而不是用于预定的高吞吐量批量评分。

このワークロードは、S3 出力要件を備えた純粋なバッチ スコアリングであり、低遅延のオンライン推論は必要ありません。SageMaker Batch Transform は、ジョブ期間中のみコンピューティングをプロビジョニングし、スループットのために複数のインスタンスを使用できるため、常時稼働の endpoint コストが排除され、夜間のピーク時のスロットル リスクが軽減されます。 中心的な問題は、デプロイメントの選択の不一致です。リアルタイムの endpoint は、インタラクティブで低遅延のリクエスト向けに設計されており、継続的に請求されますが、チームのパターンは、スケジュールされた高スループットのバッチ ジョブです。推論を SageMaker Batch Transform に移行すると、バッチ ウィンドウに合わせたサイズの一時的なコンピューティングが使用され、リクエストごとの endpoint スロットルが回避されるため、コストと信頼性の両方が向上します。 高レベルの修正アプローチは次のとおりです。 - スケジュールに従って Batch Transform ジョブをトリガーします (たとえば、EventBridge)。 - S3 から入力を読み取り、予測を S3 に書き込みます。 - 2 時間の SLA のインスタンス数/タイプをサイズ設定し、ジョブのステータス/メトリックを監視します。 主なトレードオフは、推論がジョブベース (対話型ではなく) になることですが、これは規定の要件と一致しています。 - autoscaling と endpoint は依然としてベースライン容量の料金を支払い、バースト性の高い並列呼び出しの下では依然としてボトルネックになる可能性があります。 - サーバーレス endpoint はリクエストごとの呼び出しパターンを維持し、バッチ オーケストレーションやピーク同時実行のボトルネックに直接対処しません。 - Multi-model endpoint は、スケジュールされた高スループットのバッチ スコアリング用ではなく、1 つの endpoint の背後で多くのモデルをホストするためのものです。

The exhibit shows identical input location and hyperparameters across runs but different validation AUC, which is a reproducibility red flag. To reproduce and audit results, each experiment run should record immutable dataset identifiers (for example, versioned S3 objects or timestamped prefixes) together with the run’s parameters and resulting metrics using an experiment tracker such as SageMaker Experiments. Reproducible training requires being able to re-run the same code against the same dataset version with the same configuration and then compare resulting metrics. In the exhibit, the two jobs have the same hyperparameters and point to the same S3 object key (Input: s3://ml-data/churn/train.csv) but yield different AUC values, which commonly happens when the data at that key changes over time (or when run configuration isn’t fully captured). A practical AWS approach is to: - Make datasets immutable or versioned (for example, S3 Versioning or unique, timestamped prefixes/manifests). - Track each run as an experiment/trial component and record dataset identifiers, hyperparameters, and metrics in SageMaker Experiments. This creates an auditable lineage for each metric value back to the exact dataset and settings that produced it. - Debugger focus helps diagnose training behavior, but it doesn’t solve missing dataset lineage implied by reusing s3://.../train.csv. - HPO focus improves search, but it doesn’t explain differing metrics when HyperParams are already the same. - Deployment comparison is an inference workflow and doesn’t capture training dataset/metadata needed for reproducibility.

该图显示了运行中相同的输入位置和超参数，但验证 AUC 不同，这是可重复性的危险信号。为了重现和审核结果，每次实验运行都应使用实验跟踪器（例如 SageMaker Experiments）记录不可变的数据集标识符（例如，版本化的 S3 对象或带时间戳的前缀）以及运行的参数和结果指标。 可重复的训练需要能够使用相同的配置针对相同的数据集版本重新运行相同的代码，然后比较结果指标。在图中，这两个作业具有相同的超参数并指向相同的 S3 对象键（输入：S3://ml-data/churn/train.CSV），但产生不同的 AUC 值，当该键处的数据随时间变化时（或运行配置未完全捕获时），通常会发生这种情况。 实用的 AWS 方法是： - 使数据集不可变或版本化（例如，S3 Versioning 或唯一的带时间戳的前缀/清单）。 - 将每次运行作为实验/试验组件进行跟踪，并在 SageMaker Experiments 中记录数据集标识符、超参数和指标。 这会为每个指标值创建一个可审核的沿袭，追溯到生成它的确切数据集和设置。 - Debugger 焦点有助于诊断训练行为，但它不能解决重用 S3://.../train.CSV 所隐含的缺失数据集沿袭问题。 - HPO 焦点改进了搜索，但当 HyperParams 已经相同时，它不能解释不同的指标。 - 部署比较是一个推理工作流程，不会捕获再现性所需的训练数据集/元数据。

この展示では、実行間で同一の入力位置とハイパーパラメータが示されていますが、検証 AUC が異なっており、これは再現性の危険信号です。結果を再現して監査するには、各実験実行で、SageMaker Experiments などの実験トラッカーを使用して、不変のデータセット識別子 (バージョン管理された S3 オブジェクトやタイムスタンプ付きプレフィックスなど) を実行のパラメーターおよび結果のメトリクスとともに記録する必要があります。 再現可能なトレーニングには、同じ構成の同じデータセット バージョンに対して同じコードを再実行し、結果のメトリクスを比較できる必要があります。展示では、2 つのジョブは同じハイパーパラメータを持ち、同じ S3 オブジェクト キー (入力: S3://ml-data/churn/train.CSV) を指しますが、異なる AUC 値を生成します。これは通常、そのキーのデータが時間の経過とともに変化する場合 (または実行構成が完全にキャプチャされていない場合) に発生します。 AWS の実際的なアプローチは次のとおりです。 - データセットを不変にするか、バージョン管理します (たとえば、S3 Versioning またはタイムスタンプ付きの一意のプレフィックス/マニフェスト)。 - 各実行を実験/トライアルコンポーネントとして追跡し、データセット識別子、ハイパーパラメータ、メトリクスを SageMaker Experiments に記録します。 これにより、各メトリクス値について、それを生成した正確なデータセットと設定に遡って監査可能な系統が作成されます。 - Debugger フォーカスはトレーニング動作の診断に役立ちますが、S3://.../train.CSV の再利用によって暗示されるデータセット リネージの欠落は解決されません。 - HPO フォーカスにより検索が向上しますが、HyperParams がすでに同じである場合のメトリクスの違いは説明されません。 - デプロイメントの比較は推論ワークフローであり、再現性に必要なトレーニング データセット/メタデータはキャプチャされません。

Meeting compliance and investigation needs requires durable, centralized, tamper-resistant audit logs and searchable operational logs. CloudTrail should provide organization-wide API auditing with long-term retention in a protected S3 bucket, while CloudWatch Logs supports near real-time visibility and retained endpoint logs. Any approach that relies on short-lived history or decentralized, engineer-managed storage fails the stated evidence requirements. For security investigations and compliance evidence, treat audit and operational logs as immutable records with controlled access. Use CloudTrail (preferably an organization trail across Regions) to capture API activity and deliver logs to a centralized S3 bucket in a dedicated logging account with KMS encryption, integrity controls (log file validation), and strong anti-tamper protections (for example, S3 Object Lock and restricted delete permissions). CloudWatch Logs complements this by providing near real-time log search, metric filters/alarms, and centralized application logging (such as SageMaker endpoint container logs) with retention set to match policy. The key failure patterns are depending on short-retention sources (like CloudTrail Event history) or storing logs in non-central, weakly protected locations where administrators can alter or delete evidence. - Short-lived sources like CloudTrail Event history and short CloudWatch retention cannot satisfy 7-year evidence needs. - Decentralized storage in application accounts increases the risk of log deletion/tampering and breaks centralized logging-account requirements. - Org trail to protected S3 supports durable audit evidence with encryption and integrity controls. - CloudWatch Logs + S3 is a common pairing: CloudWatch for near real-time ops/security, S3 for long-term compliance retention.

满足合规性和调查需求需要持久、集中、防篡改的审核日志和可搜索的操作日志。 CloudTrail 应提供组织范围内的 API 审核，并长期保留在受保护的 S3 存储桶中，而 CloudWatch Logs 支持近乎实时的可见性并保留 endpoint 日志。任何依赖于短暂历史或分散的、工程师管理的存储的方法都无法满足规定的证据要求。 对于安全调查和合规性证据，将审核和操作日志视为具有受控访问的不可变记录。使用 CloudTrail（最好是跨区域的组织跟踪）捕获 API 活动，并将日志传送到专用日志帐户中的集中式 S3 存储桶，并具有 KMS 加密、完整性控制（日志文件验证）和强大的防篡改保护（例如，S3 对象锁定和受限删除权限）。 CloudWatch Logs 通过提供近乎实时的日志搜索、指标过滤器/警报和集中式应用程序日志记录（例如 SageMaker endpoint 容器日志）以及保留设置以匹配策略来补充这一点。关键故障模式取决于短期保留源（例如 CloudTrail 事件历史记录）或将日志存储在非中心、保护较弱的位置，管理员可以在其中更改或删除证据。 - CloudTrail 事件历史记录等短期来源和短暂的 CloudWatch 保留无法满足 7 年证据需求。 - 应用程序帐户中的分散存储增加了日志删除/篡改的风险，并破坏了集中式日志记录帐户要求。 - 受保护的 S3 的组织跟踪通过加密和完整性控制支持持久的审计证据。 - CloudWatch Logs + S3 是常见配对：CloudWatch 用于近实时操作/安全，S3 用于长期合规保留。

コンプライアンスと調査のニーズを満たすには、耐久性があり、一元化され、改ざん耐性のある監査ログと検索可能な操作ログが必要です。CloudTrail は、保護された S3 バケットに長期保存される組織全体の API 監査を提供する必要があります。一方、CloudWatch Logs は、ほぼリアルタイムの可視性と保持された endpoint ログをサポートします。短期間の履歴やエンジニアが管理する分散型ストレージに依存するアプローチは、規定された証拠要件を満たしていません。 セキュリティ調査とコンプライアンスの証拠のために、監査ログと操作ログを、アクセスが制御された不変の記録として扱います。CloudTrail (リージョン全体の組織証跡が望ましい) を使用して、API アクティビティをキャプチャし、KMS 暗号化、整合性制御 (ログ ファイル検証)、および強力な改ざん防止保護 (S3 オブジェクト ロックや制限付き削除権限など) を備えた専用ログ アカウント内の集中 S3 バケットにログを配信します。 CloudWatch Logs は、ほぼリアルタイムのログ検索、メトリクス フィルター/アラーム、およびポリシーに一致する保持設定を備えた集中アプリケーション ログ (SageMaker endpoint コンテナ ログなど) を提供することでこれを補完します。主な障害パターンは、保存期間が短いソース (CloudTrail イベント履歴など) に依存するか、管理者が証拠を変更または削除できる、中央ではない脆弱な保護された場所にログが保存されることに依存します。 - CloudTrail イベント履歴や短期間の CloudWatch 保持などの有効期限の短いソースでは、7 年間の証拠のニーズを満たすことができません。 - アプリケーション アカウントの分散ストレージにより、ログの削除/改ざんのリスクが高まり、集中ログ アカウントの要件が破られます。 - 保護された S3 への組織証跡は、暗号化と整合性制御による耐久性のある監査証拠をサポートします。 - CloudWatch Logs + S3 は一般的な組み合わせです。ほぼリアルタイムの運用/セキュリティには CloudWatch、長期的なコンプライアンス保持には S3 が使用されます。

This is a SageMaker batch transform-style configuration where S3 is used for both the input data location and the output results location. The job’s compute parallelism is determined by how many instances are provisioned for the transform resources. In a batch inference workflow on SageMaker, you typically provide an S3 prefix for where the input objects are read from, an S3 prefix for where inference outputs are written, and a resource configuration that determines how much compute is allocated. Here, the exhibit explicitly identifies: - Input location as S3Uri: s3://ml-prod/inference-input/2026-02-25/ - Output location as S3OutputPath: s3://ml-prod/inference-output/2026-02-25/ - Parallelism capacity via InstanceCount: 4 under TransformResources A real-time endpoint configuration would not be expressed with TransformInput/TransformOutput fields like these. - Swapped S3 paths contradicts the separate S3Uri (input) and S3OutputPath (output) lines in the exhibit. - Real-time endpoint is inconsistent with the presence of TransformInput and TransformOutput in the request. - No instance parallelism conflicts with TransformResources showing InstanceCount: 4.

这是 SageMaker Batch Transform 样式的配置，其中 S3 用于输入数据位置和输出结果位置。作业的计算并行性取决于为转换资源配置的实例数量。 在 SageMaker 上的批量推理工作流程中，您通常会提供用于读取输入对象的位置的 S3 前缀、用于写入推理输出的位置的 S3 前缀，以及用于确定分配多少计算量的资源配置。 在此，图表明确指出： - 输入位置为 S3Uri：S3://ml-prod/inference-input/2026-02-25/ - 输出位置为 S3OutputPath：S3://ml-prod/inference-output/2026-02-25/ - TransformResources 下通过 InstanceCount 实现的并行容量：4 实时 endpoint 配置不会用这样的 TransformInput/TransformOutput 字段表示。 - 交换的 S3 路径与图中单独的 S3Uri（输入）和 S3OutputPath（输出）线相矛盾。 - 实时 endpoint 与请求中 TransformInput 和 TransformOutput 的存在不一致。 - 实例并行性与显示 InstanceCount: 4 的 TransformResources 没有冲突。

これは、入力データの場所と出力結果の場所の両方に S3 が使用される SageMaker Batch Transform スタイルの構成です。ジョブの計算並列処理は、変換リソースにプロビジョニングされるインスタンスの数によって決まります。 SageMaker のバッチ推論ワークフローでは、通常、入力オブジェクトの読み取り元の S3 プレフィックス、推論出力の書き込み先の S3 プレフィックス、および割り当てられるコンピューティング量を決定するリソース構成を指定します。 ここで、展示物は次のことを明確に示しています。 - S3Uri として場所を入力: S3://ml-prod/inference-input/2026-02-25/ - S3OutputPath としての出力場所: S3://ml-prod/inference-output/2026-02-25/ - InstanceCount による並列処理能力: TransformResources の 4 リアルタイムの endpoint 構成は、このような TransformInput/TransformOutput フィールドでは表現されません。 - スワップされた S3 パスは、展示内の個別の S3Uri (入力) 行と S3OutputPath (出力) 行と矛盾します。 - リアルタイム endpoint は、リクエスト内の TransformInput および TransformOutput の存在と矛盾します。 - InstanceCount: 4 を示す TransformResources と競合するインスタンス並列処理はありません。

Auditability requires immutable, linkable evidence for data, code, and runtime artifacts. Using mutable references (like an ECR tag) or losing historical versions of datasets prevents the team from reconstructing what produced a specific model. The safer pattern is to keep versioned/immutable artifacts and record their identifiers as metadata through the pipeline. To meet compliance traceability, an ML CI/CD pipeline should produce an end-to-end lineage record that ties each model to immutable identifiers for (1) the training data snapshot, (2) the exact code revision, and (3) the exact container image/build. Mutable pointers (for example, an ECR tag that can be moved) and non-versioned data locations break reproducibility because the same identifier can refer to different content over time. A robust approach is: - Store datasets and model artifacts in versioned S3 locations and capture object version IDs. - Capture code provenance (commit SHA) and container provenance (ECR image digest) and attach them as tags/metadata to training runs and registered model packages. - Use CloudTrail (and, where appropriate, S3 data events) to provide an independent audit log of changes and access. The key takeaway is to record immutable artifact IDs, not mutable names. - Mutable container reference using latest without a digest prevents proving which image actually ran. - Lost data lineage overwriting non-versioned S3 objects removes the historical training snapshot. - Versioned artifacts S3 versioning supports reconstructing exact inputs/outputs used. - Metadata + audit logs tags/Model Registry entries and CloudTrail events strengthen end-to-end traceability.

可审计性需要数据、代码和运行时工件的不可变、可链接的证据。使用可变引用（例如 ECR 标签）或丢失数据集的历史版本会阻止团队重建生成特定模型的内容。更安全的模式是保留版本化/不可变的工件，并通过管道将其标识符记录为元数据。 为了满足合规性可追溯性，ML CI/CD 管道应生成端到端沿袭记录，将每个模型与以下方面的不可变标识符联系起来：(1) 训练数据快照、(2) 准确的代码修订版和 (3) 准确的容器映像/构建。可变指针（例如，可以移动的 ECR 标签）和非版本化数据位置会破坏再现性，因为随着时间的推移，相同的标识符可能引用不同的内容。 一个稳健的方法是： - 将数据集和模型工件存储在版本化的 S3 位置并捕获对象版本 ID。 - 捕获代码来源（提交 SHA）和容器来源（ECR 图像摘要）并将它们作为标签/元数据附加到训练运行和注册模型包。 - 使用 CloudTrail（以及适当时的 S3 数据事件）提供更改和访问的独立审核日志。 关键要点是记录不可变的工件 ID，而不是可变的名称。 - 在没有摘要的情况下使用最新的可变容器引用会阻止证明实际运行的映像。 - 丢失数据沿袭覆盖非版本化 S3 对象会删除历史训练快照。 - 版本化工件 S3 Versioning 支持重建所使用的精确输入/输出。 - 元数据+审核日志标签/Model Registry 条目和 CloudTrail 事件加强了端到端的可追溯性。

監査可能性には、データ、コード、およびランタイム成果物に対する不変でリンク可能な証拠が必要です。変更可能な参照 (ECR タグなど) を使用したり、データセットの履歴バージョンを失ったりすると、チームは特定のモデルを生成したものを再構築できなくなります。より安全なパターンは、バージョン管理された/不変のアーティファクトを保持し、パイプラインを通じてその識別子をメタデータとして記録することです。 コンプライアンスのトレーサビリティを満たすために、ML CI/CD パイプラインは、各モデルを (1) トレーニング データのスナップショット、(2) 正確なコード リビジョン、(3) 正確なコンテナ イメージ/ビルドの不変の識別子に結び付けるエンドツーエンドの系統レコードを生成する必要があります。変更可能なポインター (移動可能な ECR タグなど) やバージョン管理されていないデータの場所は、同じ識別子が時間の経過とともに異なるコンテンツを参照する可能性があるため、再現性を損ないます。 堅牢なアプローチは次のとおりです。 - データセットとモデル アーティファクトをバージョン管理された S3 の場所に保存し、オブジェクトのバージョン ID をキャプチャします。 - コードの来歴 (SHA のコミット) とコンテナーの来歴 (ECR イメージ ダイジェスト) をキャプチャし、それらをタグ/メタデータとしてトレーニングの実行と登録されたモデル パッケージに添付します。 - CloudTrail (および必要に応じて S3 データ イベント) を使用して、変更とアクセスの独立した監査ログを提供します。 重要なポイントは、変更可能な名前ではなく、不変のアーティファクト ID を記録することです。 - ダイジェストなしで最新を使用する可変コンテナー参照により、どのイメージが実際に実行されたかを証明できなくなります。 - バージョン管理されていない S3 オブジェクトを上書きする失われたデータ リネージにより、履歴トレーニング スナップショットが削除されます。 - バージョン管理されたアーティファクト S3 Versioning は、使用される正確な入力/出力の再構築をサポートします。 - メタデータ + 監査ログ タグ/Model Registry エントリおよび CloudTrail イベントにより、エンドツーエンドのトレーサビリティが強化されます。

The monitoring signal already exists as a CloudWatch alarm, but the EventBridge rule is listening for a SageMaker event type that won’t fire for alarm transitions. Use the alarm’s state change event as the retraining trigger. Then EventBridge can invoke Step Functions to orchestrate the SageMaker Pipeline run. Symptom: the drift alarm is entering ALARM, but no Step Functions executions start. Root cause: the EventBridge rule is filtering on a SageMaker Model Monitor “schedule execution” event, while the team’s chosen retraining trigger is a CloudWatch alarm transition. EventBridge will never match the alarm event with the current pattern. Fix: connect the monitoring output to orchestration by triggering on the CloudWatch alarm state change event and using it to start the workflow: - Create/update an EventBridge rule with source = aws.cloudwatch - Match detail-type = CloudWatch Alarm State Change and the specific alarm name - Set the rule target to Step Functions StartExecution (optionally passing alarm details) This keeps the existing drift threshold as the retraining trigger and only corrects the event wiring. - More frequent monitoring increases cost/noise and doesn’t address the event pattern mismatch. - Turning off Data Capture removes the data needed for Model Monitor and breaks the existing drift trigger. - Rebuilding the baseline changes model-monitoring behavior but still won’t start Step Functions without the correct EventBridge trigger.

监控信号已作为 CloudWatch 警报存在，但 EventBridge 规则正在侦听不会因警报转换而触发的 SageMaker 事件类型。使用警报的状态更改事件作为重新训练触发器。然后，EventBridge 可以调用 Step Functions 来编排 SageMaker Pipeline 运行。 现象：漂移报警进入 ALARM 状态，但没有 Step Functions 执行启动。 根本原因：EventBridge 规则正在过滤 SageMaker Model Monitor“计划执行”事件，而团队选择的重新训练触发器是 CloudWatch 警报转换。 EventBridge 永远不会将报警事件与当前模式匹配。 修复：通过触发 CloudWatch 警报状态更改事件并使用它启动工作流程，将监控输出连接到编排： - 使用 source = aws.cloudwatch 创建/更新 EventBridge 规则 - 匹配 detail-type = CloudWatch Alarm State Change 和特定警报名称 - 将规则目标设置为 Step Functions StartExecution（可以选择传递警报详细信息） 这将保留现有的漂移阈值作为重新训练触发器，并且仅更正事件连接。 - 更频繁的监控会增加成本/噪音，并且无法解决事件模式不匹配的问题。 - 关闭数据捕获会删除 Model Monitor 所需的数据并破坏现有的漂移触发器。 - 重建基线会改变模型监控行为，但如果没有正确的 EventBridge 触发器，仍然无法启动 Step Functions。

モニタリング信号は CloudWatch アラームとしてすでに存在しますが、EventBridge ルールはアラーム遷移を発生させない SageMaker イベント タイプをリッスンしています。アラームの状態変更イベントを再トレーニング トリガーとして使用します。その後、EventBridge は Step Functions を呼び出して、SageMaker Pipeline の実行を調整できます。 症状: ドリフト アラームが ALARM に入りますが、Step Functions の実行は開始されません。 根本原因: EventBridge ルールは SageMaker Model Monitor「スケジュール実行」イベントをフィルタリングしていますが、チームが選択した再トレーニング トリガーは CloudWatch アラーム遷移です。EventBridge は、アラーム イベントと現在のパターンを一致させることはありません。 修正: CloudWatch アラーム状態変更イベントをトリガーし、それを使用してワークフローを開始することで、モニタリング出力をオーケストレーションに接続します。 - source = aws.cloudwatch を使用して EventBridge ルールを作成/更新します - 詳細タイプ = CloudWatch アラーム状態変更と特定のアラーム名を照合します - ルールのターゲットを Step Functions StartExecution に設定します (オプションでアラームの詳細を渡します) これにより、既存のドリフトしきい値が再トレーニング トリガーとして維持され、イベントの配線のみが修正されます。 - モニタリングをより頻繁に行うと、コスト/ノイズが増加し、イベント パターンの不一致に対処できなくなります。 - データ キャプチャをオフにすると、Model Monitor に必要なデータが削除され、既存のドリフト トリガーが無効になります。 - ベースラインを再構築するとモデル監視の動作が変更されますが、それでも正しい EventBridge トリガーがなければ Step Functions は開始されません。

SageMaker asynchronous inference is built for workloads where requests can take longer to process and/or carry larger payloads than a synchronous request-response pattern is meant to handle. It decouples the client from the model’s processing time by queueing requests and delivering outputs asynchronously. This makes it a better fit than low-latency real-time patterns. The key requirement is that inference processing time and payload size may exceed what is practical for a synchronous API call. A SageMaker asynchronous inference endpoint addresses this by accepting requests, placing them in a queue, and writing outputs to a destination (commonly Amazon S3) when processing completes. This design helps handle variable processing times and supports higher concurrency without forcing the caller to keep a connection open. Batch transform is the closest alternative but is intended for offline, job-based processing of an entire dataset rather than request-driven endpoint inference. If you need interactive, request/response behavior with low latency, a real-time endpoint (including serverless real-time for spiky traffic) is typically more appropriate. - Real-time latency focus fits low-latency synchronous calls, not long-running requests. - Serverless inference targets intermittent traffic and scales-to-zero, but still follows a synchronous real-time pattern. - Batch transform is offline/batch processing and does not provide an endpoint for per-request inference.

SageMaker 异步推理专为以下工作负载而构建：与同步请求-响应模式相比，请求可能需要更长的时间来处理和/或携带更大的有效负载。它通过对请求进行排队并异步交付输出，将客户端与模型的处理时间解耦。这使得它比低延迟实时模式更适合。 关键要求是推理处理时间和有效负载大小可能超出同步 API 调用的实际时间。 SageMaker 异步推理 endpoint 通过接受请求、将请求放入队列并在处理完成时将输出写入目标（通常为 Amazon S3）来解决此问题。这种设计有助于处理可变的处理时间并支持更高的并发性，而无需强制调用者保持连接打开。 Batch Transform 是最接近的替代方案，但旨在用于整个数据集的离线、基于作业的处理，而不是请求驱动的 endpoint 推理。如果您需要低延迟的交互式请求/响应行为，实时 endpoint（包括针对尖峰流量的无服务器实时）通常更合适。 - 实时延迟焦点适合低延迟同步调用，而不是长时间运行的请求。 - Serverless Inference 针对间歇性流量并缩放至零，但仍遵循同步实时模式。 - Batch Transform 是离线/批处理，不提供用于每个请求推理的 endpoint。

SageMaker の非同期推論は、リクエストの処理に時間がかかる場合や、同期リクエスト/レスポンス パターンで処理できるよりも大きなペイロードを運ぶワークロード向けに構築されています。リクエストをキューに入れ、出力を非同期に配信することで、クライアントをモデルの処理時間から切り離します。これにより、低レイテンシーのリアルタイム パターンよりも適切になります。 重要な要件は、推論処理時間とペイロード サイズが、同期 API 呼び出しで実際的なものを超える可能性があることです。SageMaker の非同期推論 endpoint は、リクエストを受け入れ、キューに入れ、処理が完了したときに出力を宛先 (通常は Amazon S3) に書き込むことで、この問題に対処します。この設計は、変動する処理時間の処理に役立ち、呼び出し元に接続を開いたままにすることを強制することなく、より高い同時実行性をサポートします。 Batch Transform が最も近い代替手段ですが、リクエスト駆動の endpoint 推論ではなく、データセット全体のオフラインのジョブベースの処理を目的としています。低遅延のインタラクティブなリクエスト/レスポンス動作が必要な場合は、通常、リアルタイム endpoint (急増するトラフィック用のサーバーレス リアルタイムを含む) の方が適切です。 - リアルタイム遅延の焦点は、長時間実行されるリクエストではなく、低遅延の同期呼び出しに適合します。 - Serverless Inference は、断続的なトラフィックをターゲットにし、ゼロまでスケールしますが、同期リアルタイム パターンに従います。 - Batch Transform はオフライン/バッチ処理であり、リクエストごとの推論用の endpoint は提供されません。

The model’s overall RMSE is similar for train and validation, but the residual standard deviation grows substantially for higher-priced homes. This indicates heteroscedastic errors (non-constant variance) rather than classic overfitting/underfitting. A common next step is to transform the target (for example, predict log(price)) or otherwise weight the loss to better fit relative error across price ranges. For regression, RMSE summarizes average error magnitude, but residual patterns can reveal systematic issues that a single metric can hide. In the exhibit, train and validation RMSE are close (18,900 vs 19,300), suggesting generalization is not the primary problem. The key signal is non-constant residual variance across the target range: residual standard deviation rises from $8,100 for homes under $200k to $42,300 for homes over $500k (see the bucketed residual std lines). This is heteroscedasticity, which often improves by modeling the target on a transformed scale (for example, log) so errors become more proportional across ranges, then converting predictions back to USD. This is a better fit than simply tuning training duration or model size when the dominant issue is variance that grows with the target magnitude. - Early stopping doesn’t target the issue because train and validation RMSE are already similar (18,900 vs 19,300). - More complexity is unlikely to help when the main problem is error variance increasing with price (std $8,100 to $42,300). - Classification metrics are not applicable because the task is price regression and the exhibit reports regression residuals.

该模型的整体 RMSE 在训练和验证方面相似，但对于价格较高的房屋，残余标准差会大幅增长。这表明异方差误差（非恒定方差）而不是经典的 overfitting/underfitting。常见的下一步是转换目标（例如，预测 log(price)）或以其他方式对损失进行加权，以更好地适应价格范围内的相对误差。 对于回归，RMSE 总结了平均误差幅度，但残差模式可以揭示单个指标可以隐藏的系统问题。在图中，训练和验证 RMSE 很接近（18,900 vs 19,300），这表明泛化不是主要问题。 关键信号是目标范围内的非恒定残差方差：残差标准差从 20 万美元以下房屋的 8,100 美元上升到 50 万美元以上房屋的 42,300 美元（请参见分桶残差标准线）。这就是异方差性，通常通过在变换后的尺度（例如对数）上对目标进行建模来改进，使误差在范围内变得更加成比例，然后将预测转换回美元。 当主要问题是随着目标幅度而增长的方差时，这比简单地调整训练持续时间或模型大小更合适。 - 提前停止并不能解决该问题，因为训练和验证 RMSE 已经相似（18,900 与 19,300）。 - 当主要问题是误差方差随着价格（标准 8,100 美元到 42,300 美元）而增加时，增加复杂性不太可能有帮助。 - 分类指标不适用，因为任务是价格回归并且图表报告回归残差。

モデルの全体的な RMSE は、トレーニングと検証では同様ですが、価格の高い住宅では残留標準偏差が大幅に増加します。これは、従来の overfitting/underfitting ではなく、不均一分散誤差 (非定常分散) を示します。一般的な次のステップは、ターゲットを変換する (たとえば、log(価格) を予測する) か、価格帯全体の相対誤差をより適切に適合させるために損失を重み付けすることです。 回帰の場合、RMSE は平均誤差の大きさを要約しますが、残差パターンによって、単一のメトリクスでは隠れている体系的な問題が明らかになる可能性があります。展示品では、RMSE のトレーニングと検証が近い結果 (18,900 対 19,300) であり、一般化が主要な問題ではないことを示唆しています。 重要なシグナルは、ターゲット範囲全体にわたる非一定の残差分散です。残差標準偏差は、20 万ドル未満の住宅の 8,100 ドルから、50 万ドルを超える住宅の 42,300 ドルまで上昇します (バケット化された残差標準偏差を参照)。これは不均一分散性であり、多くの場合、変換されたスケール (対数など) でターゲットをモデル化し、誤差が範囲全体でより比例するようになり、予測を USD に変換することで改善されます。 これは、主要な問題がターゲットの大きさに応じて増大する分散である場合、単にトレーニング期間やモデル サイズを調整するよりも適切です。 - 列車と検証 RMSE はすでに類似しているため (18,900 対 19,300)、早期停止は問題の対象になりません。 - 主な問題が価格とともに増加する誤差の分散である場合 (標準 $8,100 から $42,300)、複雑さを増しても役に立たない可能性があります。 - タスクは価格回帰であり、展示では回帰残差がレポートされるため、分類メトリックは適用できません。

The exhibit’s governance constraints require that PHI stays within the AWS account and that only internal employees label the data. SageMaker Ground Truth with a private workforce satisfies these constraints while also supporting the required two-annotator workflow with adjudication through annotation consolidation. The core decision is governance and quality control for labeling. The exhibit states the data contains PHI (line 2), must not leave the AWS account (line 3), and annotators must be internal employees under a HIPAA BAA (line 4). That rules out public crowdsourcing and external vendor workflows where data access expands beyond the company’s controlled workforce. SageMaker Ground Truth with a private workforce lets you: - Restrict labeling access to internal users while keeping data in your account (lines 3–4) - Configure multiple labelers per item and use annotation consolidation for adjudication (line 5) Key takeaway: when sensitive data and strict workforce governance are required, choose a private workforce labeling solution rather than public or external options. - Public crowd with qualifications still uses non-internal workers, violating the internal-employee requirement (line 4). - Public workforce with NDAs does not meet the “internal employees” constraint and increases PHI exposure (lines 2 and 4). - External vendor labeling contradicts the requirement that data must not leave the AWS account (line 3).

该图表的治理限制要求 PHI 保留在 AWS 账户内，并且只有内部员工才能标记数据。拥有私人劳动力的 SageMaker Ground Truth 可以满足这些限制，同时还支持所需的两个注释器工作流程，并通过注释合并进行裁决。 核心决策是标签的治理和质量控制。该附件指出数据包含 PHI（第 2 行），不得离开 AWS 账户（第 3 行），并且注释者必须是 HIPAA BAA 下的内部员工（第 4 行）。这就排除了公共众包和外部供应商工作流程，在这些工作流程中，数据访问范围超出了公司受控的员工范围。 SageMaker Ground Truth 拥有私人劳动力，让您： - 限制内部用户的标签访问权限，同时将数据保留在您的帐户中（第 3-4 行） -为每个项目配置多个贴标机并使用注释合并进行裁决（第 5 行） 要点：当需要敏感数据和严格的劳动力管理时，请选择私人劳动力标签解决方案，而不是公共或外部选项。 - 有资格的公众人群仍然使用非内部员工，违反了内部员工要求（第 4 行）。 - 拥有 NDA 的公共工作人员不符合“内部员工”约束，并增加了 PHI 暴露（第 2 行和第 4 行）。 - 外部供应商标签与数据不得离开 AWS 账户的要求相矛盾（第 3 行）。

展示のガバナンス上の制約により、PHI は AWS アカウント内に留まり、内部の従業員のみがデータにラベルを付ける必要があります。民間の従業員を擁する SageMaker Ground Truth は、これらの制約を満たしながら、アノテーションの統合による判断により、必要な 2 人のアノテーターのワークフローもサポートします。 中心となる決定は、ラベル表示のガバナンスと品質管理です。展示では、データには PHI が含まれており (2 行目)、AWS アカウントを離れてはいけない (3 行目)、アノテーターは HIPAA BAA に基づく社内従業員である必要がある (4 行目) と記載されています。これにより、データ アクセスが企業の管理下にある従業員を超えて拡大するパブリック クラウドソーシングや外部ベンダーのワークフローが除外されます。 SageMaker Ground Truth と民間の従業員を使用すると、次のことが可能になります。 - アカウントにデータを保持しながら、ラベル付けアクセスを内部ユーザーに制限します (行 3 ～ 4) - 項目ごとに複数のラベラーを構成し、判定に注釈の統合を使用します (5 行目) 重要なポイント: 機密データと厳格な従業員ガバナンスが必要な場合は、公的または外部のオプションではなく、プライベートの従業員ラベル付けソリューションを選択してください。 - 資格を持つ一般大衆は依然として社内以外の従業員を使用しており、社内従業員の要件 (4 行目) に違反しています。 - NDA を持つ公務員は「社内従業員」の制約を満たしておらず、PHI への曝露が増加します (2 行目と 4 行目)。 - 外部ベンダーのラベル付けは、データが AWS アカウントから出てはいけないという要件 (3 行目) に矛盾します。

SageMaker Clarify bias metrics require defining the sensitive attribute (facet) so metrics can be computed across groups. The workflow must also meet data handling requirements by preventing public exposure of PII and ensuring the generated reports are stored securely with SSE-KMS encryption. SageMaker Clarify evaluates bias by comparing outcomes across groups defined by a sensitive attribute (for example, gender) for either pre-training (dataset) or post-training (model predictions) analysis. To generate meaningful bias metrics, you must configure Clarify with the label and the facet so it can compute group-based statistics (such as disparate impact–style measures) rather than only global class distributions. Because Clarify produces artifacts (reports, constraints, and intermediate outputs) in S3, the storage location must follow your organization’s security requirements. For regulated data, this typically means restricting bucket access (no public policies/ACLs) and enabling SSE-KMS so outputs are encrypted at rest. The key takeaway is that Clarify needs an explicitly defined sensitive facet for correct bias evaluation, and its output handling must meet security controls. - Curated, non-PII input is acceptable because Clarify can assess bias using non-PII features while keeping PII out of the analysis artifacts. - Pipeline-integrated reports is acceptable because Clarify processing steps can produce repeatable, auditable outputs in S3. - Multiple facets via multiple runs is acceptable because running Clarify per protected attribute is a common way to assess bias across different groups. - Post-training bias with encrypted outputs is acceptable because Clarify supports post-training bias analysis while storing artifacts in SSE-KMS protected S3 locations.

SageMaker Clarify 偏差指标需要定义敏感属性（方面），以便可以跨组计算指标。该工作流程还必须满足数据处理要求，防止 PII 公开暴露，并确保生成的报告通过 SSE-KMS 加密安全存储。 SageMaker Clarify 通过比较由敏感属性（例如性别）定义的组之间的结果来评估偏差，以进行训练前（数据集）或训练后（模型预测）分析。要生成有意义的偏差指标，您必须使用标签和构面配置 Clarify，以便它可以计算基于组的统计数据（例如不同的影响式度量），而不仅仅是全局类分布。 由于 Clarify 在 S3 中生成工件（报告、约束和中间输出），因此存储位置必须遵循组织的安全要求。对于受监管的数据，这通常意味着限制存储桶访问（无公共策略/ACL）并启用 SSE-KMS，以便在 REST 处对输出进行加密。关键要点是 Clarify 需要明确定义的敏感方面来进行正确的偏差评估，并且其输出处理必须满足安全控制。 - 可接受精选的非 PII 输入，因为 Clarify 可以使用非 PII 特征评估偏差，同时将 PII 排除在分析工件之外。 - 管道集成报告是可接受的，因为 Clarify 处理步骤可以在 S3 中生成可重复、可审核的输出。 - 通过多次运行的多个方面是可以接受的，因为每个受保护的属性运行 Clarify 是评估不同组之间偏差的常用方法。 - 加密输出的训练后偏差是可接受的，因为 Clarify 支持训练后偏差分析，同时将工件存储在 SSE-KMS 受保护的 S3 位置中。

SageMaker Clarify バイアス メトリックでは、グループ全体でメトリックを計算できるように機密属性 (ファセット) を定義する必要があります。ワークフローは、PII の公開を防止し、生成されたレポートが SSE-KMS 暗号化を使用して安全に保存されるようにすることで、データ処理要件も満たす必要があります。 SageMaker Clarify は、トレーニング前 (データセット) 分析またはトレーニング後 (モデル予測) 分析のいずれかについて、機密属性 (性別など) によって定義されたグループ間の結果を比較することによってバイアスを評価します。意味のあるバイアス メトリックを生成するには、ラベルとファセットを使用して Clarify を構成し、グローバル クラス分布だけでなくグループベースの統計 (異種の影響スタイルの測定など) を計算できるようにする必要があります。 Clarify は S3 にアーティファクト (レポート、制約、中間出力) を生成するため、保管場所は組織のセキュリティ要件に従う必要があります。規制されたデータの場合、これは通常、バケット アクセスを制限し (パブリック ポリシー/ACL なし)、SSE-KMS を有効にして、出力が REST で暗号化されるようにすることを意味します。重要な点は、Clarify には正しいバイアス評価のために明示的に定義された機密ファセットが必要であり、その出力処理はセキュリティ制御を満たす必要があるということです。 - Clarify は、分析アーティファクトから PII を排除しながら、非 PII 機能を使用してバイアスを評価できるため、厳選された非 PII 入力が受け入れられます。 - Clarify 処理ステップは S3 で再現可能で監査可能な出力を生成できるため、パイプライン統合レポートは許容されます。 - 保護された属性ごとに Clarify を実行するのが、異なるグループ間のバイアスを評価する一般的な方法であるため、複数の実行による複数のファセットは許容されます。 - Clarify は、アーティファクトを SSE-KMS で保護された S3 の場所に保存しながら、トレーニング後のバイアス分析をサポートしているため、暗号化された出力によるトレーニング後のバイアスは許容されます。

The training step fails because the feature group was created without an offline store configuration, so there is no S3-backed offline table for Athena to query. SageMaker Feature Store does not support enabling the offline store on an existing feature group after creation. Creating a new feature group with offline storage (and backfilling features) fixes training while preserving online lookups for low-latency inference. SageMaker Feature Store uses two distinct storage paths: the online store for low-latency key-based inference lookups, and the offline store (S3 + Glue Data Catalog) for analytics and training-time batch access (for example, via Athena). The error indicates the feature group has no OfflineStoreConfig, which happens when it was created with only the online store enabled. To fix this with minimal disruption: - Create a new feature group with offline store enabled (optionally enable both online and offline). - Ingest/backfill the same feature records into the new feature group. - Point the training pipeline’s Athena/offline reads at the new offline store while leaving the existing endpoint’s online lookups unchanged until you cut over. The key takeaway is that offline storage must be planned at feature group creation time for training use cases. - Bigger instances does not create an offline store or resolve missing OfflineStoreConfig. - IAM permissions can still be required, but the failure is that the offline store does not exist to query. - Online store for training is inefficient and not intended for large batch dataset creation compared with the offline store.

训练步骤失败，因为特征组是在没有离线存储配置的情况下创建的，因此没有 S3 支持的离线表可供 Athena 查询。 SageMaker Feature Store 不支持在创建后在现有特征组上启用离线存储。创建具有离线存储（和回填特征）的新特征组可以修复训练，同时保留在线查找以实现低延迟推理。 SageMaker Feature Store 使用两个不同的存储路径：用于低延迟基于密钥的推理查找的在线存储，以及用于分析和训练时批量访问（例如，通过 Athena）的离线存储（S3 + Glue 数据目录）。该错误表明该特征组没有 OfflineStoreConfig，这是在仅启用在线存储的情况下创建的。 要以最小的干扰解决此问题： - 创建启用离线存储的新特征组（可以选择同时启用在线和离线）。 - 将相同的特征记录摄取/回填到新的特征组中。 - 将训练管道的 Athena/离线读取指向新的离线存储，同时保持现有 endpoint 的在线查找不变，直到您切换。 关键要点是，必须在为训练用例创建特征组时规划离线存储。 - 较大的实例不会创建离线存储或解决缺少的 OfflineStoreConfig。 - IAM 权限仍然可以需要，但是失败的是离线存储不存在可以查询。 - 与离线存储相比，用于训练的在线存储效率低下，并且不适用于大批量数据集创建。

機能グループがオフライン ストア構成なしで作成されたため、トレーニング ステップは失敗します。そのため、Athena がクエリするための S3 にバックアップされたオフライン テーブルがありません。SageMaker Feature Store は、作成後の既存の機能グループでのオフライン ストアの有効化をサポートしていません。オフライン ストレージ (およびバックフィル機能) を使用して新しい機能グループを作成すると、低遅延推論のためのオンライン ルックアップを維持しながらトレーニングが修正されます。 SageMaker Feature Store は 2 つの異なるストレージ パスを使用します。1 つは低レイテンシーのキーベースの推論ルックアップ用のオンライン ストア、もう 1 つは分析とトレーニング時のバッチ アクセス用のオフライン ストア (S3 + Glue データ カタログ) (たとえば、Athena 経由) です。このエラーは、機能グループに OfflineStoreConfig がないことを示しており、オンライン ストアのみを有効にして機能グループが作成された場合に発生します。 中断を最小限に抑えてこれを修正するには: - オフライン ストアを有効にして新しい機能グループを作成します (オプションでオンラインとオフラインの両方を有効にします)。 - 同じ機能レコードを新しい機能グループに取り込み/バックフィルします。 - カットオーバーするまで既存の endpoint のオンライン ルックアップを変更せずに、トレーニング パイプラインの Athena/オフライン読み取りを新しいオフライン ストアに向けます。 重要な点は、トレーニング ユース ケースの機能グループの作成時にオフライン ストレージを計画する必要があるということです。 - より大きなインスタンスでは、オフライン ストアが作成されず、欠落している OfflineStoreConfig も解決されません。 - IAM 権限は引き続き必要ですが、クエリを実行できるオフライン ストアが存在しないという問題が発生します。 - トレーニング用のオンライン ストアは、オフライン ストアに比べて非効率的であり、大規模なバッチ データセットの作成を目的としていません。

This is an unlabeled, unsupervised need to identify unusual incoming data patterns that may indicate drift. Random Cut Forest is a SageMaker built-in algorithm designed for anomaly detection on numeric features, making it appropriate for automated drift signals. This aligns with the core principle of monitoring for drift to maintain ML system performance over time. The core principle here is monitoring for drift: you want an automated signal when new data looks meaningfully different from what the model was trained on. Because the stem specifies no labels and the goal is to flag unusual patterns in feature distributions, the matching built-in approach is unsupervised anomaly detection. Amazon SageMaker Random Cut Forest (RCF) is designed to detect outliers by assigning anomaly scores to observations, which can be used to trigger investigation workflows (for example, alarms and retraining evaluation) when feature behavior changes. The key takeaway is to choose an algorithm that matches the learning setup (unlabeled anomaly detection) rather than a supervised predictor. - Supervised boosting would require labeled targets to train a predictive model, which the stem does not provide. - Supervised linear models are for classification/regression with labels, not unlabeled drift signaling. - Clustering can segment data, but it is not purpose-built to score point anomalies as a drift trigger in the way RCF is.

这是一种无标签、无监督的需求，旨在识别可能表明漂移的异常传入数据模式。随机切割森林是一种 SageMaker 内置算法，专为数字特征的异常检测而设计，使其适用于自动漂移信号。这符合监控漂移的核心原则，以随着时间的推移维持机器学习系统的性能。 这里的核心原则是监控漂移：当新数据看起来与模型训练的数据明显不同时，您需要一个自动信号。由于主干没有指定标签，并且目标是标记特征分布中的异常模式，因此匹配的内置方法是无监督异常检测。 Amazon SageMaker 随机切割森林 (RCF) 旨在通过为观测值分配异常分数来检测异常值，这可用于在特征行为发生变化时触发调查工作流程（例如警报和再训练评估）。 关键要点是选择与学习设置（未标记异常检测）相匹配的算法，而不是监督预测器。 - 监督提升需要标记目标来训练预测模型，而茎不提供这一点。 - 监督线性模型用于带标签的分类/回归，而不是未标记的漂移信号。 - 聚类可以分割数据，但它并不是像 RCF 那样专门用于将点异常作为漂移触发器进行评分。

これは、ドリフトを示す可能性のある異常な受信データ パターンを識別するための、ラベルも監視もされていないニーズです。Random Cut Forest は、数値特徴の異常検出用に設計された SageMaker 組み込みアルゴリズムであり、自動化されたドリフト信号に適しています。これは、長期にわたって ML システムのパフォーマンスを維持するためにドリフトを監視するという中心原則と一致しています。 ここでの核となる原則はドリフトを監視することです。新しいデータがモデルのトレーニングに使用されたものと大きく異なっているように見える場合には、自動化されたシグナルが必要です。ステムではラベルが指定されておらず、目的は特徴分布内の異常なパターンにフラグを立てることであるため、マッチングの組み込みアプローチは教師なし異常検出です。Amazon SageMaker ランダム カット フォレスト (RCF) は、観測値に異常スコアを割り当てることで外れ値を検出するように設計されており、フィーチャの動作が変化したときに調査ワークフロー (アラームや再トレーニング評価など) をトリガーするために使用できます。 重要な点は、教師あり予測変数ではなく、学習設定 (ラベルなしの異常検出) に一致するアルゴリズムを選択することです。 - 教師ありブースティングでは、予測モデルをトレーニングするためにラベル付けされたターゲットが必要ですが、ステムでは提供されません。 - 教師あり線形モデルは、ラベルなしのドリフト シグナリングではなく、ラベル付きの分類/回帰用です。 - クラスタリングはデータをセグメント化できますが、RCF のように点の異常をドリフト トリガーとしてスコアリングすることを目的として構築されたものではありません。

Time series data must be split by time to avoid training on information from the future relative to the validation period. Holding out the most recent 30 days (the forecast horizon) creates an evaluation that matches how the model will be used in production. This usually improves model selection and reduces the offline-to-online performance gap with minimal added cost. The core issue is temporal leakage and a mismatch between how the model is validated and how it is used. Random row splits let the model see patterns from dates that occur after (or interleaved with) the validation dates, which can make offline metrics unrealistically optimistic for forecasting. A better approach is to validate using a chronological holdout window that matches the forecast horizon: - Train on earlier history only. - Validate on the most recent 30 days for each SKU (or use rolling-origin backtesting with 30-day windows). - Use the validation results to tune and select the model. This change improves reliability and forecast performance assessment with little to no additional infrastructure cost; tuning and deployment choices become consistent with the 30-day-ahead requirement. - Spot Training can lower cost but does not fix time series leakage or horizon-misaligned validation. - Shuffled k-fold CV is generally inappropriate for time series because it mixes future and past observations across folds. - More endpoint capacity improves inference throughput/latency, not forecasting accuracy or evaluation correctness.

时间序列数据必须按时间分割，以避免对相对于验证期的未来信息进行训练。保留最近 30 天（预测范围）可创建与模型在生产中的使用方式相匹配的评估。这通常可以改善模型选择，并以最小的附加成本缩小离线到在线的性能差距。 核心问题是时间泄漏以及模型验证方式和使用方式之间的不匹配。随机行分割让模型可以看到验证日期之后（或与之交错）发生的日期的模式，这可能会使离线指标对预测变得不切实际的乐观。 更好的方法是使用与预测范围相匹配的时间保留窗口进行验证： - 仅针对早期历史进行训练。 - 对每个 SKU 最近 30 天进行验证（或使用 30 天窗口的滚动源回溯测试）。 - 使用验证结果来调整和选择模型。 这一变化提高了可靠性和预测性能评估，几乎不需要额外的基础设施成本；调整和部署选择与提前 30 天的要求保持一致。 - Spot Training 可以降低成本，但不能修复时间序列泄漏或水平错位验证。 - 打乱的 k 重 CV 通常不适合时间序列，因为它混合了跨折叠的未来和过去的观察结果。 - 更多的 endpoint 容量提高了推理吞吐量/延迟，而不是预测准确性或评估正确性。

検証期間に関連した将来の情報のトレーニングを避けるために、時系列データを時間ごとに分割する必要があります。最新の 30 日間 (予測期間) を保持すると、モデルが運用環境でどのように使用されるかに一致する評価が作成されます。これにより通常、追加コストを最小限に抑えながらモデルの選択が改善され、オフラインとオンラインのパフォーマンスのギャップが削減されます。 中心的な問題は、時間的漏洩と、モデルの検証方法と使用方法の間の不一致です。ランダムな行分割により、モデルは検証日以降に発生する (または検証日とインターリーブされた) 日付のパターンを認識できるため、オフライン メトリクスの予測が非現実的に楽観的になる可能性があります。 より良いアプローチは、予測期間と一致する時系列ホールドアウト ウィンドウを使用して検証することです。 - 以前の履歴のみに基づいてトレーニングします。 - 各 SKU の最新 30 日間で検証します (または、30 日間の期間でローリング オリジン バックテストを使用します)。 - 検証結果を使用してモデルをチューニングおよび選択します。 この変更により、追加のインフラストラクチャ コストをほとんどまたはまったく発生させずに、信頼性と予測パフォーマンス評価が向上します。チューニングと展開の選択は、30 日前の要件と一致するようになります。 - Spot Training はコストを削減できますが、時系列リークや水平方向のずれた検証は修正されません。 - シャッフルされた k フォールド CV は、フォールド全体で将来と過去の観測が混合されるため、一般に時系列には不適切です。 - endpoint の容量を増やすと、精度や評価の正確性の予測ではなく、推論のスループット/レイテンシーが向上します。

The failure is in the KMS authorization path (not S3), because the role cannot call kms:GenerateDataKey on the specific CMK required by the bucket’s encryption setting. The least-privilege fix is to allow that role to use only the necessary KMS actions on only that key, and ensure the key policy also permits the role. This error indicates the failing control plane is AWS KMS authorization, not S3: when an S3 bucket enforces SSE-KMS, the caller must be allowed to use the specified CMK for data key generation and encryption. With least privilege, you grant only the KMS permissions required for the workload (commonly kms:GenerateDataKey, plus encryption/decryption as needed) and scope them to the specific CMK ARN. Because KMS evaluates both IAM policy and the key policy, the CMK’s key policy must also allow the SageMaker execution role (directly or via an allowed principal such as the account with appropriate conditions). The key takeaway is to fix the specific missing permission on the specific resource, rather than broadening access. - Over-broad S3 permissions doesn’t address the missing KMS permission and expands access unnecessarily. - Wildcard KMS admin access would likely work but violates least privilege and increases blast radius. - Disabling encryption avoids the symptom but weakens security instead of correcting KMS authorization.

故障发生在 KMS 授权路径（而不是 S3）中，因为角色无法对存储桶加密设置所需的特定 CMK 调用 KMS:GenerateDataKey。最低权限修复是允许该角色仅对该密钥使用必要的 KMS 操作，并确保密钥策略也允许该角色。 此错误表示失败的控制平面是 AWS KMS 授权，而不是 S3：当 S3 存储桶强制执行 SSE-KMS 时，必须允许调用方使用指定的 CMK 进行数据密钥生成和加密。使用最小权限，您仅授予工作负载所需的 KMS 权限（通常为 KMS:GenerateDataKey，以及根据需要加密/解密）并将其范围限定为特定 CMK ARN。由于 KMS 评估 IAM 策略和密钥策略，因此 CMK 的密钥策略还必须允许 SageMaker 执行角色（直接或通过允许的委托人，例如具有适当条件的账户）。 关键要点是修复特定资源上缺少的特定权限，而不是扩大访问范围。 - 过于宽泛的 S3 权限无法解决缺失的 KMS 权限问题，并且会不必要地扩展访问权限。 - 通配符 KMS 管理员访问权限可能会起作用，但违反了最低权限并增加了爆炸半径。 - 禁用加密可以避免该症状，但会削弱安全性，而不是纠正 KMS 授权。

ロールはバケットの暗号化設定で必要な特定の CMK で KMS:GenerateDataKey を呼び出すことができないため、障害は KMS 認証パス (S3 ではない) で発生します。最小権限の修正は、そのロールがそのキーに対してのみ必要な KMS アクションのみを使用できるようにし、キー ポリシーでもそのロールが許可されていることを確認することです。 このエラーは、失敗したコントロール プレーンが S3 ではなく AWS KMS 認証であることを示します。S3 バケットが SSE-KMS を強制する場合、呼び出し元はデータ キーの生成と暗号化に指定された CMK の使用を許可される必要があります。最小限の権限で、ワークロードに必要な KMS 権限 (通常は KMS:GenerateDataKey、さらに必要に応じて暗号化/復号化) のみを付与し、それらの範囲を特定の CMK ARN に限定します。KMS は IAM ポリシーとキー ポリシーの両方を評価するため、CMK のキー ポリシーは SageMaker 実行ロールも許可する必要があります (直接、または適切な条件を持つアカウントなどの許可されたプリンシパル経由)。 重要な点は、アクセスを拡大するのではなく、特定のリソースに対する特定の不足している権限を修正することです。 - 広すぎる S3 権限は、不足している KMS 権限に対処せず、アクセスを不必要に拡大します。 - ワイルドカード KMS 管理者アクセスは機能する可能性がありますが、最小権限に違反し、爆発範囲が増加します。 - 暗号化を無効にすると、症状は回避されますが、KMS 認証が修正される代わりにセキュリティが低下します。

Approaches to avoid are the ones that break explicit rollout constraints. Exposing inference publicly or writing unencrypted payloads violates security requirements, and cutting over 100% at once without an immediate rollback mechanism violates the 5-minute rollback requirement. Canary, linear, and controlled blue/green patterns can meet the stated rollback and cost-cap constraints when paired with alarms and preserved prior configurations. High-level model release strategies (canary, linear, blue/green) are acceptable when they (1) shift traffic gradually or with a controlled cutover, (2) include health/KPI alarms, and (3) keep a ready rollback target (previous model package + endpoint config) that can be restored quickly. In this scenario, the unsafe approaches are the ones that directly violate stated requirements: - Public exposure or unencrypted payload storage breaks the VPC-only and KMS encryption constraints. - An immediate 100% cutover with “retrain/redeploy later” is not a rollback plan and cannot reliably restore service within 5 minutes. By contrast, canary and linear deployments use traffic weighting and monitoring to limit blast radius, and a time-boxed blue/green swap can satisfy the temporary capacity constraint if the overlap window is kept short and rollback is an endpoint config revert. - Security/compliance breach The approach that makes the endpoint public and stores payloads unencrypted violates the explicit VPC-only and KMS requirements. - No rapid rollback The approach that shifts 100% traffic immediately and relies on retraining/redeploying cannot meet the 5-minute rollback requirement. - Controlled traffic shifting Canary and linear rollouts are acceptable because weights can be reverted quickly based on alarms. - Safe blue/green A time-boxed blue/green swap is acceptable when it preserves the previous configuration and stays within the temporary capacity limit.

要避免的方法是打破明确的推出限制的方法。公开暴露推理或写入未加密的有效负载违反了安全要求，并且在没有立即回滚机制的情况下立即削减超过 100% 违反了 5 分钟回滚要求。当与警报和保留的先前配置配对时，金丝雀、线性和受控的蓝/绿模式可以满足规定的回滚和成本上限约束。 当高级模型发布策略（金丝雀、线性、蓝/绿）满足以下条件时，它们是可以接受的：(1) 逐渐转移流量或通过受控的切换，(2) 包括运行状况/KPI 警报，以及 (3) 保持可快速恢复的现成回滚目标（以前的模型包 + endpoint 配置）。 在这种情况下，不安全的方法是直接违反规定要求的方法： - 公开暴露或未加密的有效负载存储打破了仅 VPC 和 KMS 加密限制。 - 通过“稍后重新训练/重新部署”立即 100% 切换不是回滚计划，并且无法在 5 分钟内可靠地恢复服务。 相比之下，金丝雀和线性部署使用流量加权和监控来限制爆炸半径，如果重叠窗口保持较短并且回滚是 endpoint 配置恢复，则时间盒蓝/绿交换可以满足临时容量限制。 - 安全/合规性违规将 endpoint 公开并存储未加密的有效负载的方法违反了明确的仅 VPC 和 KMS 要求。 - 无法快速回滚 立即转移 100%流量并依赖重新训练/重新部署的方式无法满足 5 分钟回滚的要求。 - 受控流量转移金丝雀和线性推出是可以接受的，因为权重可以根据警报快速恢复。 - 安全蓝/绿 当保留先前的配置并保持在临时容量限制内时，限时蓝/绿交换是可以接受的。

避けるべきアプローチは、明示的なロールアウト制約を破るアプローチです。推論を公開したり、暗号化されていないペイロードを書き込んだりすることはセキュリティ要件に違反し、即時ロールバック メカニズムなしで一度に 100% 以上をカットすることは 5 分間のロールバック要件に違反します。カナリア、リニア、制御されたブルー/グリーン パターンは、アラームと組み合わせて以前の設定を保存すると、規定のロールバックとコスト キャップの制約を満たすことができます。 高レベルのモデル リリース戦略 (カナリア、リニア、ブルー/グリーン) は、(1) トラフィックを徐々に、または制御されたカットオーバーでシフトする、(2) ヘルス/KPI アラームを含む、(3) すぐに復元できる準備ができたロールバック ターゲット (以前のモデル パッケージ + endpoint 構成) を維持する場合に受け入れられます。 このシナリオでは、安全でないアプローチは、指定された要件に直接違反するものです。 - 公開公開または暗号化されていないペイロード ストレージは、VPC のみおよび KMS 暗号化制約を破ります。 - 「後で再トレーニング/再デプロイ」による即時の 100% カットオーバーはロールバック計画ではないため、5 分以内にサービスを確実に復元することはできません。 対照的に、カナリア展開とリニア展開では、トラフィックの重み付けとモニタリングを使用してブラスト半径を制限し、オーバーラップ ウィンドウが短く保たれ、ロールバックが endpoint 設定の復元である場合、タイムボックス化されたブルー/グリーン スワップは一時的な容量制限を満たすことができます。 - セキュリティ/コンプライアンス違反 endpoint を公開し、ペイロードを暗号化せずに保存するアプローチは、明示的な VPC のみおよび KMS 要件に違反します。 - 迅速なロールバックはありません 100% トラフィックを即時にシフトし、再トレーニング/再展開に依存するアプローチでは、5 分間のロールバック要件を満たすことができません。 - 制御されたトラフィックシフトのカナリアおよびリニアロールアウトは、アラームに基づいて重みをすぐに元に戻すことができるため、許容されます。 - 安全な青/緑 以前の構成が保持され、一時的な容量制限内に留まる場合、タイムボックス化された青/緑のスワップが受け入れられます。

This change applies the data minimization principle: only collect, retain, and process what is necessary for the ML objective. By reducing unused columns and unnecessary intermediate outputs, the workflow lowers S3 storage and processing compute costs while preserving training inputs that matter to the model. The core principle is data minimization: design ML pipelines to use (and keep) only the minimum data needed to meet the purpose. In the scenario, dropping unused columns and aggregating to the required granularity reduces I/O, storage footprint, and processing time, which directly lowers infrastructure costs without changing the model’s intended inputs. Deleting intermediate artifacts after use further reduces ongoing storage cost and reduces the amount of data that could be exposed in the event of an incident. Key takeaway: cost optimization can be achieved by minimizing unnecessary data movement, storage, and processing—not just by changing instance sizes. - Reproducibility is about repeatable runs (versioning code/data), not reducing retained/processed data. - Least privilege focuses on IAM permissions; it doesn’t primarily address data volume and storage/compute costs. - Defense in depth is layering security controls; it’s not the main principle behind dropping unused fields and artifacts. Questions 51-65

此更改应用了数据最小化原则：仅收集、保留和处理 ML 目标所需的内容。通过减少未使用的列和不必要的中间输出，该工作流程降低了 S3 存储和处理计算成本，同时保留对模型重要的训练输入。 核心原则是数据最小化：设计 ML Pipelines 仅使用（并保留）满足目的所需的最少数据。在该场景中，删除未使用的列并聚合到所需的粒度可以减少 I/O、存储占用空间和处理时间，从而直接降低基础设施成本，而无需更改模型的预期输入。使用后删除中间工件进一步降低了持续的存储成本，并减少了发生事件时可能暴露的数据量。 要点：成本优化可以通过最大限度地减少不必要的数据移动、存储和处理来实现，而不仅仅是改变实例大小。 - 再现性是指可重复运行（版本控制代码/数据），而不是减少保留/处理的数据。 - 最小权限重点关注 IAM 权限；它主要不解决数据量和存储/计算成本。 - 深度防御是分层安全控制；这不是删除未使用的字段和工件背后的主要原则。 问题 51-65

この変更では、ML の目的に必要なもののみを収集、保持、処理するというデータ最小化の原則が適用されます。未使用の列と不要な中間出力を削減することで、ワークフローは、モデルにとって重要なトレーニング入力を維持しながら、S3 のストレージと処理のコンピューティング コストを削減します。 基本原則はデータの最小化です。目的を満たすために必要な最小限のデータのみを使用 (および保持) するように ML Pipelines を設計します。このシナリオでは、未使用の列を削除し、必要な粒度で集計することで、I/O、ストレージ フットプリント、処理時間が削減され、モデルの意図した入力を変更することなくインフラストラクチャ コストが直接削減されます。使用後に中間アーティファクトを削除すると、継続的なストレージ コストがさらに削減され、インシデントが発生した場合に公開される可能性のあるデータの量が削減されます。 重要なポイント: コストの最適化は、インスタンス サイズを変更するだけではなく、不必要なデータの移動、ストレージ、処理を最小限に抑えることで実現できます。 - 再現性とは、反復可能な実行 (コード/データのバージョン管理) に関するものであり、保持/処理されるデータを削減するものではありません。 - 最小権限は IAM 権限に重点を置いています。主にデータ量やストレージ/コンピューティングのコストに対処するものではありません。 - 多層防御とは、セキュリティ制御を階層化することです。それは、未使用のフィールドとアーティファクトを削除するための主な原則ではありません。 質問51～65

To monitor data drift, SageMaker Model Monitor compares captured inference data to a baseline made from representative data and saved as baseline statistics and constraints in S3. The monitoring run then writes a violations artifact when the captured data no longer conforms to those baseline constraints. SageMaker Model Monitor data quality monitoring works by establishing a baseline and then comparing production inference data to it on a schedule. Typical setup and outputs: - Run a baseline job (often from training data) to generate statistics.json and constraints.json in S3. - Enable endpoint data capture (or otherwise provide a dataset) so the monitoring job has inference records to analyze. - Each monitoring execution writes results to S3, including a constraint_violations.json file that lists any violated constraints (for example, missing values, type mismatches, or distribution constraints you baselined). Key takeaway: baseline artifacts define “normal,” and constraint_violations.json is the high-level signal that drift/quality constraints were violated. - OK Create a baseline that outputs constraints.json and statistics.json to S3 — these baseline artifacts are required for comparison. - OK A non-empty constraint_violations.json means baseline constraints were breached — this is the primary drift/quality indicator from a run. - NO Model Monitor automatically derives the baseline from the first schedule run — you must provide or create baseline statistics/constraints. - NO Use SageMaker Debugger rules to detect inference data drift — Debugger targets training diagnostics, not Model Monitor drift reports. - NO Review statistics.json to identify which constraints failed — the violations are surfaced in constraint_violations.json. - NO Model Monitor reads CloudWatch Logs as the monitoring input by default — it analyzes captured data (for example, from S3 data capture), not logs.

为了监控数据漂移，SageMaker Model Monitor 将捕获的推理数据与由代表性数据制成的基线进行比较，并在 S3 中保存为基线统计数据和约束。当捕获的数据不再符合这些基线约束时，监控运行会写入违规工件。 SageMaker Model Monitor 数据质量监控的工作原理是建立基线，然后按计划将生产推断数据与其进行比较。 典型设置和输出： - 运行基线作业（通常来自训练数据）以在 S3 中生成 statistics.json 和 constraints.json。 - 启用 endpoint 数据捕获（或以其他方式提供数据集），以便监控作业具有要分析的推理记录。 - 每个监视执行都会将结果写入 S3，包括一个 constraint_violations.json 文件，其中列出了任何违反的约束（例如，缺失值、类型不匹配或您设定基线的分布约束）。 关键要点：基线工件定义“正常”，constraint_violations.json 是违反漂移/质量约束的高级信号。 - OK 创建一个将 constraints.json 和 statistics.json 输出到 S3 的基线 - 比较需要这些基线工件。 - 好的 非空的 constraint_violations.json 意味着基线约束被违反——这是运行的主要漂移/质量指标。 - 否 Model Monitor 自动从第一次计划运行中导出基线 — 您必须提供或创建基线统计数据/约束。 - 否 使用 SageMaker Debugger 规则来检测推理数据漂移 - Debugger 的目标是训练诊断，而不是 Model Monitor 漂移报告。 - 否 检查 statistics.json 以确定哪些约束失败 - 违规行为显示在 constraint_violations.json 中。 - NO 默认情况下，Model Monitor 读取 CloudWatch Logs 作为监控输入 — 它分析捕获的数据（例如，来自 S3 数据捕获），而不是日志。

データ ドリフトを監視するために、SageMaker Model Monitor はキャプチャした推論データを、代表的なデータから作成され S3 にベースライン統計および制約として保存されたベースラインと比較します。モニタリングの実行では、キャプチャされたデータがベースライン制約に準拠しなくなったときに、違反アーティファクトが書き込まれます。 SageMaker Model Monitor データ品質監視は、ベースラインを確立し、スケジュールに従って運用推論データをそれと比較することによって機能します。 一般的なセットアップと出力: - ベースライン ジョブ (多くの場合トレーニング データから) を実行して、S3 に統計情報.json とconstraints.json を生成します。 - endpoint データ キャプチャを有効にし (またはデータセットを提供し)、監視ジョブが分析する推論レコードを持てるようにします。 - 各モニタリング実行により、違反した制約 (欠損値、型の不一致、ベースライン設定した分散制約など) をリストするconstraint_violations.json ファイルを含む結果が S3 に書き込まれます。 重要なポイント: ベースライン アーティファクトは「正常」を定義し、constraint_violations.json はドリフト/品質制約に違反したことを示す高レベルのシグナルです。 - OKconstraints.json とstatistics.json を S3 に出力するベースラインを作成します。これらのベースライン アーティファクトは比較に必要です。 - OK 空でないconstraint_violations.jsonは、ベースライン制約が違反されたことを意味します。これは、実行からの主要なドリフト/品質指標です。 - いいえ Model Monitor は、最初のスケジュール実行からベースラインを自動的に導出します。ベースライン統計/制約を指定または作成する必要があります。 - いいえ SageMaker Debugger ルールを使用して推論データ ドリフトを検出します。Debugger は、Model Monitor ドリフト レポートではなく、トレーニング診断をターゲットとします。 - いいえstatistics.json を確認して、どの制約が失敗したかを特定します。違反はconstraint_violations.jsonで明らかになります。 - NO Model Monitor は、デフォルトで CloudWatch Logs をモニタリング入力として読み取ります。ログではなく、キャプチャされたデータ (たとえば、S3 データ キャプチャから) を分析します。

Detecting distribution shifts typically requires capturing inference inputs, establishing a baseline from training (or a known-good period), and running offline or scheduled comparisons. SageMaker Model Monitor and SageMaker Clarify support these analyses using batch processing and stored reports. Approaches that move PII outside AWS or that add expensive analysis to the real-time inference path violate the stated security and latency requirements. Data distribution drift detection is usually done by comparing summary statistics or distributions of recent inference data to a baseline (often from training data). In SageMaker, a common pattern is to enable endpoint data capture to encrypted S3, then run scheduled monitoring jobs: Model Monitor for data quality drift (feature statistics/constraints) and Clarify for bias drift analysis on captured samples. You can also compute custom drift metrics (for example PSI or KS tests) in a scheduled SageMaker processing job and publish results to CloudWatch for alarming. Actions to avoid are those that violate explicit constraints: exporting PII outside AWS breaks the no-egress requirement, and running explainability synchronously per request risks latency and unnecessary cost. Keep heavy analysis asynchronous/offline and keep captured data protected with encryption and controlled access. - PII exfiltration risk sending full payloads to an external SaaS violates the stated no-internet-egress and data residency constraints. - Online-path overhead computing SHAP for every request is not a drift-monitoring necessity and commonly breaks tight p99 latency targets. - Baseline + scheduled comparison using Model Monitor and/or scheduled processing jobs fits distribution-shift detection without impacting online latency. - Clarify for bias drift running Clarify on captured samples supports high-level drift investigation while keeping analysis asynchronous.

检测分布变化通常需要捕获推理输入、建立训练基线（或已知良好时期）以及运行离线或预定比较。 SageMaker Model Monitor 和 SageMaker Clarify 使用批处理和存储的报告支持这些分析。将 PII 移出 AWS 或向实时推理路径添加昂贵的分析的方法违反了规定的安全和延迟要求。 数据分布漂移检测通常通过将最近推理数据的汇总统计数据或分布与基线（通常来自训练数据）进行比较来完成。在 SageMaker 中，常见模式是启用 endpoint 数据捕获到加密的 S3，然后运行计划的监控作业：Model Monitor 用于数据质量漂移（特征统计/约束），Clarify 用于对捕获的样本进行偏差漂移分析。您还可以在计划的 SageMaker 处理作业中计算自定义漂移指标（例如 PSI 或 KS 测试），并将结果发布到 CloudWatch 以发出警报。 要避免的操作是那些违反明确约束的操作：将 PII 导出到 AWS 外部会违反无出口要求，并且每个请求同步运行可解释性都会带来延迟和不必要的成本风险。保持大量分析异步/离线，并通过加密和受控访问来保护捕获的数据。 - 将完整有效负载发送到外部 SaaS 的 PII 渗漏风险违反了规定的无互联网出口和数据驻留限制。 - 为每个请求计算 SHAP 的在线路径开销不是漂移监控的必要条件，并且通常会打破严格的 p99 延迟目标。 - 使用 Model Monitor 和/或计划处理作业的基线 + 计划比较适合分布转移检测，而不影响在线延迟。 - 用于偏置漂移的 Clarify 在捕获的样本上运行 Clarify 支持高级漂移调查，同时保持分析异步。

分布の変化を検出するには、通常、推論入力をキャプチャし、トレーニング (または既知の良好な期間) からベースラインを確立し、オフラインまたはスケジュールされた比較を実行する必要があります。SageMaker Model Monitor および SageMaker Clarify は、バッチ処理と保存されたレポートを使用してこれらの分析をサポートします。PII を AWS の外に移動するアプローチ、またはリアルタイムの推論パスに高価な分析を追加するアプローチは、規定されているセキュリティおよびレイテンシの要件に違反します。 データ分布ドリフトの検出は通常、最近の推論データの概要統計または分布をベースライン (多くの場合トレーニング データから) と比較することによって行われます。SageMaker では、一般的なパターンは、暗号化された S3 への endpoint データ キャプチャを有効にしてから、スケジュールされた監視ジョブを実行することです。データ品質ドリフト (特徴統計/制約) には Model Monitor、キャプチャされたサンプルのバイアス ドリフト分析には Clarify が使用されます。スケジュールされた SageMaker 処理ジョブでカスタム ドリフト メトリクス (PSI や KS テストなど) を計算し、結果をアラーム用に CloudWatch に公開することもできます。 避けるべきアクションは、明示的な制約に違反するアクションです。PII を AWS の外にエクスポートすると、出口なしの要件が破られ、リクエストごとに説明可能性を同期的に実行すると、レイテンシーと不必要なコストが発生する危険があります。大量の分析を非同期/オフラインに保ち、キャプチャされたデータを暗号化と制御されたアクセスで保護します。 - 完全なペイロードを外部 SaaS に送信する PII 漏洩のリスクは、規定されているインターネット出口禁止およびデータ常駐の制約に違反します。 - すべてのリクエストに対する SHAP のオンライン パス オーバーヘッド コンピューティングはドリフト監視の必要性がなく、通常は厳しい p99 遅延目標を破ります。 - Model Monitor を使用したベースラインとスケジュールされた比較および/またはスケジュールされた処理ジョブは、オンライン遅延に影響を与えることなく、分散シフト検出に適合します。 - バイアス ドリフト用の Clarify キャプチャされたサンプルで Clarify を実行すると、分析を非同期に保ちながら高レベルのドリフト調査をサポートします。

Use an immutable, low-cost archival store for audit retention and keep recent data quickly accessible. An SSE-KMS encrypted S3 bucket with Object Lock satisfies WORM and 7-year retention, while S3 lifecycle policies control cost over time. Exporting CloudWatch logs/metrics to S3 and writing SageMaker Data Capture and Model Monitor outputs to the same bucket preserves all required monitoring artifacts. The core requirement is audit-ready retention of monitoring artifacts (including captured inference payloads and time-series telemetry) with immutability and encryption, without adding meaningful inference latency. Amazon S3 is the audit-friendly system of record here: S3 Object Lock (WORM) plus SSE-KMS meets governance requirements, and S3 lifecycle transitions meet the “hot for 30 days, cheap afterward” requirement. To cover all artifact types end-to-end: - Configure SageMaker endpoint Data Capture and Model Monitor to write to the centralized S3 bucket. - Export CloudWatch Logs (subscription) and CloudWatch metrics (metric streams) to S3 to satisfy the 7-year metric retention requirement. Keeping operational views in CloudWatch for recent troubleshooting is compatible, but S3 is the durable audit store. - CloudWatch-only retention doesn’t satisfy the stated 7-year metrics requirement (CloudWatch metrics retention is shorter). - EFS on instances is not an appropriate immutable, centralized audit store and adds operational risk for long retention. - DynamoDB TTL for artifacts is a poor fit and cost-inefficient for large log/payload archives and WORM retention.

使用不可变的、低成本的归档存储进行审计保留并保持最新数据的快速访问。具有对象锁的 SSE-KMS 加密 S3 存储桶满足 WORM 和 7 年保留的要求，而 S3 生命周期策略则可以控制随时间推移的成本。将 CloudWatch Logs/指标导出到 S3 并将 SageMaker Data Capture 和 Model Monitor 输出写入同一存储桶可保留所有所需的监控工件。 核心要求是审计就绪的监控工件（包括捕获的推理有效负载和时间序列遥测）的保留，具有不变性和加密性，而不增加有意义的推理延迟。 Amazon S3 是这里的审计友好型记录系统：S3 对象锁定 (WORM) 加上 SSE-KMS 满足治理要求，并且 S3 生命周期转换满足“30 天热，之后便宜”的要求。 端到端覆盖所有工件类型： - 配置 SageMaker endpoint 数据捕获和 Model Monitor 以写入集中式 S3 存储桶。 - 将 CloudWatch Logs（订阅）和 CloudWatch 指标（指标流）导出到 S3，以满足 7 年指标保留要求。 在 CloudWatch 中保留操作视图以进行最近的故障排除是兼容的，但 S3 是持久的审核存储。 - 仅 CloudWatch 保留不满足规定的 7 年指标要求（CloudWatch 指标保留时间较短）。 - 实例上的 EFS 不是合适的不可变、集中式审计存储，并且会增加长期保留的操作风险。 - 用于工件的 DynamoDB TTL 对于大型日志/有效负载存档和 WORM 保留来说不太合适且成本效率低下。

監査の保持には不変で低コストのアーカイブ ストアを使用し、最新のデータにすぐにアクセスできるようにします。オブジェクト ロックを備えた SSE-KMS 暗号化された S3 バケットは、WORM と 7 年間の保存を満たし、S3 ライフサイクル ポリシーにより長期にわたるコストが制御されます。CloudWatch Logs/メトリクスを S3 にエクスポートし、SageMaker Data Capture と Model Monitor の出力を同じバケットに書き込むと、必要な監視アーティファクトがすべて保持されます。 中核的な要件は、意味のある推論レイテンシを追加することなく、不変性と暗号化を備えたモニタリング アーティファクト (キャプチャされた推論ペイロードや時系列テレメトリを含む) を監査に備えて保持することです。ここでの Amazon S3 は監査に適した記録システムです。S3 オブジェクト ロック (WORM) と SSE-KMS はガバナンス要件を満たし、S3 ライフサイクル移行は「30 日間はホット、その後は安価」要件を満たします。 すべてのアーティファクト タイプをエンドツーエンドでカバーするには: - 集中管理された S3 バケットに書き込むように SageMaker endpoint Data Capture と Model Monitor を構成します。 - CloudWatch Logs (サブスクリプション) および CloudWatch メトリクス (メトリクス ストリーム) を S3 にエクスポートして、7 年間のメトリクス保持要件を満たす。 最近のトラブルシューティングのために CloudWatch に操作ビューを保持することには互換性がありますが、S3 は耐久性のある監査ストアです。 - CloudWatch のみの保持は、規定されている 7 年間のメトリクス要件を満たしていません (CloudWatch メトリクスの保持はより短いです)。 - インスタンス上の EFS は、適切な不変の一元化された監査ストアではなく、長期保存による運用リスクが追加されます。 - アーティファクトの DynamoDB TTL は、大規模なログ/ペイロード アーカイブおよび WORM 保存には適合性が低く、コスト効率が悪くなります。

AWS CloudTrail is the AWS service used for auditing because it records management and data events for API calls across AWS services, including Amazon SageMaker. Those event records can be centrally stored (commonly in Amazon S3) and used as compliance evidence and for security investigations. This is distinct from operational logging and ML-specific monitoring features. For security investigations and compliance, you typically need a reliable record of “who did what, when, and from where” in an AWS account. AWS CloudTrail provides this by capturing API activity (management events and, when enabled, selected data events) across services such as IAM, Amazon S3, and Amazon SageMaker. CloudTrail logs can be delivered to an Amazon S3 bucket (often with encryption and retention controls) and optionally sent to CloudWatch Logs for near-real-time searching and alerting. In contrast, CloudWatch Logs is primarily for ingesting and querying application/service log streams, and SageMaker monitoring features focus on ML behavior (like drift) rather than account-level API auditing. - Operational logs vs audit trail CloudWatch Logs is for log ingestion/analysis, not the authoritative record of AWS API calls. - ML drift monitoring SageMaker Model Monitor detects data/quality/drift issues, not IAM/SageMaker API actions. - Config state tracking AWS Config tracks resource configuration and changes, but it is not the primary API call audit log like CloudTrail.

AWS CloudTrail 是用于审核的 AWS 服务，因为它记录跨 AWS 服务（包括 Amazon SageMaker）的 API 调用的管理和数据事件。这些事件记录可以集中存储（通常在 Amazon S3 中）并用作合规证据和安全调查。这与操作日志记录和特定于 ML 的监控特征不同。 为了进行安全调查和合规性，您通常需要 AWS 账户中“谁、何时、何地做了什么”的可靠记录。 AWS CloudTrail 通过捕获 API 跨服务（例如 IAM、Amazon S3 和 Amazon SageMaker）的活动（管理事件，以及启用后的选定数据事件）来实现这一点。 CloudTrail 日志可以传送到 Amazon S3 存储桶（通常具有加密和保留控制），也可以选择发送到 CloudWatch Logs 以进行近实时搜索和警报。相比之下，CloudWatch Logs 主要用于摄取和查询应用程序/服务日志流，SageMaker 监控特征侧重于 ML 行为（如漂移），而不是帐户级 API 审核。 - 操作日志与审计跟踪 CloudWatch Logs 用于日志摄取/分析，而不是 AWS API 调用的权威记录。 - ML 漂移监控 SageMaker Model Monitor 检测数据/质量/漂移问题，而不是 IAM/SageMaker API 操作。 - 配置状态跟踪 AWS Config 跟踪资源配置和更改，但它不是像 CloudTrail 那样主要的 API 调用审核日志。

AWS CloudTrail は、Amazon SageMaker を含む AWS サービス全体にわたる API 呼び出しの管理イベントとデータ イベントを記録するため、監査に使用される AWS サービスです。これらのイベント記録は一元的に保存され (通常は Amazon S3 に)、コンプライアンスの証拠として、またセキュリティ調査に使用できます。これは、運用ログや ML 固有の監視機能とは異なります。 セキュリティ調査とコンプライアンスのためには、通常、AWS アカウントに「誰が、いつ、どこで何をしたか」の信頼できる記録が必要です。AWS CloudTrail は、IAM、Amazon S3、Amazon SageMaker などのサービス全体で API アクティビティ (管理イベント、および有効になっている場合は選択されたデータ イベント) をキャプチャすることによってこれを提供します。CloudTrail ログは、Amazon S3 バケット (多くの場合、暗号化と保持制御を備えたもの) に配信でき、オプションで、ほぼリアルタイムの検索とアラートのために CloudWatch Logs に送信できます。対照的に、CloudWatch Logs は主にアプリケーション/サービス ログ ストリームの取り込みとクエリを目的としており、SageMaker 監視機能はアカウント レベルの API 監査ではなく ML 動作 (ドリフトなど) に焦点を当てています。 - 操作ログと監査証跡 CloudWatch Logs はログの取り込み/分析用であり、AWS API 呼び出しの信頼できる記録ではありません。 - ML ドリフト監視 SageMaker Model Monitor は、IAM/SageMaker API アクションではなく、データ/品質/ドリフトの問題を検出します。 - 構成状態追跡 AWS Config はリソース構成と変更を追跡しますが、CloudTrail のようなプライマリ API 呼び出し監査ログではありません。

In MLOps CI/CD, automation promotes only validated model artifacts. Training outputs must be evaluated against defined metrics before the model is registered and deployed, so production receives a controlled, approved version. Monitoring then closes the loop by detecting drift or degradation and triggering an automated response. CI/CD principles for ML add explicit quality controls around model artifacts, not just application code. A typical automated flow is: train a candidate model, evaluate it against agreed metrics/baselines, register/version the model and its metadata (including lineage), deploy a specific approved version to the target environment, and continuously monitor the deployed model to detect drift or performance regression. Deploying to production before evaluation is unsafe because it bypasses the key CI/CD gate that prevents unvalidated models from being promoted. The correct pattern is “train → evaluate → register → (approve) → deploy → monitor,” with automation and approvals appropriate to risk. - Evaluation gates before promotion is a standard CI/CD control to prevent pushing failing models. - Model registry and lineage supports versioning, auditability, and reproducible promotion across environments. - Monitoring-driven automation is an expected post-deploy stage to detect drift/regressions and trigger retrain/rollback.

在 MLOps CI/CD 中，自动化仅提升经过验证的模型工件。在注册和部署模型之前，必须根据定义的指标评估培训输出，以便生产收到受控的、经过批准的版本。然后，监控通过检测漂移或退化并触发自动响应来关闭循环。 ML 的 CI/CD 原则添加了围绕模型工件（而不仅仅是应用程序代码）的明确质量控制。典型的自动化流程是：训练候选模型，根据商定的指标/基线对其进行评估，注册/版本化模型及其元数据（包括沿袭），将特定的批准版本部署到目标环境，并持续监控已部署的模型以检测漂移或性能回归。 在评估之前部署到生产是不安全的，因为它绕过了阻止未经验证的模型升级的关键 CI/CD 门。正确的模式是“训练→评估→注册→（批准）→部署→监控”，并根据风险进行适当的自动化和批准。 - 升级前的评估门是标准的 CI/CD 控制，以防止推送失败的模型。 - Model Registry 和沿袭支持跨环境的版本控制、可审核性和可重复升级。 - 监控驱动的自动化是预期的部署后阶段，用于检测漂移/回归并触发重新训练/回滚。

MLOps CI/CD では、自動化により検証済みのモデル アーティファクトのみがプロモートされます。トレーニング出力は、モデルが登録およびデプロイされる前に、定義されたメトリクスに照らして評価される必要があるため、本番環境は管理された承認済みバージョンを受け取ります。その後、モニタリングはドリフトや劣化を検出し、自動応答をトリガーすることでループを閉じます。 ML の CI/CD 原則では、アプリケーション コードだけでなく、モデル アーティファクトに関する明示的な品質管理が追加されます。一般的な自動化フローは次のとおりです。候補モデルをトレーニングし、合意されたメトリクス/ベースラインに対して評価し、モデルとそのメタデータ (系統を含む) を登録/バージョン付けし、特定の承認されたバージョンをターゲット環境にデプロイし、デプロイされたモデルを継続的に監視してドリフトやパフォーマンスの低下を検出します。 評価前に実稼働環境にデプロイすると、未検証のモデルの昇格を防ぐ重要な CI/CD ゲートがバイパスされるため、安全ではありません。正しいパターンは「トレーニング → 評価 → 登録 → (承認) → 導入 → 監視」であり、リスクに応じて自動化と承認が行われます。 - プロモーション前の評価ゲートは、失敗したモデルのプッシュを防ぐための標準 CI/CD コントロールです。 - Model Registry とリネージュは、環境全体でのバージョン管理、監査可能性、再現可能なプロモーションをサポートしています。 - 監視主導の自動化は、ドリフト/回帰を検出し、再トレーニング/ロールバックをトリガーするための展開後の段階として期待されます。

The endpoint is CPU-bound and serving a deep learning transformer, so an inference-optimized family is the best match to improve latency per dollar for supported frameworks. The Model Monitor processing job is failing due to memory exhaustion with low CPU use, so a memory-optimized family is the best fit to prevent OOM and stabilize the nightly run. Instance family selection should follow the dominant resource bottleneck you observe in monitoring data. For real-time inference of deep learning models, inference-optimized instances (such as Inferentia-based choices) are purpose-built to deliver better throughput/latency per cost than general-purpose CPU instances when the model/framework is supported. For batch-style monitoring jobs that crash with out-of-memory while CPU remains low, the limiting factor is RAM, so memory-optimized instances are the appropriate fit. A practical approach is: - Use CloudWatch/endpoint metrics to identify whether inference is compute/accelerator-bound. - Use CloudWatch memory/OS logs for processing to confirm RAM pressure. - Change only the bottlenecked dimension first, then re-measure. Compute-optimized helps when CPU is the constraint; it does not fix RAM-driven failures. - OK Move the endpoint to inference-optimized: targets deep learning serving efficiency and lowers latency/cost. - OK Move the monitoring processing job to memory-optimized: increases available RAM to eliminate OOM. - NO Move the endpoint to memory-optimized: adds RAM but doesn’t address inference acceleration/throughput. - NO Move the processing job to compute-optimized: increases CPU but leaves the memory bottleneck. - NO Move both to general-purpose: may be incremental, but doesn’t directly solve the specific bottlenecks. - NO Move the endpoint to a GPU training-optimized instance: typically overprovisioned and cost-inefficient for steady inference needs.

endpoint 受 CPU 限制并为深度学习转换器提供服务，因此推理优化系列是改善受支持框架的延迟的最佳匹配。 Model Monitor 处理作业由于 CPU 使用率低而内存耗尽而失败，因此内存优化系列最适合防止 OOM 并稳定夜间运行。 实例系列选择应遵循您在监控数据中观察到的主要资源瓶颈。对于深度学习模型的实时推理，推理优化实例（例如基于 Inferentia 的选择）是专门构建的，以便在支持模型/框架时提供比通用 CPU 实例更好的单位成本吞吐量/延迟。对于在 CPU 保持较低水平时因内存不足而崩溃的批处理式监控作业，限制因素是 RAM，因此内存优化实例是合适的选择。 一个实用的方法是： - 使用 CloudWatch/endpoint 指标来确定推理是否受计算/加速器限制。 - 使用 CloudWatch 内存/操作系统日志进行处理以确认 RAM 压力。 - 首先仅更改瓶颈尺寸，然后重新测量。 当 CPU 受到限制时，计算优化会有所帮助；它不能修复 RAM 驱动的故障。 - OK 将 endpoint 转向推理优化：目标是提高深度学习服务效率并降低延迟/成本。 - OK 将监控处理作业移至内存优化：增加可用 RAM 以消除 OOM。 - 否 将 endpoint 移至内存优化：添加 RAM，但不解决推理加速/吞吐量问题。 - 否 将处理作业移至计算优化：增加 CPU，但保留内存瓶颈。 - 否 将两者移至通用：可能是渐进式的，但不能直接解决特定的瓶颈。 - 否 将 endpoint 移至 GPU 训练优化实例：通常会过度配置且成本效率低下，无法满足稳定的推理需求。

endpoint は CPU 依存であり、ディープ ラーニング トランスフォーマーとして機能するため、推論に最適化されたファミリは、サポートされているフレームワークの 1 ドルあたりのレイテンシを改善するのに最適です。Model Monitor 処理ジョブは、CPU 使用率が低い場合のメモリ枯渇が原因で失敗するため、OOM を防止して夜間の実行を安定させるには、メモリ最適化ファミリが最適です。 インスタンス ファミリの選択は、監視データで観察される主要なリソースのボトルネックに従う必要があります。ディープ ラーニング モデルのリアルタイム推論の場合、推論に最適化されたインスタンス (Inferentia ベースの選択肢など) は、モデル/フレームワークがサポートされている場合に汎用 CPU インスタンスよりもコストあたりのスループット/レイテンシが向上するように専用に構築されています。CPU 使用率が低いままメモリ不足でクラッシュするバッチ スタイルの監視ジョブの場合、制限要因は RAM であるため、メモリ最適化インスタンスが適切です。 実際的なアプローチは次のとおりです。 - CloudWatch/endpoint メトリクスを使用して、推論がコンピューティング/アクセラレータに依存しているかどうかを特定します。 - CloudWatch メモリ/OS ログを処理に使用して、RAM 圧力を確認します。 - ボトルネックとなっている寸法のみを変更してから再測定してください。 コンピューティング最適化は、CPU が制約となる場合に役立ちます。RAM に起因する障害は修正されません。 - OK endpoint を推論最適化に移行します。ディープ ラーニングの提供効率を目標にし、レイテンシー/コストを削減します。 - OK 監視処理ジョブをメモリ最適化に移動します。使用可能な RAM を増やして OOM を排除します。 - いいえ endpoint をメモリ最適化に移動します。RAM は追加されますが、推論の高速化/スループットには対応しません。 - いいえ 処理ジョブをコンピューティング最適化に移動します。CPU は増加しますが、メモリのボトルネックは残ります。 - いいえ 両方を汎用に移行します。増分的である可能性がありますが、特定のボトルネックを直接解決するものではありません。 - いいえ endpoint を GPU トレーニングに最適化されたインスタンスに移動します。通常、安定した推論のニーズに対してオーバープロビジョニングされ、コスト効率が低くなります。

The steps to avoid are the ones that break explicit constraints: protecting PII and preventing data leakage across the existing train/validation/test split. Computing imputation statistics across all splits contaminates the holdout sets and biases evaluation. Sending raw PII outside the AWS account violates the security requirement. Good data cleaning improves training quality only if it preserves security boundaries and the validity of model evaluation. In this scenario, two explicit rules apply: PII must stay inside the AWS account, and the existing train/validation/test split must remain a true holdout. Practical guardrails: - Compute any data-driven transforms (imputation values, outlier caps) using the training split only, then apply the fitted transform to validation/test. - Keep deduplication and other cleaning inside AWS services (for example, SageMaker Processing/Data Wrangler, AWS Glue) against data stored in private, encrypted S3. A common failure mode is “peeking” at validation/test when choosing cleaning parameters, which silently turns the evaluation into a training artifact. - Leakage via preprocessing is introduced when imputation is fit using all splits, making metrics unreliable. - PII exfiltration occurs if raw data is sent to a third-party dedup tool, violating the stated policy. - Train-only fitting for imputers and IQR thresholds is acceptable because it preserves holdout integrity. - In-account dedup and missingness indicators are acceptable cleaning steps that can improve signal without breaking the constraints.

要避免的步骤是打破明确约束的步骤：保护 PII 并防止在现有的训练/验证/测试拆分中出现 data leakage。计算所有分割的插补统计数据会污染保留集并导致评估偏差。将原始 PII 发送到 AWS 账户之外违反了安全要求。 只有保持安全边界和模型评估的有效性，良好的数据清理才能提高训练质量。在这种情况下，适用两个明确的规则：PII 必须保留在 AWS 账户内，并且现有的训练/验证/测试拆分必须保持真正的保留。 实用护栏： - 仅使用训练分割计算任何数据驱动的变换（插补值、离群值上限），然后将拟合变换应用于验证/测试。 - 针对存储在私有加密 S3 中的数据，在 AWS 服务（例如，SageMakerprocessing/Data Wrangler、AWS Glue）内保留重复数据删除和其他清理。 一种常见的失败模式是在选择清洁参数时“偷看”验证/测试，这会默默地将评估变成训练工件。 - 当使用所有分割进行插补时，会通过预处理引入泄漏，从而使指标不可靠。 - 如果将原始数据发送到第三方重复数据删除工具，违反规定的政策，就会发生 PII 泄露。 - 仅训练拟合输入器和 IQR 阈值是可以接受的，因为它保留了保留完整性。 - 账户内重复数据删除和缺失指标是可接受的清理步骤，可以在不破坏约束的情况下改善信号。

避けるべきステップは、明示的な制約を破るステップです。つまり、PII を保護し、既存のトレーニング/検証/テスト分割全体で data leakage を防止します。すべての分割にわたって代入統計を計算すると、ホールドアウト セットが汚染され、評価に偏りが生じます。生の PII を AWS アカウントの外に送信すると、セキュリティ要件に違反します。 適切なデータ クリーニングは、セキュリティ境界とモデル評価の妥当性を維持する場合にのみ、トレーニングの品質を向上させます。このシナリオでは、2 つの明示的なルールが適用されます。PII は AWS アカウント内に留まる必要があり、既存のトレーニング/検証/テスト分割は真のホールドアウトのままでなければなりません。 実用的なガードレール: - トレーニング分割のみを使用してデータ駆動型変換 (代入値、外れ値の上限) を計算し、適合した変換を検証/テストに適用します。 - プライベートの暗号化された S3 に保存されたデータに対して、AWS サービス (SageMaker Processing/Data Wrangler、AWS Glue など) 内で重複排除やその他のクリーニングを維持します。 一般的な失敗モードは、クリーニング パラメータを選択する際の検証/テストでの「覗き見」です。これにより、評価がトレーニング成果物に静かに変換されます。 - すべての分割を使用して代入が適合する場合、前処理による漏れが発生し、メトリクスの信頼性が低くなります。 - PII の流出は、規定のポリシーに違反して、生データがサードパーティの重複排除ツールに送信された場合に発生します。 - インピューターと IQR しきい値のトレーニングのみのフィッティングは、ホールドアウトの整合性が維持されるため許容されます。 - アカウント内の重複排除および欠落インジケーターは、制約を破ることなく信号を改善できる許容可能なクリーニング手順です。

Avoid practices that mutate release artifacts in place or bypass gated promotion. Immutable, versioned artifacts (S3 version IDs and image digests) plus an approval-controlled pipeline enable repeatable deployments and exact rollback. Direct, automated promotion from training to production violates controlled promotion requirements. Safe model releases on SageMaker rely on deploying immutable, uniquely versioned artifacts and promoting them through a controlled process. If you overwrite a model artifact at a fixed S3 key, the endpoint may still “point” to the same location while the bytes change, making audits and rollbacks ambiguous. Similarly, letting the training role update the production endpoint directly removes the required approval gate and mixes build and release responsibilities. A typical low-risk pattern is: - Register a new model package version (including S3 artifact version ID and image digest). - Require approval in the Model Registry (or a manual approval action in CI/CD). - Deploy via a pipeline using a new EndpointConfig, then shift traffic (canary/blue-green) with fast rollback. The key takeaway is that promotion should be gated, and references should be to immutable versions—not mutable “latest” locations. - Registry-based promotion is acceptable because it provides versioning plus an approval gate before production. - Blue/green traffic shifting is acceptable because it reduces blast radius and supports quick rollback. - Pinning image digests and S3 version IDs is acceptable because it guarantees artifact immutability for repeatable releases.

避免就地改变发布工件或绕过门控升级的做法。不可变的版本化工件（S3 版本 ID 和映像摘要）加上审批控制的管道可实现可重复部署和精确回滚。从培训到生产的直接、自动化升级违反了受控的升级要求。 SageMaker 上的安全模型发布依赖于部署不可变的、唯一版本化的工件并通过受控流程推广它们。如果您在固定的 S3 键处覆盖模型工件，则在字节更改时，endpoint 可能仍“指向”同一位置，从而使审核和回滚变得不明确。同样，让培训角色更新生产 endpoint 直接消除了所需的审批门并混合了构建和发布职责。 典型的低风险模式是： - 注册新的模型包版本（包括 S3 工件版本 ID 和图像摘要）。 - 需要 Model Registry 中的批准（或 CI/CD 中的手动批准操作）。 - 使用新的 EndpointConfig 通过管道进行部署，然后通过快速回滚转移流量（金丝雀/蓝绿）。 关键的一点是，促销应该受到限制，并且引用应该是不可变的版本，而不是可变的“最新”位置。 - 基于注册表的升级是可以接受的，因为它提供版本控制以及生产前的批准门。 - 蓝/绿流量转移是可以接受的，因为它减少了爆炸半径并支持快速回滚。 - 固定图像摘要和 S3 版本 ID 是可以接受的，因为它保证了可重复发布的工件不变性。

リリースアーティファクトをその場で変更したり、ゲートされたプロモーションをバイパスしたりするプラクティスは避けてください。不変のバージョン管理されたアーティファクト (S3 バージョン ID とイメージ ダイジェスト) に加え、承認制御されたパイプラインにより、反復可能なデプロイメントと正確なロールバックが可能になります。トレーニングから本番までの直接的な自動プロモーションは、制御されたプロモーション要件に違反します。 SageMaker での安全なモデルのリリースは、不変で独自にバージョン管理されたアーティファクトをデプロイし、制御されたプロセスを通じてプロモーションすることに依存しています。固定 S3 キーでモデル アーティファクトを上書きすると、バイトが変更される間も endpoint が同じ場所を「ポイント」する可能性があり、監査とロールバックがあいまいになります。同様に、トレーニングの役割に本番環境の endpoint を更新させると、必要な承認ゲートが直接削除され、ビルドとリリースの責任が混合されます。 典型的な低リスクのパターンは次のとおりです。 - 新しいモデル パッケージ バージョンを登録します (S3 アーティファクト バージョン ID とイメージ ダイジェストを含む)。 - Model Registry での承認が必要です (または CI/CD での手動承認アクション)。 - 新しい EndpointConfig を使用してパイプライン経由でデプロイし、高速ロールバックでトラフィック (カナリア/ブルーグリーン) をシフトします。 重要な点は、プロモーションには制限を設ける必要があり、参照は変更可能な「最新」の場所ではなく、不変のバージョンを参照する必要があるということです。 - レジストリ ベースのプロモーションは、バージョン管理と運用前の承認ゲートを提供するため、許容されます。 - 青/緑のトラフィックのシフトは、爆発範囲を縮小し、迅速なロールバックをサポートするため、許容されます。 - イメージ ダイジェストと S3 バージョン ID の固定は、反復可能なリリースに対するアーティファクトの不変性を保証するため許容されます。

In SageMaker Model Registry, approval status is a governance control that gates promotion, but it does not perform deployments by itself. You must wire approval-state changes to an explicit deployment action (for example, a pipeline stage) to update staging or production endpoints. SageMaker Model Registry provides a centralized place to version models (model packages) and apply an approval gate using ModelApprovalStatus (for example, PendingManualApproval to Approved). The approval state is used to control when automation is allowed to promote a model, but it does not automatically modify running infrastructure. A typical high-level promotion flow is: - Training pipeline registers a new model package version in a model package group as PendingManualApproval. - A reviewer updates the model package to Approved. - Automation (for example, EventBridge CodePipeline/Step Functions) detects the approval and runs deployment steps to create/update the endpoint. Key takeaway: approval is a gate; promotion/deployment still requires an orchestrated action. - Manual approval gate using PendingManualApproval/Approved is the standard way to block promotion until review. - Event-driven CI/CD is valid because model package state-change events can start an automated deployment workflow. - Least-privilege approvals are recommended by limiting who can update approval status and auditing via CloudTrail. - Auto-deploy misconception fails because approval does not automatically update endpoints; a pipeline must perform the deployment.

在 SageMaker Model Registry 中，审批状态是一种控制晋升的治理控制，但它本身并不执行部署。您必须将批准状态更改连接到显式部署操作（例如，管道阶段）以更新暂存或生产端点。 SageMaker Model Registry 提供了一个集中位置来版本模型（模型包）并使用 ModelApprovalStatus 应用批准门（例如，将 PendingManualApproval 更改为 Approved）。批准状态用于控制何时允许自动化推广模型，但它不会自动修改正在运行的基础设施。 典型的高层晋升流程是： - 训练管道在模型包组中将新的模型包版本注册为 PendingManualApproval。 - 审阅者将模型包更新为“已批准”。 - 自动化（例如，EventBridge CodePipeline/Step Functions）检测批准并运行部署步骤来创建/更新 endpoint。 要点：批准是一道门；推广/部署仍然需要精心策划的行动。 - 使用 PendingManualApproval/Approved 的手动审批门是在审核之前阻止升级的标准方法。 - 事件驱动的 CI/CD 是有效的，因为模型包状态更改事件可以启动自动化部署工作流程。 - 通过限制谁可以通过 CloudTrail 更新批准状态和审核来建议最低权限批准。 - 自动部署错误概念失败，因为批准不会自动更新端点；管道必须执行部署。

SageMaker Model Registry では、承認ステータスは昇格を制御するガバナンス制御ですが、それ自体で展開を実行するわけではありません。ステージングまたは運用エンドポイントを更新するには、承認状態の変更を明示的なデプロイメント アクション (パイプライン ステージなど) に結び付ける必要があります。 SageMaker Model Registry は、モデル (モデル パッケージ) をバージョン化し、ModelApprovalStatus を使用して承認ゲートを適用するための集中的な場所を提供します (たとえば、PendingManualApproval から Approved へ)。承認状態は、自動化によるモデルのプロモートをいつ許可するかを制御するために使用されますが、実行中のインフラストラクチャは自動的に変更されません。 一般的なプロモーション フローの大まかな流れは次のとおりです。 - トレーニング パイプラインは、新しいモデル パッケージ バージョンをモデル パッケージ グループに PendingManualApproval として登録します。 - レビュー担当者がモデル パッケージを承認済みに更新します。 - 自動化 (例: EventBridge) CodePipeline/Step Functions) は承認を検出し、展開手順を実行して endpoint を作成/更新します。 重要なポイント: 承認はゲートです。プロモーション/展開には依然として調整されたアクションが必要です。 - PendingManualApproval/Approved を使用した手動承認ゲートは、レビューまで昇格をブロックする標準的な方法です。 - モデル パッケージの状態変更イベントにより自動化されたデプロイ ワークフローを開始できるため、イベント ドリブン CI/CD は有効です。 - 承認ステータスを更新できるユーザーを制限し、CloudTrail 経由で監査することにより、最小権限の承認が推奨されます。 - 承認によってエンドポイントが自動的に更新されないため、自動デプロイの誤解は失敗します。パイプラインはデプロイメントを実行する必要があります。

Binary encoding is designed for high-cardinality categorical features because it represents each category using multiple binary digits, producing far fewer columns than one-hot encoding. This avoids the extreme dimensionality and sparsity that one-hot encoding creates for tens of thousands of categories. It also avoids using a single integer code that can imply a misleading order. For nominal categorical features, the main trade-off is between representational fidelity and feature dimensionality. One-hot encoding is typically preferred for low-cardinality nominal features because it does not introduce any artificial ordering, but it scales poorly as cardinality grows (it creates one column per category). Label encoding maps categories to a single integer column, which can introduce an arbitrary numeric ordering that is not meaningful for nominal data and can mislead many model types. Binary encoding is a practical compromise for high-cardinality features: it converts the category index into a binary representation spread across multiple columns, drastically reducing the number of generated features compared with one-hot while still representing distinct categories. When cardinality is very large and the model is sensitive to input dimensionality, binary encoding is often the better fit than one-hot. - One-hot for high cardinality creates an extremely wide sparse matrix with one column per unique customer_id. - Single integer codes can inject an arbitrary ordering into a nominal feature. - Raw strings as features are not directly usable by typical linear model training algorithms without transformation.

二进制编码是为高基数分类特征而设计的，因为它使用多个二进制数字表示每个类别，产生的列比 one-hot 编码少得多。这避免了 one-hot 编码为数万个类别创建的极端维度和稀疏性。它还避免使用可能暗示误导性顺序的单个整数代码。 对于名义分类特征，主要的权衡是在表征保真度和特征维度之间。 One-hot 编码通常适用于低基数名义特征，因为它不会引入任何人工排序，但随着基数的增长，它的扩展性很差（它为每个类别创建一列）。标签编码将类别映射到单个整数列，这可能会引入对标称数据没有意义的任意数字排序，并且可能会误导许多模型类型。 二进制编码是高基数特征的一种实用折衷方案：它将类别索引转换为分布在多个列上的二进制表示，与 one-hot 相比，大大减少了生成的特征数量，同时仍然表示不同的类别。 当基数非常大并且模型对输入维度敏感时，二进制编码通常比 one-hot 更适合。 - 高基数的 One-hot 创建一个极宽的稀疏矩阵，每个唯一的 customer_id 一列。 - 单个整数代码可以将任意顺序注入标称特征中。 - 原始字符串作为特征不能直接被典型的线性模型训练算法使用而不进行转换。

バイナリ エンコーディングは、複数のバイナリ数字を使用して各カテゴリを表し、ワンホット エンコーディングよりもはるかに少ない列を生成するため、高カーディナリティのカテゴリ特徴用に設計されています。これにより、ワンホット エンコーディングによって数万のカテゴリに生じる極端な次元性と希薄性が回避されます。また、誤解を招く注文を暗示する可能性のある単一の整数コードの使用も回避します。 名目上のカテゴリ特徴の場合、主なトレードオフは表現の忠実度と特徴の次元の間です。 ワンホット エンコーディングは、人為的な順序付けが導入されないため、カーディナリティが低い公称特徴に対して通常好まれますが、カーディナリティが増加するにつれて拡張性が低くなります (カテゴリごとに 1 つの列が作成されます)。ラベル エンコーディングはカテゴリを 1 つの整数列にマップします。これにより、公称データには意味のない任意の数値順序が導入され、多くのモデル タイプに誤解を招く可能性があります。 バイナリ エンコーディングは、カーディナリティの高い特徴を現実的に妥協したものです。カテゴリ インデックスを複数の列にまたがるバイナリ表現に変換し、個別のカテゴリを表現しながら、ワンホットと比較して生成される特徴の数を大幅に削減します。 カーディナリティが非常に大きく、モデルが入力次元の影響を受けやすい場合、多くの場合、ワンホットよりもバイナリ エンコードの方が適しています。 - 高カーディナリティのワンホットでは、一意の customer_id ごとに 1 つの列を持つ非常に幅の広い疎行列が作成されます。 - 単一の整数コードは、公称特徴に任意の順序を挿入できます。 - 特徴としての生の文字列は、変換せずに一般的な線形モデル トレーニング アルゴリズムで直接使用することはできません。

The unsafe statement is the one that recommends embedding an API token in a container image or source repository. Secrets should be stored in a managed secrets service (such as AWS Secrets Manager) and retrieved at runtime using least-privilege IAM permissions. This supports rotation, reduces accidental exposure, and improves auditability. For ML workflows, credentials for data sources (for example, RDS) and third-party integrations (for example, labeling APIs) should be kept out of code, images, and configuration files that are broadly readable. AWS Secrets Manager (or an equivalent managed store) is designed for storing secrets encrypted with AWS KMS, controlling access with IAM, auditing access with AWS CloudTrail, and supporting automated rotation. A secure pattern is: - Store each credential as a secret and encrypt it with KMS. - Grant only the SageMaker job/pipeline role permission to read the specific secret. - Retrieve the secret value at runtime (and cache only as needed). - Enable rotation where supported so the current value is fetched without redeploying artifacts. The key takeaway is to avoid hardcoding credentials anywhere they could be copied, scanned, or baked into immutable artifacts. - Runtime secret retrieval is an approved pattern when IAM permissions are scoped to the specific secret. - Secrets rotation is a core reason to use Secrets Manager for credentials that must change periodically. - Least privilege and auditing with IAM/KMS controls and CloudTrail supports compliance and incident response.

不安全声明是建议在容器映像或源存储库中嵌入 API 令牌的声明。密钥应存储在托管密钥服务（例如 AWS Secrets Manager）中，并在运行时使用最低权限 IAM 权限进行检索。这支持轮换、减少意外暴露并提高可审核性。 对于 ML 工作流程，数据源（例如 RDS）和第三方集成（例如标签 API）的凭据应远离具有广泛可读性的代码、图像和配置文件。 AWS Secrets Manager（或等效的托管存储）旨在存储使用 AWS KMS 加密的密钥、使用 IAM 控制访问、使用 AWS CloudTrail 审核访问以及支持自动轮换。 安全模式是： - 将每个凭证存储为秘密并使用 KMS 对其进行加密。 - 仅授予 SageMaker 作业/管道角色读取特定密钥的权限。 - 在运行时检索秘密值（并仅根据需要进行缓存）。 - 在支持的情况下启用旋转，以便在不重新部署工件的情况下获取当前值。 关键要点是避免在任何可以复制、扫描或烘焙成不可变工件的地方对凭证进行硬编码。 - 当 IAM 权限范围仅限于特定机密时，运行时机密检索是一种批准的模式。 - 秘密轮换是将 Secrets Manager 用于必须定期更改的凭证的核心原因。 - IAM/KMS 控制和 CloudTrail 的最小权限和审核支持合规性和事件响应。

安全でないステートメントは、API トークンをコンテナー イメージまたはソース リポジトリに埋め込むことを推奨するステートメントです。シークレットは、マネージド シークレット サービス (AWS Secrets Manager など) に保存し、実行時に最小権限の IAM アクセス許可を使用して取得する必要があります。これにより回転がサポートされ、偶発的な露出が減り、可聴性が向上します。 ML ワークフローの場合、データ ソース (RDS など) およびサードパーティ統合 (ラベル付け API など) の認証情報は、広範囲に読み取り可能なコード、画像、構成ファイルに含めないようにする必要があります。AWS Secrets Manager (または同等の管理ストア) は、AWS KMS で暗号化されたシークレットを保存し、IAM でアクセスを制御し、AWS CloudTrail でアクセスを監査し、自動ローテーションをサポートするように設計されています。 安全なパターンは次のとおりです。 - 各資格情報をシークレットとして保存し、KMS で暗号化します。 - 特定のシークレットを読み取る権限を SageMaker ジョブ/パイプライン ロールにのみ付与します。 - 実行時にシークレット値を取得します (必要な場合にのみキャッシュします)。 - サポートされている場合はローテーションを有効にし、アーティファクトを再デプロイせずに現在の値がフェッチされるようにします。 重要な点は、コピー、スキャン、または不変のアーティファクトに焼き付けられる可能性がある場所では、資格情報をハードコーディングしないようにすることです。 - ランタイム シークレットの取得は、IAM 権限のスコープが特定のシークレットに設定されている場合に承認されたパターンです。 - シークレットのローテーションは、定期的に変更する必要がある資格情報に Secrets Manager を使用する主な理由です。 - IAM/KMS 制御による最小権限と監査、および CloudTrail はコンプライアンスとインシデント対応をサポートします。

An operating (decision) threshold converts a model’s probability score into a class label. When false positives are much more expensive than false negatives, the business objective is to reduce false positives, which is achieved by raising the threshold. This increases precision while typically decreasing recall. The operating (decision) threshold is the probability cutoff used to map a classifier’s score to a positive/negative prediction. Changing the threshold does not change the trained model; it changes the precision–recall tradeoff. Given the stated costs, false positives are far more expensive than false negatives, so the deployment should be tuned to avoid predicting “fraud” unless the model is very confident. - Raise the threshold - fewer positives predicted - Fewer false positives - higher precision - More missed fraud cases - lower recall Model-quality techniques (regularization, tuning) and operational tools (drift monitoring) are important, but they do not directly implement the business-driven precision vs. recall choice at inference time. - Lower threshold increases recall but would increase costly false positives under these business costs. - Regularization changes training behavior/generalization, not the inference-time cutoff decision. - Model Monitor helps detect data/model drift, but it does not choose the precision/recall operating point by itself.

操作（决策）阈值将模型的概率得分转换为类别标签。当误报比漏报代价高得多时，业务目标就是减少误报，这是通过提高阈值来实现的。这会提高精确度，同时通常会降低召回率。 操作（决策）阈值是用于将分类器的分数映射到正/负预测的概率截止值。改变阈值不会改变训练好的模型；它改变了精确率与召回率的权衡。 考虑到所规定的成本，误报比误报的成本要高得多，因此应调整部署以避免预测“欺诈”，除非模型非常有信心。 - 提高阈值 - 预测的阳性更少 - 误报更少 - 精度更高 - 更多漏掉的欺诈案件 - 召回率较低 模型质量技术（正则化、调优）和操作工具（漂移监控）很重要，但它们并不能直接实现推理时业务驱动的精度与召回率选择。 - 较低的阈值会增加召回率，但在这些业务成本下会增加代价高昂的误报。 - 正则化改变训练行为/泛化，而不是推理时间截止决定。 - Model Monitor 有助于检测数据/模型漂移，但它本身不选择精度/召回工作点。

動作 (決定) しきい値は、モデルの確率スコアをクラス ラベルに変換します。偽陽性の方が偽陰性よりはるかにコストが高い場合、ビジネス目標は偽陽性を減らすことであり、これはしきい値を上げることで達成されます。これにより精度は向上しますが、通常は再現率が低下します。 動作 (決定) しきい値は、分類子のスコアを陽性/陰性の予測にマッピングするために使用される確率のカットオフです。しきい値を変更しても、トレーニングされたモデルは変更されません。精度と再現率のトレードオフが変わります。 記載されているコストを考慮すると、偽陽性は偽陰性よりもはるかにコストがかかるため、モデルに非常に自信がある場合を除き、「不正」の予測を避けるように展開を調整する必要があります。 - 閾値を上げる - 予測される陽性者数が少なくなる - 誤検知が少なく、精度が高い - 見逃される詐欺事件の増加 - 再現率の低下 モデル品質の手法 (正則化、チューニング) と運用ツール (ドリフト監視) は重要ですが、推論時のビジネス主導の精度と再現率の選択を直接実装するものではありません。 - しきい値を低くするとリコールが増加しますが、これらのビジネスコストの下ではコストのかかる誤検知が増加します。 - 正則化は、推論時間のカットオフの決定ではなく、トレーニングの動作/一般化を変更します。 - Model Monitor はデータ/モデルのドリフトの検出に役立ちますが、精度/リコール動作点をそれ自体で選択することはありません。

Amazon SageMaker Clarify provides bias detection for ML datasets and models. It can compute bias-related metrics by comparing outcomes across sensitive attributes, helping teams assess potential bias in training data before model development. SageMaker Clarify is the SageMaker feature specifically intended to help identify potential bias and explainability concerns. For bias, it analyzes a dataset (such as a training set) by using a chosen sensitive attribute and label/outcome to compute bias metrics that summarize how outcomes differ across groups. This makes it suitable for a pre-training data preparation step to evaluate bias at a high level and decide whether additional data collection, rebalancing, or feature changes are needed. Other SageMaker features focus on data transformation, monitoring production drift/quality, or debugging training behavior rather than quantifying dataset bias metrics. - Data preparation tooling transforms and profiles data but is not the SageMaker bias-metrics feature. - Production monitoring targets data/model quality and drift after deployment, not pre-training dataset bias evaluation. - Training diagnostics help find training issues (like overfitting or performance bottlenecks), not bias metrics.

Amazon SageMaker Clarify 为 ML 数据集和模型提供偏差检测。它可以通过比较敏感属性的结果来计算与偏差相关的指标，帮助团队在模型开发之前评估训练数据中的潜在偏差。 SageMaker Clarify 是 SageMaker 特征，专门用于帮助识别潜在的偏见和可解释性问题。对于偏差，它通过使用选定的敏感属性和标签/结果来分析数据集（例如训练集），以计算总结不同组之间结果差异的偏差指标。这使得它适合预训练数据准备步骤，以在高水平上评估偏差并决定是否需要额外的数据收集、重新平衡或特征更改。 其他 SageMaker 特征侧重于数据转换、监控生产偏差/质量或调试训练行为，而不是量化数据集偏差指标。 - 数据准备工具可转换和分析数据，但不是 SageMaker 偏差指标特征。 - 生产监控的目标是数据/模型质量和部署后的漂移，而不是预训练数据集偏差评估。 - 训练诊断有助于发现训练问题（例如 overfitting 或性能瓶颈），而不是偏差指标。

Amazon SageMaker Clarify は、ML データセットとモデルのバイアス検出を提供します。機密属性間の結果を比較することでバイアス関連の指標を計算できるため、チームがモデル開発前にトレーニング データの潜在的なバイアスを評価するのに役立ちます。 SageMaker Clarify は、潜在的なバイアスと説明可能性に関する懸念を特定するのに役立つことを特に目的とした SageMaker 機能です。バイアスについては、選択した機密属性とラベル/結果を使用してデータセット (トレーニング セットなど) を分析し、グループ間で結果がどのように異なるかを要約するバイアス メトリクスを計算します。これは、高レベルでバイアスを評価し、追加のデータ収集、再バランス、または機能の変更が必要かどうかを決定するためのトレーニング前のデータ準備ステップに適しています。 他の SageMaker 機能は、データセットのバイアス メトリクスを定量化するのではなく、データ変換、本番環境のドリフト/品質のモニタリング、またはトレーニング動作のデバッグに重点を置いています。 - データ準備ツールはデータを変換およびプロファイリングしますが、SageMaker のバイアスメトリクス機能ではありません。 - 実稼働モニタリングは、トレーニング前のデータセットのバイアス評価ではなく、デプロイ後のデータ/モデルの品質とドリフトを対象としています。 - トレーニング診断は、バイアス指標ではなく、トレーニングの問題 (overfitting やパフォーマンスのボトルネックなど) を見つけるのに役立ちます。

Use CI/CD orchestration to automatically build artifacts, execute a managed ML workflow, and promote models into deployment. CodePipeline/CodeBuild automate build and packaging, SageMaker Pipelines automates the train/evaluate workflow, and SageMaker Model Registry enables approval-based promotion and deployment. Together, these minimize manual steps while keeping deployments repeatable and auditable. The goal is an automated, repeatable path from code commit to deployed model. In AWS, a common pattern is to use CI/CD tooling for build automation, SageMaker-native workflow orchestration for training, and a registry/approval mechanism for controlled promotion to deployment. A high-level automated flow is: - Code changes trigger CodePipeline. - CodeBuild builds containers/artifacts and publishes to ECR/S3. - SageMaker Pipelines runs processing training evaluation and produces a model artifact. - The pipeline registers a model package in SageMaker Model Registry. - An approval (automatic or manual) gates deployment of the approved model package to an endpoint. This achieves end-to-end orchestration without relying on humans to kick off each stage. - OK Use CodePipeline and CodeBuild to build/push images to ECR: provides automated build and release orchestration on commits. - OK Use SageMaker Pipelines to orchestrate processing, training, and evaluation: managed workflow for repeatable ML pipelines. - OK Use Model Registry approval to trigger deployment: supports controlled promotion and automated deployment actions. - NO Running Studio notebooks is not a CI/CD orchestration mechanism and is inherently manual. - NO SNS notifications that require engineers to start steps breaks the “minimal manual steps” requirement. - NO Glue interactive sessions are for data processing/ETL, not direct SageMaker endpoint deployment orchestration.

使用 CI/CD 编排自动构建工件、执行托管 ML 工作流程并将模型提升到部署中。 CodePipeline/CodeBuild 自动化构建和打包，SageMaker Pipelines 自动化训练/评估工作流程，SageMaker Model Registry 实现基于批准的升级和部署。总之，这些可以最大限度地减少手动步骤，同时保持部署的可重复性和可审核性。 目标是从代码提交到部署模型的自动化、可重复路径。在 AWS 中，常见的模式是使用 CI/CD 工具进行构建自动化，使用 SageMaker 原生工作流程编排进行培训，并使用注册/批准机制进行受控升级到部署。 高级自动化流程是： - 代码更改触发 CodePipeline。 - CodeBuild 构建容器/工件并发布到 ECR/S3。 - SageMaker Pipelines 运行处理训练评估并生成模型工件。 - 管道在 SageMaker Model Registry 中注册模型包。 - 批准（自动或手动）将批准的模型包部署到 endpoint。 这实现了端到端的编排，而无需依赖人类来启动每个阶段。 - OK 使用 CodePipeline 和 CodeBuild 构建/推送映像到 ECR：在提交时提供自动构建和发布编排。 - OK 使用 SageMaker Pipelines 协调处理、培训和评估：可重复 ML Pipelines 的托管工作流程。 - OK 使用 Model Registry 审批触发部署：支持受控升级和自动化部署操作。 - NO Running Studio 笔记本不是 CI/CD 编排机制，本质上是手动的。 - 没有要求工程师启动步骤的 SNS 通知违反了“最少手动步骤”要求。 - 没有 Glue 交互式会话用于数据处理/ETL，而不是直接的 SageMaker endpoint 部署编排。

CI/CD オーケストレーションを使用して、アーティファクトを自動的に構築し、マネージド ML ワークフローを実行し、モデルをデプロイメントにプロモートします。CodePipeline/CodeBuild はビルドとパッケージ化を自動化し、SageMaker Pipelines はワークフローのトレーニング/評価を自動化し、SageMaker Model Registry は承認ベースのプロモーションと展開を可能にします。これらを組み合わせることで、手動の手順が最小限に抑えられ、導入の再現性と監査性が維持されます。 目標は、コードのコミットからデプロイされたモデルまでの自動化された反復可能なパスです。AWS では、ビルドの自動化には CI/CD ツールを使用し、トレーニングには SageMaker ネイティブのワークフロー オーケストレーションを使用し、デプロイメントへの制御されたプロモーションにはレジストリ/承認メカニズムを使用するのが一般的なパターンです。 高レベルの自動化フローは次のとおりです。 - コード変更により CodePipeline がトリガーされます。 - CodeBuild はコンテナ/アーティファクトを構築し、ECR/S3 に公開します。 - SageMaker Pipelines は処理トレーニング評価を実行し、モデル アーティファクトを生成します。 - パイプラインはモデル パッケージを SageMaker Model Registry に登録します。 - 承認 (自動または手動) により、承認されたモデル パッケージの endpoint への展開がゲートされます。 これにより、各ステージの開始を人間に頼ることなく、エンドツーエンドのオーケストレーションが実現します。 - OK CodePipeline および CodeBuild を使用して、イメージを ECR にビルド/プッシュします。コミット時に自動ビルドおよびリリース オーケストレーションを提供します。 - OK SageMaker Pipelines を使用して処理、トレーニング、評価を調整します。反復可能な ML Pipelines の管理されたワークフローです。 - OK Model Registry 承認を使用して展開をトリガーします。制御されたプロモーションと自動展開アクションをサポートします。 - いいえ Studio ノートブックの実行は CI/CD オーケストレーション メカニズムではなく、本質的に手動です。 - エンジニアにステップの開始を要求する SNS 通知はなく、「最小限の手動ステップ」要件に違反します。 - いいえ Glue インタラクティブ セッションはデータ処理/ETL 用であり、SageMaker endpoint デプロイメント オーケストレーションを直接行うためのものではありません。

Use Amazon EventBridge rules to trigger SageMaker Pipelines for both scheduled and event-driven runs. An EventBridge schedule can start a nightly execution, and an EventBridge S3 object-created event can start execution when new labeled data arrives. This is serverless, auditable, and works with least-privilege IAM roles. For high-level pipeline automation on AWS, Amazon EventBridge is the standard service to define both time-based schedules and event-driven triggers. In this scenario, you can create two EventBridge rules: a cron rule for 1:00 AM UTC and an event pattern rule that matches S3 Object Created events for the labeled-data prefix. Each rule targets either SageMaker directly (where supported) or a small Lambda/Step Functions target that calls sagemaker:StartPipelineExecution using a least-privilege IAM role. This approach is fully managed (no always-on compute), produces audit trails via CloudTrail/EventBridge/Lambda logs, and cleanly supports both trigger types for the same SageMaker Pipeline. - Always-on scheduler running an EC2 cron job violates the cost/ops requirement for no long-lived servers. - S3 lifecycle rules are for object management/expiration and are not an event trigger for SageMaker Pipeline executions. - Repo-only webhook triggers on code changes, not nightly schedules or S3 data arrival, so it misses required triggers. Continue in the web appUse IT Mastery for interactive AWS MLA-C01 practice with mixed sets, timed mocks, topic drills, explanations, and progress tracking. Try AWS MLA-C01 on Web Share this guide: {const e=this.textContent;this.textContent="Copied",setTimeout(()=>{this.textContent=e},1200)}):window.prompt("Copy link:",this.dataset.copyUrl),!1'>Copy link · LinkedIn · Email · Reddit IT Mastery Start Free Practice Exam practice on WebUse the web app for Free Practice Exam topic drills, timed mock exams, scenario-based questions, detailed explanations, and saved progress. Original IT Mastery practice only; not official questions, copied live-exam content, or exam dumps. Open in IT Mastery View plans & pricesFree preview Included No purchase required Full practice bank 2,604 questions in this bank All included with Premium Premium access: A subscription or access pass includes this entire bank and every other IT Mastery practice bank while your access is active. Current alignment Mapped to the current vendor blueprint, domains, services, task statements, and skill areas where published. Practice modes Use topic drills, timed mocks, code or scenario practice, and focused pages before deeper mixed practice. Teaching explanations Explanations teach the service choice, configuration trade-off, command behavior, or troubleshooting rule behind the answer. Stable bank Questions are prebuilt and reviewed before publication, so practice is stable and inspectable, not improvised during a quiz. Scenario Guide Updates & Feedback Browse Practice Tests & Interview Prep - AIF-C01 - Cheat Sheet - Study Plan - Exam Blueprint - Scenario Guide - Free Practice Exam - Updates & Feedback - Official Resources - AIP-C01 - Cheat Sheet - Study Plan - Exam Blueprint - Scenario Guide - Free Practice Exam - Updates & Feedback - Official Resources - CLF-C02 - Cheat Sheet - Study Plan - Exam Blueprint - Scenario Guide - Free Practice Exam - Updates & Feedback - Official Resources - DEA-C01 - Cheat Sheet - Study Plan - Exam Blueprint - Scenario Guide - Free Practice Exam - Updates & Feedback - Official Resources - MLA-C01 - Cheat Sheet - Study Plan - Exam Blueprint - Scenario Guide - Free Practice Exam - Updates & Feedback - Official Resources - SAA-C03 - Cheat Sheet - Study Plan - Exam Blueprint - Scenario Guide - Free Practice Exam - Updates & Feedback - Official Resources - SCS-C03 - Cheat Sheet - Study Plan - Exam Blueprint - Scenario Guide - Free Practice Exam - Updates & Feedback - Official Resources - SOA-C03 - Cheat Sheet - Study Plan - Exam Blueprint - Scenario Guide - Free Practice Exam - Updates & Feedback - Official Resources Mastery Exam Prep - Mastery Exam Prep is built and operated by Tokenizer Inc., a Canadian software and education company. Text-first, practice-driven exam study tools with realistic exam-style questions and clear explanations. Navigate - Support - Email updates - Feedback / Request an exam - FAQ - Methodology - Why Mastery - Author Page - About Us For Organizations - Institutional Access - Training Providers - Referral Partners Legal - Privacy Policy - Terms of Service - Trademarks & Disclaimer Get the AppsWeb Apps, Login & Installs - Finance Prep — Securities, insurance, mortgage, real estate & accounting App Store (Canada) · App Store (U.S.) · Google Play (Canada) · Google Play (U.S.) · Web App · Login · Finance exam pages - IT Mastery — Cloud & IT certifications App Store · Google Play · Web App · Login - PM Mastery — Project management & agile App Store · Google Play · Web App · Login Use these links for web access, subscriber login, and mobile installs. Each app supports web and mobile access with the same account. - Finance Prep Web app · Login · Exams - IT Mastery Web app · Login · Exams - PM Mastery Web app · Login · Exams Open the apps page for App Store and Google Play installation links. © 2026 Tokenizer Inc. (Canada) (function(){var r=20,h=.5,l=60,c=.8,o=!1,i=!1,s=!1,e=document.visibilityState==="visible"?Date.now():null,a=0;function n(){if(window.gtag)try{gtag.apply(null,arguments)}catch{}}function d(){return(a+(e?Date.now()-e:0))/1e3}function u(){var e=document.documentElement,t=document.body,n=e.scrollTop||t.scrollTop,s=Math.max(e.scrollHeight-e.clientHeight,1);return n/s}function t(){var e=d(),t=u();!o&&(s||e>=r&&t>=h)&&(o=!0,n("event","qualified_view",{page_location:location.href,visible_seconds:Math.round(e),depth:Math.round(t*100),site:"Mastery"})),!i&&e>=l&&t>=c&&(i=!0,n("event","deep_read",{page_location:location.href,visible_seconds:Math.round(e),depth:Math.round(t*100),site:"Mastery"}))}document.addEventListener("visibilitychange",function(){document.visibilityState==="visible"?e=Date.now():e&&(a+=Date.now()-e,e=null),t()}),window.addEventListener("scroll",t,{passive:!0}),document.addEventListener("click",function(e){var o=e.target.closest("a[data-cta]");if(!o)return;s=!0,n("event","cta_click",{id:o.getAttribute("data-cta")||"unknown",page_location:location.href,site:"Mastery"}),t()},{capture:!0}),setInterval(t,1e3),document.visibilityState==="visible"&&(e=Date.now()),t()})()

使用 Amazon EventBridge 规则为计划运行和事件驱动运行触发 SageMaker Pipelines。 EventBridge 计划可以开始夜间执行，而 EventBridge S3 对象创建的事件可以在新标记数据到达时开始执行。这是无服务器的、可审计的，并且适用于最低权限的 IAM 角色。 对于 AWS 上的高级管道自动化，Amazon EventBridge 是定义基于时间的计划和事件驱动的触发器的标准服务。在此场景中，您可以创建两个 EventBridge 规则：UTC 凌晨 1:00 的 cron 规则和与标记数据前缀的 S3 对象创建事件匹配的事件模式规则。每个规则直接针对 SageMaker（如果支持）或使用最低权限 IAM 角色调用 sagemaker:StartPipelineExecution 的小型 Lambda/Step Functions 目标。 此方法是完全托管的（没有始终在线的计算），通过 CloudTrail/EventBridge/Lambda 日志生成审计跟踪，并且完全支持同一 SageMaker Pipeline 的两种触发器类型。 - 运行 EC2 cron 作业的始终在线调度程序违反了无长期服务器的成本/操作要求。 - S3 生命周期规则用于对象管理/过期，而不是 SageMaker Pipeline 执行的事件触发器。 - 仅存储库 Webhook 在代码更改时触发，而不是在夜间计划或 S3 数据到达时触发，因此它会错过所需的触发器。 在 Web 应用程序中继续使用 IT Mastery 进行交互式 AWS MLA-C01 练习，包括混合组、定时模拟、主题练习、解释和进度跟踪。 在 Web 上试用 AWS MLA-C01 分享本指南： {const e=this.textContent;this.textContent="Copied",setTimeout(()=>{this.textContent=e},1200)}):window.prompt("复制链接：",this.dataset.copyUrl),!1'>复制链接 · LinkedIn · 电子邮件 · Reddit 精通信息技术 在网络上开始免费模拟考试练习使用网络应用程序进行免费模拟考试主题练习、定时模拟考试、基于场景的问题、详细解释和保存的进度。仅用于原始 IT 掌握练习；不是官方问题、复制的现场考试内容或考试转储。 在 IT 精通中打开 查看计划和价格免费预览 包括 无需购买 完整的实践银行 2,604 在这家银行的问题 全部包含在高级版中 高级访问：当您的访问处于活动状态时，订阅或访问通行证包括整个银行和所有其他 IT Mastery 实践银行。 当前对齐方式 映射到当前发布的供应商蓝图、领域、服务、任务声明和技能领域。 练习模式 在进行更深入的混合练习之前，使用主题练习、定时模拟、代码或场景练习以及重点页面。 教学讲解 解释教导答案背后的服务选择、配置权衡、命令行为或故障排除规则。 稳定的银行 问题是在发布之前预先构建和审查的，因此练习是稳定且可检查的，而不是在测验期间即兴发挥。 场景指南 更新与反馈 浏览模拟测试和面试准备 - AIF-C01 - 备忘单 - 学习计划 - 考试蓝图 - 场景指南 - 免费模拟考试 - 更新和反馈 - 官方资源 - AIP-C01 - 备忘单 - 学习计划 - 考试蓝图 - 场景指南 - 免费模拟考试 - 更新和反馈 - 官方资源 - CLF-C02 - 备忘单 - 学习计划 - 考试蓝图 - 场景指南 - 免费模拟考试 - 更新和反馈 - 官方资源 - DEA-C01 - 备忘单 - 学习计划 - 考试蓝图 - 场景指南 - 免费模拟考试 - 更新和反馈 - 官方资源 - MLA-C01 - 备忘单 - 学习计划 - 考试蓝图 - 场景指南 - 免费模拟考试 - 更新和反馈 - 官方资源 - SAA-C03 - 备忘单 - 学习计划 - 考试蓝图 - 场景指南 - 免费模拟考试 - 更新和反馈 - 官方资源 - SCS-C03 - 备忘单 - 学习计划 - 考试蓝图 - 场景指南 - 免费模拟考试 - 更新和反馈 - 官方资源 - SOA-C03 - 备忘单 - 学习计划 - 考试蓝图 - 场景指南 - 免费模拟考试 - 更新和反馈 - 官方资源 掌握考试准备 - Mastery Exam Prep 由加拿大软件和教育公司 Tokenizer Inc. 构建和运营。以文本为先、以实践为导向的考试学习工具，具有真实的考试式问题和清晰的解释。 导航 - 支持 - 电子邮件更新 - 反馈/请求考试 - 常问问题 - 方法论 - 为什么要精通 - 作者页面 - 关于我们 对于组织 - 机构准入 - 培训机构 - 推荐合作伙伴 合法的 - 隐私政策 - 服务条款 - 商标和免责声明 获取应用程序网络应用程序、登录和安装 - 金融预科——证券、保险、抵押贷款、房地产和会计 应用商店（加拿大） · 应用商店（美国） · Google Play（加拿大） · Google Play（美国） · 网页应用程序 · 登录 · 金融考试页面 - IT 精通 — 云和 IT 认证 应用商店 · 谷歌游戏 · 网页应用程序 · 登录 - PM 掌握 — 项目管理和敏捷 应用商店 · 谷歌游戏 · 网页应用程序 · 登录 使用这些链接进行网络访问、订阅者登录和移动安装。每个应用程序都支持使用同一帐户进行网络和移动访问。 - 财务准备 网络应用程序 · 登录 · 考试 - 精通信息技术 网络应用程序 · 登录 · 考试 - 下午掌握 网络应用程序 · 登录 · 考试 打开 App Store 和 Google Play 安装链接的应用页面。 © 2026 Tokenizer Inc.（加拿大） (function(){var r=20,h=.5,l=60,c=.8,o=!1,i=!1,s=!1,e=document.visibilityState==="visible"?Date.now():null,a=0;function n(){if(window.gtag)try{gtag.apply(null,arguments)}catch{}}函数 d(){return(a+(e?Date.now()-e:0))/1e3}function u(){var e=document.documentElement,t=document.body,n=e.scrollTop||t.scrollTop,s=Math.max(e.scrollHeight-e.clientHeight,1);return n/s}function t(){var e=d(),t=u();!o&&(s||e>=r&&t>=h)&&(o=!0,n("event","qualified_view",{page_location:location.href,visible_seconds:Math.round(e),深度:Math.r ound(t*100),site:"精通"})),!i&&e>=l&&t>=c&&(i=!0,n("event","deep_read",{page_location:location.href,visible_seconds:Math.round(e),深度:Math.round(t*100),site:"精通"}))}document.addEventListener("visibilitychange",function(){document.visibilityState==="visible"?e=日期。 now():e&&(a+=Date.now()-e,e=null),t()}),window.addEventListener("scroll",t,{passive:!0}),document.addEventListener("click",function(e){var o=e.target.closest("a[data-cta]");if(!o)return;s=!0,n("event","cta_click",{id:o.getAttribute("data-cta")||"unknown",page_location :location.href,site:"掌握"}),t()},{捕获:!0}),setInterval(t,1e3),document.visibilityState==="可见"&&(e=Date.now()),t()})()

Amazon EventBridge ルールを使用して、スケジュールされた実行とイベント ドリブンの実行の両方で SageMaker Pipelines をトリガーします。EventBridge スケジュールは夜間の実行を開始でき、EventBridge S3 オブジェクト作成イベントは新しいラベル付きデータが到着したときに実行を開始できます。これはサーバーレスで監査可能で、最小特権の IAM ロールで動作します。 AWS での高レベルのパイプライン自動化の場合、Amazon EventBridge は、時間ベースのスケジュールとイベント駆動のトリガーの両方を定義する標準サービスです。このシナリオでは、2 つの EventBridge ルールを作成できます。1 つは UTC 午前 1 時の cron ルール、もう 1 つはラベル付きデータ プレフィックスの S3 オブジェクト作成イベントと一致するイベント パターン ルールです。各ルールは、SageMaker を直接 (サポートされている場合)、または最小権限の IAM ロールを使用して sagemaker:StartPipelineExecution を呼び出す小さな Lambda/Step Functions ターゲットのいずれかをターゲットにします。 このアプローチはフルマネージド (常時稼働コンピューティングなし) であり、CloudTrail/EventBridge/Lambda ログを介して監査証跡を生成し、同じ SageMaker パイプラインの両方のトリガー タイプを明確にサポートします。 - EC2 cron ジョブを実行する常時オンのスケジューラーは、長期間存続するサーバーがない場合のコスト/運用要件に違反します。 - S3 ライフサイクル ルールはオブジェクトの管理/有効期限用であり、SageMaker Pipeline 実行のイベント トリガーではありません。 - リポジトリのみの Webhook は、夜間のスケジュールや S3 データの到着ではなく、コード変更時にトリガーされるため、必要なトリガーが失われます。 ウェブアプリで続行IT Mastery を使用して、混合セット、時間制限付きモック、トピックドリル、説明、進捗状況追跡によるインタラクティブな AWS MLA-C01 練習を行います。 AWS MLA-C01 をウェブで試す このガイドを共有します: {const e=this.textContent;this.textContent="Copied",setTimeout(()=>{this.textContent=e},1200)}):window.prompt("Copy link:",this.dataset.copyUrl),!1'>リンクをコピー · LinkedIn · 電子メール · Reddit ITマスタリー Web で無料模擬試験の練習を開始するWeb アプリを使用して、無料模擬試験のトピックのドリル、時間指定された模擬試験、シナリオベースの質問、詳細な説明、および進行状況の保存を行います。オリジナルの IT マスタリー実践のみ。公式の問題、コピーされたライブ試験コンテンツ、または試験ダンプではありません。 ITマスタリーで開く プランと価格を見る無料プレビュー 付属 購入は必要ありません フルプラクティスバンク 2,604 この銀行に関する質問 すべてプレミアムに含まれています プレミアム アクセス: サブスクリプションまたはアクセス パスには、アクセスが有効な間、この銀行全体と他のすべての IT マスタリー プラクティス バンクが含まれます。 現在のアライメント 現在のベンダー ブループリント、ドメイン、サービス、タスク ステートメント、および公開されているスキル領域にマッピングされます。 練習モード より深く混合した演習を行う前に、トピックのドリル、時間制限付きモック、コードまたはシナリオの演習、および焦点を絞ったページを使用します。 指導説明 説明では、サービスの選択、構成のトレードオフ、コマンドの動作、または答えの背後にあるトラブルシューティングのルールがわかります。 安定した銀行 問題は公開前に事前に作成およびレビューされるため、練習は安定していて検査可能であり、クイズ中に即興で行うことはありません。 シナリオガイド アップデートとフィードバック 模擬テストと面接の準備を閲覧する - AIF-C01 - チートシート - 学習計画 - 試験の青写真 - シナリオガイド - 無料模擬試験 - アップデートとフィードバック - 公式リソース - AIP-C01 - チートシート - 学習計画 - 試験の青写真 - シナリオガイド - 無料模擬試験 - アップデートとフィードバック - 公式リソース - CLF-C02 - チートシート - 学習計画 - 試験の青写真 - シナリオガイド - 無料模擬試験 - アップデートとフィードバック - 公式リソース - DEA-C01 - チートシート - 学習計画 - 試験の青写真 - シナリオガイド - 無料模擬試験 - アップデートとフィードバック - 公式リソース - MLA-C01 - チートシート - 学習計画 - 試験の青写真 - シナリオガイド - 無料模擬試験 - アップデートとフィードバック - 公式リソース - SAA-C03 - チートシート - 学習計画 - 試験の青写真 - シナリオガイド - 無料模擬試験 - アップデートとフィードバック - 公式リソース - SCS-C03 - チートシート - 学習計画 - 試験の青写真 - シナリオガイド - 無料模擬試験 - アップデートとフィードバック - 公式リソース - SOA-C03 - チートシート - 学習計画 - 試験の青写真 - シナリオガイド - 無料模擬試験 - アップデートとフィードバック - 公式リソース マスタリー試験の準備 - Mastery Exam Prep は、カナダのソフトウェアおよび教育会社である Tokenizer Inc. によって構築および運営されています。現実的な試験形式の問題と明確な説明を備えた、テキストファーストの実践中心の試験学習ツールです。 ナビゲート - サポート - 更新情報をメールで送信 - フィードバック / 試験のリクエスト - よくある質問 - 方法論 - なぜマスタリーなのか - 著者ページ - 私たちについて 組織向け - 機関へのアクセス - トレーニングプロバイダー - 紹介パートナー 法律上の - プライバシーポリシー - 利用規約 - 商標と免責事項 アプリを入手ウェブアプリ、ログイン、インストール - 財務の準備 — 証券、保険、住宅ローン、不動産、会計 App Store (カナダ) · App Store (米国) · Google Play (カナダ) · Google Play (米国) · ウェブアプリ · ログイン · 財務試験ページ - IT マスタリー — クラウドおよび IT 認定資格 アプリストア · Googleプレイ · ウェブアプリ · ログイン - PM マスタリー — プロジェクト管理とアジャイル アプリストア · Googleプレイ · ウェブアプリ · ログイン これらのリンクは、Web アクセス、加入者ログイン、モバイル インストールに使用します。各アプリは、同じアカウントによる Web アクセスとモバイル アクセスをサポートします。 - 財務の準備 ウェブアプリ · ログイン · 試験 - ITマスタリー ウェブアプリ · ログイン · 試験 - PMマスタリー ウェブアプリ · ログイン · 試験 App Store および Google Play のインストール リンクのアプリ ページを開きます。 © 2026 Tokenizer Inc. (カナダ) (function(){var r=20,h=.5,l=60,c=.8,o=!1,i=!1,s=!1,e=document.visibilityState==="visible"?Date.now():null,a=0;function n(){if(window.gtag)try{gtag.apply(null,arguments)}catch{}}function d(){return(a+(e?Date.now()-e:0))/1e3}function u(){var e=document.documentElement,t=document.body,n=e.scrollTop||t.scrollTop,s=Math.max(e.scrollHeight-e.clientHeight,1);return n/s}function t(){var e=d(),t=u();!o&&(s||e>=r&&t>=h)&&(o=!0,n("event","qualified_view",{page_location:location.href,visible_seconds:Math.round(e), Depth:Math.r ound(t*100),site:"Mastery"})),!i&&e>=l&&t>=c&&(i=!0,n("event","deep_read",{page_location:location.href,visible_seconds:Math.round(e), Depth :Math.round(t*100),site:"マスタリー"}))}document.addEventListener("visibilitychange",function(){document.visibilityState==="visible"?e=日付。now():e&&(a+=Date.now()-e,e=null),t()}),window.addEventListener("scroll",t,{passive:!0}),document.addEventListener("click",function(e){var o=e.target.closest("a[data-cta]");if(!o)return;s=!0,n("event","cta_click",{id:o.getAttribute("data-cta")||"unknown",page_location :location.href,site:"マスタリー"}),t()},{capture:!0}),setInterval(t,1e3),document.visibilityState==="visible"&&(e=Date.now()),t()})()