AWS What's New Digest

Appearance

2026年08月26日 ​

[Iot Core] AWS IoT Core now supports native InfluxDB routing for time-series data ​

概要 ​

AWS IoT CoreがネイティブなInfluxDBルールアクションをサポートし、デバイスの時系列データをカスタムコードや中間サービスなしで直接InfluxDB（自己ホストまたはAmazon Timestream for InfluxDB互換）へ書き込めるようになりました。

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

新しいInfluxDBルールアクションは、AWS IoT Coreのルールエンジンから送られてくるメッセージを自動的にInfluxDBのline protocol形式に変換して、指定したInfluxDB宛に書き込みます。書き込み先は（1）Amazon TimestreamのInfluxDB互換エンドポイント、または（2）自己ホストのInfluxDBクラスタのいずれかを指定可能です。バッチ処理は2モードをサポートしています： ・デバイス側バッチ: デバイスが事前にバッチ化したペイロードを送信し、ネットワーク・API呼び出しのオーバーヘッドを低減します。 ・サーバー側バッチ: IoTルールエンジンが個別メッセージを集約して一括でInfluxDBに書き込み、スループットとコスト効率を改善します。 ルールアクションでは宛先のデータベース情報、認証（トークンや証明書等）、およびバッチングパラメータ（バッチサイズやタイムアウトなど）を指定します。データはmeasurement、tag、field、timestampといったInfluxDBのline protocol要素にマッピングされるため、ミリ秒単位の高頻度テレメトリでも直接書き込めます。これにより中間のデータパイプライン（Lambda、Kinesis等）を自前で構築・運用する必要がなくなります。

影響範囲・利用シーン ​

  • 対象ユーザー: IoTプラットフォーム開発者、組み込み/エッジデバイス開発者、データエンジニア、SRE/運用チーム
  • 利用シーン: センサや計測器からの高頻度時系列データの直接収集・監視（例：ライフサイエンスの実験データ、産業機器のテレメトリ、IoTモニタリングダッシュボード）
  • 運用効果: 中間処理の削減によりアーキテクチャが簡素化され、レイテンシ低下とコスト最適化（特にバッチ化によるAPI呼び出し削減）が可能。データパイプライン構築工数と運用負荷を低減します。

技術的な注意点 ​

  • IAM権限: IoTルールの作成・編集権限と、必要に応じてTimestreamや他の関連サービスに対するIAM権限を確認してください（ルールエンジンが外部エンドポイントへアクセスする設定がある場合は追加の権限が必要となる可能性があります）。
  • 認証／ネットワーク: 自己ホストInfluxDBへ書き込む場合は接続エンドポイント、ポート、TLS設定、APIトークンや証明書をルールアクションに正しく設定する必要があります。VPC内の自己ホスト環境ではVPC接続（プライベート接続）、パブリックエンドポイント利用時はインターネット経由の通信制御を検討してください。
  • リージョン制限: この機能は「Amazon Timestream for InfluxDB」が利用可能なAWSグローバルリージョンで提供されます。利用予定リージョンでの対応状況を事前に確認してください。
  • フォーマット互換性: 送信データはInfluxDBのline protocolに変換されます。measurement/tag/field/timestampのマッピングやタイムスタンプ精度（ns/us/ms）の指定に注意してください。入力ペイロードの構造によってはルール側でのマッピング設定が必要です。
  • メッセージ/バッチ制限: AWS IoT Coreやルールエンジン側のペイロードサイズ制限やタイムアウト、バッチサイズ上限があるため、大規模バッチの設計時は制限を確認してください。
  • コスト: IoT Coreのメッセージ処理・ルールエンジンの利用料金、Timestreamの受信/ストレージ料金、自己ホストInfluxDBの運用コスト（ホスティング・ネットワーク・スケール）が発生します。バッチ設定でコスト最適化が可能です。
  • 可観測性/エラーハンドリング: ルール実行の失敗や書き込みエラー時のリトライ/デッドレター処理、監視用のメトリクス/ログ設定を事前に設計してください。

参考情報 ​

[General] AWS Batch now supports Amazon ECS Managed Instances ​

概要 ​

AWS Batchが新たにAmazon ECS Managed Instances（ECS MI）を計算オプションとしてサポートしました。AWS管理のインフラ上でGPUアクセラレーションや計算集約型バッチを簡便に実行できるようになります。

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

