AWS What's New Digest

Appearance

2026年06月03日 ​

[RDS] Amazon RDS for Db2 launches support for IBM Db2 v12.1 and Db2 Community Edition ​

概要 ​

Amazon RDS for Db2 が IBM Db2 version 12.1 および Db2 Community Edition をサポート開始しました。これにより Standard／Advanced に加え、開発・テスト用途向けにライセンス料不要の Community Edition をマネージドサービスとして利用できるようになります。

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

Amazon RDS for Db2 が Db2 v12.1 をサポートし、これにより RDS 上で Db2 Standard、Db2 Advanced、Db2 Community Edition の各エディションを利用可能になりました。Db2 Community Edition は Standard/Advanced と同等の機能を備えつつ、開発およびテスト用途に関する商用ソフトウェアライセンス料が不要となるエディションです。利用手順は IBM の無料 Customer ID を取得し、Amazon RDS コンソールからインスタンスを作成するだけです。RDS の管理機能（自動バックアップ、パッチ適用、監視など）は引き続き利用可能で、Db2 v12.1 に含まれる新機能や互換性の詳細は IBM のドキュメントを参照してください。Amazon RDS for Db2 12.1（および Community Edition のサポート）は、現行の Amazon RDS for Db2 提供リージョンすべてで利用可能です。

影響範囲・利用シーン ​

  • 対象ユーザー: データベース開発者、DBA、SRE、ISV（Db2 によるアプリ開発や評価を行うチーム）
  • 利用シーンまたは効果: 開発／テスト環境や PoC（概念実証）で Db2 のフル機能をライセンスコストを抑えて利用可能。既存アプリの Db2 12.1 への移行検証やトレーニングにも適する
  • 運用効果: ライセンス費用を抑えつつ RDS の管理機能（バックアップ、監査、監視、スナップショット等）で運用負荷を低減。短期間でインスタンスを立ち上げて検証を高速化できる

技術的な注意点 ​

  • IBM Customer ID: Db2 Community Edition を利用するには IBM の無料 Customer ID が必要（事前に取得してください）
  • IAM権限: RDS インスタンス作成・管理に必要な IAM 権限（例: rds:CreateDBInstance、rds:ModifyDBInstance、rds:DescribeDBInstances 等）を付与する必要があります
  • リージョン制限: 記事発表時点では「Amazon RDS for Db2 が提供されている全リージョン」で有効とされていますが、詳細はコンソールで利用可能なエンジンバージョンを必ず確認してください
  • コスト: Community Edition 自体は開発／テスト向けにソフトウェアライセンス料が不要ですが、RDS のインスタンス時間、ストレージ、バックアップ、I/O、データ転送等の通常の AWS 利用料金は発生します。本番用途では IBM のライセンス条件を確認してください
  • 互換性/移行: Db2 v12.1 で追加・変更された機能や非推奨項目があるため、本番移行前にアプリケーションの互換性検証を実施してください（詳細は IBM ドキュメント参照）
  • 制約: Community Edition は記事の説明では開発／テスト向けのライセンス条件となっているため、商用本番利用の可否は IBM のライセンス条項を確認してください

参考情報 ​

[Iot Core] AWS IoT Core adds new logs to troubleshoot connectivity and authentication ​

概要 ​

AWS IoT CoreがCloudWatch Logs向けに2つの新しいログイベントタイプ（Ping、Connection.AuthNError）を追加しました。MQTTのKeep‑alive（Ping）送受信状態や接続時の認証エラーを詳細なエラーコード付きで記録でき、接続障害や認証問題のトラブルシューティングが容易になります。

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

