AWS What's New Digest

Appearance

2026年07月30日 ​

[Msk] Amazon MSK Express brokers now delivers Apache Kafka data to Amazon S3 ​

概要 ​

Amazon MSK Express ブローカーが Apache Kafka データを Amazon S3 の汎用バケットへ直接配信できる機能を提供開始しました。フルマネージドで自動スケーリング・リトライ・バックプレッシャー制御を行い、高スループットかつ低コストでの S3 配信を実現します。

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

MSK Express ブローカーは、Apache Kafka のデータを Amazon S3（汎用バケット）へ直接配信するフルマネージド機能を追加しました。主な特徴は以下の通りです。

  • フルマネージド配信: コネクタの運用（デプロイ・スケーリング・バージョン管理・セキュリティパッチ適用）をユーザーが行う必要がなく、MSK Express が自動で処理します。
  • 高スループット: S3 への配信は最大で 10 GB/s のスループットをサポートします。
  • 信頼性: スケーリング、リトライ、バックプレッシャー管理により配信ギャップを発生させずエンドツーエンドの信頼性を提供します。
  • コスト削減: AWS の試算では、自己管理のコネクタと比べて最大で約 60% の取り込み/配信コスト削減が見込めます。これは追加のブローカー egress スループットのプロビジョニングが不要になることにも起因します。
  • 適用ケース: ログアーカイブ、コンプライアンス保存、Kafka のリプレイ、AI/ML モデル学習のためのデータ蓄積 など。
  • 利用開始: MSK Express ブローカーを提供しているすべてのリージョンで利用可能（リージョン単位の提供状況は確認が必要）。 注意点: 記事はデータフォーマット（例: Avro/Parquet/JSON のいずれで出力されるか）やロールアウト時の具体的なバッチ単位・ファイル分割ポリシーの詳細を明示していません。既存のコネクタで行っていた変換やカスタム処理が必要な場合は、追加の処理を検討する必要があります。

影響範囲・利用シーン ​

  • 対象ユーザー: Kafka を利用してデータ取り込み・蓄積を行うデータエンジニア、SRE、プラットフォームチーム
  • 利用シーン: ログアーカイブやコンプライアンス保存、Kafka データの長期保存とリプレイ、AI/ML の学習データ蓄積など、Kafka データを S3 に継続配信したいユースケース
  • 運用効果: コネクタのデプロイ・スケーリング・運用負荷を軽減し、配信の信頼性を向上。チーム間の調整や connector プラグイン管理の手間を削減
  • コスト影響: 自己運用のコネクタ群に比べて総コスト削減（記事ベースで最大約60%）が期待できるが、S3 ストレージや PUT リクエスト等の通常の S3 費用は別途発生します

技術的な注意点 ​

  • IAM権限: MSK がターゲット S3 バケットへ書き込めるように、適切なバケットポリシーまたは IAM ロール (PutObject 等) を付与する必要があります。SSE-KMS を使う場合は KMS キーへのアクセス許可も必要です。
  • リージョン制限: MSK Express ブローカー提供リージョンで利用可能。全リージョンで自動的に利用可能とは限らないため、利用前に対象リージョンでの提供状況を確認してください。
  • コスト: MSK Express の配信機能に対する料金が発生する可能性があります（記事参照）。さらに S3 のストレージ料金、PUT/GET リクエスト料金、データ転送費用や KMS 使用料などが別途発生します。詳細は料金ページを確認してください。
  • データ整合性/フォーマット: S3 へ書き出されるオブジェクトの分割単位やレコードの順序保証、出力フォーマット（Avro/Parquet/JSON 等）の仕様は確認が必要です。厳密なレコード単位の exactly-once 要求や、カスタム変換が必要な場合は追加設計が必要です。
  • セキュリティ: 転送中の暗号化や S3 側の暗号化設定、バケットポリシーでのアクセス制御、監査ログ（CloudTrail）設定を確認してください。
  • 既存コネクタとの共存: カスタム処理や特定のコネクタ機能が必要な場合は、従来のコネクタ運用を継続または併用する設計検討が必要です。

参考情報 ​

[Msk] Amazon MSK Express brokers now deliver data to streaming tables for Apache Iceberg ​

概要 ​

Amazon MSK Express ブローカーが Apache Kafka トピックを継続的に Apache Iceberg ストリーミングテーブル（Amazon S3 Tables 上の Iceberg テーブル）としてマテリアライズする機能を追加しました。セルフ管理のパイプラインと比べてデータ取り込み／配信コストを最大60%、ダウンストリームのクエリコストを最大30%削減できます。

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

