AWS What's New Digest

Appearance

2026年03月27日 ​

[Gamelift] Amazon GameLift Servers expands instance support with next-generation EC2 instance families ​

概要 ​

Amazon GameLift ServersがEC2の第5世代から第8世代インスタンスをサポートしました。これにより最新のCPUアーキテクチャ（Intel/AMD/Graviton）やメモリ・ネットワーク性能を活かして、ゲームサーバーをより高性能かつコスト効率よく運用できます。

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

今回のアップデートにより、GameLift Serversで利用できるEC2インスタンスの世代が5〜8世代に拡張され、以下の主要インスタンスファミリーが利用可能です。一般用途（Mシリーズ）: CPU・メモリ・ネットワーキングのバランスが取れた汎用型。コンピュート最適化（Cシリーズ）: 高い計算性能を重視し、記事記載の目安で2:1のメモリ比（計算寄りワークロード向け）。メモリ最適化（Rシリーズ）: 大規模シミュレーションや多数プレイヤー接続向けに8:1のメモリ比で高メモリ容量を提供。世代ごとの特徴も強化されています。5th Gen: Intelプロセッサでの安定性・実績。6th Gen: AWS Graviton2（ARM）を含むIntel/AMDの選択肢で価格性能比改善。7th Gen: DDR5メモリやネットワーク強化により旧世代からの性能向上。8th Gen: Graviton4や最新のIntel Xeon搭載で要求の厳しい負荷に対応。さらにローカルストレージ付き（d）、強化ネットワーキング（n）、およびプロセッサアーキテクチャ（Intel/AMD/Graviton：i/a/g 表記）などのバリエーションが選べます。これらはGameLift Serversがサポートするリージョンで利用可能（AWS China除く）。新世代への移行により、スケール・コスト効率・性能の最適化が可能です。詳細はGameLift ServersドキュメントおよびEC2インスタンスタイプの概要を参照してください。

影響範囲・利用シーン ​

  • 対象ユーザー: マルチプレイヤーゲーム開発者、ゲームスタジオのサーバーエンジニア、SRE/運用チーム
  • 利用シーン: 大規模マッチメイキング／多数同時接続セッション、物理シミュレーションやAI処理などCPU/メモリ負荷の高いゲームサーバー、コスト最適化のためのインスタンスタイプ選定
  • 運用効果: 新しい世代での価格性能比向上によりランニングコスト低減や同一コストでの処理能力増加が期待できる。アーキテクチャ（x86 vs ARM）選択で最適なバイナリビルドやイメージを用意することで性能と効率を引き上げられる

技術的な注意点 ​

  • IAM権限: 新しいインスタンスタイプでフリートを起動する際は、EC2関連（RunInstances, DescribeInstances等）やGameLiftの適切なIAM権限が必要です。
  • リージョン制限: GameLift Serversがサポートするリージョンでは利用可能ですが、AWS China（中国リージョン）では未対応です。各世代/ファミリーが全リージョンで提供されているとは限りません。
  • 互換性（アーキテクチャ）: Graviton（ARM）インスタンスを使う場合はサーバーバイナリ／コンテナをARM向けにビルドする必要があります。既存のx86バイナリはそのままでは動作しません。
  • ドライバ／AMI: 強化ネットワーキング（ENA等）やローカルNVMe（dオプション）を利用する際は、対応したAMIとカーネル/ドライバが必要です。EFA等の追加要素は別途確認してください。
  • コスト: 新世代で価格性能比は改善される傾向ですが、インスタンスサイズ・世代・アーキテクチャにより料金は異なります。スポット/リザーブド/セービングスプランの適用可否も確認してください。
  • 移行手順: 新世代に移行する際は性能ベンチマーク、ネットワークレイテンシ試験、メモリ/CPUプロファイリング、そしてビルド/デプロイのテストを実施してください。オートスケーリング設定やスケジューリングポリシーの見直しも推奨されます。
  • 運用制約: GameLiftのServer SDKやサードパーティライブラリがターゲットアーキテクチャをサポートしているか確認してください。

参考情報 ​

[General] AWS HealthImaging announces study-level fine-grained access control ​

概要 ​

AWS HealthImagingがDICOMのStudy/Series単位での細粒度アクセス制御をサポートしました。IAMポリシーでStudy Instance UID／Series Instance UIDを直接指定してアクセス権を付与でき、短時間の動的なアクセスはSTSセッションポリシーで発行できます。

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

技術的には、HealthImagingに格納された医用画像（DICOM Studyは1つ以上の image set リソースとして表現される）に対して、従来の個別 image set ARN を列挙する代わりに、DICOM Study Instance UID および Series Instance UID を直接 IAM ポリシー内で指定して DICOMweb API へのアクセス権を付与できるようになりました。これにより、ポリシーの管理負荷が低減され、特定のStudyやSeriesにのみアクセスを限定することでPHI（保護対象医療情報）の露出を抑制できます。加えて、AWS Security Token Service（STS）のセッションポリシーを用いて動的かつ短時間の権限付与（低レイテンシ認証）を行えるため、ケース単位の一時アクセスや外部パートナーへの共有、研究用データ配布などのワークフローに適しています。HealthImagingはHIPAA適合が可能なサービスであり、本機能は現時点で US East (N. Virginia), US West (Oregon), Asia Pacific (Sydney), Europe (Ireland), Europe (London) のリージョンで一般提供されています。