追加された2つのイベントタイプは以下の通りです。

  • Ping: デバイスがMQTTのKeep‑alive（通常はクライアントからのPINGREQ）を送信した際に発行されるログです。Keep‑aliveの失敗や応答の欠落、接続が維持できていないクライアントを検出するのに役立ちます。これにより、ネットワーク断、クライアント側ハング、CoAP/HTTPブリッジ等での接続維持問題の早期発見が可能です。
  • Connection.AuthNError: 認証に失敗して拒否された接続試行を記録するログです。拒否理由を示す詳細なエラーコード（例: 証明書の期限切れ、証明書失効、署名不一致、認可ポリシーによる拒否など）が含まれ、どの資格情報／証明書が原因かを速やかに特定できます。 利用方法: AWS IoT Coreのイベントレベルログ設定でログレベル（例: INFO/WARN/ERROR）とCloudWatch Logsのロググループを指定し、該当のイベントタイプにオプトインします。記録されたログはCloudWatch Logsの通常機能（ロググループ、保持期間、サブスクリプションフィルタ、Logs Insightsクエリなど）で集計・検索・アラート化できます。記事によれば、この2つのイベントタイプはAWS IoT Coreが提供されているすべてのリージョンで利用可能です。詳細なログ項目やフィールドはAWS IoT Core開発者ガイドの「AWS IoT log entries」を参照してください。

影響範囲・利用シーン ​

  • 対象ユーザー: IoTデバイス運用者、SRE/運用チーム、IoTアプリ開発者、セキュリティチーム
  • 利用シーンまたは効果: 大量デバイスの接続維持状態監視（Pingログ）や接続失敗時の原因特定（Connection.AuthNError）により、障害対応と根本原因分析が高速化される
  • 運用効果: デバイス切断や認証エラーの原因をログレベルで早期に把握でき、証明書ローテーションや認証設定ミスの修正、SLA／可用性改善に寄与する
  • スケーラビリティ影響: 大規模フリートでPingログをフル取得するとログ量が増大するため、保存期間や収集ポリシーを設計する必要がある

技術的な注意点 ​

  • IAM権限: AWS IoT Core のログ設定変更権限（IoTの設定更新）およびCloudWatch Logsのロググループ作成/書込（logs:CreateLogGroup, logs:CreateLogStream, logs:PutLogEvents など）が必要です
  • リージョン制限: 記事は「AWS IoT Core が利用可能なすべてのリージョンで利用可能」と記載していますが、実際の利用前に対象リージョンでオプトイン設定が可能かコンソール/APIで確認してください
  • コスト: CloudWatch Logsの取り込み・保管・取得に伴う料金が発生します。Pingログは頻度が高くログ量が増えやすいため、保持期間の最小化、ログフィルタリング、サンプリングやサブスクリプション経由で集約するなどのコスト対策を検討してください
  • ログフォーマット/内容: Connection.AuthNErrorは詳細なエラーコードを含みます。各コードの意味と対処方法は開発者ガイドのログエントリ仕様を確認してください
  • 導入手順: IoT Coreのイベントレベルログ設定でログレベルとCloudWatch Logsグループを指定し、該当イベントタイプ（Ping、Connection.AuthNError）にオプトインする必要があります
  • 互換性/影響範囲: 既存のログ収集/解析パイプライン（CloudWatch Logs Insights、Lambdaサブスクリプション、Kinesis Firehose等）へ新しいイベントを取り込む場合はパーサやアラートルールの更新が必要です

参考情報 ​

[EKS] Amazon EKS and Amazon EKS Distro now supports Kubernetes version 1.36 ​

概要 ​

Amazon EKS と Amazon EKS Distro が Kubernetes 1.36 をサポート開始しました。新規クラスターの作成や既存クラスターのアップグレードが EKS コンソール、eksctl、IaC ツールから可能です。

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

Kubernetes 1.36 は複数の新機能とバグ修正を含んでおり、EKS 上で利用できるようになりました。主な強化点は以下の通りです。

  • User Namespaces（一般提供）: コンテナ内の root をホスト上の非特権ユーザーにマッピングできるようになり、コンテナからの突破が発生してもノードレベルの特権昇格を防ぎやすくなります。コンテナ分離の強化に貢献します。

  • Mutating Admission Policies (MAPs): CEL（Common Expression Language）ベースで API サーバー側でリソースを変換（ミューテート）できる仕組みが導入され、従来の外部 MutatingAdmissionWebhook に依存せずに低レイテンシ／高可用なインライン変換が可能になります。既存の webhookベースの処理と置き換える際は互換性を確認してください。

  • In-Place Pod-Level Resources Vertical Scaling: Pod を再起動せずに Pod レベルで共有される CPU／メモリのスケール（リソース割当の変更）を行える機能が追加されました。これにより、一部のワークロードで再起動を伴わないリソース調整が可能になります。ただしスケジューラ／kubelet とランタイムの対応や制約（ノード上のアロケーションや QoS の扱い）に注意が必要です。

  • Resource Health Status: Pod のステータスにデバイスヘルス情報が含まれるようになり、ハードウェア由来のクラッシュループなどの原因切り分けが容易になります。

