AWS What's New Digest

Appearance

2026年04月14日 ​

[Elastic Block Store] Amazon EC2 C8gn, M8gn, and R8gn instances now support higher Amazon EBS-optimized performance ​

概要 ​

Amazon EC2のC8gn、M8gn、R8gnインスタンス（48xlargeおよびmetal-48xl）で、Amazon EBS向けの最大スループットとIOPSが2倍に引き上げられました。新しいインスタンスや起動後に停止→起動した既存インスタンスは追加費用なしで恩恵を受けられます。

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

対象は AWS Graviton4プロセッサと第6世代AWS Nitroカードを搭載するC8gn、M8gn、R8gnの48xlargeおよびmetal-48xlサイズです。Nitro Systemの強化により、EBS最適化性能が従来の最大60 Gbps / 240,000 IOPSから、120 Gbps / 480,000 IOPSへと倍増しました。これにより、ネットワーク負荷が高くかつブロックストレージ性能を要求するワークロード（大規模データ分析、高性能ファイルシステム、並列I/Oバウンドアプリケーションなど）でスループットとIOPSのボトルネックを緩和できます。今日以降に起動される新規インスタンスは自動的に新性能が有効になります。既存の稼働中インスタンスは停止→起動を行うことで新しいEBS性能が適用されます。これは追加インスタンス料金なしで全てのAWSリージョン（該当インスタンスタイプが一般提供されているリージョン）で利用可能です。ただし、EBSの使用量やプロビジョンドIOPSを増やすとEBSの課金が増える点には注意が必要です。

影響範囲・利用シーン ​

  • 対象ユーザー: クラウドエンジニア、SRE、データエンジニア、HPC/ビッグデータワークロードを扱う開発者
  • 利用シーン: 大規模データ分析、分散ファイルシステム（例: Lustre、BeeGFS）、データウェアハウス、ネットワーク集約型アプリケーションでの高スループットなブロックストレージ利用
  • 運用効果: EBS帯域幅とIOPSが倍増することでI/Oボトルネックが緩和され、ジョブ完了時間短縮やスループット向上が期待できる。既存インスタンスは停止→起動で適用可能なため短期的なメンテナンスで性能を引き上げられる

技術的な注意点 ​

  • 対象サイズ: 効果が適用されるのは C8gn、M8gn、R8gn の 48xlarge と metal-48xl のみです（他サイズは対象外）
  • 停止/起動: 稼働中インスタンスは停止してから起動すると新性能が有効になります。停止中の影響（パブリックIPの変更やインスタンスストアのデータ消失等）に注意してください
  • リージョン制限: 該当インスタンスタイプが一般提供されている全リージョンで利用可能とされていますが、リージョンにより未提供の場合があるため事前にリージョンの可用性を確認してください
  • コスト: インスタンス側の追加料金は発生しませんが、増加したスループットやIOPSを利用するとEBSの課金（プロビジョンドIOPSやスループット関連の利用量）が増える可能性があります
  • IAM権限: 停止/起動を行うには ec2:StopInstances / ec2:StartInstances 等の適切な権限が必要です
  • OS/ドライバ: 高いEBS性能を活かすにはゲストOSのNVMe/EBSドライバやカーネルが最新に近いこと、IOスケジューラやボリュームの設定（マルチキュー、io-uring等）を最適化しておくことを推奨します
  • 互換性: メタルインスタンス（metal-48xl）はハードウェア直接アクセスが可能なため構成上の違いがあります。停止→起動の挙動やインスタンスストアの有無など運用差分に注意してください

参考情報 ​

[Opensearch Service] Amazon OpenSearch Serverless now supports Derived Source for storage optimization ​

概要 ​

Amazon OpenSearch ServerlessがDerived Sourceをサポートしました。インデックスに既に格納されている値から必要時に_sourceを動的に再構築することで、コレクションのストレージ消費を削減できます。

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

Derived Sourceは、元のドキュメントのコピーである_sourceフィールドを永続的に保持せず、既にインデックスに格納されているフィールド値から必要時に_sourceをオンザフライで再構築する仕組みです。これにより、特に多くのインデックス済みフィールドを含む時系列データやログ解析向けコレクションでストレージ量を大幅に削減できます。Derived Sourceはインデックス単位で有効化でき、インデックス作成時またはマッピング更新時に設定します。再構築はインデックス内の格納済み値（インデックス、doc_valuesなど）を利用するため、_sourceに存在していたがインデックス化されていないフィールドや元のJSONのフォーマット（順序や空白など）は復元できない点に注意が必要です。AWSのOpenSearch Serverlessが利用可能なすべてのリージョンでサポートされています。