この新機能は MSK Express ブローカー内で Kafka トピックをネイティブに Apache Iceberg テーブルに書き出す機能です。主な技術要素は以下の通りです。

  • 継続的マテリアライズ: Kafka のストリームをリアルタイムに Iceberg テーブル（Amazon S3 Tables）へ書き込み、データをテーブルとして即利用可能にします。
  • インラインのインテリジェントコンパクション: 高頻度取り込みによる多数の小さな Parquet ファイル問題（small-file problem）をブローカー側で解消し、クエリ性能とコストを予測可能に維持します。
  • 同時書き込みの調整: 高スループットコンシューマー間での競合を解消する組み込みの協調機構により、整合性と競合解決を提供します。
  • スループットとコスト面: Iceberg への配信は最大 10 GB/s をサポート（クラスタ/配信上限として記載）し、ネイティブ機能のため追加のコネクタパイプラインのブローカー送信帯域（egress）を増やす必要がなく、インフラ増強コストを抑えられます。
  • 互換性: 書き出したストリーミングテーブルは Apache Spark、Trino、Apache Flink など任意のクエリエンジン／処理フレームワークで参照・変換可能です。
  • 有効化方法: MSK コンソールから Express クラスターを選び数クリックで有効化、または MSK API / MCP サーバー経由で設定可能です。
  • 地域と料金: MSK Express ブローカーが提供される全リージョンで利用可能。詳細な料金は MSK の料金ページを参照してください。

影響範囲・利用シーン ​

  • 対象ユーザー: Kafka を利用するデータエンジニア、プラットフォーム／SRE、リアルタイム分析を行うデータサイエンティスト
  • 利用シーン: フロード検知やパーソナライゼーションなどのリアルタイム取り込みデータをほぼリアルタイムで Iceberg テーブルに統合して分析・ETL に利用するケース
  • 運用効果: カスタムコネクタや中間ストレージの運用・スケール負担を削減し、small-file 問題を解消することで下流クエリのパフォーマンス安定化とコスト削減が期待できる

技術的な注意点 ​

  • IAM権限: MSK コンソール/API でストリーミングテーブル配信を有効化するための MSK および S3（および関連する Iceberg テーブル管理用）の適切な IAM 権限が必要です。事前に実行ロールとポリシーを確認してください。
  • リージョン制限: 本機能は Amazon MSK Express ブローカーが提供されるリージョンで利用可能です。利用前に対象リージョンで Express ブローカーがサポートされているか確認してください。
  • コスト: ブローカー側のネイティブ配信は追加のブローカー egress 帯域を必要としない点でインフラコストを削減しますが、S3 ストレージ、リクエスト、Iceberg メタデータ操作、さらにクエリエンジンの処理コストは別途発生します。料金ページで詳細を確認してください。
  • スループット制限: ドキュメント上は最大 10 GB/s のサポートとありますが、実運用ではクラスターサイズや設定、S3 側のスループット（PUT/GET/リクエスト制限）に依存します。負荷試験で実効スループットとレイテンシ挙動を確認してください。
  • データ整合性とレイテンシ: インラインコンパクションは small-file 問題を緩和しますが、書き込み側での処理（コンパクションや協調）により取り込みレイテンシが増減する可能性があります。新規ワークロードでは取り込み遅延とクエリ鮮度のトレードオフを検証してください。
  • 互換性/フォーマット管理: Iceberg テーブルのスキーマ、パーティション戦略、スキーマ進化ルール（例: フィールド追加/削除）を事前に設計しておくこと。既存のコネクタやストリーミング処理との整合性を確認してください。

参考情報 ​

[Govcloud Us] Grok 4.3 from xAI is now available on Amazon Bedrock in AWS GovCloud (US-West) ​

概要 ​

xAIのGrok 4.3がAmazon BedrockでAWS GovCloud (US-West)に利用可能になりました。政府・規制対応環境で推論効率に優れたreasoning-firstモデルをBedrock経由で利用できます。

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

Grok 4.3は「reasoning-first」設計の大規模言語モデルで、推論時の“reasoning effort”を none / low / medium / high の4段階で設定可能です（高設定ほど推論深度・計算量が増加し、応答の推論品質が向上する代わりにレイテンシとコストが上がります）。エージェント向けのツール呼び出し（tool calling）や指示追従（instruction-following）に強く、構造化出力やマルチターン会話、検索系ワークフローに対して一貫した高品質な応答を返します。トークン効率が高く、高頻度推論でもコスト抑制に寄与します。Grok 4.3はAmazon Bedrock上の新しい推論エンジン「Mantle」で実行され、Mantleは価格性能（price/performance）を狙った最適化、ツール呼び出しのサポート、構造化出力フォーマット、応答ストリーミングをサポートします。今回のローンチにより、xAIはAWS GovCloud (US-West)のBedrockモデルプロバイダーに加わり、規制対応リージョンでの生成AIアプリ構築時に選択肢が拡がります。リージョンごとの対応状況はモデルのリージョン一覧を参照してください。利用はAmazon BedrockのAPI/SDK経由で行い、ストリーミング応答やツール呼び出しはクライアント実装側でのハンドリング（ストリーム受信、JSON構造の検証、タイムアウト管理等）が必要です。