EKS 側の提供情報として、EKS は EKS が利用可能なすべての AWS リージョン（AWS GovCloud (US) 含む）で Kubernetes 1.36 をサポートしています。アップグレードは EKS コンソール／eksctl／IaC（CloudFormation/Terraform 等）から実行可能で、EKS Distro のビルドは ECR Public Gallery と GitHub で入手できます。アップグレード前は EKS Cluster Insights やドキュメントで互換性と既知の問題を確認してください。

影響範囲・利用シーン ​

  • 対象ユーザー: Kubernetes クラスター管理者、プラットフォームエンジニア、SRE
  • 利用シーンまたは効果: セキュリティ強化（User Namespaces によるノード権限低減）、API レベルでの軽量なリソース変換（Mutating Admission Policies）、ダウンタイムを伴わないリソース調整（In-Place Vertical Scaling）、ハードウェア障害の原因特定の迅速化（Resource Health Status）
  • 運用効果: アップグレードによりコンテナの分離性と運用の柔軟性が向上。自動化されたポリシー適用や再起動不要のスケーリングで運用負荷低減が期待できる一方、互換性確認やテストが必要

技術的な注意点 ​

  • IAM権限: クラスター作成/アップデートには eks:CreateCluster / eks:UpdateClusterVersion / eks:UpdateClusterConfig / eks:DescribeCluster 等の適切な権限が必要です。eksctl や IaC による操作では追加の IAM 権限が必要な場合があります。
  • アドオン互換性: CoreDNS、kube-proxy、AWS VPC CNI などのアドオンやサードパーティコントローラーのバージョン互換性を事前に確認し、必要に応じてアドオンのアップデートを実施してください。EKS のマネージドアドオンが利用可能な場合は先に更新手順を確認すること。
  • ノード/ランタイム互換性: In-Place リソース変更や User Namespaces などは kubelet・CRI（container runtime）や OS イメージの対応が必要な場合があります。マネージドノードグループ／自己管理ノードの挙動を確認し、必要ならノードの AMI/OS/ドライバ更新を行ってください。
  • アップグレード手順: まずステージング環境で検証し、Cluster Insights で問題を確認したうえで本番にロールアウトしてください。Managed Nodegroup は順次置換が発生するため、ノード入れ替え時の pod 再スケジュールを考慮してください。
  • コスト: コントロールプレーンのバージョンアップ自体に追加課金は通常ありませんが、ノードの置換やスケール操作、ストレージ再アタッチ等により一時的な追加コストや容量消費が発生する可能性があります。
  • リージョン制限: EKS が利用可能な全リージョン（AWS GovCloud (US) 含む）でサポートされていますが、実施前に対象リージョンでの提供状況を公式ドキュメントで確認してください。
  • EKS Distro: EKS Distro の 1.36 ビルドは ECR Public Gallery と GitHub で入手可能です。バイナリ/イメージを用いる場合はリリースタグとハッシュを必ず確認してください。
  • 互換性/既知の問題: Kubernetes 1.36 の変更点や既知の問題は Kubernetes のリリースノートと EKS のバージョンライフサイクル情報で確認してください。

参考情報 ​

[Config] AWS Config now supports internal service linked rules ​

概要 ​

AWS Configがinternal service linked rulesをサポートしました。これにより、AWSサービス（例：AWS Security Hub CSPM）がAWS Configのマネージドルールを使ってサービス固有の設定評価をデプロイ・管理し、評価結果を直接当該サービスへ配信できるようになります。

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