影響範囲・利用シーン ​

  • 対象ユーザー: ログ/時系列データを扱うデータエンジニア、SRE、検索プラットフォーム運用者
  • 利用シーンまたは効果: ログ・メトリクス等の大量データを長期保存するコレクションでのストレージ削減（コスト削減）
  • 運用効果: ストレージ使用量の低減によるストレージコスト削減。特にフィールドが多いドキュメントで効果が大きい
  • パフォーマンス影響: _source再構築処理によりドキュメント取得時のCPU負荷やレイテンシが若干増加する可能性があるため、取得頻度が高いワークロードでは注意が必要
  • 互換性影響: _sourceへの依存がある更新処理やスクリプト、あるいは元のJSONの完全な復元を前提とする運用に影響が出る可能性がある

技術的な注意点 ​

  • IAM権限: インデックス設定の作成/更新を行うためのOpenSearch Serverless関連の適切な権限が必要です
  • リージョン制限: 記事によればOpenSearch Serverlessがサポートされているすべてのリージョンで利用可能です。利用前に対象リージョンでのサービス提供状況を確認してください
  • コスト: ストレージコストは低減される一方で、クエリ時のCPU使用増加によりクエリコスト（サーバーレスの処理料金やレスポンス時間に起因する運用コスト）やレイテンシの影響が出る可能性があります
  • 互換性/制約: インデックスされていないフィールドや一部のメタ情報（元のJSONの順序・フォーマット等）は再構築できません。ハイライト、スクリプト更新、部分更新(update that relies on _source)、再インデックスや外部プロセスで元の生データを必要とする処理は動作が異なるか失敗する可能性があります
  • インデックス設定/運用: Derived Sourceはインデックスレベルでの設定（作成時またはマッピング更新時）で有効化します。既存のドキュメントに対して有効化する場合は、再インデックスが必要になるケースがあるため計画的に実施してください
  • トラブルシューティング: _sourceが期待どおり復元されない場合は、該当フィールドが実際にインデックス/格納されているか（indexed/stored/doc_values など）を確認してください
  • 注意点: 特に更新頻度の高いドキュメントや、部分的な更新/アップサートで_sourceに依存している実装がある場合は、事前に影響評価とテストを行ってください

参考情報 ​

[Redshift] Amazon Redshift introduces key performance optimization for Top-K queries ​

概要 ​

Amazon RedshiftがTop-K（ORDER BY … LIMIT）クエリの処理をブロック単位で賢くスキップする最適化を導入し、不要なI/Oと計算を大幅に削減して応答を高速化します。パッチリリースP199以降で全リージョンに追加費用なく自動適用されます。

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

この最適化は、ORDER BYで指定されたカラムのブロックごとの最小/最大値（ブロックメタデータ）を利用して、読み込むべきデータブロックの順序付けと選別を行います。処理中はメモリ内でK件の候補行のみを保持し、それより不利なブロックをスキップすることで、テーブル全体のスキャンを避けられる場合に限定して最小限のブロックだけを読み取ります。特にデータが物理的にソート済み、または部分的にソートされており、最新行がストレージ末尾に追記されるようなケース（例：ORDER BY … DESC LIMIT K）で効果が顕著です。典型的なユースケースは大量のトランザクションから直近K件を取得する処理や、販売データから上位/下位K件の製品抽出、膨大なLLMプロンプトの中から最新/最古のK件抽出などです。本機能はP199パッチ以降のRedshiftで追加料金なしに自動で適用され、クエリの書き換えや設定変更は不要です。ただし、物理配置とORDER BYカラムの相関が弱い場合や、複雑な結合・集計・ウィンドウ関数などを含むクエリでは適用できないことがあり得ます。また、メモリ使用量は保持するK行に比例しますので非常に大きなKを指定する場合は注意が必要です。

影響範囲・利用シーン ​

  • 対象ユーザー: データ分析者、BIエンジニア、SRE/運用チーム、機械学習/NLPエンジニア
  • 利用シーン: 大量トランザクションからの最新K件取得、販売カタログからの上位/下位K件抽出、LLM用プロンプトの最新/最古K件抽出などTop-Kクエリ全般
  • 運用効果: I/OとCPU負荷の低減によりクエリ応答時間が大幅短縮され、クエリコスト削減とクラスタリソースの空き確保による他処理への影響軽減が期待できる

