AWS What's New Digest

Appearance

2026年08月11日 ​

[SageMaker] AWS Glue adds one-click access to SageMaker Unified Studio from the AWS console ​

概要 ​

AWS Glue コンソールからワンクリックで Amazon SageMaker Unified Studio を開ける連携機能が追加され、Glue カタログのテーブル閲覧からそのまま Studio 上でクエリ実行、データ品質チェック、パイプライン構築などを開始できるようになりました。セットアップ用のインライン権限パネルにより、必要な IAM ポリシーをコンソール内で作成・調整できます。

変更内容・新機能の詳細 ​

今回のアップデートにより、Glue コンソール（および S3 Tables、Athena、EMR、Redshift の各コンソール）から SageMaker Unified Studio をワンクリックで起動できるようになりました。Glue でカタログテーブルを参照中に同一の IAM ロールを使って Studio のノートブックやその他の Studio 機能へ移行でき、データ探索やクエリ実行、データ品質チェック、ML パイプラインの作成をスムーズに開始できます。SageMaker Unified Studio をまだ設定していないアカウント向けに、必要な IAM ポリシーをコンソール内で作成・設定できる「インライン権限パネル」が用意され、IAM コンソールに移動してポリシーを別途作成する手間を削減します。本機能は SageMaker Unified Studio をサポートする全リージョンで利用可能です。なお、Studio 上での処理（ノートブック、トレーニング、処理ジョブ等）は別途 SageMaker の課金対象となります。

影響範囲・利用シーン ​

  • 対象ユーザー: データエンジニア、データアナリスト、ML エンジニア、SRE/運用チーム
  • 利用シーン: Glue カタログのテーブルを参照しながら、ワンクリックで SageMaker Unified Studio を開いてノートブック実行、クエリ、データ品質チェック、パイプライン作成を行うワークフロー
  • 運用効果: コンテキスト切替やブラウザタブの移動、別途 IAM 設定を行う工数が削減され、導入・開始までの時間が短縮される
  • 導入要件: SageMaker Unified Studio のセットアップ（ドメイン／ユーザプロファイル等）と、Glue が参照するデータソース（S3、Redshift、Athena 等）へのアクセス権が必要
  • 制限／注意: SageMaker Unified Studio がサポートされているリージョンのみ利用可。Studio 側の compute／ノートブック等は別途課金

技術的な注意点 ​

  • IAM権限: Glue コンソールから Studio を開くには、Glue ロール／ユーザに SageMaker 関連 API を実行できる権限が必要です。インライン権限パネルでポリシーを作成・変更する場合は iam:CreatePolicy / iam:PutRolePolicy 等の IAM 管理権限が必要になる場合があります。既存ロールを使う際は、ロールの信頼ポリシーが必要なサービスによる sts:AssumeRole を許可していることを確認してください。
  • リージョン制限: 本機能は Amazon SageMaker Unified Studio がサポートされているリージョンで利用可能です。Studio 非対応リージョンでは表示されません。
  • ネットワーク／VPC: Studio のユーザプロファイルが VPC 内で構成されている場合、Glue で参照する S3 バケットや Redshift などへのアクセス経路（VPC エンドポイントやルーティング、セキュリティグループ）が適切に設定されている必要があります。
  • クロスアカウント／データアクセス: データが別アカウントにある場合は適切なクロスアカウントロールやリソースポリシー、Lake Formation の設定が必要です。単に「ワンクリック」で開けてもデータアクセス権限が不足していると操作は失敗します。
  • コスト: Glue／SageMaker（Studio の compute やトレーニング、Processing 等）は別料金です。Studio でノートブックやインスタンスを起動すると課金が発生する点に注意してください。
  • その他: インライン権限パネルは利便性向上だが、組織のガバナンス方針に沿って IAM ポリシーの作成・付与を行ってください。必要に応じて IAM のレビューや変更管理を適用してください。

参考情報 ​

[Secrets Manager] AWS Secrets Manager adds managed external secrets support for Jenkins and SonarQube ​

概要 ​

AWS Secrets Managerは、JenkinsのAPIトークンとSonarQubeのトークンに対するマネージド外部シークレット（managed external secrets）対応を追加しました。コンソールからカスタムローテーションコードを作成せずにこれらのサードパーティ資格情報を自動ローテーションできます。

変更内容・新機能の詳細 ​

Secrets Managerのmanaged external secretsにJenkinsとSonarQubeが新たに対応しました。JenkinsではSecrets Managerが新しいAPIトークンを発行（mint）し、発行後に新しいトークンが有効であることを検証してから古いトークンを取り消す（revoke）ため、CI/CDジョブの中断を防ぎます。ローテーション方式は「セルフローテーション（トークン自身が置換を認証）」と「管理者補助ローテーション（別の管理者トークンでgenerate/revokeを実行）」の両方をサポートします。SonarQubeではWeb APIを用いてUser Tokens、Global Analysis Tokens、Project Analysis Tokensの3種類をローテーション可能で、User Tokensはセルフローテーション、分析用トークンは管理者トークンを用いたローテーションとなります。これらは既存のBigID、Confluent Cloud、Datadog、GitLab、MongoDB Atlas、Okta、Paddle、Salesforce、Snowflake向けのmanaged external secretsサポートに加わる形です。JenkinsとSonarQubeの統合は、Secrets Managerのmanaged external secretsがサポートされている全リージョンで利用可能です。運用側はコンソールまたはAPIでシークレット設定を行うだけで、独自のローテーション実装が不要になります。

影響範囲・利用シーン ​

  • 対象ユーザー: CI/CDチーム、SRE、DevOpsエンジニア、セキュリティ/資格情報管理担当者
  • 利用シーン: JenkinsのAPIトークンやSonarQubeのユーザ・分析用トークンを定期的に自動ローテーションして漏えいリスクを低減する場面（パイプライン認証情報の自動更新、定期的なキー管理）
  • 運用効果: 手動ローテーションやカスタムスクリプトを廃止でき、トークン無効化によるCI/CD停止リスクを低減し、資格情報管理の一元化と監査性を向上させる