AWS Batch on ECS Managed Instancesは、AWSが管理するAmazon EC2インスタンス（ECS Managed Instances）を計算基盤として利用する新しいコンピュートオプションです。ユーザーはAWS BatchのCreateComputeEnvironment APIまたは管理コンソールでmanagedInstancesProviderブロックを指定してコンピュート環境を作成できます。managedInstancesProviderで許可するインスタンスタイプやネットワーキング設定（サブネット、セキュリティグループ等）を定義し、作成したコンピュート環境をジョブキューに関連付けてジョブを投入します。ジョブ実行はOn-Demand、Spot、予約キャパシティのいずれにも対応します。特徴として、GPU対応インスタンスの利用が可能であり、AMIの更新やセキュリティパッチ適用、インスタンスライフサイクル管理をAWSが自動で行うため、従来の顧客管理のAmazon EC2環境に比べて運用負荷が低減します。本機能はAWS Batchが利用可能な全リージョンでサポートされています。

影響範囲・利用シーン ​

  • 対象ユーザー: バッチ処理を実行するデータサイエンティスト、機械学習エンジニア、HPC／バッチワークロード担当のクラウドエンジニア
  • 利用シーン: GPUを使ったトレーニングや推論バッチ、レンダリング、並列シミュレーションなどの計算集約型ジョブをAWS管理のEC2インフラ上で実行
  • 運用効果: AMI更新やセキュリティパッチ、インスタンスのライフサイクル管理をAWSに委任することで運用工数を削減し、より短い導入時間でGPUインスタンスを利用可能
  • コスト影響: On-Demand/Spot/予約のいずれかを選択できるため柔軟だが、GPUインスタンスはコストが高め。Spotを活用してコスト最適化が可能

技術的な注意点 ​

  • IAM権限: ComputeEnvironment作成やジョブ実行にはAWS BatchとECSに関する適切なIAM権限とサービスリンクドロールが必要です。事前に権限を確認してください。
  • インスタンスタイプ/GPUドライバ: GPUを利用する場合は対象インスタンスタイプ（例: p/ g シリーズ等）をmanagedInstancesProviderで指定し、コンテナ内で必要なCUDA/ドライバ互換性を確認してください。コンテナイメージ側でドライバとの互換性を管理する必要があります。
  • ネットワーク/セキュリティ: サブネット、セキュリティグループ、ENI設定はmanagedInstancesProviderで制御します。VPCエンドポイントやNAT等のネットワーク構成に依存するため事前に設計を確認してください。
  • スポットの中断: Spotインスタンスを使用する場合は中断耐性（再試行、チェックポイント等）の設計が必要です。
  • カスタムAMIの利用: 本機能はAWS管理インフラを前提としているため、カスタムAMIや特殊なベアメタル設定の可否は導入前に公式ドキュメントで確認してください。
  • モニタリングとログ: CloudWatchメトリクス／ログやAWS Batch/ECSのメトリクスでジョブ・インスタンス状態を監視する運用設計を行ってください。
  • リージョン制限: 記事時点では「AWS Batchが利用可能な全リージョン」でサポートされていますが、導入前に利用リージョンでの正式サポート状況を確認してください。
  • コスト: AWSがAMI更新等の運用を行いますが、インスタンス利用料金（On-Demand/Spot/Reserved）は発生します。GPUインスタンスは高コストとなるためサイズと購入オプションを検討してください。

参考情報 ​

[Ec2] Capacity Reservation Resource Groups now support Amazon EC2 Capacity Blocks and interruptible Capacity Reservations ​

概要 ​

Capacity Reservation Resource Groupsが、従来のOn-Demand Capacity Reservations (ODCR)に加え、Capacity Blocks for MLおよびinterruptible（中断可能な）Capacity Reservationsをグループに追加できるようになりました。これにより、異なる予約タイプを横断してインスタンス起動を一元管理しやすくなります。

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

Amazon EC2のCapacity Reservation Resource GroupsはこれまでODCRのみをグループ化していましたが、本アップデートにより以下をグループへ追加できるようになりました：On-Demand Capacity Reservations、interruptible Capacity Reservations、Capacity Blocks for ML。利用手順は、Capacity Reservation Resource Groupを作成し、任意のCapacity Reservationをそのグループに追加してから、インスタンス起動時にそのリソースグループをターゲットに指定します。EC2 FleetおよびEC2 Auto Scalingグループと併用する場合は、予約タイプ間の優先順位（prioritization preferences）を指定し、予約群で容量が不足した際に自動的にEC2のOn-Demand容量へフォールバックする設定も可能です。追加料金は発生しません（ただし各種Reservation自体の課金やOn-Demand利用時の課金は別途発生します）。本機能は、Capacity Blocks for MLおよびinterruptible ODCRsがサポートされる全リージョンで利用可能ですが、AWS GovCloud (US) と中国リージョンは除外されています。