internal service linked rulesは既存のサービスリンクドレコーダー機能を拡張する仕組みで、AWSサービス側がAWS Configのマネージドルールを用いてリソース構成の評価を行えるようにします。評価の結果はAWS Config経由で顧客に課金されることなく、ルールをデプロイした当該AWSサービスへ直接配信されます。これらの内部ルールは顧客が管理するAWS Configのレコーダーやルールとは独立して動作するため、顧客は従来どおりAWS Configをインベントリ、ガバナンス、コンプライアンス、監査用途に利用でき、同時にAWSサービスはサービス固有の評価を独自に管理できます。現時点でAWS Security Hub CSPMのinternal service-linked rulesは商用リージョン、GovCloud、Chinaの各リージョンで利用可能です。詳細な運用や評価結果の可視化方法は、ルールをデプロイする各AWSサービス側のドキュメントを参照してください。

影響範囲・利用シーン ​

  • 対象ユーザー: セキュリティ/コンプライアンス担当、SRE、クラウド運用チーム
  • 利用シーン: AWSサービス（例：Security Hub CSPM）が提供するCSPM評価を利用してサービス固有のセキュリティチェックを自動化・統合する場面
  • 運用効果: AWSサービス側での自動評価により、個別にルールを作成・管理する負荷が軽減され、監査・検出の一貫性が向上する。評価結果は当該サービスに直接届くため、該当サービスでの検出・対応フローにシームレスに組み込める

技術的な注意点 ​

  • IAM権限: internal service linked rulesはサービスリンクドロール（service-linked role）を使用して評価を実行します。顧客側で該当サービスのサービスリンクドロールや表示権限を確認してください。
  • リージョン制限: Security Hub CSPMのinternal service-linked rulesは商用リージョン、GovCloud、Chinaで利用可能です。その他のサービスやリージョンの対応状況は個別に確認してください。
  • コスト: AWS Configから顧客への追加課金は発生しないと明示されていますが、ルールを提供するAWSサービス側（例：Security Hub CSPM）の利用料金や評価頻度に伴うコストは別途発生する可能性があります。
  • 可視性/監査: 評価結果はルールをデプロイしたAWSサービスに配信されるため、結果の確認・履歴・CloudTrailへの記録方法は当該サービス側の実装に依存します。顧客がAWS Configコンソールで直接全ての内部評価結果を確認できるとは限りません。
  • 運用上の注意: internal service linked rulesはAWSサービス側が管理するため、顧客による設定変更や削除は制限される場合があります。ルールの挙動や合致条件、頻度などはサービスのドキュメントで確認してください。

参考情報 ​

[Deadline Cloud] AWS Deadline Cloud now supports persistent storage for Service Managed Fleets ​

概要 ​

AWS Deadline CloudのService-Managed Fleets(SMF)で、ワーカーに永続的なストレージ（Amazon EBS）を割り当てられるようになりました。これによりワーカーのライフサイクルでソフトウェアやアセットを保持でき、起動時間の短縮とジョブ完了の高速化が図れます。

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

これまでSMFワーカーはエフェメラル（揮発）ストレージのみを利用していたため、ワーカーが再作成・再起動されるたびにConda環境、Perforceワークスペース、シェーダキャッシュや資産コレクション等を再構築する必要がありました。今回のアップデートでは、Deadline CloudがSMFワーカーにAmazon EBSボリュームをアタッチして永続化できるようになり、これらのデータをワーカーのライフサイクルを跨いで保持します。永続ボリュームの数はワーカーごとに設定可能で、TTL（time-to-live）を指定してボリュームの保持期間を制御できます。これによりストレージコストとワーカー起動パフォーマンスのバランスを調整できます。永続ストレージ機能は、Deadline Cloudが提供されている全リージョンで利用可能で、料金は既存のSMF用EBS料金と同等です（詳細はDeadline Cloudの料金ページ参照）。