技術的な注意点 ​

  • パッチ/バージョン: P199以降のパッチが適用されたAmazon Redshiftで利用可能です
  • 適用条件: ORDER BY + LIMIT（Top-K）クエリが対象。物理ブロックのmin/max情報が有効に働く（ソート/部分ソートされている等）場合に特に効果を発揮します
  • 互換性/制約: ジョイン、集計、ウィンドウ関数、複雑なサブクエリ等を含む場合は最適化の適用可否が実行計画に依存するため、効果が限定されることがあります
  • メモリ/リソース: 実行時にK件分の候補行をメモリで保持するため、非常に大きなKを指定するとメモリ負荷が増加します
  • IAM権限: 本最適化自体に特別なIAM権限は不要です（既存のクエリ実行権限で自動適用されます）
  • リージョン制限: Amazon Redshiftが提供されている全リージョンで利用可能とされています（P199以降）
  • コスト: 最適化の利用に追加料金は発生しません。ただしクエリ実行時間と読み取りデータ量の削減により実質的なコスト低減が見込めます
  • 確認方法/運用: クラスターのパッチレベルを確認し（P199以上）、対象クエリでEXPLAINやクエリ実行統計（読み取られたブロック数）を比較して効果を検証してください

参考情報 ​

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

概要 ​

Aurora DSQL向けのPHPコネクタ（PDO_PGSQL互換）が公開され、IAMトークンによる自動認証、SSL設定、コネクションプーリングなどが組み込まれてPHPアプリケーションを簡単にAurora DSQLへ接続できるようになりました。

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

Aurora DSQL Connector for PHP (PDO_PGSQL)は、既存のPDO_PGSQL機能と完全互換を保ちながら、以下を自動化／提供します。認証トークンの自動生成と更新により従来の静的パスワード保存に伴うセキュリティリスクを排除し、接続ごとに有効なIAMベースのトークンを用いる仕組みを実装します。またSSL設定の自動化、接続プーリングのサポートによりスクリプトから本番ワークロードまで同一の認証方式でスケール可能です。オプトインの楽観的同時実行制御（OCC）再試行（指数バックオフ）を備え、クライアント側の再試行ロジック実装を容易にします。さらにカスタムIAM認証情報プロバイダとAWSプロファイルのサポートにより、EC2/ECS/IAMロールやローカルのAWS CLIプロファイル等を使った認証運用が可能です。コネクタはIAMトークン生成（RDS/AuroraのDB認証トークン）とトークン有効期限管理を行い、必要に応じて再生成します。導入は既存のPDO_PGSQLコードを大きく変えずに行え、PHP側ではPDOインターフェースを通して接続・クエリを実行できます。

影響範囲・利用シーン ​

  • 対象ユーザー: PHPでAurora DSQLを利用するアプリケーション開発者、SRE/運用チーム
  • 利用シーン: ウェブアプリやバッチ処理などのPHPアプリケーションをIAMベースの短期トークンで安全に接続する場面
  • 運用効果: 静的なDBパスワード管理を不要にしてセキュリティを向上、コネクションプーリングでスループット改善、組み込みの再試行機構でトランザクションの信頼性が向上

技術的な注意点 ​

  • 必要コンポーネント: PHP本体、PDO_PGSQL拡張が必要です。コネクタはPDOベースの接続を前提とします
  • IAM権限: DB接続用のIAM認証トークン発行（rds-db:connect など）や必要に応じてSTS/GetCredentialsを行える権限が必要です。IAMロール／プロファイルの設定を確認してください
  • トークン有効期限: IAM生成トークンは短期（例:数分〜15分程度）で期限切れになるため、コネクタ側での再生成とプール管理の挙動を理解しておく必要があります
  • 再試行とOCC: OCC再試行はオプトイン機能です。トランザクションの冪等性や副作用のある処理では注意が必要です
  • コスト: コネクタ自体に追加料金は発生しませんが、トークン生成やAPI呼び出しはAWS APIの呼び出しとなり大量に発生するとAPIレートや関連サービスの利用に影響する可能性があります
  • リージョン制限: Aurora DSQL自体が利用可能なリージョンに依存します。導入前に対象リージョンでAurora DSQLおよび関連コネクタがサポートされているか確認してください
  • 互換性: 既存のPDO_PGSQLコードと互換性を保つ設計ですが、接続文字列や認証方式の切替箇所は確認・テストしてください
  • セキュリティ: SSLが自動構成されますが、証明書検証ポリシーやTLSバージョンの要件は環境に合わせて確認してください