技術的な注意点 ​

  • IAM権限: Secrets Manager（例: secretsmanager:RotateSecret, secretsmanager:GetSecretValue, secretsmanager:PutSecretValue, secretsmanager:UpdateSecretVersionStage）およびSecrets Managerの関連APIを呼べる権限が必要です。管理者ローテーション用のトークンを格納するシークレットへのアクセス権も設定してください。
  • リージョン制限: 利用可能なリージョンはAWS Secrets Managerのmanaged external secretsがサポートするリージョンに限定されます（記事で「全サポートリージョンで利用可能」と明記）。
  • ローテーション方式: Jenkinsはセルフローテーションと管理者補助ローテーションをサポート。SonarQubeはUser Tokensがセルフローテーション、Global/Project Analysis Tokensは管理者トークンによるローテーションとなります。
  • トークン/資格情報要件: 管理者補助ローテーションでは管理者用の有効なAPIトークンを事前にSecrets Managerへ登録しておく必要があります。Jenkins/SonarQube側でAPIトークンの生成・取り消しが可能なバージョン・設定であることを確認してください。
  • ネットワーク/接続: Secrets Managerのローテーション処理が対象のJenkins/SonarQubeのAPIエンドポイントに到達できる必要があります。オンプレミスやプライベートVPC内のサービスの場合はVPCエンドポイント、NAT、あるいはプロキシ経由の通信経路を検討してください。
  • コスト: Secrets Managerのシークレット保管・API利用に対する通常の料金が発生します（シークレットごとの月額料金、API呼び出し等）。ローテーション自体で追加のAWSサービス費用が発生する可能性があるため、管理するシークレット数とローテーション頻度を考慮してください。

参考情報 ​

[Connect] Amazon Connect Customer launches performance dashboard for Cases ​

概要 ​

Amazon Connect の Cases に、ケースのボリュームや解決トレンド、SLA達成率などを可視化するパフォーマンスダッシュボードが追加されました。期間比較やテンプレート／担当者／キュー単位での分解分析が可能です。

変更内容・新機能の詳細 ​

このダッシュボードはマネージャー向けに設計され、以下の主要指標を表示・比較します：作成されたケース数、平均解決時間（平均処理時間）、ファーストコンタクト解決率（FCR）、SLA達成率。現在期間と前期間の比較表示により、増減や傾向を把握できます。フィルタ・ドリルダウンはケーステンプレート、割当ユーザー、割当キューといった次元で可能なため、例えば「返金対応のケースで請求チームのSLA未達が増えている」といった具体的な原因調査と改善優先度の判断がしやすくなります。ダッシュボードは Amazon Connect の Cases 機能に統合されており、Cases が有効なアカウントで利用できます。対応リージョンは記事に列挙された通り（US East (N. Virginia)、US West (Oregon)、Canada (Central)、Europe (Frankfurt)、Europe (London)、Asia Pacific (Seoul)、Asia Pacific (Singapore)、Asia Pacific (Sydney)、Asia Pacific (Tokyo)、Africa (Cape Town)）です。利用開始や詳細は Cases の製品ページとドキュメントを参照してください。

影響範囲・利用シーン ​

  • 対象ユーザー: コンタクトセンターのマネージャー、オペレーションリード、SRE/運用チーム
  • 利用シーン: 期間比較によるパフォーマンス把握、特定テンプレートや担当者単位でのボトルネック検出、SLA違反の多い業務プロセスの特定
  • 運用効果: SLA違反の早期発見と原因切り分けが可能になり、対応優先度の決定やプロセス改善による顧客体験向上につながる

技術的な注意点 ​

  • IAM権限: Amazon Connect コンソールへのアクセス権に加え、Cases データの表示／分析に必要な Connect の権限が必要です。組織の最小権限ポリシーを確認してください。
  • リージョン制限: 利用可能リージョンは記事記載のとおりです（US East (N. Virginia)、US West (Oregon)、Canada (Central)、Europe (Frankfurt)、Europe (London)、Asia Pacific (Seoul)、Asia Pacific (Singapore)、Asia Pacific (Sydney)、Asia Pacific (Tokyo)、Africa (Cape Town)）。上記以外のリージョンでは未対応の可能性があります。
  • コスト: 記事ではダッシュボード自体の追加料金は明記されていませんが、Amazon Connect や Cases の利用に伴う通常のサービス料金（記録保持、メトリクス保持、データ転送など）は発生する可能性があります。詳細は料金ページを確認してください。
  • 導入要件: Cases 機能が有効化されている Amazon Connect インスタンスが必要です。既存のケースデータに基づいてメトリクスが生成されるため、ダッシュボード表示には一定量のデータが必要となる場合があります。

参考情報 ​

[Clean Rooms] AWS Clean Rooms supports exporting privacy-enhanced analysis logs for SQL ​

概要 ​

AWS Clean RoomsがSQL解析向けの「プライバシー強化分析ログ」のS3エクスポートをサポートしました。Spark実行の詳細情報をプライバシー保護された形でS3に出力でき、クエリの最適化や障害対応が容易になります。

変更内容・新機能の詳細 ​

今回の機能追加により、AWS Clean Roomsのコラボレーション内で実行されたSQLクエリについて、プライバシー強化（privacy-enhanced）された分析ログを指定したS3バケットへエクスポートできます。ログにはSparkの実行メトリクス（ジョブ/ステージ/タスクの実行時間、データスキュー、シャッフル量など）に関する情報が含まれ、クエリ性能のボトルネック特定やリソース最適化に役立ちます。コラボレーション所有者は、コラボレーション作成時または変更要求（change request）を通じて、メンバーに対して分析ログのエクスポート権限を付与します。クエリ実行後、メンバーは許可されたS3パスへログを出力できます。ログは「プライバシー強化」されているため、基データ（個々のレコード）を露出しないような加工や集約・赤字化が施されている点に留意してください。

