AWS What's New Digest

Appearance

2026年08月25日 ​

[Identity And Access Management] IAM Roles Anywhere now provides a Java plugin for the AWS SDK ​

概要 ​

IAM Roles AnywhereがAWS SDK for Java v2向けのJavaプラグインを提供開始しました。JVM内で直接一時的なAWS認証情報を取得・自動更新でき、外部プロセスやcredential_processの設定が不要になります。

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

このプラグインはAWS SDK for Java v2のサービスクライアントビルダーに設定して利用します。プラグインは同一JVM内で動作し、IAM Roles AnywhereのCreateSession APIを呼び出して一時クレデンシャルを取得、期限切れ前に自動でリフレッシュします。サポートする鍵タイプはRSA、楕円曲線（EC）、ML-DSAで、動作にはJava 8以上が必要です。外部のcredential helperを別プロセスで走らせたり、AWSプロファイルにcredential_processを設定したりする必要がなくなるため、アプリケーション側での認証ロジック実装が不要になります。追加料金は発生しません。IAM Roles Anywhereは全リージョン（AWS GovCloud (US)、欧州主権クラウド（ドイツ）、中国リージョン含む）で利用可能です。プラグインの導入手順や最新リリース情報、署名検証方法については、公式ドキュメント、Maven CentralやGitHubのリポジトリで確認できます。

影響範囲・利用シーン ​

  • 対象ユーザー: オンプレミスやコロケーション、別クラウド上でJavaアプリケーションを運用する開発者／SRE
  • 利用シーン: JavaベースのワークロードがAWSリソースへアクセスする際に、アプリケーション内で自動的に一時認証情報を取得して利用する（例：S3、DynamoDB、KMSなどへのアクセス）
  • 運用効果: 外部プロセスやcredential_process設定を不要にしデプロイ／運用の簡素化、認証情報の自動リフレッシュによるセッション管理負荷低減、JVM内で完結するためレイテンシ低下とオーケストレーションの簡略化が期待できる

技術的な注意点 ​

  • IAM権限: Roles Anywhere利用のための信頼ロール、信頼アンカー、プロファイルなどIAM側の設定が必要です（CreateSession呼び出し権限はIAMで管理されます）
  • Javaバージョン: Java 8以上が必須です（AWS SDK for Java v2が前提）
  • SDK互換性: 本プラグインはAWS SDK for Java v2向けです。v1では利用できません
  • キー管理: RSA/EC/ML-DSAのプライベート鍵を安全に保管・管理してください。鍵が漏洩すると不正アクセスのリスクがあります
  • ネットワーク: Roles Anywhereエンドポイントへアウトバウンド接続が必要です。プロキシやファイアウォール設定を確認してください
  • リージョン制限: 発表によれば全リージョンで利用可能（GovCloud/欧州主権クラウド/中国を含む）ですが、導入前に利用リージョンでのコンソール／ドキュメントで確認してください
  • コスト: プラグイン自体に追加料金はありませんが、Roles Anywhere APIの呼び出しや関連するAWSサービス利用に伴う通常の請求は発生します
  • 互換性と運用: 既存のcredential helperやcredential_processを使った構成は引き続き利用可能で、段階的な移行を検討できます
  • 署名検証／リリース情報: Maven CentralやGitHubのリポジトリで現在版や署名検証手順を確認してください

参考情報 ​

[Govcloud Us] AWS Lambda introduces managed runtimes in public preview for Node.js 26 and Python 3.15 ​

概要 ​

AWS Lambdaがマネージドランタイムのパブリックプレビューを開始しました。まずNode.js 26およびPython 3.15が対象で、GA前に互換性検証やフィードバック提供が可能になります。

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

今回のアップデートでは、Lambdaのマネージドランタイムに“パブリックプレビュー”段階が導入され、まずNode.js 26とPython 3.15が公開されます。プレビュー版は本番運用向けではなく、プレビュー期間中はランタイムに_BREAKING CHANGES_（互換性を壊す変更）が入り得る点が明示されています。プレビューランタイムは最終的なGA版と同じランタイム識別子（nodejs26.x / python3.15）を使用するため、GAに達するとユーザー側での追加作業なしに自動的に“卒業”します。コンソールでは「Node.js 26 (Preview)」「Python 3.15 (Preview)」を選択するか、CLI/CloudFormation/SAM/CDKでそれぞれ nodejs26.x / python3.15 を指定して利用できます。プレビューは全てのAWS商用リージョン、AWS GovCloud (US)、および中国リージョンで利用可能で、追加費用はなく標準のLambda課金が適用されます。ただし、プレビュー期間中はLambdaのSLAやAWSテクニカルサポートの対象外であり、本番ワークロードでの使用は推奨されません。サードパーティのオブザーバビリティプロバイダ、IaCツール、デプロイメントフレームワークは互換性検証や修正の期間を確保できます。