影響範囲・利用シーン ​

  • 対象ユーザー: GovCloud環境で生成AIを使う開発者、SRE、セキュアな企業システム担当者
  • 利用シーン: 顧客サポート自動応答、ウェブ開発支援、判例調査や法務リサーチ、金融文書のQ&Aなどのエンタープライズ業務
  • 運用効果: 推論設定（reasoning effort）を業務要件に合わせて調整することで、品質とコストのトレードオフを運用レベルで最適化できる
  • 選択肢拡大: GovCloudでxAIモデルを直接使えるため、コンプライアンス要件があるワークロードでのモデル選択肢が増える

技術的な注意点 ​

  • IAM権限: Bedrockのモデル呼び出しやストリーミング、ツール統合に必要なIAMポリシーを確認・付与してください（Bedrock関連権限およびGovCloudアカウントのアクセス設定）。
  • リージョン制限: 本リリースは AWS GovCloud (US-West) 向けの提供開始を示しています。利用前に対応リージョンを確認してください（他リージョンでの提供状況は別途確認が必要）。
  • コスト: Grok 4.3はトークン効率が良い設計ですが、reasoning effort設定やストリーミング・ツール呼び出し頻度により推論コストは変動します。コスト試算と負荷テストを推奨します。
  • セキュリティ/コンプライアンス: GovCloudは法規制・データ居住要件向けですが、モデル使用時の入力データに含まれる機密情報の扱いやログ保管ポリシーについては自組織での確認が必要です。
  • Mantle/機能制約: Mantle が提供するストリーミング、構造化出力、ツール呼び出しの実装仕様（API形式、タイムアウト、エラーハンドリング）を事前に確認してください。クライアント側の実装（部分受信の組み立て、エラーリトライ）が必要です。
  • API/SDK: Amazon BedrockのAPI/SDK経由での呼び出しとなるため、SDKのバージョンやサンプル実装を確認してください。レスポンス形式（JSON schema等）の検証を組み込むと安全です。
  • レート制限/スロットル: 高頻度推論や大規模バッチ処理ではスロットルや同時実行制限に注意し、必要に応じてAWSサポートへクォータ引き上げを依頼してください。

参考情報 ​

[Bedrock] Gemma 4 models are now available on Amazon Bedrock in AWS GovCloud (US-West) ​

概要 ​

Google DeepMind の Gemma 4 モデル群が Amazon Bedrock 上で AWS GovCloud (US‑West) に追加されました。Gemma 4 は推論・マルチモーダル・エージェント・ソフトウェア工学などの生成AIワークロードに向けた複数のバリアントを提供します。

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

Gemma 4 ファミリは Bedrock 上で3つのバリアント（Gemma 4 31B、Gemma 4 26B‑A4B、Gemma 4 E2B）として利用可能になりました。これらは密結合（dense）および Mixture‑of‑Experts（MoE）アーキテクチャを含み、35以上の言語に対応、テキスト／画像／動画／音声のマルチモーダル入力をサポートします。主な特徴としてネイティブな関数呼び出し（tool/function calling）、構造化出力のサポート、推論ストリーミング、および長文コンテキスト処理（Gemma 4 31B は最大256k トークン）があります。各バリアントの想定用途は次の通りです：31B は推論・コーディング重視の長コンテキストワークロード向け、26B‑A4B はコスト／レイテンシ重視、E2B は最小サイズで対話型・低レイテンシ用途向けです。Amazon Bedrock 側ではコストパフォーマンス最適化とツール呼び出し・構造化出力・推論ストリーミングの改善が行われており、オープンウェイトモデルを用いた信頼性ある生成AIアプリケーションの構築が容易になっています。

影響範囲・利用シーン ​

  • 対象ユーザー: AWS GovCloud（US‑West）で政府機関や規制業務、セキュアなクラウド環境を必要とするエンタープライズ開発者、データサイエンティスト、SRE、AIプロダクトチーム
  • 利用シーン: 長文推論・ドキュメント要約や法務・医療文書の高精度解析、マルチモーダルエージェント（画像/音声を含む対話）、ソースコード生成・レビュー、ツール連携（関数呼び出し）を伴う自動化ワークフロー
  • 運用効果: モデル選択でコスト・レイテンシのトレードオフを最適化でき、長コンテキスト対応で大規模文脈を要する解析が可能。GovCloud での提供によりデータ主権やコンプライアンス要件を満たしたまま先進機能を利用可能