影響範囲・利用シーン ​

  • 対象ユーザー: VFX/アニメーション制作チーム、レンダーファーム管理者、CGオペレーター、3Dシミュレーションやゲームコンテンツ制作チーム
  • 利用シーンまたは効果: Conda環境やPerforceワークスペース、シェーダキャッシュなどの開発／ランタイム資産をワーカーの再生成後も保持し、ワーカー起動時間を短縮してレンダーやバッチ処理を高速化
  • 運用効果: ワーカーの再構築に伴うセットアップ作業・ネットワーク転送を削減でき、ジョブのスループット向上・コスト効率の改善が期待できる（特に頻繁にワーカーを循環させる環境で効果が大きい）

技術的な注意点 ​

  • IAM権限: EBSボリュームの作成・アタッチ・削除には該当するIAM権限（EC2/EBS関連）が必要になるため、事前にロール/ポリシーを確認してください
  • リージョン制限: Deadline Cloudが提供されているすべてのリージョンで永続ストレージは利用可能です（ただしご利用のリージョンでDeadline Cloud自体がサポートされていることを確認してください）
  • コスト: 永続EBSボリュームのストレージ料金が発生します。記事では「既存のSMF EBS料金と同等」とあり、ボリュームの数・サイズ・保持期間（TTL）によりコストが変動します。不要なボリュームを長時間保持しないようTTLを適切に設定してください
  • 運用/管理: ワーカーごとのボリューム数やTTLを設計段階で決める必要があります。永続化するデータのバックアップ／スナップショット運用方針も検討してください
  • 互換性: 永続化対象として例示されているのはConda環境、Perforceワークスペース、シェーダキャッシュ、アセットコレクション等です。アプリケーション固有の設定やロックファイル等については運用での確認が必要です

参考情報 ​

[Sagemaker Deploy] Amazon SageMaker Studio now sets up in seconds with model customization ready from the start ​

概要 ​

Amazon SageMaker Studioのクイックセットアップが20秒以内に完了するよう高速化され、新規に作成されたStudio環境ではサーバーレスのモデルカスタマイズ用の権限（マネージドポリシー）が自動で設定されるようになりました。これにより、サインイン後ほぼ即座にノートブックやファインチューニングなどの実験を開始できます。

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

変更点の要旨は次のとおりです。クイックセットアップ（SageMaker AI コンソール経由）で新しいStudio環境を作成すると、セットアップ時間が従来の数分から20秒未満に短縮されます。加えて、新規環境にはサーバーレスのモデルカスタマイズジョブ（例: ファインチューニング、報酬関数を用いた強化学習のチューニング、モデル評価、およびSageMaker/Bedrockエンドポイントへのデプロイ）を実行するための権限を付与する新しいマネージドポリシー AmazonSageMakerModelCustomizationCoreAccess が自動で作成・アタッチされます。これにより、従来必要だったIAMロールやポリシーの手動作成・設定が不要になり、実験開始の摩擦が低減します。既存のStudio環境については、権限を追加するための操作案内（アクション可能なメッセージ）とドキュメントへの直接リンクが表示され、ガイダンスに沿って権限を付与できます。本機能は、Amazon SageMaker StudioがサポートされているAWSの全商用リージョンで利用可能です。開始方法はSageMaker AI コンソールからクイックセットアップで新しいStudio環境を作るだけです。

影響範囲・利用シーン ​

  • 対象ユーザー: 機械学習エンジニア、データサイエンティスト、MLプラットフォーム担当者
  • 利用シーン: ノートブック起動やパイプライン開発、ファインチューニングやRLHFなどモデルカスタマイズ実験の即時開始
  • 運用効果: 初期セットアップの時間短縮と権限設定の省力化により、プロトタイピングのスピード向上と導入障壁の低下
  • セキュリティ影響: 新規環境に自動アタッチされるマネージドポリシーにより手動での誤ったロール設定が減る一方、付与される権限を確認する運用が必要
  • 既存環境への影響: 既存Studioには自動付与されないため、表示される案内に従って手動で権限を追加する必要がある

