Skip to content

2026年07月11日

[Ec2] Amazon EC2 network/EBS instances now available in additional regions

概要

Amazon EC2の新しいR8シリーズ(R8in、R8ib、R8idn、R8idb)が、AWSリージョン(東京および欧州フランクフルト/アイルランド)で利用可能になりました。これらはカスタム第6世代Intel Xeonスケーラブルプロセッサと第6世代Nitroカードを搭載し、前世代に比べてvCPUあたり最大43%の演算性能向上を実現します。

変更内容・新機能の詳細

R8シリーズはネットワーク性能またはEBS帯域に最適化された複数のバリアントを提供します。R8in/R8idnは最大600 Gbpsのネットワーク帯域を提供し(強化ネットワーキングEC2インスタンスの中で最大)、リアルタイム大規模データ分析、分散インメモリキャッシュ、AI/MLキャッシュ、5G UPFなどのネットワーク集約型ワークロードに適しています。R8ib/R8idbは最大300 GbpsのEBS帯域を提供し(非アクセラレータ型の汎用コンピュートインスタンスで最大)、高性能ファイルシステムやNoSQL、大規模商用DBやデータレイクなどブロックストレージ性能を重視するワークロードに適します。R8idn/R8idbはローカルNVMeストレージを備え、ローカル低遅延ストレージと高EBSスループットを同時に必要とする用途に向きます。R8シリーズはカスタム第6世代Intel Xeonと第6世代AWS Nitroカードにより、前世代(R6in/R6idn)比でvCPU当たり最大43%の計算性能向上を実現します。48xlarge、96xlarge、metal-48xl、metal-96xlの各サイズでElastic Fabric Adapter(EFA)をサポートし、密に結合されたクラスタでのレイテンシ低減とスケーリング性能向上が可能です。購入オプションはSavings Plans、オンデマンド、スポットに対応。今回の拡張でTokyo(アジアパシフィック)およびEurope(Frankfurt、Ireland)で利用可能になり、既存のUS East/US West/Europe(Spain)等のリージョンでも利用可能なサイズがあります。

影響範囲・利用シーン

  • 対象ユーザー: 高ネットワーク帯域や高EBS帯域を必要とするデータ分析者、分散キャッシュ/インメモリシステム運用者、DB/NoSQL設計者、Telco(5G UPF等)
  • 利用シーン: リアルタイム大規模データ解析、分散インメモリキャッシュ/AI/MLキャッシュフリート、高スループットEBSを要する高性能ファイルシステムやNoSQL、大規模商用DBやデータレイクのI/O集約ワークロード
  • 運用効果: vCPUあたりの計算性能向上と最大600Gbpsネットワーク/300Gbps EBS帯域により、より少ないインスタンスでの処理集約化、クラスタ間通信遅延の低減、I/O待ち時間の短縮によるスループット改善が期待できる

技術的な注意点

  • リージョン制限: 新たに Asia Pacific (Tokyo) と Europe (Frankfurt, Ireland) で利用可能。既存の利用可能リージョン(US East/West、Europe Spain等)も併用されるが、全サイズが全リージョンで提供されるわけではないためリージョンごとのサイズ提供状況を確認してください。
  • インスタンスサイズ/機能制限: EFAは 48xlarge、96xlarge、metal-48xl、metal-96xl のみサポート。最大ネットワーク/EBS帯域はインスタンスサイズに依存します。
  • OS/ドライバ要件: EFA利用には対応するOSカーネルとEFAドライバ(Linux向けのefaドライバ等)が必要です。AMIの互換性を事前に確認してください。
  • IAM権限: インスタンス起動やENI/EFAの使用には標準的なEC2起動権限(ec2:RunInstances、ec2:CreateNetworkInterface 等)が必要です。EFA固有の権限やENI操作権限を含めてロール/ポリシーを確認してください。
  • ストレージ注意点: R8id* 系はNVMeローカルストレージを提供しますが、インスタンスの停止でローカルデータは消失する点に注意。EBSは別途課金(容量/IOPS/スループット)されます。
  • コスト: 高性能化に伴いインスタンス時間コストは高めになる可能性があります。EBSやデータ転送(ネットワーク)コストも増加するため設計時に見積もりを行ってください。Savings Plans/スポットの利用で費用対効果を改善可能です。
  • ネットワーク/帯域の実効: 最大値(600Gbps/300Gbps)は理想条件かつサイズ依存のため、実運用ではアプリケーション特性、NIC設定、OSスタック、配置(Placement Group)などのチューニングが必要です。