参考情報 ​

[Govcloud Us] Amazon EC2 M8i and M8i-flex instances are now available in AWS GovCloud (US-West) Region ​

概要 ​

Amazon EC2の新しい汎用インスタンスファミリ M8i と M8i-flex が AWS GovCloud (US-West) リージョンで利用可能になりました。カスタムIntel Xeon 6プロセッサを採用し、先代のIntelベースインスタンスに比べてメモリ帯域や価格性能比が向上しています。

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

M8i/M8i-flexはAWS専用カスタムIntel Xeon 6プロセッサを搭載し、同等のIntelベースクラウドプロセッサと比べて最大で15%の価格性能向上、メモリ帯域幅で最大2.5倍を実現するとしています。M7i/M7i-flex比では最大20%の総合性能向上をうたっており、ワークロードによってはさらに大きな改善が見込めます（例：PostgreSQLで最大30%高速化、NGINXで最大60%、AI推薦モデルで最大40%の改善）。 M8i-flexは大〜16xlargeまでの一般的なサイズをカバーし、計算資源を完全に使い切らない多くの一般用途（Web/アプリサーバ、マイクロサービス、中小データストア、VDI、エンタープライズアプリ等）でコストパフォーマンスを出しやすい設計です。一方、M8iは継続的な高CPU使用率や最大サイズが必要なワークロード向けで、SAP認定を受けた13サイズ（うちベアメタル2サイズ、96xlargeを新規追加）を提供します。ガイドはAWSマネジメントコンソールから起動可能で、詳細はインスタンスタイプページとAWS Newsブログを参照してください。

影響範囲・利用シーン ​

  • 対象ユーザー: クラウドエンジニア、インフラ/プラットフォーム担当、アプリ開発者、データベース管理者
  • 利用シーンまたは効果: 一般目的のWeb/アプリケーションサーバ、マイクロサービス、小中規模データストア、VDI、エンタープライズ/SAPワークロード、機械学習推論や推薦モデルの高速化
  • 運用効果: 同等ワークロードでの価格性能改善によりインスタンスコスト削減やスループット向上、特定アプリケーション（PostgreSQL/NGINX/推奨モデル）でのレスポンス向上が期待できる

技術的な注意点 ​

  • リージョン制限: 本アナウンスは AWS GovCloud (US-West) 向けの提供開始。他リージョンでの利用可否は別途確認してください
  • IAM権限: 新インスタンスタイプの起動には通常のEC2起動権限が必要。組織ポリシーでインスタンスタイプ制限をしている場合は更新が必要です
  • コスト: 価格性能は向上しているがインスタンス単価はサイズ/リージョンで異なるため、実運用前に料金表で確認し性能ベンチマークと合わせて比較してください
  • ベアメタル注意点: M8iの一部サイズはベアメタル提供。ベアメタルはハイパーバイザ機能やサードパーティソフトの要件に影響するため利用前に制約を確認してください
  • 互換性/認証: M8iはSAP認定済み。ただしSAP導入時はSAPのサポート対象要件や構成ガイドに従い検証してください
  • ベンチマーク推奨: 公表値は代表的な比較結果のため、実ワークロードでの性能検証（CPU/メモリ/ネットワーク/ストレージI/O）を事前に行ってください

参考情報 ​

[CloudWatch] Amazon CloudWatch Logs Insights now supports saved queries with parameters ​

概要 ​

Amazon CloudWatch Logs Insightsの保存クエリでパラメータが利用可能になりました。プレースホルダ付きの再利用可能なクエリテンプレートに値を渡せるため、ほぼ同一のクエリを複数保持する必要がなくなります。

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