影響範囲・利用シーン ​

  • 対象ユーザー: LambdaでNode.jsまたはPythonを利用する開発者、SRE、プラットフォーム/デプロイ担当者、サードパーティツールベンダー
  • 利用シーン: 新しいランタイム（言語）機能の互換性検証、CI/CDやテスト環境での実動作テスト、オブザーバビリティ／デプロイツールの互換性チェック
  • 運用効果: GA前に問題を発見・報告できるため、GA後の突発的な互換性障害を低減できる。サードパーティエコシステムが事前対応することで本番移行時のリスクを小さくできる

技術的な注意点 ​

  • IAM権限: 通常のLambda作成・更新権限（lambda:CreateFunction, lambda:UpdateFunctionConfiguration 等）が必要です。CI/CDから指定する場合はデプロイ用の権限を確認してください
  • リージョン制限: 商用リージョン、AWS GovCloud (US)、中国リージョンで利用可能と明記されていますが、利用前に対象リージョンでプレビューが有効か確認してください
  • コスト: 追加料金は発生せず、標準のLambda利用料金が適用されます
  • サポート/SLA: パブリックプレビュー中はLambdaのSLAおよびAWSテクニカルサポートの対象外です。プレビュー版は本番稼働での使用を推奨しません
  • 互換性/破壊的変更: プレビュー期間中は破壊的変更が入り得るため、プロダクション環境での使用は避け、ステージングやCI環境で十分にテストしてください
  • 移行作業: ランタイム識別子はGAと同一のため、GAへは自動的に移行されますが、コードや依存パッケージの互換性確認（ビルド/テストパイプラインの実行）は必須です
  • 運用対策: プレビュー利用時はエイリアスや段階的デプロイ（Traffic shifting）でリスクを限定する、インテグレーションテストと監視を強化することを推奨します

参考情報 ​

[Govcloud Us] Amazon RDS now supports the latest CU for Microsoft SQL Server ​

概要 ​

Amazon RDS for SQL Server が Microsoft SQL Server 2025 の最新 Cumulative Update (CU6, KB5093421) をサポートしました（RDS エンジン版: 17.00.4055.5.v1）。RDS コンソールや AWS CLI/SDK を使ってインスタンスをアップグレードできます。

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

今回のリリースは Microsoft が配布する SQL Server 2025 の累積更新プログラム（CU6 / KB5093421）を Amazon RDS がサポート対象に追加したものです。RDS 上の SQL Server エンジンは RDS 管理下でエンジンバージョン 17.00.4055.5.v1 として提供され、エンジンバージョンを変更することで CU6 の適用（エンジンのアップグレード）が可能です。アップグレードは Amazon RDS コンソール、または AWS CLI/AWS SDK の modify-db-instance 相当の操作で実行できます。アップデートの内容（修正点や改善点）は Microsoft の KB5093421 のリリースノートを参照してください。Amazon RDS はエンジンの適用や再起動管理を行いますが、インスタンスの再起動や短時間のサービス中断が発生する可能性があるため、事前のバックアップ取得およびステージング環境での動作確認を推奨します。

影響範囲・利用シーン ​

  • 対象ユーザー: Amazon RDS 上で Microsoft SQL Server を運用しているアプリケーション所有者、DBA、SRE/運用チーム
  • 利用シーンまたは効果: セキュリティ修正やバグフィックス、パフォーマンス改善を取り込むためのエンジンアップデートを実施可能。コンプライアンスや脆弱性対応が必要な環境で迅速に CU を適用できる
  • 運用効果: 最新の修正を適用することで既知の不具合やセキュリティ問題を軽減できる。メンテナンスウィンドウを利用した計画的なアップグレードで稼働率への影響を最小化できる