影響範囲・利用シーン ​

  • 対象ユーザー: データサイエンティスト、SRE/データエンジニア、パブリッシャーや第三者計測ベンダー
  • 利用シーン: クエリパフォーマンスのボトルネック解析、データスキューやシャッフルオーバーヘッドの特定、コラボレーションにおける問題切り分け
  • 運用効果: 問題の早期検出・解決によりクエリ実行時間とコストを削減可能（例: スキュー検出による再パーティショニングで処理時間短縮）
  • セキュリティ/コンプライアンス: プライバシー強化ログにより解析可能性を維持しつつ共同分析時のデータ漏洩リスクを低減

技術的な注意点 ​

  • IAM権限: コラボレーション所有者がメンバーへエクスポート権限を付与する必要があります。S3へ書き込むための適切なIAMロール/ポリシーとバケットポリシーが必要です
  • S3設定: 出力先S3バケットの暗号化（SSE-S3/SSE-KMS）、バケットポリシー、ライフサイクルやアクセスログ設定を検討してください。KMSを使う場合はKMSキーへのアクセス権を付与する必要があります
  • リージョン制限: AWS Clean Rooms自体のリージョン対応に依存します。使用予定のリージョンで本機能が利用可能かAWS Regions表やドキュメントで確認してください
  • コスト: S3ストレージ、PUTリクエスト、転送コストが発生します。ログ量が多い場合は保管ポリシーでコスト最適化を検討してください。また、分析クエリ実行コスト自体には影響があります
  • ログ内容とプライバシー: ログはSpark実行に関するメタデータ／メトリクスを中心に含みますが、基データそのものは露出しないよう処理されています。プライバシー強化の具体的な処理内容（どのフィールドが除外／集約されるか）はドキュメントで確認してください
  • 運用フロー: エクスポートはクエリ実行後に行うため、事前にS3パスと権限を準備しておく必要があります
  • 監査: 監査目的でのログ保持やアクセス制御の記録（CloudTrail等）を併用すると安全性が向上します

参考情報 ​

[RDS] Amazon RDS for MariaDB now supports MariaDB 12.3 ​

概要 ​

Amazon RDS for MariaDB が MariaDB の長期サポート（LTS）版であるメジャー版 12.3（マイナー 12.3.2）をサポート開始しました。Oracle 互換関数やJSON検証、クエリオプティマイザ改善などが含まれるリリースです。

変更内容・新機能の詳細 ​

RDS for MariaDB が MariaDB 12.3.2 をサポートします。主な技術的追加・改善点は以下の通りです。

  • Oracle TO_DATE() 関数互換性: Oracle から MariaDB へ移行する際にアプリケーション側のコード変更を削減できる互換関数が追加されています（完全互換を保証するものではなく、移行時の検証が必要です）。
  • IS JSON プレディケート: データベース側で JSON ドキュメントのバリデーションを行えるようになり、アプリケーション側での検査やカスタム関数への依存を減らせます。
  • クエリオプティマイザの改善: 再配置可能な LEFT JOIN（reorderable LEFT JOIN）や、RANGE パーティションに対する ordered scan（順序付き走査）の処理が効率化され、該当クエリのパフォーマンスが向上します。これらはアプリケーションの変更なしに恩恵を受けられることが多いです。

RDS 側では、アップグレード方法として Amazon RDS Blue/Green Deployments、インプレースアップグレード、スナップショットからの復元が利用可能です。また、外部の MariaDB からの移行は AWS Database Migration Service (AWS DMS) を使って行えます。詳細は MariaDB のリリースノートおよび RDS の MariaDB リリースノートを参照してください。

影響範囲・利用シーン ​

  • 対象ユーザー: データベース管理者、DBA、アプリケーション開発者（特に Oracle からの移行を検討しているチーム）
  • 利用シーンまたは効果: Oracle 互換関数による移行工数削減、データベースネイティブの JSON 検証によるアプリケーション簡素化、LEFT JOIN や RANGE パーティションを使うクエリのパフォーマンス向上
  • 運用効果: アップグレードで長期サポート版を利用できるため、セキュリティパッチとバグ修正の継続的な受領が可能。Blue/Green を使えばダウンタイムを最小化して移行検証が行える

技術的な注意点 ​

  • IAM権限: アップグレードや Blue/Green 展開、スナップショット復元を行うには適切な RDS/IAM 権限が必要です（rds:ModifyDBInstance、rds:CreateDBInstance、rds:RestoreDBInstanceFromDBSnapshot 等）。
  • リージョン制限: 新しいエンジンバージョンはリージョンによって利用開始時期が異なります。利用可否は AWS マネジメントコンソールかリージョン別ドキュメントで確認してください。
  • コスト: Blue/Green 展開や追加のリソースを使う移行では一時的に追加コストが発生します。アップグレード自体に追加料金は通常発生しませんが、並行稼働するインスタンス分の料金に注意してください。
  • 互換性とテスト: TO_DATE() 互換やオプティマイザ改善はいずれもアプリケーション依存の影響が出る可能性があるため、ステージ環境での回帰テストを必ず実施してください。SQL モードや格納プロシージャ・トリガーの挙動差異も確認が必要です。
  • アップグレード方式とダウンタイム: インプレースアップグレードはダウンタイム（再起動や短時間の停止）が発生する場合があります。Blue/Green デプロイはダウンタイムを抑えた移行を可能にしますが、切替時に接続の切り替えが必要です。
  • バックアップ/復元: アップグレード前にスナップショットを取得しておくこと。必要に応じてスナップショットからの復元で旧バージョンへロールバックできます。
  • 対応バージョン指定: RDS コンソール上で MariaDB エンジンのバージョン（12.3.2 など）を明示して作成／変更してください。