影響範囲・利用シーン ​

  • 対象ユーザー: 医療機関のSRE/運用チーム、画像診断者（放射線科医・病理医）、医療ソフトウェア開発者、研究機関
  • 利用シーンまたは効果: 病理ケース単位のアクセス制御、外部放射線読影パートナーへの特定検査共有、研究用データの制御付き配布（Study/Series単位でスコープ可能）
  • 運用効果: ポリシーの記述と保守が簡易化され、PHIへのアクセス範囲をより細かく限定できるためコンプライアンス負荷と情報漏洩リスクが低減される
  • 開発／統合への影響: DICOMweb API を用いる既存アプリは最小限の変更でポリシー置換が可能。短期トークンでの認証を組み込むことでインタラクティブなワークフロー対応が容易になる

技術的な注意点 ​

  • IAM権限: IAMポリシーでStudy Instance UID/Series Instance UIDを指定してアクセス権を与える必要があるため、ポリシーの更新・検証（IAM Policy Simulator等）を行ってください。STSを使う場合は適切なロール信頼ポリシーとAssumeRole/AssumeRoleWithWebIdentity等の設定が必要です
  • リージョン制限: 現在の一般提供リージョンは US East (N. Virginia), US West (Oregon), Asia Pacific (Sydney), Europe (Ireland), Europe (London) です。その他リージョンでは未対応の可能性があります
  • コスト: 機能利用自体に専用料金が明記されていない場合でも、S3等のストレージ、APIリクエスト、データ転送、STS呼び出し等の通常のAWS料金が発生します。短期トークン発行頻度やデータ転送量はコストに影響します
  • セキュリティ/コンプライアンス: Study/SeriesのUIDはPHIに紐づく可能性があるため取り扱いに注意してください。アクセス監査は CloudTrail やサービスのアクセスログで行い、最小権限原則を適用してください
  • 互換性/移行: 従来の image set ARN ベースのポリシーは引き続き有効であり、段階的移行が可能です。アプリ側ではDICOMwebのURLやUIDの指定方法が現在の実装と整合するか確認してください
  • パフォーマンス: 記載の「低レイテンシ認証」は対話的ワークフロー向けの利点だが、セッション発行頻度・同時発行数により遅延が変動するため負荷試験を推奨します

参考情報 ​

[SageMaker] Amazon SageMaker Studio launches support for Kiro and Cursor IDEs as remote IDEs ​

概要 ​

Amazon SageMaker StudioがKiroとCursorのローカルIDEからStudio上の開発環境へリモート接続できるようになりました。これにより、既存のKiro/Cursorの設定を維持したままSageMakerのスケーラブルな計算資源とデータにアクセスできます。

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

新機能は、KiroおよびCursorのAWS Toolkit拡張を用いてローカルIDEからSageMaker Studioの開発環境（Studio apps）へリモート接続する機能です。接続後はローカルのKiro/Cursorでの「spec-driven development」「会話型コーディング」「自動特徴量生成」等のワークフローを維持しつつ、実行はSageMaker Studio上の計算インスタンスで行えます。認証はKiro/Cursor内のAWS Toolkit拡張またはSageMaker StudioのWeb UIを通じて行い、数クリックで任意のStudio開発環境に接続できます。既存のJupyterLab、Code-OSSベースのCode Editor、VS Codeリモートに加え、KiroとCursorがリモートIDEとしてサポートされます。ローカルで保持するspec、steeringファイル、hooksなどのカスタム設定をそのまま利用でき、Studioのセキュリティ境界（アクセス制御、ロール、ネットワーク設定）は維持されます。

影響範囲・利用シーン ​

  • 対象ユーザー: データサイエンティスト、機械学習エンジニア、ML/ソフトウェア開発者
  • 利用シーン: ローカルIDE（Kiro/Cursor）でのエージェント的・会話型の開発を継続しつつ、重い学習・推論処理や大規模データアクセスはSageMaker Studioの計算リソースで実行したいケース
  • 運用効果: ローカルとクラウド間のコンテキストスイッチを削減し、生産性向上および開発フローの一貫性を確保できる
  • セキュリティ影響: Studioの既存のアクセス制御・IAMロール・ネットワーク境界を維持したまま開発可能で、データのクラウド側集中管理が容易になる
  • コスト影響: 計算やストレージはSageMakerの従来の料金体系が適用されるため、クラウド計算の利用増加がコスト増に直結する可能性がある