保存クエリに最大20個のパラメータを定義でき、各パラメータには任意のデフォルト値を設定できます。クエリテンプレート内にプレースホルダを置き、実行時にパラメータ値を渡すことで同一テンプレートを異なる条件（例: log level、service name、時間範囲など）で使い回せます。実行時の呼び出し例としては $ErrorsByService(logLevel="ERROR", serviceName="OrderEntry") のような構文を使用します。複数のパラメータ付き保存クエリを組み合わせて複雑なログ解析ワークフローを構築することもでき、クエリの保守負荷を大幅に削減します。機能は全ての商用AWSリージョンで利用可能で、Amazon CloudWatchコンソール、AWS CLI、AWS CDK、各種AWS SDKから作成・実行できます。なお、保存クエリの追加自体は料金対象ではありませんが、Logs Insightsクエリの実行はスキャン量に対する課金が発生するため、実行頻度やスキャン対象の範囲によってコストが変動します。

影響範囲・利用シーン ​

  • 対象ユーザー: ログ解析を行うソフトウェア開発者、SRE/運用チーム、セキュリティ分析者
  • 利用シーン: サービス別やレベル別の障害調査、定型的なログ検索テンプレートの共有、自動化された診断ジョブやCI/CDパイプライン内のログ確認
  • 運用効果: クエリの重複管理が不要になりメンテナンス負荷が低下、テンプレート化により誤用が減り再現性のある解析が可能
  • コスト影響: 保存クエリ自体に追加料金はないが、パラメータ化によるクエリ実行頻度やスキャン対象拡大でLogs Insightsのスキャン課金が増える可能性がある
  • リージョン: 全商用AWSリージョンで利用可能（パブリック/政府/中国リージョンの扱いは別途確認）

技術的な注意点 ​

  • パラメータ上限: 1つの保存クエリにつき最大20個のパラメータを定義できます
  • デフォルト値: 各パラメータは任意でデフォルト値を設定可能。実行時に値を渡さない場合はデフォルトが使用されます
  • 呼び出し構文: 保存クエリ名を$接頭辞で呼び出し、括弧内に key="value" の形式でパラメータを渡します（例: $ErrorsByService(logLevel="ERROR")）
  • IAM権限: 保存・取得・実行にはCloudWatch Logsの権限が必要です。代表的なAPI権限は logs:PutQueryDefinition, logs:DescribeQueryDefinitions, logs:GetQueryDefinition, logs:StartQuery, logs:GetQueryResults などです。実運用では最小権限でロール/ポリシーを設計してください
  • SDK/CLI/CDK: コンソールのほかAWS CLI、AWS SDK、AWS CDKで作成・実行可能。各ツールでの具体的なパラメータ指定方法はドキュメントを参照してください
  • 入力検証: パラメータはクエリに埋め込まれて評価されるため、受け渡す値の形式（文字列や時間書式など）を統一・検証しておくことを推奨します。大きな時間範囲や広範なフィルタを誤って指定するとスキャン量が増えコスト増加につながります
  • 互換性/制限: 記載のとおりパラメータ数とデフォルトの仕様がある以外にも、クエリ言語の構文に依存する制約がある可能性があるため、複雑な式にパラメータを挿入する場合は動作確認を行ってください
  • リージョン制限: 全商用リージョンで利用可能。特殊リージョン（AWS GovCloud、AWS China）での対応状況は別途確認が必要です

参考情報 ​

[Govcloud Us] Amazon EC2 R8i and R8i-flex instances are now available in AWS GovCloud (US-West) Region ​

概要 ​

Amazon EC2の新しいメモリ最適化インスタンス「R8i」と柔軟サイズの「R8i-flex」がAWS GovCloud (US‑West)リージョンで利用可能になりました。カスタムIntel Xeon 6プロセッサ搭載により従来世代より高いメモリ帯域と価格性能比を実現します。

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

R8iおよびR8i-flexはAWS専用のカスタムIntel Xeon 6プロセッサを採用したメモリ最適化インスタンスです。主な特徴は以下の通りです。

  • 性能: 既存のIntelベース前世代比で最大15%の価格性能改善、メモリ帯域は2.5倍を実現。R7i比で平均20%高い性能（ワークロードによってはそれ以上の改善）。
  • ワークロード別の向上例: PostgreSQLで最大30%高速、NGINX等のWebアプリで最大60%高速、レコメンデーション等の深層学習モデルで最大40%高速。
  • R8i-flex: メモリ最適化のFlexライン初登場。一般的に使われるサイズ（large〜16xlarge）を提供し、計算資源をフルに使わないメモリ集約型アプリケーションでのコスト最適化が容易。
  • R8i: 13種類のサイズを提供（うち2つはベアメタル）、新たに96xlargeサイズを追加し、大規模・継続的な高CPU使用率が必要なワークロード向けに最適。
  • SAP対応: R8iはSAP認定済みで、142,100 aSAPSを提供。ミッションクリティカルなSAPワークロードに適合。
  • 利用方法: AWS Management Consoleから起動可能。現時点ではAWS GovCloud (US‑West)リージョンで利用可能と発表されています。