技術的な注意点 ​

  • RDSエンジンバージョン: サポートされた RDS エンジン版は 17.00.4055.5.v1（SQL Server 2025 CU6）です
  • ダウンタイム: アップグレード時にインスタンスの再起動が発生する可能性があり、短時間のサービス中断が発生します。フェイルオーバー可能な構成（マルチAZ）でも一時的な接続切れが発生する場合があります
  • バックアップ/検証: 本番適用前にスナップショット取得、ステージング環境での互換性検証を必ず行ってください
  • IAM権限: アップグレードを実行するには rds:ModifyDBInstance などの RDS 操作権限が必要です。自動メンテナンス適用を操作する場合は追加の権限を確認してください
  • リージョン制限: 本アナウンスは GovCloud (US) カテゴリで公開されています。各リージョンでの提供状況はリージョン別のリリース情報を確認してください
  • コスト: CU の適用自体に追加料金は通常発生しませんが、アップグレード作業中のスナップショット保存や一時的なリソース利用、ダウンタイムに伴う間接コストが発生する可能性があります

参考情報 ​

[Govcloud Us] Amazon RDS for Oracle now supports July 2026 Release Update ​

概要 ​

Amazon RDS for Oracle が Oracle の 2026年7月リリースアップデート（RU）をサポートしました。Oracle Database 19c、21c、26ai 向けに提供されており、特にセキュリティ更新を含むためアップグレードが推奨されます。

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

今回の対応では、Amazon RDS for Oracle が Oracle の July 2026 Release Update（RU）を 19c、21c、26ai に対してサポートします。重要な変更点として、Oracle Database 19c の RU の命名規則が変更され、.ru-、.mrp-、.r を組み合わせた形式（例: 19.0.0.0.ru-2026-07.mrp-2026-07.r1）になります。Oracle が 19c と 26ai 向けに毎月配布する Critical Security Patch Update（CSPU）は、Amazon RDS 上では MRP（Monthly Recommended Patch）として提供され、CSPU に Oracle 推奨の追加修正をバンドルした形になります。Oracle Database 21c の RU については従来の命名フォーマットが継続されます。RU の適用は RDS 管理コンソール、AWS SDK、AWS CLI から行えます。自動でマイナーアップグレードを適用するには「Automatic Minor Version Upgrade」を有効にし、AWS Organizations の upgrade rollout policy を使うことで非本番→検証→本番へ段階的に自動適用するロールアウト運用が可能です。適用は DB インスタンスの再起動を伴うことがあり、メンテナンスウィンドウ中に実行する運用が推奨されます。

影響範囲・利用シーン ​

  • 対象ユーザー: Amazon RDS for Oracle を利用する DB 管理者、SRE、アプリケーション開発チーム（Oracle 19c/21c/26ai を利用しているユーザー）
  • 利用シーン: セキュリティパッチ適用や定期的なマイナーアップグレード（CSPU/MRP を含む）を自動化・段階的に展開したい運用（非本番で検証後に本番へ展開）
  • 運用効果: セキュリティ脆弱性修正の迅速反映、段階的ロールアウトによるリスク低減、メンテナンス自動化による運用負荷の軽減

技術的な注意点 ​

  • IAM権限: DB インスタンスのパッチ適用や自動アップグレードの設定変更には rds:ModifyDBInstance 等の RDS 変更権限が必要です
  • ダウンタイム/再起動: RU 適用はインスタンスの再起動を伴う可能性があり、メンテナンスウィンドウでの実行を推奨します
  • 命名規則: 19c の RU は新フォーマット（例: 19.0.0.0.ru-2026-07.mrp-2026-07.r1）に変更されます。21c は従来フォーマットのままです
  • 自動アップグレード設定: Automatic Minor Version Upgrade を有効にするとメンテナンスウィンドウで自動適用されます。AWS Organizations の upgrade rollout policy を使用すると段階的ロールアウトが可能です
  • リージョン制限: この発表は GovCloud (US) カテゴリでのリリース情報です。利用可能リージョンやタイミングはリージョン毎に異なる場合があるため、対象リージョンでの提供状況を確認してください
  • コスト: パッチ適用自体に直接の追加料金は通常発生しませんが、再起動による可用性影響やテスト工数など運用コストが発生する点に注意してください

参考情報 ​

[Secrets Manager] AWS Secrets Manager adds managed external secrets support for Cisco Security Platform and Netskope ​

概要 ​