技術的な注意点 ​

  • IAM権限: Studioへの接続にはSageMakerおよび関連リソース（S3、ECR等）に対する適切なIAM権限と、Studioユーザープロファイル/アプリの作成・接続権限が必要です。AWS Toolkitでの認証情報管理も必要になります
  • 認証方法: Kiro/Cursor内のAWS Toolkit拡張またはSageMaker StudioのWeb UIを使って認証できます。SSOやプロファイル構成の影響を確認してください
  • ネットワーク: Studio環境がVPC内でインターネットアクセスを制限している場合、接続やデータアクセスに影響する可能性があるため、セキュリティグループやVPCエンドポイントの設定を確認してください
  • データ管理: 実行とデータは基本的にStudio側（S3やEFS等）で管理されます。ローカルIDEにデータをダウンロードするとローカル側の取り扱い（セキュリティ・コンプライアンス）に注意が必要です
  • 互換性: 既存のJupyterLab/Code-OSS/VS Codeのリモート接続と並行して利用可能ですが、Kiro/Cursor固有の拡張が必要です（AWS Toolkit拡張のインストールと設定が前提）
  • コスト: SageMaker Studio上の計算インスタンス・ストレージの使用に対して通常のSageMaker課金が発生します。開発・実験での長時間インスタンス稼働はコストに直結します
  • リージョン制限: 本告知では明示されていません。利用可否や提供開始タイミングはリージョンによって異なる可能性があるため、対象リージョンの提供状況を事前に確認してください

参考情報 ​

[ECS] Amazon ECS Managed Instances now supports FIPS-certified workloads on Graviton and GPU accelerated instances in AWS GovCloud (US) Regions ​

概要 ​

Amazon ECS Managed InstancesがAWS GovCloud (US)リージョンでFIPS準拠モードをサポートしました。GravitonベースおよびGPU加速インスタンスを含む幅広いインスタンスタイプでFIPS-validated暗号モジュールを使ったコンテナワークロードが実行できます。

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

ECS Managed InstancesはAWS GovCloud (US)においてデフォルトでFIPS準拠モードが有効になります。これにより、ECS Managed InstancesはFIPS準拠のエンドポイントを通じて通信し、FIPS検証済みの暗号モジュールを利用し、基盤となるカーネルをFIPSモードで起動します。今回の拡張で、Graviton（ARM）ベースインスタンスやGPUアクセラレーションを利用するインスタンスを含む、ネットワーク最適化やバースト型を含む広範なインスタンスタイプ上でFIPS対応のワークロードをデプロイ可能になりました。設定は新規・既存のAmazon ECSクラスターで、AWS コンソール、Amazon ECS MCP Server、ECS Express Mode、またはInfrastructure-as-Codeツールを使って有効化できます。なお、ECS Managed Instancesの管理に対する追加料金が発生し、これは通常のAmazon EC2コストに加算されます。

影響範囲・利用シーン ​

  • 対象ユーザー: 連邦政府機関やFIPS準拠が求められる組織のクラウド/セキュリティ/DevOpsチーム
  • 利用シーンまたは効果: GravitonやGPUを活用したコンテナワークロードをGovCloud (US)上でFIPS-validated暗号を用いて安全に稼働させ、法令・契約上の暗号要件を満たす
  • 運用効果: FIPS準拠の通信と暗号モジュールにより監査・コンプライアンス対応が容易になり、ARMベースのコスト効率やGPUによる性能を規制下でも享受可能
  • 対応インスタンスタイプ: Gravitonベース（ARM）、GPU加速、ネットワーク最適化、バースト型インスタンス等の広範なタイプが対象

技術的な注意点 ​

  • IAM権限: ECSと関連リソース（EC2、IAM、VPC等）を操作するための適切なIAM権限が必要です。ECS Managed Instancesの有効化に関する権限を事前確認してください
  • リージョン制限: 本機能はAWS GovCloud (US)リージョンでデフォルト有効です。標準AWSリージョンでの挙動は異なる可能性があります
  • コスト: ECS Managed Instancesの管理に対する追加料金が発生します（この料金は通常のEC2使用料に加算されます）。コスト試算を事前に行ってください
  • 互換性・AMI: FIPSモードでのカーネル起動やFIPS検証済み暗号モジュールの利用はカスタムAMIやカーネルモジュールに影響を与える可能性があります。使用するAMIがFIPSモードと互換であるか確認してください
  • 運用影響: FIPSモード切替やカーネルのFIPSブートは再起動や設定変更を伴う場合があるため、既存ワークロードへの導入時は稼働計画・テストを推奨します
  • 設定方法: AWS コンソール、Amazon ECS MCP Server、ECS Express Mode、またはIaC（CloudFormation/CDK/Terraform等）から有効化可能です。自動化ツールを使う場合は対応リソースとパラメータを確認してください

参考情報 ​

[General] Aurora DSQL launches connector that simplifies building Ruby applications ​

概要 ​