技術的な注意点 ​

  • IAM権限: Bedrock のモデル呼び出しには適切な IAM ポリシー（Bedrock の Invoke/Use 権限）が必要です。ロールやポリシーを事前に確認してください。
  • リージョン制限: 現在の発表は AWS GovCloud (US‑West) 向けの提供です。他のリージョン（例: ap‑northeast‑1 等）での可用性は別途確認してください。
  • コスト: MoE アーキテクチャや長コンテキスト処理は計算コストが高くなる可能性があります。モデルごとのレイテンシと料金を比較し、26B‑A4B や E2B での検証を推奨します。
  • モデル特性: Gemma 4 31B は最大256Kトークンのコンテキストウィンドウを持つため、長文解析に有利ですが、メモリとレイテンシの影響を考慮する必要があります。
  • API/運用: ネイティブ関数呼び出し・構造化出力・レスポンスストリーミングはプロンプト設計とクライアント実装の調整が必要です。ストリーミング受信・部分出力のハンドリングを実装してください。
  • セキュリティ／コンプライアンス: GovCloud 提供はデータ主権や規制対応を意図していますが、FedRAMP／ITAR 等の認可要件がある場合は AWS 担当と確認の上、追加の設定や監査ログ整備を行ってください。
  • テスト推奨: 本番導入前に代表的なプロンプト／入力形式（マルチモーダル含む）で性能・コスト・フォールト挙動を評価してください。

参考情報 ​

[Directory Service] AWS Managed Microsoft AD now supports Standard to Enterprise Edition upgrade ​

概要 ​

AWS Managed Microsoft AD（AWS Directory Service）が、Standard Edition から Enterprise Edition へ既存ディレクトリを移行せずにインプレースでアップグレードできるようになりました。コンソール、AWS CLI、APIから操作可能で、既存の信頼関係やアプリ連携、グループポリシーを保持します。

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

技術的には、Standard Edition（最大約5,000ユーザー／オブジェクト想定）で稼働しているAWS Managed Microsoft ADを、そのままEnterprise Edition（最大約500,000オブジェクトをサポート）へエディション変更できる機能が追加されました。アップグレードはAWS Management Consoleのディレクトリアクションメニューで「Upgrade Edition」を選択するか、AWS CLI/API経由で実行します。アップグレード中にDNS設定の変更やワークロードの再参加（re-join）は不要で、既存のトラスト関係、アプリケーション統合、グループポリシー設定は保持されます。リージョンについては、AWS Directory Service が提供されている全リージョンで利用可能とされています。料金はエディションに応じた Directory Service の課金体系に準じるため、Enterprise に切り替えると単価が上がる可能性があります。詳細手順や前提条件は管理者ガイドの手順に従ってください。

影響範囲・利用シーン ​

  • 対象ユーザー: Active Directory を大規模に運用している企業、ID/アクセス管理担当、SRE・インフラ運用チーム
  • 利用シーンまたは効果: Standard Edition のオブジェクト上限に達した環境で、ディレクトリを新規作成やワークロード再参加なしで拡張してスケールアップできる（最大数十万オブジェクト対応に拡張）
  • 運用効果: 移行工数・ダウンタイムの削減、既存信頼関係・ポリシーの維持によるアプリケーション互換性の確保
  • リスク／制限: エディション変更に伴う料金増、（ドキュメントに明記がない限り）ダウングレードは想定しない運用が必要。事前にバックアップや検証を推奨

技術的な注意点 ​

  • IAM権限: ディレクトリの変更を行うために Directory Service 関連の更新権限（例: ds:UpdateDirectory など）およびDescribe権限が必要。詳細はIAMポリシーで確認してください
  • リージョン制限: AWS Directory Service が提供されている全リージョンで利用可能と案内されていますが、利用前に対象リージョンでの提供状況をコンソール/ドキュメントで確認してください
  • コスト: Enterprise Edition は料金体系が異なるため、エディション切替後は時間単位の料金が上がる可能性があります。事前に価格ページで想定コストを確認してください
  • ダウンタイム: 記載ではDNSやワークロードの再参加は不要とされていますが、運用上の安全性確保のためメンテナンスウィンドウで実行し、影響確認を行ってください
  • バックアップ: 変更前にスナップショットや構成のバックアップ（設定のエクスポート、重要設定の記録）を取得することを推奨します
  • 互換性: 既存の信頼関係、グループポリシー、アプリ統合は保持されるとされていますが、アプリケーション側で想定外の影響が出ないか検証を行ってください
  • ダウングレード可否: ドキュメントにダウングレードについての明示がないため、エディション変更は不可逆の可能性が高い点に留意してください
  • 操作方法: コンソール、AWS CLI、API（Directory Service の該当アクション）から実行可能。手順は管理者ガイドを参照してください