AWS Secrets Managerが管理対象外部シークレット機能を拡張し、Cisco Security Platform（Security Cloud Control）のAPIキー（リフレッシュトークン）とNetskopeのRBACv3サービスアカウント用REST APIトークンの自動ローテーションをコンソール上でカスタムコード不要で実行できるようになりました。

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

Secrets Managerの「managed external secrets（管理対象外部シークレット）」にCisco Security PlatformとNetskopeが追加されました。CiscoではOAuthパターンに従い、Secrets Managerが保存しているリフレッシュトークンをスケジュールに従ってローテーション（Ciscoが定期的に再発行する新しいリフレッシュトークンを取得して保存）します。アプリケーション側は保存されたリフレッシュトークンを使って短期間のアクセストークンを都度取得して利用します。Netskopeについては、Secrets ManagerがRBACv3のサービスアカウント用REST APIトークンをNetskopeのSCIM API経由でローテーションし、新しく生成されたトークンを検証してからローテーションを完了します。両統合ともセルフオーセンティケーション方式（保存された資格情報が自身のローテーションを認可する）を採用しており、ローテーション用に別途管理者資格情報を用意する必要はありません。これらは、BigID、Confluent Cloud、Datadog、GitLab、Jenkins、MongoDB Atlas、Okta、Paddle、Salesforce、Snowflake、SonarQube 等に対する既存の管理対象外部シークレットサポートに追加されたものです。CiscoおよびNetskopeの管理対象外部シークレットは、AWS Secrets Managerの管理対象外部シークレットがサポートされているすべてのリージョンで利用可能です。ローテーションスケジュールやシークレットの設定はSecrets Managerコンソール／APIから行います。

影響範囲・利用シーン ​

  • 対象ユーザー: セキュリティエンジニア、クラウド／インフラ運用チーム、アプリケーション開発者
  • 利用シーン: Cisco Security PlatformやNetskopeを利用する環境でのAPIキー／トークンの自動ローテーション導入（手動更新やカスタムローテータの不要化）
  • 運用効果: シークレット管理・ローテーションの自動化により、キー漏えいリスクの低減と運用負荷の削減が可能。ローテーション失敗時の検知やロールバック運用をSecrets Manager上で一元管理できる

技術的な注意点 ​

  • IAM権限: シークレットの作成・更新・ローテーションにはSecrets Managerの権限（例: secretsmanager:RotateSecret, secretsmanager:GetSecretValue, secretsmanager:PutSecretValue, secretsmanager:DescribeSecret 等）が必要です。ロールやポリシーを事前に設定してください。
  • Netskope前提: RBACv3サービスアカウントとSCIM APIが有効であることが必要です。サービスアカウントの種類や権限設定が不適切だとローテーションに失敗します。
  • Cisco前提: アプリケーションがリフレッシュトークンを使って短命のアクセストークンを取得するOAuthフローに対応している必要があります。リフレッシュトークンの初期登録手順を確認してください。
  • セルフオーセンティケーション: これらの統合は保存された資格情報が自身をローテーションする方式のため、別途管理者資格情報を渡す必要はありません。ただし初期シークレットの投入と権限設定は必要です。
  • リージョン制限: 発表の通り、AWS Secrets Managerの管理対象外部シークレットがサポートされる全リージョンで利用可能です。利用予定リージョンで管理対象外部シークレットがサポートされていることを事前に確認してください。
  • コスト: Secrets Managerのシークレット保管料およびAPI呼び出し（ローテーション実行）に対する課金が発生します。ローテーション頻度を高くするとAPIコールとそれに伴うコストが増加する可能性があります。
  • 運用注意点: ローテーション前後でアプリケーションがアクセストークン取得に失敗しないことを検証する運用フローを用意してください（Netskopeは生成トークンの検証を行いますが、アプリ側の互換性確認は必須）。
  • 既存インテグレーション: 他の管理対象外部シークレット（例: Datadog, Okta, Snowflake 等）と同様にコンソールで設定可能で、カスタムローテーションコードは不要です。

参考情報 ​

[ECS] Amazon ECS now automatically detects and repairs container instances with impaired agent connectivity ​

概要 ​

Amazon ECSはコンテナインスタンスにおけるエージェント接続状態を継続的に監視し、接続が損なわれた（AGENT_CONNECTIVITYの変化）インスタンスを検出して自動的に復旧処理を行う機能を提供開始しました。これにより検出されにくいワークロード障害を減らし、アプリケーションの可用性を向上させます。

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