Amazon Aurora DSQL向けの公式Rubyコネクタ（pg gem）が公開され、IAMトークンベース認証・SSL・接続プーリング等を自動で扱えるようになり、既存のpg gem互換性を保ったままRubyアプリケーションの認証・接続実装を簡素化します。

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

Aurora DSQL Connector for Ruby（pg gem）は、接続ごとに短期有効なIAMトークンを自動生成して従来の固定パスワード方式に伴うセキュリティリスクを排除します。コネクタは以下を提供します：IAMトークン生成の自動化、SSL/TLS設定のハンドル、接続プーリング管理、オプトインの楽観的並行制御（OCC）リトライ（指数バックオフ付き）、カスタムIAMクレデンシャルプロバイダーおよびAWSプロファイルサポート。pg gemの既存APIや機能との互換性を維持するため、既存コードへの導入コストを最小化し、スクリプトから本番ワークロードまで同じ認証フローでスケールできます。トランジェントな接続障害に対する自動リトライや、IAM資格情報の多様な取得方法（環境変数、プロファイル、カスタムプロバイダ）により運用の柔軟性が向上します。コード例や導入手順は公式ドキュメントおよびGitHubリポジトリで提供されています。

影響範囲・利用シーン ​

  • 対象ユーザー: RubyでAurora DSQLに接続するアプリケーション開発者、SRE/運用チーム
  • 利用シーン: Webアプリケーションやバッチ処理での安全なDB接続、短命トークンを利用したセキュアな認証導入、接続プーリングが必要な高スループットアプリ
  • 運用効果: ハードコード／長期パスワード管理の排除によるセキュリティ向上、トークン自動生成とリトライ機構により接続の安定性向上、既存pg gem互換のため移行コストを抑えて本番導入を容易化

技術的な注意点 ​

  • IAM権限: RDS/AuroraへのIAM認証を利用するため、適切なIAMポリシー（例: rds-db:connect相当の権限や必要なSTSアクセス）をユーザー/ロールに付与する必要があります。詳細は導入前に確認してください。
  • トークン有効期間とプール: IAMトークンは短命です。コネクタは接続ごとにトークン生成を行う設計ですが、長期間保持する独自の接続プールを使う場合はトークン期限切れ対策（再取得やコネクション再作成）を確認してください。
  • ドライバ互換性: pg gemとRubyのバージョン互換性を事前に確認してください。コネクタはpg gem互換を謳いますが、サポートされるバージョンレンジは公式リポジトリで確認する必要があります。
  • リージョン制限: 記事本文では明示的なリージョン制限の記載がありません。利用するリージョンでAurora DSQLおよび関連APIが利用可能か公式ドキュメントで確認してください。
  • コスト: コネクタ自体に直接課金は通常ありませんが、IAMトークン生成やSTS/API呼び出しの増加、ログやメトリクスの増加による間接的なコスト影響がある可能性があります。Free Tierの対象となる条件も公式で確認してください。
  • 運用設定: SSL/TLSの設定やカスタムIAMプロバイダー、AWSプロファイル利用時は設定ミスが接続障害の原因になるため、導入前にテスト環境で検証してください。

参考情報 ​

[General] AWS Lambda increases the file descriptor limit to 4,096 for functions running on Lambda Managed Instances ​

概要 ​

AWS Lambdaは、Lambda Managed Instances（LMI）で実行される関数のファイルディスクリプタ上限を1,024から4,096に4倍引き上げました。これにより高並列のネットワーク接続やファイルI/Oを多用するワークロードが安定して動作しやすくなります。

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

従来、Lambda実行環境ではプロセスあたりのファイルディスクリプタ上限が1,024でしたが、今回LMI上で動作する関数については上限を4,096に引き上げました。ファイルディスクリプタはファイルハンドル、ネットワークソケット、パイプや他のI/Oリソースごとに1つ消費されるため、同一インスタンスで複数リクエストを同時処理したり大規模な接続プーリングを行うワークロードでは上限に達しやすくなります。LMIは管理されたAmazon EC2インスタンス上でLambda関数を実行し、ルーティング・ロードバランシング・オートスケーリングを組み合わせるため、最新世代のプロセッサや高帯域ネットワークを利用する用途に向きます。今回の引き上げにより、I/O集約型の高並列ウェブサービス、ファイル大量処理パイプライン、外部サービスへの大規模コネクションプールを使うAI前処理ワークフローなどがLMI上で効率的に動作します。なおこの変更は「Lambda Managed Instances」で実行される関数に対するものであり、従来の（完全マネージド）Lambda実行環境の上限が自動的に変わるわけではありません。また本機能はLMIが一般提供されているリージョンで利用可能です。