参考情報


[Emr] Amazon EMR on EKS now supports Apache Spark troubleshooting agent

概要

Amazon EMR on EKSでApache Sparkトラブルシューティングエージェントが利用可能になりました。自然言語での診断、根本原因解析、PySparkコードの推奨を受け取れるため、分散ログやSpark History Serverを手動で追う手間を削減できます。

変更内容・新機能の詳細

このエージェントはSpark History Serverのデータ、分散実行(executor)ログ、クラスター設定を解析して、メモリエラー、データスキュー、リソース競合、接続障害などの原因を特定します。EMRの全デプロイ形態(EMR on EC2、EMR Serverless、EMR on EKS)で利用可能になり、EMR on EKSコンソールの失敗ジョブ画面にある「Troubleshoot with AI」から直接アクセスできます。さらにModel Context Protocol(MCP)経由でKiro、Claude Code、Cursorなどの対応するAIコーディングエージェントからも利用可能です。すべての操作は読み取り専用で実行され、IAMロールによる認証とAWS CloudTrailによるログ記録が行われます。エージェントはSageMaker Unified Studioが利用可能な全リージョンで提供されます。利用開始はEMR on EKSコンソールから、または好みのAIコーディングエージェントにMCPサーバーを設定して行います。

影響範囲・利用シーン

  • 対象ユーザー: データエンジニア、ETL開発者、SRE/運用チーム
  • 利用シーン: 失敗したSparkジョブの原因特定、PySparkコードの修正提案取得、ジョブ再実行前の診断
  • 運用効果: 分散ログ・History Serverを手動で横断して調査する時間を削減し、根本原因の特定と復旧までの時間を短縮
  • 導入効果: 開発サイクルの短縮、デバッグの効率化により運用コスト低下やダウンタイム短縮に寄与
  • リージョン制限: SageMaker Unified Studioが提供されるリージョンで利用可能

技術的な注意点

  • IAM権限: 読み取り専用だが、エージェントがログやHistory ServerデータにアクセスできるようにS3/CloudWatch Logs、EMR/EKS関連の読み取り権限を持つIAMロールが必要
  • リージョン制限: SageMaker Unified Studioが利用可能なリージョンで提供。該当しないリージョンでは未対応
  • ログ要件: Spark History Serverの履歴・executorログ(S3やCloudWatchに保存されていること)が解析に必須。ログ未保存だと解析精度が低下
  • MCP/エージェント統合: MCP互換のAIコーディングエージェント(Kiro、Claude Code、Cursor等)を使用する場合はMCPサーバーの設定が必要
  • 操作形態: 全操作は読み取り専用。クラスター設定やジョブ実行状態を変更しない設計
  • 監査: アクセスはAWS CloudTrailに記録されるため監査可能
  • コスト: エージェント自体の追加料金は明記されていないが、SageMakerや関連サービスの利用やログ保存(S3/CloudWatch)のコスト影響がある可能性あり。必要に応じてコスト見積りを確認してください

参考情報


[General] Amazon Location Service enhances Places APIs with new address and search options

概要

Amazon Location ServiceのPlaces APIが強化され、住所表記の制御、多言語住所翻訳、移動ユーザー向けの検索最適化、ドライブスルー情報や住所パースの追加メタデータが利用可能になりました。複数のPlaces関連APIで新パラメータ/レスポンスフィールドが提供されます。

変更内容・新機能の詳細