影響範囲・利用シーン ​

  • 対象ユーザー: GovCloud環境でメモリ集約型アプリケーション（データベース、インメモリキャッシュ、分析、機械学習推論、SAP等）を運用するクラウドエンジニア／アーキテクト
  • 利用シーンまたは効果: 大規模PostgreSQLやNGINXなどのWebサービス、レコメンデーションモデル、SAPミッションクリティカル環境でのスループット向上とコスト効率化
  • 運用効果: 同等性能を低コストで達成したり、既存インスタンスから移行することでレスポンス改善やスケールダウンが可能
  • リージョン制限: 発表時点ではAWS GovCloud (US‑West)で利用可能。商用（パブリック）リージョンへの展開状況は別途確認が必要
  • コスト影響: 価格性能比は改善されているが、ベアメタルや大サイズは単価が高いためワークロードに応じたサイズ選定でコスト最適化が必要

技術的な注意点 ​

  • IAM権限: インスタンス起動にはec2:RunInstances等の標準EC2権限と、必要に応じてiam:PassRoleが必要です
  • リージョン制限: 現時点での提供はAWS GovCloud (US‑West)リージョン。別リージョンでの利用可否は公式アップデートを確認してください
  • AMI/互換性: x86_64（Intel）アーキテクチャ向けのAMIsを使用。ENAや最新ドライバが必要な場合があるため、最適化済みのAMIを選択してください
  • サイズ/機能制限: R8i-flexはlarge〜16xlargeが提供範囲。R8i本体は13サイズ（うち2つはベアメタル）で、最大全96xlargeが追加されています。必要なサイズがリージョンで利用可能か事前に確認してください
  • SAP/認証: R8iはSAP認定（142,100 aSAPS）ですが、SAP導入時はSAP NotesやAWSのSAPページでサポートポリシーと構成要件を確認してください
  • コスト: 発表は価格性能の改善を示していますが、実際の料金はリージョン・サイズ・購入オプション（オンデマンド/リザーブド/Savings Plans）で変動します。移行前にベンチマークと見積りを推奨
  • ベアメタル注意点: ベアメタルはハイパフォーマンスだが単価が高く、ハードウェア依存のライセンスや運用上の制約に留意してください

参考情報 ​

[Iot Core] AWS IoT is now available in Israel (Tel Aviv) and Europe (Milan) AWS Regions ​

概要 ​

AWS IoT Core と AWS IoT Device Management が Israel (Tel Aviv) と Europe (Milan) リージョンで利用可能になりました。これにより、これら地域の顧客はレイテンシ短縮、データ主権の強化、データ転送コストの削減といった利点を享受できます。

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

AWS IoT Core は、MQTT、HTTPS、（一部リージョンで）LoRaWAN といった業界標準の双方向プロトコルを用いて数十億の IoT デバイスを安全にクラウドへ接続し、大規模にメッセージをルーティングするマネージドサービスです。AWS IoT Device Management はデバイスの検索、分類、監視、リモート管理（ジョブ実行、OTA 更新など）をスケーラブルに行うための機能を提供します。今回の拡張により、AWS IoT は世界で27リージョンで利用可能となり、Tel Aviv と Milan のリージョンを利用することでリージョン内エンドポイント、ローカルなレジデンシ要件や低遅延性を活かした設計が可能です。導入時は各リージョンのエンドポイント、認証（X.509 証明書や Cognito、IAM ポリシー）、およびデバイスシャドウやメッセージルールの設定を確認してください。なお LoRaWAN やその他の付帯機能はリージョンごとにサポート状況が異なるため、該当リージョンでの対応状況を事前に確認する必要があります。

影響範囲・利用シーン ​

  • 対象ユーザー: IoT プラットフォーム開発者、組み込み/ファームウェアエンジニア、SRE/運用チーム、規制対応担当者
  • 利用シーン: ローカル顧客向けのリアルタイム制御・監視（工場監視、スマートビル管理、ヘルスケア機器連携など）、データ主権要件があるアプリケーションの地域内データ処理
  • 運用効果: レイテンシ低減による制御応答性向上、リージョン内でのデータ保管によりコンプライアンス対応が容易、クロスリージョン転送の削減による通信コスト最適化