影響範囲・利用シーン ​

  • 対象ユーザー: 高並列なWeb/APIサービス開発者、SRE/運用チーム、データ処理・ETLエンジニア、AIワークフロー開発者
  • 利用シーン: 高同時接続を必要とするWebサービス、外部DBやマイクロサービスへ多数のソケット接続を張るバッチ／ストリーム処理、ファイル大量入出力を伴うデータパイプライン
  • 運用効果: 接続プールや同時処理数を増やせるためレイテンシ低下やスループット向上につながる。ファイルディスクリプタ不足による予期せぬエラー（EMFILE等）の発生頻度を低減できる
  • 制約・留意点: この増加はLMIで実行される関数にのみ適用され、標準Lambda実行環境の上限は変わらないため、LMIへデプロイする設計変更が必要な場合がある

技術的な注意点 ​

  • 適用範囲: 本変更はLambda Managed Instances（LMI）で動作する関数に対するものです。標準のLambda関数（完全マネージド実行環境）には影響しません
  • プロセス制限: ファイルディスクリプタ上限はプロセス（ulimit -n 相当）ベースで設定されます。アプリケーションがスレッドやプロセスを増やす場合、合計消費量に注意してください
  • 監視・対策: fd使用量（/proc/<pid>/fd など）やEMFILE/ENFILEエラーの監視、接続・ハンドルの適切なクローズやプール管理を実装してください
  • IAM権限: LMIを操作・デプロイするためのLambdaおよび関連するEC2/Auto ScalingのIAM権限が必要です（組織のポリシーに依存）
  • リージョン制限: LMIが一般提供されているリージョンで利用可能です。個別リージョンの提供状況はドキュメントで確認してください
  • コスト: LMIは管理されたEC2インスタンス上で動作するため、処理量を増やすとインスタンス利用料やネットワークコストが増加する可能性があります。上限増加自体に別途料金はないが、より多くのリソースを使う設計変更はコスト影響を検討してください
  • 移行上の注意: 標準LambdaからLMIへ移す場合、デプロイ方法やライフサイクル、ログ/メトリクス収集方法が異なるため、CI/CDや監視の調整が必要です

参考情報 ​

[Appconfig] AWS AppConfig adds enhanced targeting during feature flag rollout ​

概要 ​

AWS AppConfigは、機能フラグや動的設定の段階的ロールアウト中に、特定のセグメントや個々のユーザーへ値を割り当てる強化されたターゲティング機能を追加しました。AppConfig Agentを利用して、ロールアウト期間中に“スティッキー”な割り当て（同一ユーザーが常に同じ変化の扱いを受ける）を実現します。

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

今回のアップデートは、AppConfigのプログレッシブデリバリー（段階的ロールアウト）機能に対して、より細かなターゲティング制御を提供します。顧客が提供するエンティティ識別子（例: ユーザーID、デバイスIDなど）を用いて、特定のセグメントまたは個々のIDに対して機能フラグや設定値を“スティッキー”に割り当てます。割り当てロジックと評価はAppConfig Agent上で行われ、ロールアウト中でも同一のエンティティが一貫した扱いを受けるため、部分展開による不整合やテストのばらつきを低減します。これにより、たとえば『特定の5%に入るユーザー群を固定して段階的リリースする』『特定ユーザーID群を常にオンにして検証する』といった運用が可能になります。技術的には、クライアント側でエンティティIDを提供・保持し、AppConfig Agentが構成データを取得・評価してローカルで適用します。評価方法はハッシュベースの一貫割当などを用いる想定で、ロールアウトの割合変更や設定更新があっても対象エンティティの割当は保持されます。

影響範囲・利用シーン ​

  • 対象ユーザー: 機能フラグ/設定管理を行う開発者、SRE、プロダクトマネージャー
  • 利用シーン: 段階的ロールアウト（カナリアや段階的リリース）で特定ユーザー群やセグメントを固定してテストや検証を行う場面
  • 運用効果: 展開中の不整合を低減し、問題発生時の影響範囲を限定。特定ユーザーで安定的に検証ができるためフィードバックループが短縮される

技術的な注意点 ​

  • AppConfig Agent: ターゲティング（スティッキー割当）を利用するにはAppConfig Agentの導入・稼働が必要で、クライアント側でエンティティIDを提供する実装変更が必要です
  • IAM権限: AppConfig（およびAppConfig Dataプレーン）から設定を取得するための適切なIAM権限（例: appconfig:GetConfiguration / appconfigdata:GetLatestConfiguration など）を付与してください
  • リージョン制限: 新機能はリージョン単位で段階的に展開される可能性があります。利用前に対象リージョンでの提供状況を公式ドキュメント／コンソールで確認してください
  • コスト: 基本的には既存のAppConfig利用料金の枠内で動作しますが、Agentによる頻繁な取得や追加の監視・ログ出力が増えるとAPI呼び出しやログストレージに伴うコスト増の可能性があります
  • 互換性/移行: 既存のフラグや設定は従来通り動作しますが、スティッキーなターゲティングを使うにはクライアントの改修（エンティティID送出やAgent導入）が必要です。エンティティIDが変わると割当が変動する点に注意してください
  • セキュリティ/プライバシー: エンティティIDが個人識別子になる場合は、取り扱いや保存、送信時の暗号化・最小化に注意してください