影響範囲・利用シーン ​

  • 対象ユーザー: クラウドインフラ/クラウドアーキテクト、SRE、データサイエンス/MLプラットフォームチーム
  • 利用シーンまたは効果: 複数種類の予約（ML向けブロック、割安な中断可能予約、ODCR）を1つの管理単位で利用して、ワークロードを予約容量に対して効率的に配置・起動できる。EC2 FleetやAuto Scalingと組み合わせて優先度設定や自動フォールバックを行うことで、可用性とコストを両立しやすくなる
  • 運用効果: 予約管理の簡素化によりインスタンス起動ポリシーの一元化が可能になり、予約枯渇時の自動フォールバックでサービス中断リスクを低減。MLトレーニング等で専用のCapacity Blockを使いつつ、予備としてinterruptible予約やOn-Demandを組み合わせる運用が容易になる

技術的な注意点 ​

  • IAM権限: Capacity ReservationおよびCapacity Reservation Resource Groupの作成・編集・使用に関するEC2権限（リソースグループのアクションや予約操作に対する権限）を付与する必要があります。具体的な最小権限は利用するAPI/CLIで確認してください。
  • リージョン制限: Capacity Blocks for MLおよびinterruptible ODCRsがサポートされるリージョンで利用可能。AWS GovCloud (US) と中国リージョンでは未対応です。
  • コスト: 機能利用自体に追加料金はなし。既存のCapacity ReservationやCapacity Blockの課金ルール、On-Demand利用時の課金は別途発生します。自動フォールバックでOn-Demandに切り替わるとOn-Demand料金が適用されます。
  • 中断特性: interruptible Capacity Reservationsは中断される可能性があるため、短時間のバースト型処理や再試行可能なワークロードに適しています。中断時の挙動（再配置やフォールバック）を設計に組み込んでください。
  • 互換性/運用: EC2 FleetおよびEC2 Auto Scalingと組み合わせて、予約タイプごとの優先度設定と自動フォールバックを構成できます。グループに追加した各予約の属性（インスタンスタイプ、アベイラビリティゾーン、期間など）は起動時のマッチングに影響します。

参考情報 ​

概要 ​

AWS Lambda MicroVMs が AWS PrivateLink に対応しました。これにより VPC 内のリソースから Lambda MicroVMs の API や各 MicroVM の HTTP エンドポイントへ、パブリックインターネットを経由せずにプライベートに接続できます。

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

今回のリリースで、Lambda MicroVMs に対して PrivateLink（Interface VPC エンドポイント）経由のプライベート接続が利用可能になりました。VPC 内で PrivateLink VPC エンドポイントを作成することで、MicroVM イメージの作成や MicroVM の起動といった MicroVM 管理 API への呼び出し、および各 MicroVM が公開する HTTP エンドポイントへのアクセスを、インターネット経由にせずに行えます。エンドポイントの作成は AWS マネジメントコンソール、AWS CLI、AWS CloudFormation、AWS SDKs から可能で、Lambda MicroVMs が利用可能な全リージョンでサポートされています。プライシングは AWS PrivateLink の料金が適用されます（エンドポイントの時間課金とデータ処理量に基づく課金）。

影響範囲・利用シーン ​

  • 対象ユーザー: 金融機関、医療、政府機関、セキュアなネットワーク分離が必要なアプリケーション開発者・運用者
  • 利用シーン: VPC 内システムから MicroVM 管理 API（イメージ作成・起動）や MicroVM の HTTP エンドポイントへアクセスする際に、トラフィックをパブリックインターネットに出さずに通信する必要があるケース
  • 運用効果: ネットワーク分離・コンプライアンス要件の遵守が容易になり、セキュリティ境界内でのテスト・本番運用、内部サービス間連携が可能になる（監査要件や規制対応の支援）