参考情報 ​

[Aiml] FLUX.2-small-decoder and gemma-4-12B-it models now available on Amazon SageMaker JumpStart ​

概要 ​

Black Forest Labs の FLUX.2-small-decoder と Google の gemma-4-12B-it が Amazon SageMaker JumpStart に追加され、画像生成の高速化とメモリ効率化、およびマルチモーダル理解とエージェント機能を低メモリで実現できるようになりました。

変更内容・新機能の詳細 ​

FLUX.2-small-decoder は FLUX.2 イメージ生成パイプライン向けに設計された蒸留済みの VAE デコーダで、標準の FLUX.2 デコーダのドロップイン置換として動作します。公表値ではデコード速度が約1.4×向上し、VRAM 利用量を約1.4×削減しつつ、画質の低下は最小限〜無視できるレベルです。解像度が上がるほど利点が大きくなり、大規模な生産向け画像生成ワークロードに適します。

gemma-4-12B-it はテキスト・画像・音声を統一して扱うエンコーダ不要のデコーダオンリートランスフォーマーです。単一のデコーダに全モダリティを流し込む設計により、より大きな MoE（Mixture-of-Experts）モデルに近い性能を、より小さなメモリフットプリントで提供します。ネイティブな function calling とエージェント的ワークフローをサポートし、16GB の RAM 程度でも動作可能なコンパクトさを謳っています。これら両モデルは SageMaker JumpStart のモデルカタログから数クリック、または SageMaker Python SDK を用いてデプロイ可能で、既存の SageMaker インフラ（推論エンドポイント、バッチ推論、パイプライン等）に統合できます。

影響範囲・利用シーン ​

  • 対象ユーザー: 画像生成パイプライン開発者、生成AI をプロダクションで運用するSRE/MLエンジニア
  • 利用シーン: 高解像度画像生成の推論コスト削減とスループット改善（FLUX.2-small-decoder）
  • 利用シーン: テキスト・画像・音声を統合したマルチモーダルアプリやエージェント機能搭載アプリの実装（gemma-4-12B-it）
  • 運用効果: VRAM 消費とレイテンシの低減によりインスタンスコスト削減やより多くの同時リクエスト処理が可能
  • 導入効果: JumpStart 経由でのワンクリックデプロイにより PoC→本番移行が容易化

技術的な注意点 ​

  • IAM権限: SageMaker モデルのデプロイには適切な SageMaker 実行ロールと IAM ポリシー（推論・ECR・S3 アクセス等）が必要です
  • リージョン制限: モデルの提供状況はリージョンごとに異なる場合があります。利用前に SageMaker JumpStart カタログで利用可能リージョンを確認してください
  • インスタンスタイプ: GPU を利用するワークロード（特に高解像度生成）は g4/g5 系列や ml.g5 系等の GPU インスタンスを推奨。gemma-4-12B-it は小さい構成で 16GB RAM 程度でも動作可能とされますが、実際のメモリ要件はバッチサイズやトークン長・入力モダリティによって変動します
  • コスト: デプロイ時のインスタンス時間、データ転送、SageMaker 推論エンドポイント料金が発生します。VRAM 削減はコスト削減に寄与しますが、総コストはワークロード次第です
  • モデル互換性: FLUX.2-small-decoder は既存の FLUX.2 デコーダのドロップイン置換を想定していますが、パイプラインに組み込む前に品質検証を行ってください
  • 性能注意: 公表の性能は条件依存（解像度・バッチサイズ・ハードウェア）です。期待どおりの速度／品質が得られるか事前にベンチマークを実施してください
  • 運用上の留意点: ログ、監視、オートスケーリング設定（SageMaker エンドポイントまたはプロダクションパイプライン）を整備してレイテンシとコストを管理してください
  • ライセンス/利用規約: モデル固有のライセンスや利用制限が適用される場合があります。利用前に該当モデルのライセンス条項を確認してください

参考情報 ​

[Aiml] langcache-embed-v3-small, Mellum2-12B-A2.5B-Thinking, and LightOnOCR-2-1B models now available on Amazon SageMaker JumpStart ​

概要 ​

Amazon SageMaker JumpStart に Redis、JetBrains、LightOn の新しいファウンデーションモデル（langcache-embed-v3-small、Mellum2-12B-A2.5B-Thinking、LightOnOCR-2-1B）が追加され、セマンティックキャッシュ最適化、コード推論/生成、高性能な文書OCR の用途が簡単にデプロイ可能になりました。

変更内容・新機能の詳細 ​

追加されたモデルの技術的要点：

  • langcache-embed-v3-small (Redis)

    • 文や段落を高品質な密ベクトル空間にマッピングする埋め込みモデル。表現の違いに関係なく意味的に同等なクエリを近接させることで、ベクトル類似度に基づく「インテリジェントなキャッシュヒット」が可能になります。これにより高頻度推論ワークロードで冗長なLLM呼び出しを削減し、応答時間を短縮できます。埋め込みは類似検索（k-NN）や近似近傍検索（ANN）と組み合わせて利用します。

  • Mellum2-12B-A2.5B-Thinking (JetBrains)

    • コード生成、デバッグ、マルチステップ推論、エージェント型ワークフローに特化したモデル。Mixture-of-Experts (MoE) アーキテクチャを採用（64エキスパート、トークンあたり8エキスパートを活性化）、推論時には総パラメータ12Bのうち約2.5B分のみをアクティブにすることで、スループットとレイテンシのバランスを最適化します。コンテキスト長は131,072トークンと非常に長く、明示的な chain-of-thought（推論トレース）を出力してから最終解答を返す設計のため、ルーティング、RAG、サブエージェント、プライベートデプロイに適しています。

  • LightOnOCR-2-1B (LightOn)

    • PDF・スキャン・画像からページ単位で自然順序のテキストを直接生成するエンドツーエンドのビジョン言語OCRモデル。従来の褆層化したOCRパイプラインに依存せず、OlmOCR-Bench 上で高い性能を達成しつつ、競合手法より約9倍小さく、処理速度も大幅に向上しています。1Bパラメータ級であり、ページ画像→整形済テキスト変換を直接行います。