参考情報 ​

[General] The AWS Advanced JDBC Wrapper now supports automatic query caching with Valkey ​

概要 ​

AWS Advanced JDBC Wrapperが自動クエリキャッシュ機能をValkey（Amazon ElastiCache for Valkey）に対してサポートしました。AuroraおよびRDS（PostgreSQL、MySQL、MariaDB）からのクエリ結果セットを簡単な設定で自動的にElastiCacheに格納・取得できます。

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

今回の機能追加により、開発者は個々のクエリごとにキャッシュ読み書きロジックを手書きする必要がなくなります。導入は、ラッパーの依存関係追加、クエリキャッシュプラグインの有効化、データベースとValkeyキャッシュのエンドポイント設定、そしてアプリケーション側でキャッシュ対象クエリを注記（アノテーションやクエリヒント）するだけです。対応データベースはAmazon AuroraおよびRDSのPostgreSQL、MySQL、MariaDBで、フレームワーク統合はHibernateやSpring Dataのアノテーション方式、あるいは手動のクエリヒント方式をサポートします。キャッシュ格納先としてはAmazon ElastiCache for Valkey（サーバーレス構成の作成も可能）とシームレスに連携します。これにより頻繁に参照される結果セットのDB読み取り回数を削減し、読み取りレイテンシの低減、DBリソースの節約、コスト低減やアプリケーションの耐障害性向上が期待できます。キャッシュの生成はResultSet単位で行われ、TTLや無効化戦略、エビクションに基づく整合性設計が重要になります。

影響範囲・利用シーン ​

  • 対象ユーザー: アプリケーション開発者、バックエンドエンジニア、SRE/運用チーム
  • 利用シーンまたは効果: 頻繁に実行されるリード系クエリ（参照専用API、ダッシュボード、ランキング等）のレスポンス改善とDB負荷軽減
  • 運用効果: データベースの読み取り回数削減によりレイテンシ低減とスケール負荷の低減、コスト削減が見込める
  • アプリ設計への影響: キャッシュ無効化やTTL設計が必要になり、一貫性要件に応じた設計変更が発生する可能性がある

技術的な注意点 ​

  • IAM権限: ElastiCacheおよびRDS/Aurora操作用のIAM権限、必要に応じてMCP/CLI/SDKの利用権限を確認してください
  • リージョン制限: 記事で明示されていないため、利用前にElastiCache for ValkeyとAdvanced JDBC Wrapperの対応リージョンを確認してください
  • コスト: ElastiCache for Valkeyの利用料金が発生しますが、DB読み取り削減で総コストが下がるケースが多いです。コスト比較は必ず実施してください
  • ネットワーク/セキュリティ: RDS/AuroraとElastiCacheが同一VPCまたはルーティング可能なネットワークにあり、適切なセキュリティグループ/サブネット設定が必要です
  • 互換性/対応DB: Amazon Aurora、RDS PostgreSQL、MySQL、MariaDBをサポート。利用するJDBCドライバやフレームワークのバージョン互換性を確認してください
  • 実装手順（概要）: 1) Advanced JDBC Wrapper依存を追加 2) クエリキャッシュプラグインを有効化 3) DBおよびValkeyのエンドポイントを設定 4) キャッシュ対象クエリをアノテーション／ヒントで指定
  • 運用上の注意: キャッシュキー設計、TTL、整合性（整合性重視なら短めのTTLあるいは書き込み時の無効化戦略）およびキャッシュヒット率の監視を行ってください
  • 移行/既存環境: 既存のキャッシュ実装（カスタムキーやフォーマット）から移行する場合はキー互換性と一貫性戦略を検討してください

参考情報 ​

[Ec2] Amazon EC2 R8gd instances are now available in additional AWS Regions ​

概要 ​

Amazon EC2のR8gdインスタンス（最大11.4TBのローカルNVMe SSD、AWS Graviton4搭載）が、追加リージョン（米国西部（北カリフォルニア）、アジア太平洋（ソウル・香港・ジャカルタ）、アフリカ（ケープタウン）、カナダ西部（カルガリー））で利用可能になりました。Graviton3比で性能向上し、ローカル高速ストレージを必要とするワークロードに最適化されています。

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