参考情報 ​

[Ec2 Auto Scaling] Amazon EC2 Auto Scaling now supports Instance Refresh in CloudFormation ​

概要 ​

Amazon EC2 Auto Scaling が CloudFormation の新しい UpdatePolicy「AutoScalingInstanceRefresh」をサポートしました。CloudFormation テンプレートの更新でインスタンス置換が必要になった場合に、自動で Instance Refresh を実行できます。

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

CloudFormation の AutoScalingInstanceRefresh update policy をオートスケーリンググループに設定すると、テンプレートの更新でインスタンス置換が必要なプロパティを変更した際に CloudFormation が自動的に Instance Refresh をトリガーします。Instance Refresh により以下の機能が利用できます：root ボリュームの置換を含むインプレース更新、launch-before-terminate（新しいインスタンスを先に起動してから古いインスタンスを削除）、CloudWatch アラームに基づく監視、チェックポイントと bake time を使った段階的ロールアウト。更新中もスケーリングポリシーやヘルスチェックは有効のまま動作するため、サービス健全性を維持しつつロールアウトが可能です。スタックの失敗時は CloudFormation のスタックロールバックで復旧します。本機能は全リージョンで追加料金なしに利用できます。設定は CloudFormation テンプレート内で AutoScalingGroup リソースに対する UpdatePolicy: AutoScalingInstanceRefresh で行います（詳細は CloudFormation Template Reference を参照）。

影響範囲・利用シーン ​

  • 対象ユーザー: インフラ/プラットフォームエンジニア、SRE、DevOps チーム
  • 利用シーン: LaunchTemplate/LaunchConfiguration やボリューム設定等の変更によるローリング更新を CloudFormation で自動化したいケース
  • 運用効果: 手動でのインスタンス入れ替え作業を削減し、ローリング更新中もスケーリング/ヘルスチェックを維持してダウンタイムやリスクを低減できる
  • 注意となるユースケース: 大規模な ASG の更新ではチェックポイントや bake time を適切に設定しないと更新に長時間を要する可能性がある

技術的な注意点 ​

  • IAM権限: CloudFormation が Auto Scaling と関連リソースを操作できる IAM 権限（autoscaling:StartInstanceRefresh 等）が必要です
  • CloudFormation 設定: UpdatePolicy の指定は AutoScalingGroup リソースに対して行います（AutoScalingInstanceRefresh のパラメータで最大同時置換数、チェックポイント、アラーム等を指定）
  • アラーム連携: アラームベースの監視を使う場合は事前に CloudWatch Alarm を定義し、UpdatePolicy に参照させる必要があります
  • ロールバック: スタック更新失敗時は CloudFormation のスタックロールバックにより復旧しますが、ロールバック時の挙動（既に置き換えたインスタンスの扱い等）を事前に検証してください
  • リージョン制限: 本機能は全 AWS リージョンで利用可能とされています（追加料金なし）
  • コスト: 機能自体は追加料金なし。ただし launch-before-terminate により一時的に同時稼働インスタンス数が増えることで EC2 利用料金が増加する点に注意してください
  • 互換性/注意点: 更新トリガーとなる具体的なプロパティ（LaunchTemplate/LaunchConfiguration、BlockDeviceMappings 等）を理解しておくこと。Mixed Instances やカスタムライフサイクルフック等との相互作用は事前検証を推奨します

参考情報 ​

[Redshift] Amazon Redshift Data API announces long polling, session management, and flexible batch execution ​

概要 ​

Amazon Redshift Data APIが長い待機（long polling）、セッション一覧取得（ListSessions）、および柔軟なバッチ実行（ExecutionMode／パラメータ共有）をサポートしました。これによりAPIコールの削減、セッション可視化、バッチ実行時のトランザクション柔軟性が向上します。

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

主な新機能は以下のとおりです。長い待機（Long polling）: ExecuteStatement、BatchExecuteStatement、DescribeStatement、GetStatementResult、GetStatementResultV2 の各APIで WaitTimeSeconds パラメータを指定することで、SQLステートメントが終了するまで同期レスポンスの返却を遅延させ、頻繁なポーリングを不要にします。これによりHTTPリクエスト/レスポンスの往復やエラー再試行が減り、クライアント実装が簡素化されます。ListSessions: セッションを再利用するアプリケーション向けにアクティブなセッション一覧を取得し、状態（status）、コンピュートターゲット、データベース等でフィルタリングできます。外部でセッションIDを追跡する必要がなくなります。柔軟なバッチ実行（Flexible batch execution）: BatchExecuteStatement に ExecutionMode パラメータが追加され、AUTO_COMMIT モードを指定するとバッチ内の各SQLが独立してコミットされるため、個別の失敗がバッチ全体のロールバックを引き起こさなくなります（ETLや管理スクリプトでの部分処理許容に有用）。さらに BatchExecuteStatement が配列の SqlParameter を受け取り、パラメータを一度定義してバッチ内の任意のステートメントで参照可能になり、リテラル埋め込みの削減とパラメータ再利用を実現します。これらは Amazon Redshift Provisioned と Serverless のData APIで一般提供（GA）され、商用リージョンおよびAWS GovCloud (US) のData API対応リージョンで利用可能です。