SageMaker JumpStart を通じて、これらのモデルはコンソール上のモデルカタログから数クリックでデプロイでき、また SageMaker Python SDK を用いてプログラム的にエンドポイント化（リアルタイム推論 / バッチ推論）できます。JumpStart は推奨インスタンスタイプやデプロイテンプレートを提示するため、各モデルのメモリ・GPU要件に沿ったデプロイが可能です。

影響範囲・利用シーン ​

  • 対象ユーザー: MLエンジニア、アプリケーション開発者、SRE/運用チーム、ドキュメント処理担当者
  • 利用シーンまたは効果: 高頻度LLM呼び出しを伴うアプリでのセマンティックキャッシュによるコスト削減とレイテンシ改善（langcache）
  • 利用シーンまたは効果: コード補完・生成、デバッガ補助、マルチステップ推論やエージェントワークフローの高スループット低遅延推論（Mellum2）
  • 利用シーンまたは効果: 大量ドキュメントのPDF/スキャン→テキスト化（多言語対応）を高速かつ高精度に処理するOCRパイプラインの簡素化（LightOnOCR）
  • 運用効果: JumpStart から即時デプロイできるため PoC から本番化までの時間短縮、推論コスト最適化（MoE による活性化削減、埋め込みのキャッシュ化等）

技術的な注意点 ​

  • IAM権限: SageMaker のモデルデプロイ・エンドポイント作成に必要な IAM 権限（SageMakerFullAccess 等）と、VPC/サブネット/セキュリティグループの操作権限を事前に確認してください
  • リージョン制限: すべてのリージョンで即時利用可能とは限りません。コンソールの JumpStart モデルカタログで配信先リージョンを確認してください
  • コスト: 推論インスタンス、データ転送、ストレージ、（埋め込みキャッシュ用の追加 Redis 等）インフラのコストが発生します。MoE はアクティブ化パラメータを抑えることで単回推論コストを低減しますが、大規模トラフィックでは総コストを評価してください
  • 推論要件: Mellum2 の 131,072 トークン長や MoE の動作は高メモリ/高帯域のインスタンスを推奨します。JumpStart は推奨インスタンスを表示しますが、リアルタイム SLA に合わせて適切な GPU インスタンスを選んでください
  • 埋め込み運用: langcache-embed-v3-small をキャッシュに使う場合、埋め込み保存先（DynamoDB/S3/ElastiCache/ベクトルDB）の選定、類似度計算（ANN ライブラリや Amazon OpenSearch/Elasticsearch、Amazon MemoryDB など）との統合設計が必要です
  • モデルライセンス・データ保護: 各モデルは提供者（Redis/JetBrains/LightOn）のライセンス条件に従います。機密データの外部送信やログ保存ポリシーに関しては社内のコンプライアンス要件を確認してください
  • デプロイ方法: SageMaker コンソールの JumpStart カタログまたは SageMaker Python SDK（ドキュメント参照）でデプロイ可能。バッチ/リアルタイム/API 経由の利用形態を選べます
  • 互換性: MoE モデルは内部で特定のランタイム設定や最適化を要する場合があります。JumpStart のデプロイオプションで自動的に最適化されますが、カスタム最適化を行う場合はモデル提供元のドキュメントを参照してください

参考情報 ​

[Ec2] Amazon EC2 High Memory U7i instances now available in AWS South America (São Paulo) region ​

概要 ​

Amazon EC2 High Memory U7in-24TB (u7in-24tb.224xlarge) が AWS 南米（サンパウロ）リージョンで利用可能になりました。24 TiB の DDR5 メモリと 896 vCPU、最大 100 Gbps の Amazon EBS 帯域や 200 Gbps のネットワーク、ENA Express を備え、大規模インメモリデータベースやトランザクション処理向けに最適化されています。

変更内容・新機能の詳細 ​

概要: u7in-24tb.224xlarge は EC2 の第7世代 High Memory U7i ファミリーの 24 TiB モデルで、カスタム第4世代 Intel Xeon Scalable（Sapphire Rapids）プロセッサを採用。主なスペック: 24 TiB DDR5 メモリ、896 vCPU、最大 100 Gbps の Amazon EBS 帯域（データ読み込み・バックアップの高速化に寄与）、200 Gbps ネットワーク帯域、および ENA Express 対応。利用目的: インメモリデータベース（SAP HANA、Oracle、SQL Server など）や大量メモリを必要とする分析・キャッシュ用途、トランザクションスループットのスケールアウトに適する。運用面: 大容量メモリと高帯域を活かすため、最新の OS カーネル／ENA ドライバや最適化された AMI を利用することが推奨される。費用: 大容量インスタンスのためインスタンスタイプの時間単価は高めで、EBS ストレージの使用量やスループットに応じた追加コストが発生する点に留意。

影響範囲・利用シーン ​

  • 対象ユーザー: エンタープライズのデータベース管理者、SRE、アプリケーションアーキテクト（大規模インメモリ DB を運用する組織）
  • 利用シーン: SAP HANA、メモリ内キャッシュ、大規模のOLTP/分析ワークロード、短時間での大量データロードやバックアップ
  • 運用効果: メモリ容量増大によりデータ配置をメモリ中心にでき、レイテンシ低下とトランザクションスループット向上が期待できる
  • コスト影響: 大容量インスタンスは時間単価が高く、EBS 帯域/IO 要求が増えるとストレージコストも上昇する可能性がある
  • リージョン影響: 南米（サンパウロ, sa-east-1）リージョンで新たに利用可能になったため、南米ユーザーのレイテンシ改善やデータ主権要件への対応が容易になる