R8gdはAWS Graviton4プロセッサを搭載したメモリ最適化・ローカルストレージ付きインスタンスファミリーです。主な仕様は以下の通りです：

  • 最大11.4 TBのローカルNVMeベースのSSD（インスタンスストア）を提供し、ブロックレベルで高スループット・低レイテンシのローカルI/Oを実現。
  • Graviton4によりGraviton3ベースの同等インスタンスと比べて最大約30%の総合性能向上。I/O集約型データベースでは最大40%の性能向上、リアルタイムデータ分析のクエリでは最大20%高速化との公表値。
  • AWS Nitro System上で動作し、セキュリティとハードウェアアクセラレーションの恩恵を受ける。
  • 12のインスタンスサイズを用意。ネットワーク帯域は最大50 Gbps、Amazon EBS向け帯域は最大40 Gbps。
  • EC2インスタンス帯域幅ウェイト（bandwidth weighting）設定により、ネットワークおよびEBS帯域を25%調整可能で、ワークロードに合わせた帯域配分の柔軟化が可能。
  • EFA（Elastic Fabric Adapter）を24xlarge、48xlarge、metal-24xl、metal-48xlのサイズでサポートし、MPIなどの低レイテンシ通信を必要とする分散アプリケーションに対応。
  • 利用開始・移行はAWS Management Console、Graviton Fast Startプログラム、Porting Advisor for Gravitonなどの支援ツールを活用可能。

影響範囲・利用シーン ​

  • 対象ユーザー: データベースエンジニア、リアルタイム分析者、ビッグデータ処理者、HPCユーザー、SRE/インフラ担当者
  • 利用シーンまたは効果: ローカルNVMe上で高スループット・低レイテンシI/Oを必要とするオンプレ代替のデータベース（例：NoSQL、OLTP）、キャッシュ、ログ集約、リアルタイム分析、HPC通信（EFA利用）に最適で、Graviton4への移行でコスト性能比を改善可能
  • 運用効果: I/O集約ワークロードのクエリ/トランザクション応答向上とネットワーク/EBS帯域の柔軟な割当てによりリソース最適化が可能
  • リージョン影響: 追加された特定リージョン（米国西部（北カリフォルニア）、アジア太平洋（ソウル・香港・ジャカルタ）、アフリカ（ケープタウン）、カナダ西部（カルガリー））で利用可能。未対応リージョンでは利用不可

技術的な注意点 ​

  • IAM権限: インスタンス起動、EFA設定、ENI作成、必要なEBS/インスタンスストア操作のためのEC2関連権限が必要です
  • インスタンスストア特性: ローカルNVMeはインスタンスストア（エフェメラル）です。インスタンス停止/再起動でデータが消失する可能性があるため、永続性が必要なデータはEBS/S3へバックアップやレプリケーションを行ってください
  • EFA要件: EFAを利用するには対応AMI、EN A/EFAドライバ、適切なセキュリティグループ設定、（ワークロードによっては）クラスタ配置（placement group）等の構成が必要です
  • 帯域幅調整: ネットワーク・EBS帯域を25%調整できるが、これにより他のワークロードや全体割当に影響が出る可能性があるため、パフォーマンステストで最適値を確認してください
  • リージョン制限: 本リリースでの拡張対象リージョン以外では未提供の可能性があるため、利用前にコンソールでリージョンごとの提供状況を確認してください
  • コスト: Graviton4は性能向上でコスト効率が向上する可能性がありますが、インスタンス種別・サイズ・ローカルストレージ容量・リージョンにより料金が異なります。EFAや高帯域利用は追加料金/転送コストに影響するため見積りを確認してください

参考情報 ​

[Ec2] Amazon EC2 M8a instances now available in AWS Europe (Ireland) region ​

概要 ​

Amazon EC2の汎用インスタンスM8aがAWS Europe (Ireland) リージョンで利用可能になりました。5th Gen AMD EPYC（Turin）を採用し、M7a比で性能・メモリ帯域・価格性能が向上しています。

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

M8aインスタンスは5th Gen AMD EPYCプロセッサ（コードネーム：Turin、最大4.5GHz）を搭載し、同クラスのM7aと比較して最大で約30%の性能向上、価格性能で最大約19%の改善を実現します。メモリ帯域はM7a比で約45%増加し、レイテンシに敏感なワークロードにも適しています。ベンチマークではGroovyJVMで最大60%高速化、Cassandraで最大39%高速化を確認しています。SAP認定を取得しており、計12サイズ（うち2サイズはベアメタル）を提供するため、ワークロードに合わせた細かいサイズ選択が可能です。M8aは第6世代AWS Nitroカードを採用しており、高いネットワーク・ストレージスループットが求められる金融アプリケーション、ゲーム、レンダリング、アプリケーションサーバ、シミュレーション、ミドル規模データストア、開発環境、キャッシュ群などに適しています。購入方法はSavings Plans、オンデマンド、Spotが利用可能で、AWS Management Consoleから起動できます。

影響範囲・利用シーン ​

  • 対象ユーザー: クラウドエンジニア、アプリケーションオーナー、DBA、SAP導入者、ゲーム／レンダリング開発者
  • 利用シーン: 高スループット／低レイテンシを要するアプリケーション（金融トレーディング、リアルタイムゲームサーバ、キャッシュ層、ミドル規模のデータストア、シミュレーションやレンダリング処理）
  • 運用効果: 同等規模のワークロードで処理性能向上と価格性能改善が期待でき、スケール-downによるコスト削減やレスポンス改善によるSLA達成が可能