影響範囲・利用シーン ​

  • 対象ユーザー: アプリケーション開発者、データエンジニア、SRE/運用チーム
  • 利用シーン: ポーリングを減らしたいクライアント（Lambdaやコンテナ）での結果取得、セッションを跨いでクエリを再利用するワークフロー、ETLやバッチ処理で部分成功を許容するケース
  • 運用効果: APIコール数と冗長リトライの削減、セッション管理の簡素化、バッチ処理中の個別失敗による全体ロールバック回避により処理効率と耐障害性が向上します

技術的な注意点 ​

  • IAM権限: 新しいAPI（ListSessions、BatchExecuteStatementの新モードなど）に対する redshift-data:ListSessions や redshift-data:BatchExecuteStatement 等の権限をポリシーに追加する必要があります
  • リージョン制限: GAはAmazon Redshift Data APIをサポートする全ての商用リージョンおよび AWS GovCloud (US) で提供されています。利用前に対象リージョンがData APIをサポートしているか確認してください
  • コスト: Data API呼び出し自体に追加の専用料金は通常発生しませんが、クエリ実行によるRedshiftクラスター/Serverlessのコンピュートコストやデータ転送は発生します。長い待機（WaitTimeSeconds）を使うとクライアント（例: Lambda）の実行時間が増え、課金影響が出る場合があります
  • トランザクション/互換性: ExecutionMode=AUTO_COMMIT を使うと各ステートメントが独立してコミットされ、従来の“バッチを一つのトランザクションで実行”する動作（失敗時に全ロールバック）が変わります。原子性が必要な処理は従来モード（単一トランザクション）を使用してください
  • クライアント実装: WaitTimeSeconds を利用する場合は、HTTPクライアントや呼び出し元サービス（Lambdaタイムアウト等）のタイムアウトを WaitTimeSeconds より長く設定してください。長時間ブロッキングに伴う接続管理やリトライ戦略を見直してください
  • パラメータ利用: BatchExecuteStatement の SqlParameter 配列によりパラメータを再利用できますが、パラメータ名・型の一致やプレースホルダ参照に注意し、SQLインジェクション対策としてパラメータ化を推奨します
  • 監査/セキュリティ: ListSessions によりセッション一覧が取得可能になるため、セッション情報へアクセスできるアカウントの制限やCloudTrail等での監査を検討してください

参考情報 ​

[Glue] AWS Glue announces VPC support, filter pushdown, and partition support for the REST API connector ​

概要 ​

AWS GlueのREST APIコネクタがVPC接続、フィルタプッシュダウン、パーティション対応をサポートしました。これによりプライベートなRESTエンドポイントへの安全な接続、必要データのみの取得、並列読み取りによる高速な取り込みがカスタムコード不要で可能になります。

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

主な新機能: ・VPCサポート: REST APIコネクタがVPC内のサブネット（プライベートサブネット）、VPN接続、またはAWS PrivateLink経由のエンドポイントへアクセス可能になりました。GlueはENIを作成してVPC内から直接APIへ接続するため、トラフィックをパブリックインターネットに露出させずにETLを実行できます。 ・フィルタプッシュダウン: Glueジョブのクエリ述語（例: where句に相当）をAPIネイティブなパラメータに変換して送信できるようになり、ソース側で絞り込みを行って対象レコードのみを返すため、転送データ量とジョブ実行時間が削減されます。実装上はAPIのパラメータ対応（フィルタ/クエリパラメータ）に依存します。 ・パーティションサポート: 大量データ・ページングAPI向けに、フィールドベース（例: 日付やIDレンジ）またはレコードカウントベース（ページサイズ/オフセット）という戦略でデータを分割し、複数のSparkワーカーで並列に読み取ることで取り込み時間を短縮します。これにより高スループットでの並列フェッチが可能です。 共通特徴: いずれの機能もカスタムコーディング不要でGlueのコネクタ設定から利用可能。これらはAWS Glueが利用可能な全ての商用リージョンで提供されています。