対象のAPI: Geocode, ReverseGeocode, GetPlace, Suggest, Autocomplete, SearchNearby, SearchText。

主な追加・変更点:

  • AddressNamesModeパラメータ: 住所コンポーネント名の返却方法を制御します。デフォルトは正規化(canonical)名で、代わりに入力と一致する名称(matched)や行政階層に基づく名称(administrative)を要求できます。これにより表示ポリシーやローカル表記の再現が可能です。
  • AddressTranslationsパラメータ: プレイス名の翻訳を50以上の言語で返却します。多言語対応アプリでのラベル表示やUIローカライズに便利です。
  • TravelModeパラメータ: SuggestおよびSearchTextの検索結果を「移動中(ナビ/車載)」向けに最適化し、経路探索や車上での関連性を高めます。
  • DriveThrough属性: GetPlace, Suggest, SearchNearby, SearchTextのレスポンスにその場所がドライブスルーを提供しているかを示す属性が追加され、物流、デリバリー、ナビ等で利用可能です。
  • GeocodeのParsing.AdditionalInfo: 入力された住所文字列がどのように解釈(パース)されたかの追加情報が返るようになり、曖昧な入力や自動補正の内訳確認に役立ちます。

実装上のポイント: 新パラメータは既存APIの拡張であり、デフォルトの挙動(後方互換)は維持されています。AddressTranslationsや追加フィールドの要求によりレスポンスサイズが増加するため、帯域・処理の影響を考慮してください。

影響範囲・利用シーン

  • 対象ユーザー: アプリ開発者、ナビ/車載システム開発者、フードデリバリー・ラストワンマイル物流エンジニア、多言語対応を必要とするプロダクトチーム
  • 利用シーン: 移動中のユーザー向けのPOI候補提示(ナビ/車載)、ドライブスルー判定を含めた配送ルート最適化、国際化されたUIでの住所表示/検索、多言語対応チャットボットやロケーション検索
  • 運用効果: 検索結果の関連性向上(TravelModeによる最適化)、ユーザー入力に忠実な表示や行政名称での整合性確保(AddressNamesMode)、多言語対応の実装工数削減(AddressTranslations)、配達・経路決定精度向上(DriveThrough属性)

技術的な注意点

  • IAM権限: Amazon Location ServiceのPlaces操作用のIAM権限が必要です(例: geo:SearchPlaceIndexForText, geo:SearchPlaceIndexForPosition, geo:GetPlace, geo:SearchPlaceIndexForSuggestions 等)。最小権限でロール/ポリシーを設計してください
  • リージョン制限: 本機能は記事で列挙されたリージョンで利用可能です(US East (Ohio), US East (N. Virginia), US West (Oregon), AP-NorthEast/Asia Pacific (Tokyo), AP-South (Mumbai), AP-Southeast (Sydney), Canada (Central), Europe (Frankfurt), Europe (Ireland), Europe (London), Europe (Spain), Europe (Stockholm), South America (São Paulo), AWS GovCloud (US-West))。利用前に対象リージョンでサービスが有効か確認してください
  • コスト: Places APIはリクエスト単位で課金されます。AddressTranslationsや追加フィールドを要求するとレスポンスサイズが増え、データ転送コストや処理時間に影響する可能性があります。利用量とコストモデルを確認してください
  • API互換性: 既存のクライアントはデフォルト設定で動作し続けます。新パラメータはオプションで追加互換性は保たれていますが、新フィールドの存在を前提としたパース処理はバージョン差異に注意してください
  • レスポンス/実装注意: AddressTranslationsは多言語フィールドを含むためJSONレスポンスが大きくなり得ます。DriveThroughやParsing.AdditionalInfoなどの新フィールドは存在しない場合があるため、NULL/欠損に対する堅牢なハンドリングが必要です
  • パラメータ制約: AddressTranslationsは50+言語に対応とされています。AddressNamesModeの値は記事の説明(normalized/canonical, matched, administrative)に基づき設定してください。TravelModeはSuggestとSearchTextに対しての最適化パラメータです