技術的な注意点 ​

  • IAM権限: VPC エンドポイント作成（例: ec2:CreateVpcEndpoint 等）や Lambda MicroVM 管理 API を呼び出すための IAM 権限を事前に確認し付与してください
  • エンドポイント種別: PrivateLink は Interface エンドポイント方式のため、ENI に紐づくセキュリティグループやプライベート IP 割当数、サブネットの IP 空き容量を考慮する必要があります
  • DNS/名前解決: プライベート DNS を有効化するか、VPC 内で適切な DNS 解決設定を行ってエンドポイント経由の名前解決を確保してください
  • リージョン制限: Lambda MicroVMs が利用可能なリージョンでサポートされます。各リージョンでの提供状況は AWS Capabilities by Region を確認してください
  • コスト: PrivateLink のエンドポイント時間課金およびデータ処理に応じた料金が発生します。大規模なデータ転送がある場合はコスト影響を見積もってください
  • 運用制約: VPC エンドポイントのソフト/ハードリミット（アカウントあたりのエンドポイント数やサブネットごとの ENI 数）に注意し、必要に応じてリミット引き上げを申請してください

参考情報 ​

[RDS] Amazon RDS for PostgreSQL supports minor versions 18.6, 17.11, 16.15, 15.19, and 14.24 ​

概要 ​

Amazon RDS for PostgreSQL がマイナー版 18.6、17.11、16.15、15.19、14.24 をサポート開始しました。これらはセキュリティ修正（CVE対応）やコミュニティによるバグ修正・改善を含むため、最新マイナー版への更新が推奨されます。

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

サポート開始されたマイナーバージョン：PostgreSQL 18.6、17.11、16.15、15.19、14.24。これらのマイナーリリースには既知の脆弱性（CVE）修正、バグフィックス、性能や信頼性の改善が含まれます。RDSでは以下の方法でマイナー版へ移行できます。

  • 自動マイナーアップグレード（Automatic minor version upgrades）: DB インスタンスに対して有効化すると、スケジュールされたメンテナンスウィンドウ中に自動で適用されます。
  • スケジュールされたメンテナンスウィンドウ: 管理コンソールまたは CLI からメンテナンスウィンドウを設定し、その時間帯にアップグレードを実行します。
  • AWS Organizations Upgrade Rollout Policy: 大規模環境で段階的に複数アカウント／複数環境を移行する際に、低優先度環境で検証してから本番環境へ展開するオーケストレーションを行えます。
  • Amazon RDS Blue/Green デプロイ: マイナーアップグレード時のダウンタイムを最小化するために、ブルー/グリーンの切替を利用して稼働中の環境への影響を抑えつつ移行できます。 運用面では、スナップショット取得、検証環境での事前テスト、接続ドライバや拡張（例: PostGIS、pglogical 等）の互換性確認が重要です。アップグレードはマイナーリリースのため通常は後方互換性が保たれますが、拡張やカスタム設定次第では影響が出る可能性があります。アップグレードはコンソール、AWS CLI、および SDK 経由で実行可能です。料金や地域での提供状況は Amazon RDS for PostgreSQL のページで確認してください。

影響範囲・利用シーン ​

  • 対象ユーザー: データベース管理者（DBA）、SRE/運用チーム、アプリケーション開発者、セキュリティ担当者
  • 利用シーン: セキュリティパッチ適用と脆弱性対応、バグ修正適用による安定稼働、定期的な保守（マイナーアップグレード）の実行
  • 運用効果: CVE リスク低減、パフォーマンス・安定性の向上、手順の自動化（自動マイナーアップグレード／Organizations による段階展開）による運用負荷軽減
  • 可用性/ダウンタイム影響: 標準的なマイナーアップグレードは短時間の再起動を伴うことがあり、Blue/Green を利用するとダウンタイムを最小化可能
  • 大規模運用への利便性: AWS Organizations Upgrade Rollout Policy により複数アカウント・複数環境の段階ロールアウトが可能で、安全な横展開が容易になる
  • コスト影響: Blue/Green など追加リソースを用いる場合は一時的なリソース課金が発生する可能性あり。スナップショット保存コストも考慮する必要あり
  • リージョン制限: 新バージョンの提供状況はリージョンによって異なるため、利用前にリージョンでの提供可否を確認してください