Amazon ECSはインフラ障害（例: EBSボリューム劣化、ホストのサーマルイベント、ネットワーク切断など）によってECSエージェントがコントロールプレーンと切断された場合に、AGENT_CONNECTIVITYという新しいコンテナインスタンスのヘルス変更イベントを生成します。すべてのコンピュートオプション（AWS Fargate、Amazon ECS Managed Instances、Amazon ECS on EC2）でこのヘルス変更イベントがサーフェスされます。AWS FargateおよびECS Managed Instancesでは、ECSが自動的に回復処理を実行します（影響を受けたインスタンスのタスクを自動的にドレインしてデプロイ済みタスクを移動、障害インスタンスを登録解除しつつ必要な代替キャパシティを起動）。Amazon ECS on EC2のワークロードでは、このAGENT_CONNECTIVITYイベントをトリガーとして、ユーザー側のインスタンス置換ワークフロー（例: EventBridgeルール→Auto ScalingやSSM/EC2操作）を開始することで復旧を自動化できます。本機能は追加料金なしで利用でき、AWS CommercialおよびAWS GovCloud (US)の全リージョンで利用可能です。詳細は「Monitor Amazon ECS Container Instance Health」のドキュメントを参照してください。

影響範囲・利用シーン ​

  • 対象ユーザー: コンテナ運用チーム、SRE、DevOpsエンジニア、Fargate/ECSマネージドインスタンスを利用している開発者
  • 利用シーン: EBS障害やホスト異常でECSエージェントが切断された場合の自動復旧（Fargate/ECS Managed Instances）や、ECS on EC2でのインスタンス置換ワークフロー起動
  • 運用効果: 手動介入を減らしてワークロードのダウンタイムを短縮、障害の見落としを低減しアプリケーション可用性を向上

技術的な注意点 ​

  • 自動修復の適用範囲: 自動的な復旧はAWS FargateとAmazon ECS Managed Instancesに対して実行されます。Amazon ECS on EC2ではヘルスイベントが発行されるのみで、インスタンス置換はユーザー側のワークフローで実行する必要があります
  • IAM権限: イベント連携や自動復旧ワークフロー（インスタンスのドレイン、登録解除、Auto Scaling起動、SSM実行など）を組む場合は、該当するECS/EC2/Auto Scaling/SSM/EventBridgeの権限を付与してください
  • イベント連携: AGENT_CONNECTIVITYのヘルス変更イベントはEventBridge/CloudWatch Events等でキャプチャしてワークフローを起動できます。カスタム自動化を組む場合はEventBridgeルールとターゲット（Lambda、Step Functions、Auto Scaling APIなど）を利用します
  • リージョン制限: 公表によればAWS CommercialおよびAWS GovCloud (US)の全リージョンで利用可能です。特定のリージョンでの実装状況はドキュメント/コンソールで確認してください
  • コスト: 本機能自体に追加料金は発生しません。ただし、自動復旧ワークフローで起動する代替インスタンスや関連サービス（Lambda実行、Step Functions、追加のEC2/Fargateリソース等）には通常の料金が発生します

参考情報 ​

[Sagemaker Mlops] SageMaker MLflow now supports customer managed keys ​

概要 ​

SageMaker MLflow が AWS KMS のカスタマー管理キー（CMK）を使った暗号化をサポートしました。組織が独自の鍵でデータを保護・監査できるようになり、コンプライアンス要件に対応しやすくなります。

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

SageMaker MLflow App で保存されるデータを、顧客が管理する KMS キー（CMK）で暗号化できるようになりました。これにより、対称型の AWS KMS キーを用いてアーティファクトやメタデータ等のデータを顧客管理下の鍵で暗号化し、アクセスや鍵操作は AWS CloudTrail を通じて監査可能です。CMK は MLflow App と同じ AWS アカウント・リージョンに作成する必要があり、サポートされるのは対称キーのみです。本機能は MLflow App が提供されている全リージョンで一般利用（GA）となっています。

影響範囲・利用シーン ​

  • 対象ユーザー: セキュリティ/コンプライアンス要件が厳しい企業、クラウドセキュリティ/ガバナンス担当者
  • 利用シーン: MLflow に保存するモデルアーティファクトや実験メタデータの鍵管理を組織ポリシーに合わせて統制したい場合
  • 運用効果: 鍵のライフサイクル（作成・ローテーション・削除）やアクセスを自社で管理でき、CloudTrail による操作ログで監査証跡を取得可能になることで、コンプライアンス監査やセキュリティレビューが容易になる