参考情報


[SageMaker] Amazon SageMaker HyperPod now supports AMI-based node lifecycle configuration for Slurm clusters using continuous provisioning

概要

Amazon SageMaker HyperPodは、継続プロビジョニング(continuous provisioning)を使用するSlurmクラスターに対してAMIベースのノードライフサイクル構成をサポートするようになりました。これにより、S3へライフサイクルスクリプトをアップロードせずにノードを即時に構成・投入でき、ジョブスケジューリング開始までの時間が短縮されます。

変更内容・新機能の詳細

従来、Slurmクラスターのノード初期化にはライフサイクル構成スクリプト(LifecycleConfig)をS3に置き、クラスター作成時に指定してノード起動時に実行する方式が一般的でした。今回の拡張により、SageMaker HyperPodが提供するAMIをベースにノードを構成する方式が、継続プロビジョニングモードでも利用可能になりました。AMIベースの構成では、ノードは起動時に予め用意されたAMIから必要なソフトウェア(Docker、Enroot、Pyxisなど)や設定(Slurmのアカウンティング設定、SSH鍵生成、ログローテーション等)が適用された状態でプロビジョニングされます。継続プロビジョニングでは空きキャパシティが出次第ノードが追加されますが、各ノードはAMIから直接構成されるため、ライフサイクルスクリプトの管理やS3へのアップロードが不要になり、ノードがより早くジョブのスケジューリング可能状態になります。

カスタマイズ方法としては、完全にライフサイクルスクリプトを省略する(APIでインスタンスグループ定義にLifeCycleConfigブロックを含めない、またはコンソールではCustom setupのLifecycle scriptsで「None」を選択)だけでAMIベース構成が有効になります。さらにAMIベースのベースラインに対して追加のカスタム処理が必要な場合は、APIのLifeCycleConfigでOnInitCompleteパラメータとSourceS3Uriを指定するか、コンソールの「Extension script file in S3」フィールドにS3のURIを与えることで拡張スクリプトを実行できます。従来通り、フルコントロールが必要なユースケースではカスタムのライフサイクル構成スクリプトを使い続けることも可能です。今回の機能は、SageMaker HyperPodが提供されている全リージョンで利用可能です。

影響範囲・利用シーン

  • 対象ユーザー: AI/MLエンジニア、クラスタ管理者、SRE/運用チーム
  • 利用シーンまたは効果: 継続プロビジョニングを利用するSlurmクラスターの迅速なスケールアウトとノード投入時間短縮(ジョブをより早くスケジューリング可能)
  • 運用効果: ライフサイクルスクリプトのS3管理やアップロードが不要になり運用負荷が低減、標準AMIによりノードの構成一貫性と再現性が向上
  • 導入効果: 新規クラスター作成やスケールアウト時のデプロイ時間短縮により、トレーニング待ち時間の削減が期待できる
  • 互換性・制限: 高度な初期化や特殊なパッケージが必要なケースでは、拡張スクリプトまたは従来のLifecycleConfigを併用する必要がある
  • リージョン: SageMaker HyperPodが提供されている全リージョンで利用可能

技術的な注意点

  • IAM権限: クラスター作成、EC2インスタンスの起動、必要に応じてS3から拡張スクリプトを取得する権限(SageMakerおよびEC2/S3関連の権限)を確認してください
  • リージョン制限: 記事の通り、SageMaker HyperPodが利用可能なリージョンで利用可能です。HyperPod未対応リージョンでは利用できません
  • コスト: 新機能自体の追加料金は明示されていませんが、継続プロビジョニングによるノード増加はEC2の利用料金および関連ストレージ/ネットワークリソースのコスト増加を招きます
  • AMI管理: AMIベース構成はAMIの中身(OSパッチ、ライブラリバージョン、セキュリティ更新)に依存します。セキュリティやソフトウェアの更新ポリシーを定め、必要なら独自にAMIを作成・管理することを検討してください
  • ライフサイクル拡張: AMIベースのベースラインに追加処理が必要な場合は、OnInitComplete + SourceS3Uri(API)またはコンソールのS3拡張スクリプト欄で指定する方式を利用してください。拡張スクリプトはAMIの初期化処理完了後に実行されます
  • 既存クラスターへの影響: 既存のクラスター設定やライフサイクルスクリプトはそのまま維持できます。動作を切り替えるにはクラスター作り直しが必要となる場合があります
  • インスタンスタイプ互換性: 一部の特殊なインスタンスタイプやアクセラレータに対しては追加のドライバや設定が必要になる可能性があります。使用するインスタンスタイプで必要なソフトウェア/ドライバがAMIに含まれているか確認してください