技術的な注意点 ​

  • IAM権限: 新しいマネージドポリシー AmazonSageMakerModelCustomizationCoreAccess が自動で作成・アタッチされます。内容を確認し、必要に応じて最小権限ポリシーやカスタムロールへ置き換えてください。
  • リージョン制限: SageMaker Studioがサポートされている全てのAWS商用リージョンで利用可能です（リージョンごとのサービス提供状況は確認してください）。
  • コスト: サーバーレスモデルカスタマイズジョブ、ファインチューニング、デプロイ、Bedrock利用などは別途料金が発生します。実行したジョブやエンドポイントの利用状況を確認してコスト管理してください。
  • 既存Studio環境: 新規環境のみ自動付与。既存環境では表示される案内からドキュメントに従い手動で権限を追加する必要があります。
  • セキュリティ運用: マネージドポリシーの適用範囲を監査（CloudTrail）し、S3バケットやネットワーク（VPCエンドポイント／アクセス制御）周りの最小権限とデータ保護を検討してください。
  • ログ/モニタリング: モデルカスタマイズジョブのログ・メトリクスはCloudWatchやS3に出力されます。成果物やログの保存先バケットのアクセス設定を確認してください。

参考情報 ​

[General] Amazon ElastiCache for Valkey now supports durability ​

概要 ​

Amazon ElastiCache（Valkey 9.0以降）が耐久性（durability）をサポートしました。これにより、マイクロ秒の読み取り遅延を維持しつつデータ損失を許容できないワークロードでElastiCacheを利用できます。

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

ElastiCacheはマルチAZにまたがるトランザクショナルログを用いてデータを永続化する耐久性機能を提供します。これにより高速なフェイルオーバー、データベース復旧、ノード再起動時のデータ保護が可能になります。耐久性は2つの書き込みモードを選択可能です。同期書き込み（synchronous）では、クライアントに応答する前に少なくとも2つのAZにデータを永続化し、単一障害点でのデータ損失をゼロにすることを目指します（書き込みレイテンシは一桁ミリ秒程度を想定）。非同期書き込み（asynchronous）では、クライアント応答後に永続化を行うためマイクロ秒レベルの書き込み遅延を維持しますが、稀に最大で約10秒分の未コミットデータが失われる可能性があります。いずれのモードでも読み取りはマイクロ秒レイテンシを維持します。対象ユースケースの例として、AIエージェントの長期メモリやワークフロー状態、RAG向けのナレッジベース、決済トークン化、リアルタイム在庫管理など、データ損失が許容できないが低レイテンシを要求する用途が挙げられます。耐久性はValkey 9.0以降で利用可能で、AWS マネジメントコンソール、SDK、CLIから新しいクラスタ作成時に耐久性オプションを選択して有効化します。料金や詳細はElastiCacheの価格ページ・ドキュメントを確認してください。

影響範囲・利用シーン ​

  • 対象ユーザー: アプリケーション開発者、SRE/運用チーム、AIエンジニア（低レイテンシかつデータ損失不可のシステム担当者）
  • 利用シーン: AIエージェントの長期メモリ保持、RAGナレッジベース、決済トークン管理、リアルタイム在庫・注文管理など、キャッシュ以上の永続性を要求するリアルタイム処理
  • 運用効果: フェイルオーバー／ノード再起動時のデータ損失リスク低減、迅速な復旧による可用性向上と運用負荷の低減

技術的な注意点 ​

  • Valkeyバージョン: DurabilityはValkey 9.0以降で利用可能です（新しいクラスタ作成時に選択）。
  • クラスタ作成: 既存クラスタでの後付け有効化が不可である可能性があるため、新規クラスタ作成時に耐久性オプションを選択してください。
  • 書き込みモードのトレードオフ: 同期書き込みはゼロデータ損失を目指すが書き込みレイテンシが一桁ミリ秒に増加する可能性、非同期はマイクロ秒書き込みを維持するが最悪約10秒の未コミットデータ損失リスクあり。
  • IAM権限: ElastiCacheのクラスタ作成・設定変更権限（例: elasticache:CreateCacheCluster / CreateReplicationGroup / Modify* 等）を持つことを確認してください。
  • コスト: 非同期モードは追加料金なしと明記されているが、同期モードや増加するストレージ・ネットワーク使用量に伴うコスト影響がある可能性があるため、料金ページで確認してください。
  • リージョン制限: 商用リージョン、AWS China、AWS GovCloud (US) で利用可能（記事時点）。

参考情報 ​

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

Copyright © 2026