技術的な注意点 ​

  • IAM権限: インスタンス起動や暗号化済みボリュームの利用には通常の EC2/EBS 起動権限が必要です（必要な IAM ポリシーを事前に確認してください）
  • リージョン制限: 本リリースは AWS 南米（サンパウロ）リージョン向けの追加（sa-east-1）。他リージョンでの利用可否はリージョンごとに異なります
  • ドライバ/OS 要件: ENA Express と高スループット EBS をフルに活用するには、対応する ENA ドライバ/カーネルが必要です。最新の公式 AMI またはベンダーが推奨する AMI を使用してください
  • SAP/ソフトウェア認定: SAP HANA 等の商用データベースで利用する場合は、該当 DB ベンダーおよび SAP の EC2 インスタンス認定／サイズガイドに従ってください
  • ネットワーク/ストレージ: 最大値（100 Gbps EBS、200 Gbps ネットワーク）はワークロードや AZ、並列性に依存します。EBS ボリュームタイプ（io2/Block Express 等）や配置を設計時に検討してください
  • コスト: 大容量メモリインスタンスは高額なため、必要なサイズの事前検証（ベンチマーク）と、Savings Plans/リザーブドインスタンスの検討を推奨します

参考情報 ​

[Aiml] GLM-5.2 FP8, NVIDIA-Nemotron-Nano-12B-v2 and GLM-OCR models now available on Amazon SageMaker JumpStart ​

概要 ​

Amazon SageMaker JumpStart に Z.ai の GLM-5.2 FP8、NVIDIA の Nemotron-Nano-12B-v2、Z.ai の GLM-OCR の 3 モデルが追加され、長期コンテキストのエージェント的ワークフロー、高スループット推論、複雑な文書理解といった用途をカバーします。

変更内容・新機能の詳細 ​

追加されたモデルの主な技術的特徴：

  • GLM-5.2 FP8 (Z.ai): 長期的なコンテキストを必要とする“agentic engineering”ワークフロー向けに最適化された大規模言語モデル。GLM-5.1 からの能力向上を謳い、初めて実用的な 1,000,000 トークン（1M）コンテキストウィンドウを提供。要件定義から実装・デプロイまでのプロジェクトレベルの文脈を一度に扱えるため、長時間実行タスクや完全な開発ワークフローの単一タスク処理が可能。FP8 最適化によりメモリ効率と推論スループットの改善が期待される（ただしハードウェア依存）。

  • NVIDIA Nemotron-Nano-12B-v2: Mamba-2 と Transformer を組み合わせたハイブリッドアーキテクチャを採用し、推論時に reasoning trace（思考過程）を生成してから最終応答を出す設計。128K の長いコンテキストと 12B パラメータのコンパクト設計により、精度を維持しつつリードするオープンモデルに比べて最大で 6x の推論スループット向上を達成するとされる。推論効率と一貫した推論トレースが求められるエンタープライズ用途に適する。

  • GLM-OCR (Z.ai): 0.9B パラメータのマルチモーダル OCR モデルで、スキャン PDF、手書きメモ、数式を含む学術論文、複数カラムや複雑な表、コードドキュメント、多言語テキストなど実世界の複雑資料を対象に、高精度かつ低レイテンシでの構造復元（テーブル・数式・段組み）を行い、出力を Markdown / JSON / LaTeX に整形可能。リアルタイムサービスやエッジデバイスでも使えるほどの低遅延を志向しているため、大量ドキュメント処理や請求書抽出ワークフローに向いている。

デプロイ方法：SageMaker JumpStart のモデルカタログからコンソール上で数クリックでエンドポイント化できるほか、SageMaker Python SDK を使ってプログラム的にデプロイ・推論・ファインチューニング（必要に応じて）できます。用途に応じてリアルタイムエンドポイント、マルチモデルエンドポイント、バッチ変換、またはホスティングのスケール設定（マルチインスタンスやオートスケーリング）を選択可能です。

影響範囲・利用シーン ​

  • 対象ユーザー: モデル駆動のソフトウェア開発、自動化ワークフローを求める機械学習エンジニア、SRE、プロダクトチーム
  • 利用シーンまたは効果: GLM-5.2 FP8 はプロジェクト全体を通した長期コンテキスト処理（要件→設計→実装→テスト→デプロイ）を単一タスクで実行可能にし、工程の自動化・一貫性向上に寄与
  • 対象ユーザー: エンタープライズアプリケーション開発者、レイテンシとスループットを重視する推論運用チーム
  • 利用シーンまたは効果: Nemotron-Nano-12B-v2 は高スループットかつ推論トレースを必要とする業務系チャットボットや知識処理パイプラインで、コスト対性能比を改善
  • 対象ユーザー: ドキュメント処理担当、RPA／EC／会計システムの開発者
  • 利用シーンまたは効果: GLM-OCR はスキャン文書・手書き・多列レイアウト・数式混在文書の構造化抽出（請求書・論文・技術文書）をリアルタイムまたは大規模処理で高速化
  • 運用効果: JumpStart のワンクリックデプロイにより PoC→本番移行の導入コストと時間が短縮され、必要に応じてインスタンス選択やスケールで性能／コストの最適化が可能