技術的な注意点 ​

  • IAM権限: KMS キーを使用するための kms:Decrypt/kms:Encrypt/kms:GenerateDataKey 等の権限を付与し、SageMaker サービスプリンシパルが利用できるようキー ポリシーを設定してください
  • KMSキー種別: 対称型の AWS KMS カスタマー管理キーのみサポート。非対称キーや外部キー（外部 KMS）は不可
  • キー配置: CMK は SageMaker MLflow App と同一の AWS アカウントおよびリージョンで作成する必要があります
  • CloudTrail監査: KMS および SageMaker による鍵操作やアクセスは CloudTrail に記録されます。監査要件に応じて CloudTrail の設定（ログ保管先、ログイベント管理）を確認してください
  • リージョン制限: 本機能は MLflow App が提供されているリージョンで一般提供されています。利用前に対象リージョンで MLflow App が利用可能か確認してください
  • コスト: KMS の使用に伴う API 呼び出しやキー管理の料金が発生します。キーの作成数やリクエスト数によりコストが増加する可能性があります
  • 互換性/注意点: SageMaker 側の設定方法（コンソール/CLI/SDK）で CMK を指定する必要があります。既存のデータを新規 CMK に切り替える場合の移行手順や影響を事前に検討してください

参考情報 ​

[Govcloud Us] Amazon EKS now supports multiple external OIDC identity providers per cluster ​

概要 ​

Amazon EKSが1クラスタあたり最大10個までの外部OpenID Connect（OIDC）アイデンティティプロバイダをサポートしました。これにより社員・委託業者・CI/CD等、異なるユーザ群ごとに個別のIdPを直接クラスタへ紐付けできます。

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

変更点の要約:

  • 1つのAmazon EKSクラスタに対して最大10個の外部OIDCプロバイダを関連付け可能になりました。
  • 各プロバイダは独立して設定・管理でき、ユーザやワークロードはそれぞれのIdPを通じて認証・アイデンティティマッピングされます。
  • 既存のIAM認証（aws-auth等）は引き続き併用可能であり、統合や中継ブローカーを挟まずに複数IdPを直接扱えます。
  • プロバイダの追加は従来どおりAWS Management ConsoleまたはAssociateIdentityProviderConfig API（AWS CLI / SDK経由）で行います。
  • 追加料金はなく、Amazon EKSが利用可能なリージョンで提供されます。 技術的な補足:
  • 「外部OIDCプロバイダ」は一般的にOkta、Azure AD、Google WorkspaceなどのOIDC準拠のIdPを想定します。
  • 各プロバイダごとにIssuer URLやクレーム（username/group）マッピング、JWKSエンドポイントなどの設定情報を登録します。
  • 認証後のアクセス制御はKubernetes RBACで行うため、各IdPからのクレームを踏まえたRole/RoleBinding/ClusterRoleBindingの設計が必要です。
  • 既存のIAMベース認証（例: IAMユーザー・ロールをKubernetesユーザにマップする設定）とは並列で運用できます。

影響範囲・利用シーン ​

  • 対象ユーザー: クラスタ管理者、セキュリティチーム、SRE、エンタープライズのIdP管理者
  • 利用シーン: 社員・契約者・CI/CD用のIdPを分けたマルチテナント環境、異なる組織間でのクラスタ共有、IdP移行フェーズでの段階的切替
  • 運用効果: 中継ブローカー不要で直接IdPを紐付け可能になるためアクセス構成が簡素化され、各ユーザ層ごとのポリシー運用が容易に。複数IdPの並存で移行コストや単一障害点のリスクが低減される

技術的な注意点 ​

  • IAM権限: eks:AssociateIdentityProviderConfig 等のEKS操作権限が必要です（DescribeCluster等も含む）。コンソール操作権限とAPI操作権限を確認してください。
  • リージョン制限: Amazon EKSが利用可能な全リージョンで提供されています。GovCloud(US)のカテゴリで発表されていますが、対象リージョンでの提供状況は事前に確認してください。
  • 制限事項: 1クラスタあたりの外部OIDCプロバイダ数は最大10個です。設計時にこの上限を考慮してください。
  • コスト: この機能自体に追加料金は発生しません。ただし、EKSの通常料金、IdP側のライセンス/利用料、運用・監査のコストは別途発生します。
  • 運用注意: 複数IdPから同一のクレーム（username/group）が発行されるとRBACでの衝突が起こり得ます。クレーム名、ユーザ名空間、グループ設計を明確化してから導入してください。
  • 検証推奨: 本番適用前にステージングで各IdPのIssuer/JWKS/claimマッピング、Token検証フロー、RBACの挙動を検証してください。