影響範囲・利用シーン ​

  • 対象ユーザー: データエンジニア、ETL開発者、SRE/運用チーム
  • 利用シーンまたは効果: プライベートネットワーク上のREST API（社内システム、パートナーAPI、独自プラットフォーム）からの安全なデータ取り込み。フィルタプッシュダウンにより不要データの転送コストを削減し、パーティションで並列化して大容量・ページネーションAPIの取り込み時間を短縮
  • 運用効果: ネットワーク経路の簡素化（VPC内完結）、データ転送量とGlue実行時間の削減、API側のスループットを活かした高速インジェスト
  • 制約: フィルタプッシュダウンとパーティションはソースAPIが適切なフィルタ／ページネーション／キー指定をサポートしていることが前提

技術的な注意点 ​

  • IAM権限: Glueサービスロールにiam:PassRoleとGlue実行権限に加え、VPC用ENIの作成や削除/参照（例: ec2:CreateNetworkInterface、ec2:DeleteNetworkInterface、ec2:DescribeNetworkInterfaces）が必要
  • ネットワーク設定: 使用するサブネットとセキュリティグループで外向き接続（必要ならNAT/ルート）やPrivateLink/VPN接続が適切に設定されていること。セキュリティグループでAPIホストへのアウトバウンドを許可
  • API要件: フィルタプッシュダウンはAPIがクエリパラメータ等でのフィルタをサポートしていることが前提。パーティション戦略はAPIがページサイズ/オフセット、トークン、またはキー範囲指定をサポートしている必要あり
  • スロットリングとレート制限: 並列リクエストを増やすとソースAPI側でスロットリングされる可能性があるため、並列度やリトライ/バックオフ設定を調整してください
  • コスト: Glueジョブの追加実行時間やDPUコスト、VPCエンドポイント（Interface Endpoint）やデータ転送料金、APIプロバイダ側のリクエスト課金が発生する場合あり
  • リージョン制限: AWS Glueが利用可能なすべての商用リージョンで利用可能（記事時点）。ただしリージョン固有のネットワーク構成やサービス制約は確認してください
  • 互換性/バージョン: コネクタ設定やGlue Studio/Glueジョブのバージョンに依存する可能性があるため、導入前にドキュメントの設定例とサンプルを事前検証してください

参考情報 ​

[WAF] AWS WAF adds pre-parse text transformations and new text transformations ​

概要 ​

AWS WAFがクエリ引数向けの「プリパース（pre-parse）テキスト変換」と、任意のルールで使える10種類の新しいテキスト変換を追加しました。これにより、アプリケーションが解釈する方法と同じ形でリクエストを正規化して検査できるようになります。

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

新機能は2点あります。1) プリパーステキスト変換（query arguments向け）: WAFがクエリ文字列をキー・バリューにパースする前に生のクエリ文字列を正規化します。これによりHTTPパラメータ汚染（HTTP parameter pollution）やパーサ間差分を突く回避（parser differential evasion）といった攻撃を防ぎやすくなります。プリパース変換は最大10個までチェーン可能で、例としてURLデコード、重複クエリ引数をカンマで結合（Combine Duplicate Query Arguments by Comma）、セミコロンをアンパサンドに置換（Replace Semicolons with Ampersands）などが利用できます。2) 新しいテキスト変換（任意のルールで使用可能）: 大文字化（Uppercase）、トリム（Trim）、空白除去（Remove Whitespace）、SHA256ハッシュ化などの業界標準オプションに加え、Amazon Threat Research Teamが開発したOS（コマンドライン）に配慮したデコード関数やJavaScriptデコード関数など、解析前の正規化に役立つ変換が追加されました。各新変換はWCU（WAF Capacity Unit）を10消費します。プリパースとポストパース（既存のテキスト変換）を同一ルール文内で重ねて適用できるため、細かい正規化ロジックを1ルールで構築できます。これらはすべてのAWSリージョンで利用可能です。

影響範囲・利用シーン ​

  • 対象ユーザー: WAFを使ってアプリケーション層の保護を行うセキュリティチーム、SRE、クラウド/アプリケーションエンジニア
  • 利用シーン: HTTPパラメータ汚染対策、複数エンコーディング／エスケープ手法に対するルールの正規化、シグネチャ／カスタムルール適用前の入力整形
  • 運用効果: ルールの誤検知・見逃しを減らし、アプリケーションが解釈する形に近い検査が可能になることで回避テクニックへの耐性が向上
  • 導入影響: 複雑な正規化ロジックをWAF側で集約できるためルール数削減や管理容易化が期待できる一方、WCU消費増加によりWeb ACLの容量計画が必要