技術的な注意点 ​

  • リージョン制限: 本アナウンスは AWS Europe (Ireland)（eu-west-1）リージョンへの展開を示しています。その他リージョンでは未提供の可能性があります
  • AMI/OS互換性: ベアメタル／仮想インスタンス間でのAMI互換性やライセンス要件に注意。カーネルやドライバ（ENA, NVMeなど）の対応を事前に確認してください
  • ドライバ/カーネル: 第6世代Nitroカードを使用するため、ENA（Elastic Network Adapter）やNVMeドライバに対応したカーネルが必要です。古いカーネルでは性能が出ない／未対応の可能性があります
  • IAM権限: インスタンス起動や関連リソース（ENI、IAMロール、EBS）の操作に必要なEC2関連権限を確認してください
  • インスタンス制限/クォータ: 新しいインスタンスタイプ導入時はアカウントごとのクォータ（vCPU上限等）を超える可能性があるため、事前にクォータ増加申請を検討してください
  • ベアメタル特有の注意: ベアメタルはホスト層へのアクセスが可能ですが、ライセンスやセキュリティ要件、ハードウェア固有の制約（例：一部のVM専用機能未対応）を確認する必要があります
  • コスト: 記載の通りM7a比で価格性能は向上していますが、時間単価はサイズによって異なります。既存のインスタンスからの移行では費用試算（オンデマンド/Spot/Savings Plansを含む）を行ってください
  • パフォーマンス検証: アプリケーション固有のワークロードで性能差が異なるため、本番移行前にベンチマークや負荷試験で確認することを推奨します

参考情報 ​

[Ec2] Amazon EC2 M8a instances now available in AWS GovCloud (US-West) region ​

概要 ​

Amazon EC2の汎用インスタンスM8aが、AWS GovCloud (US‑West) リージョンで利用可能になりました。5th Gen AMD EPYC（Turin）を採用し、M7a比で性能と価格性能比が向上しています。

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

M8aインスタンスは5th Gen AMD EPYCプロセッサ（コードネーム：Turin、最大周波数4.5GHz）を搭載し、M7aに対して最大で約30%の性能向上、最大19%の価格性能向上を実現します。メモリ帯域はM7a比で約45%増加しており、レイテンシーに敏感なワークロードにも適しています。特定のベンチマークではGroovyJVMで最大60%高速化、Cassandraで最大39%高速化を確認しています。M8aはSAP認定済みで、合計12サイズ（うち2つはベアメタル）を提供し、最新の第6世代AWS Nitroカードを採用しています。用途例としては金融アプリケーション、ゲーム、レンダリング、アプリケーションサーバ、シミュレーション、ミッドサイズのデータストア、開発環境、キャッシュ群など高性能・高スループットを要するアプリケーションに適します。購入はOn‑Demand、Savings Plans、Spotで可能です。

影響範囲・利用シーン ​

  • 対象ユーザー: 政府機関・規制対応が必要なエンタープライズ／SaaSプロバイダー、SAP導入企業、金融システム運用者、ゲーム・レンダリング・シミュレーション開発者
  • 利用シーン: レイテンシー敏感なアプリケーション、高スループット処理、中規模データストア、キャッシュノード、SAPワークロード、開発／テスト環境での高性能検証
  • 運用効果: 同等構成での処理性能向上および価格性能比改善によりインスタンスタイプの統合やコスト削減が可能。メモリ帯域の増加によりメモリボトルネックの解消とレイテンシ低減が期待できる

技術的な注意点 ​

  • IAM権限: インスタンス起動やSavings Plans利用には通常のEC2起動・購入権限が必要です（GovCloudアカウント固有のアクセス制御を確認してください）
  • リージョン制限: 本リリースは AWS GovCloud (US‑West) での提供開始。GovCloudは分離されたAWSパーティションであり、利用には専用アカウントと申請が必要／データ居住制約や運用ポリシーに注意してください
  • OS/ドライバ互換性: 最新のLinuxディストリやWindows AMIでのサポートが想定されますが、使用するディストリのカーネル／ENAおよびNVMeドライバの互換性を事前に確認してください。ベアメタル利用時はハードウェア依存のドライバやライセンス制約に留意
  • ライセンスとSAP: M8aはSAP認定済みですが、SAPの導入要件（SLES/RHELバージョン、SAP Notes、ライセンス持ち込みなど）は別途確認してください
  • コスト: AWS側は価格性能比の改善を謳っていますが、実運用での総コストは選択したサイズ、稼働率（On‑Demand/Spot/Savings Plans）、ライセンス形態に依存します。ベアメタルや大容量サイズは費用が高くなる場合があります
  • パフォーマンス注意点: 公表されているベンチマークは特定ワークロードでの結果です。実際のアプリケーションでの効果はワークロード依存のため事前に性能検証（ベンチマーク）を行ってください

参考情報 ​

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

Copyright © 2026