技術的な注意点 ​

  • IAM権限: iot:Connect、iot:Publish、iot:Subscribe、iot:Receive 等のデバイス側権限や、Device Management 用の iot:CreateJob/iot:UpdateThing/iot:Describe* などの管理系権限を適切に付与してください
  • リージョン制限: Tel Aviv と Milan で IoT Core / Device Management は利用可能ですが、LoRaWAN や関連サービス（Device Defender、Fleet Provisioning、OTA など）のサポート状況は機能ごとに異なる可能性があるため、利用前にリージョン別の対応状況を確認してください
  • コスト: リージョン内通信は通常コストが低くなりますが、データ取り込み・メッセージ処理・Device Management の API 使用・データ転送量に基づく課金が発生します。クロスリージョンやクロスアカウントでの連携がある場合は追加の転送コストを見積もってください
  • エンドポイント/証明書: 各リージョンで固有の IoT エンドポイントが提供されます。デバイスの証明書（X.509）や MQTT over TLS の設定、Fleet Provisioning のエンドポイントを地域向けに設定してください
  • 統合サービス依存: IoT から連携する Lambda、Kinesis、S3、DynamoDB、IoT Analytics 等の各サービスが対象リージョンで利用可能かを事前に確認してください

参考情報 ​

[Backup] Amazon FSx now supports copying file system backups across AWS opt-in Regions ​

概要 ​

Amazon FSx がオプトインリージョン（デフォルトで無効なリージョン）へのファイルシステムバックアップのコピーをサポートしました。これにより FSx for Windows File Server、FSx for Lustre、FSx for OpenZFS のバックアップをより広いリージョン間／アカウント間で保管・復元できるようになります。

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

今回の拡張により、Amazon FSx はオプトインリージョンへ、またはオプトインリージョンからのバックアップコピーをサポートします。対象は Amazon FSx for Windows File Server、Amazon FSx for Lustre、Amazon FSx for OpenZFS です。機能の主なポイントは次の通りです。

  • 同一AWSアカウント内: Amazon FSx コンソール、API、CLI を使ってオプトインリージョンへ/からバックアップをコピー可能。
  • クロスアカウント（同一AWS Organization内）: AWS Backup を利用してオーガニゼーション内のアカウント間でオプトインリージョンをまたいだバックアップコピーが可能。
  • 目的: 事業継続（BCP）、災害復旧（DR）、コンプライアンス要件対応のために、デフォルト有効リージョンに限定されないクロスリージョン・クロスアカウントのバックアップ設計が可能になる。
  • 既存動作との差分: これまではデフォルトで有効なリージョン間でのみバックアップのコピーが可能だったが、今回オプトインリージョンを含む範囲に拡大された。
  • 実装上の注意点: オプトインリージョンは各アカウントで有効化（opt-in）しておく必要がある点、暗号化（KMS）やクロスアカウントアクセスの権限設定が必要になる点に留意。

影響範囲・利用シーン ​

  • 対象ユーザー: クラウドアーキテクト、SRE/運用チーム、バックアップ/セキュリティ担当者
  • 利用シーン: 災害対策のため地理的に離れたオプトインリージョンへバックアップを保管する、組織内アカウント間でのバックアップ共有、法規制により特定リージョンでのデータ保管が必須なケース
  • 運用効果: 多様なリージョンを使った冗長化設計が可能になり、DR計画の柔軟性と地域コンプライアンス対応力が向上
  • 制限/範囲: オプトインリージョンは事前にアカウントで有効化する必要があり、クロスアカウントコピーは同一AWS Organization内でのAWS Backup経由に限定される