技術的な注意点 ​

  • IAM権限: SageMaker のモデルデプロイ権限（SageMakerFullAccess など）および関連する S3 アクセス権を事前に確認してください
  • インスタンスタイプ: 高い推論性能・FP8 の恩恵を得るには対応 GPU（例: NVIDIA H100 等）や十分な VRAM を備えたインスタンスを選択する必要があります。小型モデルは軽量 GPU / CPU での運用も可能です
  • コンテキスト長: GLM-5.2 FP8 は最大 1M トークン、Nemotron-Nano-12B-v2 は最大 128K。大コンテキストはメモリとレイテンシ、コストに大きく影響します
  • コスト: 大コンテキスト/高スループット運用は推論時間とインスタンス数を増やすためコスト増加要因になります。エンドポイント構成（オンデマンド/プロビジョニング/スポット）で最適化を検討してください
  • リージョン制限: JumpStart のモデル提供状況はリージョンごとに異なる可能性があります。利用前に対象リージョンの JumpStart カタログで公開状況を確認してください
  • ライセンス/利用条件: 各モデルの利用規約や商用利用条件（提供元ライセンス）を確認してください。データ送信や二次利用に制約がある場合があります
  • 前処理/後処理: GLM-OCR は画像品質（解像度、デノイズ、回転補正）とページ分割の前処理、出力 Markdown/JSON/LaTeX の検証や正規化を推奨します
  • スケーリング/可用性: 高スループット用途ではマルチインスタンスやコンカレンシー設定、オートスケーリングを組み合わせた設計が必要です
  • データ保護: 機密データを扱う場合は VPC エンドポイント／プライベート接続、暗号化、監査ログを有効にしてデータ保護を確保してください
  • 精度検証: 公表されているベンチマークは参照値です。導入前に自社データで精度・レイテンシ・コストの検証を行ってください

参考情報 ​

[Gamelift] Amazon GameLift Streams Now Offers Service-managed Shader Caching ​

概要 ​

Amazon GameLift Streamsがサービス管理のシェーダーキャッシュ機能を提供開始しました。ストリームセッションで生成したシェーダーキャッシュを自動で収集・複製・配布し、以降のセッションで自動的にロードして読み込み時間や視覚的スタッタリングを低減します。

変更内容・新機能の詳細 ​

利用者はストリームセッションをキャプチャ用に指定してアプリケーションを実行するだけで、GameLift Streamsがそのセッションで生成されたシェーダーキャッシュを取得します。取得されたキャッシュはサービス側で互換性のあるストリームグループやロケーションへ複製され、以降のセッションで自動的にロードされます。アプリケーション側のコード変更は不要です。キャッシュの状態や保存サイズはListApplicationShaderCaches APIまたはAmazon GameLift Streamsコンソールで確認できます。サポートされるランタイムは Linux (Ubuntu 22.04)、Proton、Windows Server 2022 です。課金は各シェーダーキャッシュの最新バージョンのストレージ利用分に対して発生します（詳細は料金ページ参照）。

影響範囲・利用シーン ​

  • 対象ユーザー: クラウドゲーム配信事業者、リモートレンダリング／ストリーミングを行うゲーム開発チーム、SRE/運用チーム
  • 利用シーンまたは効果: ストリーミングセッションでの初期読み込み時間短縮、レンダリング中の視覚的スタッタリング軽減。新しいストリーム配信ロケーションへキャッシュを自動配布することで、複数リージョンにまたがる配信環境でも体験の一貫性を向上
  • 運用効果: アプリ改修不要でキャッシュ配布を自動化でき、運用負荷低下とエンドユーザーUX改善が期待できる
  • パフォーマンス影響: 適切に生成されたシェーダーキャッシュがあればフレームドロップや遅延の低減につながる。キャッシュの有無で初回体験に差が出るため、キャプチャ戦略が重要
  • コスト影響: シェーダーキャッシュの保存に対するストレージ料金が発生（最新バージョン分）。大量にキャッシュを保持するとストレージコストが増加する可能性あり

技術的な注意点 ​

  • IAM権限: ListApplicationShaderCachesなどのGameLift Streams関連APIやコンソール表示に必要なIAM権限を付与してください
  • リージョン制限: すべてのリージョンで利用可能とは限りません。サポートされるリージョンはAWSリージョン表で確認してください
  • コスト: シェーダーキャッシュの最新バージョン分のストレージ料金が発生します。料金ページで料金体系を事前に確認してください
  • ランタイムサポート: Linux (Ubuntu 22.04)、Proton、Windows Server 2022 がサポート対象です。その他のOS/ランタイムでは動作保証されません
  • 互換性・複製: キャッシュは互換性のあるストリームグループ／ロケーションへ複製されます。GPUドライバやランタイムの差異により互換性が制限される場合があります
  • 運用: キャプチャ用セッションを意図的に作成してキャッシュを生成する必要があります。自動化ワークフローを組むことで効果的に運用できます
  • 監視/管理: ListApplicationShaderCaches APIまたはコンソールでキャッシュ状態とサイズを確認可能。保持ポリシーやバージョン管理は設計段階で検討してください

参考情報 ​

[Ec2] Amazon EC2 introduces application status checks ​

概要 ​

Amazon EC2はアプリケーションレベルの稼働状況を検出する「application status checks」を導入しました。従来のインスタンス/システムステータスチェックに加え、HTTP/HTTPSでアプリケーションの応答を定期確認できる機能です。

変更内容・新機能の詳細 ​

ユーザーがプロトコル(HTTP/HTTPS)、ポート、パス、および「正常」と見なすレスポンスコードを指定してチェックを作成します。チェックはインスタンスIDまたはタグでインスタンスに関連付け可能で、EC2が指定したポートとパスに対して60秒ごとにHTTP/HTTPSリクエストを送信し、アプリケーションのヘルスを報告します。検知対象の例として、Webサーバがリクエストを受け付けなくなった状態、Dockerデーモンが停止している状態、誤ったネットワーク設定、ネットワークインターフェースがトラフィックを通さない状態などが挙げられます。Auto Scalingグループはこのアプリケーションステータスを基にインスタンス回復（不健康なインスタンスの置換）を実行できます。本機能は全ての商用AWSリージョンとAWS GovCloud (US)で利用可能で、価格や利用開始手順はAmazon EC2 User Guideで確認できます。