参考情報


[Ec2] Amazon EC2 G7 instances are now available in the AWS US East (N. Virginia) Region

概要

Amazon EC2の新しいG7インスタンス(NVIDIA RTX PRO 4500 Blackwell Server Edition搭載)が米国東部(N. Virginia)リージョンで利用可能になりました。G6世代と比べてAI推論やグラフィックス性能が大幅に向上しています。

変更内容・新機能の詳細

G7インスタンスは最大8基のNVIDIA RTX PRO 4500 Blackwell Server Edition GPU(各GPU 32 GB)とカスタムIntel Xeon 6プロセッサを搭載し、最大192 vCPU、最大768 GiBのシステムメモリ、最大7.6 TBのローカルNVMe SSD、および最大700 GbpsのElastic Fabric Adapter(EFA)ネットワーク帯域をサポートします。AWSによれば、G6と比較してAI推論性能は最大4.6倍、グラフィックス性能は最大2.1倍となるため、言語翻訳、画像・動画解析、音声認識などのAI推論や、リアルタイムでのシネマ品質レンダリングやゲームストリーミングといったグラフィックス用途に適しています。さらに、ビデオトランスコーディング、空間コンピューティング、レコメンダーシステム、RAG(Retrieval Augmented Generation)推論、リアルタイムデータパイプラインなどのGPU加速データ分析ワークロードも加速可能です。G7インスタンスはOn-Demand、Spot、Savings Plansで購入でき、AWSコンソール、AWS CLI、SDKから起動可能です。現在はUS East (N. Virginia)、US East (Ohio)、US West (Oregon)で利用できます。

影響範囲・利用シーン

  • 対象ユーザー: 機械学習エンジニア、データサイエンティスト、レンダリング/ゲーム開発者、ストリーミングサービス事業者
  • 利用シーン: 大規模AI推論(翻訳、画像/動画解析、音声認識)、RAG推論やレコメンダー等の推論パイプライン、リアルタイム/バッチのGPU加速データ分析、シネマ品質のリアルタイムレンダリングやクラウドゲーム配信
  • 運用効果: 推論レイテンシ低下とスループット向上によりコスト効率が改善し、複雑なグラフィックス処理や高帯域ネットワークを必要とする分散トレーニング/推論で性能向上が期待できる
  • コスト影響: 高性能GPU・大メモリ構成のためインスタンスタイプ単価は上昇。SpotやSavings Plansでコスト最適化が可能
  • リージョン制限: 公開時点では us-east-1(N. Virginia)に加え、us-east-2(Ohio)、us-west-2(Oregon)のみで提供

技術的な注意点

  • IAM権限: EC2のRunInstances等の基本権限に加え、EBS、ENI作成権限などが必要です
  • ドライバ/ソフトウェア: NVIDIAドライバ/CUDA等のインストールが必要(AMIに同梱されていない場合あり)。EFA使用時は対応カーネルとEFAドライバが必要です
  • ネットワーク: 最大700 Gbpsを引き出すにはElastic Fabric Adapter(EFA)とEN A(Enhanced Networking)ドライバの対応が必要です
  • インスタンス上のストレージ: ローカルNVMeはインスタンスストア(揮発性)であり、停止/終了でデータ消失するため永続データはEBS/S3に保存してください
  • クォータ/キャパシティ: vCPU・GPUの利用上限(サービスクォータ)に注意。大規模投入時は事前にクォータ引き上げ申請を行ってください
  • 互換性: 一部の古いAMIやカスタムカーネルはGPU/EFAドライバと互換性がない場合があります。サポートされるOS/AMIでの検証を推奨します
  • コスト: 高性能構成のため料金は高め。SpotやSavings Plans、リザーブドインスタンスの検討を推奨
  • リージョン制限: 記載のリージョン以外では未提供のため、展開リージョンを事前確認してください