技術的な注意点 ​

  • IAM権限: FSx のバックアップ操作には該当する FSx の API 権限が必要。クロスアカウントで AWS Backup を使う場合は AWS Backup のサービスロール、バックアップボールトポリシー、ターゲットアカウントの許可設定が必要です。
  • リージョン制限: 対象となるのはオプトインリージョン（デフォルトで無効なリージョン）へのコピー対応で、利用前に当該リージョンをアカウントで有効化（opt-in）してください。リージョンでの FSx の各ファイルシステムタイプのサポート状況も確認が必要です。
  • KMS/暗号化: 暗号化されたバックアップをコピーする場合、宛先リージョンにおける KMS キー（またはマルチリージョンキー）と適切なキーアクセス許可が必要です。KMS キーはリージョンごとに管理されるため、クロスリージョンでの暗号化設定を事前に設計してください。
  • コスト: クロスリージョンコピーによるコピー操作費用、宛先リージョンでのバックアップストレージ料金、リージョン間データ転送費が発生する可能性があります。料金表と見積もりで確認してください。
  • 操作/自動化: 同一アカウント内の単発操作は FSx コンソール/API/CLI で実行可能。組織全体のポリシーや定期コピーを運用する場合は AWS Backup を使ったバックアッププラン／ポリシーの利用が推奨されます。
  • サービスクォータ: 大量のバックアップコピーや一度に多数のジョブを実行する場合はサービスクォータ（APIレート、ストレージ上限等）を確認し、必要なら引き上げ申請を行ってください。

参考情報 ​

[Elastic Disaster Recovery] AWS Elastic Disaster Recovery now supports IPv6 ​

概要 ​

AWS Elastic Disaster Recovery (AWS DRS) がデータレプリケーションと制御プレーン接続の両方で IPv6 をサポートするようになりました。IPv6のみ／デュアルスタック環境でも IPv4 を用いず DR 構成が可能になります。

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

今回の拡張により、AWS DRS はエージェントとサービス間の制御プレーン通信およびデータレプリケーションで IPv6 を利用できるようになりました。レプリケーション設定でインターネットプロトコルを IPv6 に変更すると、DRS のデュアルスタックエンドポイント（IPv4/IPv6）を経由してエージェントからサービスへの通信およびレプリケーションが行われます。これにより、IPv6-only 環境や IPv4 アドレス利用が制限される環境でもオフサイト レプリケーションと迅速なリカバリ（ポイントインタイム復旧を含む）が可能になります。既存のレプリケーション設定は影響を受けず、デフォルトは従来通り IPv4 のまま動作します。機能は AWS DRS が利用可能でかつ Amazon EC2 が IPv6 をサポートするリージョンで提供されます（最新の対応状況は AWS Regional Services List を参照）。

影響範囲・利用シーン ​

  • 対象ユーザー: インフラ／クラウドエンジニア、SRE、災害復旧を担当する運用チーム
  • 利用シーン: IPv6-only またはデュアルスタック環境でのデータレプリケーションおよびフェイルオーバー検証、クラウド移行時のネットワーク近代化要件への対応
  • 運用効果: IPv4 アドレスを確保できない環境でも DR を構築可能になり、ネットワーク制約下での可用性向上と運用の簡素化が期待できる
  • リージョン／前提条件: AWS DRS と Amazon EC2 の両方で IPv6 をサポートするリージョンのみ有効（最新は AWS Regional Services List を確認）

技術的な注意点 ​

  • IAM権限: 既存の DRS 用 IAM ポリシーは変更不要のはずだが、エージェント導入やレプリケーション設定変更には該当する DRS の操作権限が必要
  • エージェントの要件: エージェント側が IPv6 をサポートするバージョンであることを確認してください（エージェントを最新版にアップデートする必要がある場合があります）
  • ネットワーク設定: オンプレ側および VPC 側で IPv6 のルーティング、ルートテーブル、セキュリティグループ、NACL を適切に設定し、DRS の IPv6 エンドポイントへの疎通（TCP/UDP ポート要件）を許可してください
  • DNS: エンドポイント解決で AAAA レコードが利用されるため、DNS 設定と解決経路を確認してください
  • 既存設定への影響: 既存のレプリケーション設定は自動で切り替わらず IPv4 のまま動作します。IPv6 を使うにはレプリケーション設定を明示的に変更する必要があります
  • リージョン制限: 機能は DRS と EC2 の IPv6 サポートがあるリージョンに限定されます。東京など特定リージョンでの可用性は AWS Regional Services List を確認してください
  • コスト: 機能自体に追加料金は明示されていませんが、データ転送量（IPv6 のアウトバウンド料金）、レプリケーションストレージ、テスト時の EC2 インスタンス費用などの既存コストが発生します
  • 運用上の推奨: 本番切替前に IPv6 ベースのレプリケーションおよびフェイルオーバーを検証し、ログやモニタリングで IPv6 通信の正常性を確認してください

参考情報 ​

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

Copyright © 2026