技術的な注意点 ​

  • IAM権限: WAFのルール・Web ACLを編集する権限（waf:UpdateWebACL等）が必要です。事前に最小権限を確認してください
  • リージョン制限: 発表によれば全リージョンで利用可能です。ただしグローバルリソース（CloudFront用Web ACL等）の取り扱いは別途確認してください
  • コスト: 新しい各テキスト変換は10 WCUを消費します。記事では「追加料金は発生しない」とあるものの、WCU増加はWeb ACLの課金対象となるため総コストに影響する可能性があります。WAFのWCUベースの料金を確認してください
  • チェーン制限: 1ルール内でプリパース変換は最大10個までチェーン可能です。過剰なチェーンは処理負荷や意図しない変換順序の副作用を招くため注意が必要です
  • 適用範囲: プリパース変換はクエリ文字列（query arguments）向けです。ボディやヘッダに対するプリパースは別途既存の変換を使用してください
  • 運用上の注意: 変換によるアプリケーション側との解釈差がないかステージング環境で十分に検証してください。特に重複パラメータやセミコロン／アンパサンド変換はアプリ挙動に影響する可能性があります
  • 互換性: 既存ルールやマネージドルールと組み合わせた場合の変換順序で判定が変わる可能性があるため、既存ルールの動作確認を推奨します

参考情報 ​

[Direct Connect] AWS announces AWS Interconnect - multicloud connectivity with Oracle Cloud Infrastructure in GA ​

概要 ​

AWSは「AWS Interconnect - multicloud」を一般提供（GA）し、Oracle Cloud Infrastructure（OCI）向けのマルチクラウド専用プライベート接続をサポートしました。これにより、AWSとOCI間でスケーラブルかつ冗長なプライベート接続を簡単に構築できます。

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

AWS Interconnect - multicloudはクラウド間のプライベート接続を目的に設計されたサービスで、従来の「自前でマルチクラウド接続を構築する」アプローチが抱えていたグローバルかつ多層的なネットワーク運用の複雑さを軽減します。OCIはパブリックプレビュー後に本GAで対応した最新のクラウドプロバイダで、既にGoogle Cloudにも対応済み、Microsoft Azureは2026年後半の対応予定です。本サービスは現在OCI向けにAWSリージョン us-east-1（北バージニア）で利用可能で、AWS Management Console、CLI、APIを通じてInterconnectを作成できます。主な利点は、プロビジョニングの迅速化、スケール可能で冗長な専用接続、クラウド間の一貫した操作体験、およびオープン仕様の採用による相互運用性向上です。実装面では、ルーティング（BGPなど）、ネットワークセグメンテーション、セキュリティ設定（ACL/セキュリティグループ）、およびデータ転送量に関するコスト設計が必要になります。

影響範囲・利用シーン ​

  • 対象ユーザー: クラウドアーキテクト、ネットワークエンジニア、SRE、マルチクラウド戦略を採用するエンタープライズ
  • 利用シーン: AWSとOCI間での低遅延・高帯域のデータ同期、バックアップ/DRレプリケーション、ハイブリッドアプリケーションのフロント/バックエンド分離、クラウド間データ移行や相互運用性確保
  • 運用効果: 自前構築に比べて接続のプロビジョニングと運用が簡素化され、障害耐性の高い専用経路でパフォーマンスとセキュリティを向上できる
  • 制約・注意点: 現時点ではOCI向けがus-east-1での提供に限定されるため、他リージョンのワークロードは別設計や追加ネットワークを検討する必要がある

技術的な注意点 ​

  • IAM権限: Interconnect作成・管理には該当するAWSリソース作成権限（Interconnect/Direct Connect相当の権限やVPC関連の権限）が必要です。事前にIAMロール/ポリシーを確認してください
  • リージョン制限: OCI向けのGA提供は現時点で us-east-1（N. Virginia）のみです。Google Cloudは既対応、Azureは2026年後半対応予定
  • ネットワーク設定: BGPやルーティング、VLAN/Virtual Interfaceの設定、オンプレ・他クラウドとの経路設計が必要です。VPCサブネット、ルートテーブル、セキュリティグループ等との整合性を確認してください
  • セキュリティ: トラフィックは専用接続経由ですが、アプリケーション層での暗号化やアクセス制御は別途実装が必要です。コンプライアンス要件に応じた監査/ログ設計を行ってください
  • コスト: Interconnectの利用料やデータ転送（クロスクラウド）の課金が発生する可能性があります。導入前に料金体系と帯域要件を評価してください
  • 運用注意: マルチクラウド接続は障害切替や冗長経路設計（複数インターコネクト、冗長VIF等）が重要です。監視・アラート設計（CloudWatch等）と運用手順を整備してください
  • 互換性・仕様: OCI側はオープン仕様を採用しており相互運用性は高いですが、OCI側での設定や制限事項（OCIのネットワーク・地域ポリシー等）も確認が必要です

参考情報 ​

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

Copyright © 2026