影響範囲・利用シーン ​

  • 対象ユーザー: EC2上でサービスを稼働させるアプリケーション開発者、SRE、運用チーム
  • 利用シーン: Webサーバやコンテナデーモンなどアプリケーションレベルの可用性監視（ポート/パス単位の稼働確認）
  • 運用効果: OSやホストの到達性だけでなくアプリケーションの不具合検知が可能になり、アラート精度向上と早期復旧が実現
  • スケーリング/自動復旧: Auto Scalingと連携して不健康なインスタンスを自動で置換できるため、手動介入の削減と可用性向上が期待できる
  • 導入の容易さ: 従来の外部監視ソリューションを自前で構築・維持する必要が減る（設定はプロトコル/ポート/パス/応答コードの指定とインスタンス紐付けのみ）

技術的な注意点 ​

  • IAM権限: チェックの作成・管理、インスタンスへの関連付けにはEC2リソース管理を許可するIAM権限が必要です。具体的な必要権限は公式ドキュメントで確認してください。
  • セキュリティグループ/ネットワークACL: EC2が送信する監視リクエストがインスタンスに到達できるよう、該当ポートへのインバウンドを許可してください。ヘルスチェック送信元のホワイトリスト方法および送信元IP範囲についてはドキュメントを確認することを推奨します。
  • TLS/証明書: HTTPSチェックを使用する場合はTLSハンドシェイクが成功する必要があります。自己署名証明書や不正な証明書を使用しているとチェックが失敗する可能性があるため注意してください。
  • チェック頻度と応答時間: チェックは60秒ごとに実行されます。アプリケーションの一時的な遅延や短時間のスパイクが誤検知につながらないよう、リトライや判定ポリシー（例えば連続n回失敗で不健康）を設計してください。
  • Auto Scaling連携: Auto Scalingでアプリケーションステータスをヘルスチェックに組み込む場合、ASGのヘルスチェック設定や置換ポリシーを確認・調整してください。
  • ログ/監視連携: ステータス結果の可視化やアラート連携（CloudWatch/Events/ EventBridge等）を組み合わせて運用自動化を検討してください。
  • コスト: 追加のヘルスチェックに対して料金が発生する可能性があります。利用開始前にEC2の料金ページ/ユーザーガイドで料金を確認してください。
  • リージョン制限: 全ての商用AWSリージョンおよびAWS GovCloud (US)で利用可能です。特殊な組織ポリシーやGovCloud特有の要件がある場合は確認してください。

参考情報 ​

[Opensearch Service] Amazon OpenSearch Serverless now supports up to 10,000 collections per collection group ​

概要 ​

Amazon OpenSearch Serverless（次世代）は、1つのコレクショングループ内でサポートするコレクション数の上限を従来の1,500件から10,000件に引き上げました。これにより、多数のコレクションを単一の共有コンピュートプールで効率的に運用できます。

変更内容・新機能の詳細 ​

コレクショングループは複数のコレクションをまとめて管理し、OpenSearch Compute Units（OCU）を共有する仕組みです。今回の変更で、次世代（next generation）のAmazon OpenSearch Serverlessにおいて、1グループあたりのコレクション上限が10,000件に拡張されました（従来は1,500件）。コレクションごとに異なるAWS KMSキーで暗号化されている場合でも同一グループでOCUを共有可能です。対象は新規・既存のnextgenコレクショングループであり、利用可能なすべてのリージョンに自動で適用されます。主にマルチテナント環境でテナント毎にコレクションを用意するケースや、コレクション数が急増するワークロードでの利用に有効で、OCU利用率の向上とコスト削減が期待できます。運用上はOCUの利用率・レイテンシ・スロットリング（スループット）を監視し、必要に応じて複数のコレクショングループに分割するなどの対策を検討してください。

影響範囲・利用シーン ​

  • 対象ユーザー: マルチテナントアプリケーション開発者、SRE/運用チーム、検索プラットフォームを大規模に運用するチーム
  • 利用シーン: テナント毎にコレクションを作成するマルチテナント環境、コレクション数が数千〜万単位に達するログやメタデータ検索の集約
  • 運用効果: 単一のコレクショングループで多くのコレクションを共有することでOCUの利用効率が向上し、コスト削減（コレクションあたりのコスト低減）と管理の簡素化が可能
  • 制約・留意点: 共有OCUでの「ノイジーネイバー」やスループット競合によりパフォーマンス影響が発生する可能性があるため、モニタリングと必要に応じたグループ分割が必要

技術的な注意点 ​

  • 適用範囲: 増加した上限は次世代（nextgen）Amazon OpenSearch Serverlessのコレクショングループに自動適用されます（従来世代には該当しない可能性あり）
  • リージョン制限: nextgenが利用可能な全リージョンで適用。ただし一部リージョンでnextgenが未提供の場合は対象外となります
  • IAM権限: コレクショングループ/コレクションの作成・変更にはOpenSearch Serverless関連およびKMSキー管理の適切なIAM権限が必要です
  • KMS: コレクションごとに異なるKMSキーで暗号化していても同一グループでOCU共有が可能です。KMSキーのアクセス制御を適切に設計してください
  • コスト: コレクショングループはOCUを共有して課金されるため、集約によりコスト削減が期待できますが、OCU使用量自体はワークロードに応じて課金されます
  • クォータ管理: 追加の上限緩和が必要な場合はService QuotasやAWSサポートで確認してください
  • 運用監視: OCUのCPU/メモリ/スループット、レイテンシ、およびKMS暗号処理の影響を監視し、性能低下時はグループ分割やOCU増強を検討してください

参考情報 ​

AI要約はOpenAI APIによって生成されています。

Copyright © 2026