参考情報 ​

[Aurora] Amazon Aurora now supports PostgreSQL 18.4, 17.10, 16.14, 15.18, and 14.23 ​

概要 ​

Amazon Aurora PostgreSQL互換エディションがPostgreSQLの最新マイナーバージョン（18.4、17.10、16.14、15.18、14.23）をサポートしました。これらはコミュニティのバグ修正やCVE対応、Aurora固有の改善を含みます。

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

今回サポートされたのはPostgreSQLのマイナーバージョン18.4、17.10、16.14、15.18、14.23です。各マイナーリリースにはPostgreSQLコミュニティによるバグ修正やセキュリティ修正（既知のCVE対応）が含まれており、加えてAurora固有の最適化・修正（エンジンとの互換性向上、パフォーマンス改善、運用性向上など）が適用されています。運用面では、スケジュールされたメンテナンスウィンドウ中に自動マイナーアップグレードを実行可能で、大規模環境向けにはAWS OrganizationsのUpgrade Rollout Policyを使って段階的に複数DBクラスタをオーケストレーションできます。推奨される運用フローは、まず非本番（低優先度）環境で新しいマイナー版を検証し、その後段階的に本番へ展開することです。Aurora自体は高パフォーマンスと可用性を目指した設計で、スケール・トゥ・ゼロのサーバーレス、Aurora Global Databaseによるリージョン冗長化、I/O集約ワークロード向けのAurora I/O-Optimized、継続的バックアップや組み込みセキュリティなどの機能を提供します。詳細な影響や既知の修正は各リリースノートで確認してください。

影響範囲・利用シーン ​

  • 対象ユーザー: Aurora PostgreSQLを利用するアプリケーションオーナー、DB管理者、SRE
  • 利用シーン: セキュリティパッチ適用（CVE対応）、バグ修正適用、パフォーマンス改善を取り込みたい時のマイナーアップグレード
  • 運用効果: 自動マイナーアップグレードとOrganizationsのロールアウトポリシーを組み合わせることで大規模環境の段階的なロールアウトが可能になり、リスク低減と迅速なCVE対応が実現できる

技術的な注意点 ​

  • IAM権限: DBクラスタのアップグレードや自動アップグレード設定にはrds:ModifyDBCluster / rds:ModifyDBInstance等の権限が必要です。Organizationsポリシーの適用にはOrganizations管理権限が必要になります。
  • リージョン制限: 新しいエンジンバージョンのサポート状況はリージョンにより展開タイミングが異なるため、コンソールやAPIで対象リージョンの利用可否を確認してください。
  • ダウンタイム/影響: マイナーアップグレードは通常同一メジャーバージョン内の非破壊的アップグレードですが、クラスタのリブートやフェイルオーバーが発生する可能性があり、短時間の接続切断や遅延が生じます。メンテナンスウィンドウでの適用を推奨します。
  • 互換性と拡張機能: 使用している拡張（PostGIS、pglogical、pg_stat_statements等）が新マイナーバージョンでサポートされているか検証してください。パラメータグループやカスタム設定が期待通り動作するか事前に確認が必要です。
  • 自動アップグレード設定: 自動マイナーアップグレードを有効にするとメンテナンス中に自動で適用されます。大規模環境ではOrganizationsのUpgrade Rollout Policyで段階的適用を設計してください。
  • コスト: アップグレード自体に直接費用は発生しませんが、フェイルオーバーやリブートに伴うパフォーマンス影響で間接的な運用コストが発生する可能性があります。また、Aurora I/O-Optimized等の構成変更はコストに影響します。
  • 事前準備: 公式のリリースノートとCVEリストを必ず確認し、バックアップ（スナップショット）と検証環境での事前テストを行ってください。

参考情報 ​

[General] Amazon SageMaker HyperPod enhances support for Ray ​

概要 ​