参考情報


[Database Migration Service] AWS DMS Schema Conversion now supports offline SQL Server conversion

概要

AWS Database Migration Service (DMS) の Schema Conversion が、Microsoft SQL Server に対するオフライン(コネクション不要)ソース変換に対応しました。ソース DB に直接接続せずにメタデータを抽出してアップロードすることで、セキュリティ審査やファイアウォール/ VPN 設定の遅延を回避できます。

変更内容・新機能の詳細

オンプレミスやセキュア環境の Microsoft SQL Server から、管理者が標準的なデータベースコマンドを使ってメタデータ(DDL、スキーマ定義、ストアドプロシージャなど)を抽出し、人が読める形式のファイルとして生成します。そのファイルを DMS Schema Conversion にアップロードすると、接続方式と同等のスキーマ・コード変換処理が実行され、ターゲットデータベース用の変換結果が得られます。オフライン方式は外部ツールのソース DB への直接アクセスを禁止するセキュリティポリシーを持つ組織向けに最適化されており、セキュリティチームがコマンドと出力を事前確認した上でアップロードできるため承認プロセスが簡素化されます。対応ターゲットは DMS Schema Conversion がサポートする全ターゲットで、変換に追加料金は発生しません。地域別対応状況は AWS の「Supported AWS Regions」ページで確認してください。なお、オフライン機能はスキーマ/コードの変換を対象とし、実データの移行や連続レプリケーションは別途 DMS の接続設定やタスクが必要です。

影響範囲・利用シーン

  • 対象ユーザー: オンプレミス/セキュア環境で運用するDB管理者、クラウド移行担当者、セキュリティチーム
  • 利用シーン: 生産系 SQL Server に外部ツール接続を許可できない環境でのスキーマおよびコード変換(移行前の互換性評価・移行計画作成)
  • 運用効果: ファイアウォールや VPN 設定、長期のセキュリティ審査を不要にして、数週間に及ぶ承認プロセスを「コマンド実行→ファイルアップロード」のワークフローに短縮可能

技術的な注意点

  • サポートソース: 現時点でオフラインソースは Microsoft SQL Server 向け(ソース)が対象です
  • データ移行: オフラインはスキーマ/コード変換専用。実データの移行や継続レプリケーションは別途 DMS タスクや接続が必要です
  • メタデータ抽出: 管理者が標準的な SQL コマンドで完全なメタデータ(テーブル定義、インデックス、ビュー、ストアドプロシージャ等)を抽出する必要があります。抜けがあると変換結果に影響します
  • IAM権限: DMS Schema Conversion にアップロード・実行するための適切な IAM 権限(S3 アップロード権限や Schema Conversion の利用権限等)を準備してください
  • リージョン制限: 機能の利用可否はリージョン依存です。事前に Supported AWS Regions ページで提供状況を確認してください
  • コスト: スキーマ変換自体に追加料金は発生しないと明記されていますが、S3 などアップロード先ストレージや関連サービスの通常料金は発生します
  • バージョン互換性: SQL Server のバージョン差分や特定の拡張機能により変換の互換性が影響を受ける場合があります。変換後は出力物のレビューとテストを必ず行ってください
  • セキュリティ: メタデータファイルに機密情報(例: パスワードなど)が含まれないか確認し、安全な転送手段と保存先を利用してください
  • 注意点: 一部の動的 SQL や実行時依存のオブジェクトはオフライン抽出で完全に解析できない可能性があるため、必要に応じて追加情報を提供して検証してください

参考情報

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