技術的な注意点 ​

  • IAM権限: ModifyDBInstance、DescribeDBInstances、CreateDBSnapshot、rds:StartAutomationExecution（Organizations のロールアウトを使用する場合の追加権限）など、アップグレードに必要な権限を付与してください
  • リージョン制限: 新しいマイナーリリースは順次リージョン展開される可能性があるため、事前に対象リージョンで利用可能か確認してください
  • バックアップ/スナップショット: アップグレード前に必ずスナップショットを取得し、問題発生時はスナップショットから復旧する手順を用意してください（マイナーアップグレードの「ロールバック」は直接不可）
  • メンテナンスウィンドウ: 自動マイナーアップグレードを有効にした場合、設定したメンテナンスウィンドウ中に適用されます。ウィンドウの時間帯は業務影響を考慮して設定してください
  • テスト/検証: ステージング環境で事前にアップグレード検証を行い、アプリケーション接続や拡張（extensions）・カスタムプラグインの互換性を確認してください
  • 自動アップグレード設定: インスタンス単位で自動マイナーアップグレードを有効/無効にできるため、環境ポリシーに沿って設定してください。Organizations のポリシーで一括制御も可能です
  • Blue/Green デプロイ注意点: 別の環境を作成して切替える方式のため、一時的に追加インスタンスやストレージが必要になりコストが発生します。VPC、パラメータグループ、セキュリティグループの整合性も確認してください
  • 拡張モジュールと互換性: PostGIS 等のサードパーティ拡張はバージョン差により互換性問題が生じることがあるため、事前に利用可能な拡張バージョンを確認してください
  • 互換性の範囲: マイナーリリースは基本的に後方互換性を保ちますが、非推奨機能やバグ修正により挙動が変わるケースがあるためアプリケーションレベルでの検証が必要です
  • コスト: 自動アップグレード自体に追加料金は発生しませんが、アップグレードに伴うスナップショット保管、追加の一時的リソース（Blue/Green）などは課金対象になります

参考情報 ​

[Connect] Amazon Connect Customer now lets you update the customer profile on a case or add a profile after a case is opened ​

概要 ​

Amazon Connectのエージェント機能が強化され、ケース作成後でも顧客プロファイルを変更したり、顧客が未特定だったケースに後からプロファイルを追加できるようになりました。これにより誤った紐付けの修正や本人確認後のプロファイル割当てが容易になります。

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

エージェントはオープン済みのケースに対して、誤って紐付けられた顧客プロファイルを別のプロファイルに更新したり、ケース作成時に顧客が特定できなかった場合に後からプロファイルを追加できます。これによりケース履歴の整合性が保たれ、共有電話番号や匿名問い合わせ、本人確認が必要な対応において適切に顧客情報を紐付けられます。変更はケースの履歴・応対記録に反映される想定で、CRM連携や分析データの正確性向上に寄与します。Amazon Connect 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)。詳細や導入手順はAmazon Connect Casesのページおよび公式ドキュメントを参照してください。

影響範囲・利用シーン ​

  • 対象ユーザー: Amazon Connectを利用するコンタクトセンターのエージェント、管理者、CRM連携担当者
  • 利用シーン: 誤った顧客プロファイルが紐づいたケースの修正、共有電話番号や匿名問い合わせで後から顧客を特定してプロファイルを追加する場面
  • 運用効果: ケース履歴の整合性向上により対応品質・分析精度が改善され、顧客体験（CX）の向上と誤対応の削減が期待できる
  • リージョン: 利用可能リージョンは記事記載の通り（N. Virginia, Oregon, Canada Central, Frankfurt, London, Seoul, Singapore, Sydney, Tokyo, Cape Town）

技術的な注意点 ​

  • IAM権限: エージェントがケースのプロファイルを更新するには、Connect Cases関連のケース編集・プロファイル参照/更新権限を適切に付与する必要があります
  • リージョン制限: 現時点で利用可能なリージョンは記事に列挙されたリージョンに限定されています。未対応リージョンでの利用は不可です
  • コスト: 機能自体の個別追加料金は明記されていませんが、Amazon Connectの利用料やデータ保存・転送に伴う料金が発生する可能性があります。コスト影響を事前に確認してください
  • 監査/ログ: 変更操作に対する監査要件がある場合は、CloudWatch/CloudTrail等のログ設定やConnect側の監査機能を確認し、操作履歴が記録されることを確認してください
  • 外部連携: CRMやデータレイクと連携している環境では、プロファイル変更が外部データの一貫性（顧客IDや重複管理）に影響を与えるため、同期・マッピングの設計を見直してください

参考情報 ​

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

Copyright © 2026