Amazon SageMaker HyperPodがRayのサポートを強化しました。Studio上での対話的開発、組み込みの可観測性、障害耐性を備えた分散トレーニング、及び高速化された推論機能が利用可能になりました。

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

主な強化点は以下の通りです。

  • マネージド開発環境: SageMaker StudioのWeb UIからRayクラスタを作成・編集・監視・削除でき、JupyterLab/Code EditorやローカルIDEを実行中のクラスタにアタッチしてクラスタ規模の計算資源に対して対話的に反復開発が可能です。マルチノードRayクラスタがローカル開発環境のように振る舞い、変更を即座にテストできます。
  • 組み込み可観測性: Amazon Managed Service for Prometheus上のメトリクスとGrafanaダッシュボードがプロビジョニングされ、Ray Dashboardへはセキュアなブラウザリンクでワンクリックアクセスできます。ジョブ実行の初回から可視化を提供します。
  • 耐障害性のあるトレーニング: ノードの自動復旧やハング検出によりGPU障害やジョブの停止、学習の急落やスループット低下に対処します。Tiered checkpointing（クラスタメモリからの状態復元）により良好な“goodput”（有効な処理量）を最大化します。タスクガバナンス（クォータ、優先度、プリエンプション）でGPU利用率を改善します。
  • 推論の高速化: Ray Serve向けに階層化されたキー・バリューキャッシュを導入し、time-to-first-tokenを短縮します。SageMaker JumpStartのモデルを直接デプロイ可能です。
  • 運用・統合の柔軟性: オープンソースのRayコードは変更不要で動作します。SageMaker Studioに統合された体験をそのまま使うか、個別機能だけを自社MLプラットフォームに組み込むことも可能です。
  • 実行基盤: HyperPod上のRayサポートはAmazon EKSでオーケストレーションされます。利用可能リージョンはSageMaker HyperPodがサポートするAWSリージョンに依存します。

影響範囲・利用シーン ​

  • 対象ユーザー: 機械学習エンジニア、データサイエンティスト、MLOps/SREチーム
  • 利用シーンまたは効果: 分散データ処理・分散学習・強化学習・モデルサービングをRayで運用・開発する際に、対話的開発と本番級の可観測性・耐障害性を短期間で導入可能
  • 運用効果: ジョブハングやGPUフォールトからの自動回復、タスクガバナンスによるGPU利用率向上で長時間学習の成功率と有効なGPU時間あたりの処理量（goodput）が向上
  • 開発速度: Studioからクラスタにアタッチして即時検証できるため、コード変更ごとにジョブを再投入するオーバーヘッドを削減
  • 導入柔軟性: Open-source Ray互換性により既存Rayコードの移行コストが低く、必要な機能のみを取り込める

技術的な注意点 ​

  • IAM権限: SageMaker Studio、EKS、関連リソース（Prometheus、Grafana、S3など）への適切なIAMロール/権限が必要。事前に最小権限ポリシーを確認してください。
  • リージョン制限: SageMaker HyperPodがサポートするAWSリージョンでのみ利用可能です。利用前に対象リージョンでの提供状況を確認してください。
  • コスト: SageMaker HyperPod/EKSクラスタの稼働コスト、GPUインスタンス費用、Amazon Managed Service for PrometheusおよびGrafanaの料金、ネットワーク/ストレージ（Checkpoint保存先）の費用が発生します。JumpStartモデル利用時の追加コストも考慮してください。
  • EKS要件: HyperPod上のRayはAmazon EKSでオーケストレーションされます。クラスタ設定、ノードグループ（GPUインスタンスタイプ）、VPC/サブネット、セキュリティグループの設計が必要です。
  • ネットワーク/セキュリティ: StudioからEKS上のRay Dashboardへアクセスするためのセキュアなブラウズ経路が提供されますが、社内ネットワークポリシーやプライベートサブネット構成に応じた追加設定が必要な場合があります。
  • チェックポイントとストレージ: Tiered checkpointingはクラスタメモリを活用してgoodputを高めますが、永続化やリカバリ要件に応じたS3等の外部ストレージ設計が必要です。
  • 互換性: オープンソースRayは変更不要で動作しますが、サポートされるRayのバージョンや互換性はドキュメントで要確認です。
  • 運用挙動: タスクガバナンスのプリエンプションや自動復旧は動作中のタスクに影響を与える可能性があるため、再試行/チェックポイント戦略を設計してください。

参考情報 ​

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

Copyright © 2026