本日の主なトピック #
- Amazon FSx によるオプトインリージョン間バックアップの柔軟性向上
- Amazon OpenSearch Serverless のストレージ効率を改善する Derived Source
- Aurora DSQL 専用 PHP コネクタによる開発と認証の簡素化
- AWS Elastic Disaster Recovery の IPv6 完全対応によるネットワーク近代化への適応
- 最新の第8世代 Intel インスタンス(M8i/R8i)の GovCloud (US-West) 提供開始
¥3,520 Amazonで見る
AWS運用入門 改訂第2版 押さえておきたいAWSの基本と運用ノウハウ [AWS深掘りガイド] 単行本(ソフトカバー) – 2025/7/11
Amazon FSx、AWSオプトインリージョン間でのバックアップコピーに対応 #
投稿日: 2026年04月13日
何ができるようになったのか #
Amazon FSx(Windows File Server、Lustre、OpenZFS)において、**オプトインリージョン(デフォルトで無効化されているリージョン)**との間でのバックアップコピーが可能になりました。同一アカウント内であれば FSx コンソールや API/CLI から、AWS Organizations 内の複数アカウント間であれば AWS Backup を通じて、オプトインリージョンを対象としたクロスリージョン・クロスアカウントのバックアップと復旧が行えます。
何が嬉しいのか #
ビジネス継続性(BCP)、災害復旧(DR)、およびコンプライアンス要件を満たすためのアーキテクチャ設計が、より広範なリージョンで柔軟に行えるようになります。特に特定のオプトインリージョンにデータを局所化させる必要がある、あるいは逆にオプトインリージョンからデータを退避させる必要があるケースにおいて、管理が容易になります。
これまでとどう変わるのか #
- これまで: デフォルトで有効なリージョン間でのバックアップコピーはサポートされていましたが、香港やミラノといったオプトインリージョンを含むクロスリージョンコピーには制限がありました。
- これから: 全14のオプトインリージョンを含め、デフォルト有効リージョンと同様にクロスリージョン・クロスアカウントのバックアップ運用が統合管理できるようになります。
具体的なユースケース #
- 地理的冗長性の確保: アジアパシフィック(香港)リージョンの FSx データを、DR 対策として他のリージョンにバックアップコピーする。
- コンプライアンス遵守: 特定の国や地域(例:イスラエル、イタリア)の法的要件に基づき、オプトインリージョン内でバックアップを保持・移動させる。
Amazon OpenSearch Serverless、ストレージ最適化のための「Derived Source」をサポート #
投稿日: 2026年04月13日
何ができるようになったのか #
Amazon OpenSearch Serverless で、インデックスのストレージ消費を抑える「Derived Source(派生ソース)」機能が利用可能になりました。インデックスのマッピング定義でこの機能を有効にすると、元のドキュメント全体を保持する _source フィールドの保存をスキップし、検索結果の取得時などにインデックス内の値から動的に _source を再構成します。
何が嬉しいのか #
特にログ分析や時系列データなど、インデックスされるフィールドが多いコレクションにおいて、ストレージコストを大幅に削減できます。_source フィールドは通常、生データのコピーとしてストレージを占有しますが、これを排除することで効率的なリソース利用が可能になります。
これまでとどう変わるのか #
- これまで: 2025年6月の OpenSearch 3.0 でベクトルデータ向けに、同年9月の 3.1 で汎用データ向けに導入された機能ですが、Serverless 環境での対応が待たれていました。
- これから: Serverless でも Derived Source が利用可能になり、フルマネージドな運用を維持しつつ、大規模なデータセットのストレージ効率を向上させることができます。
具体的なユースケース #
- 大規模ログ分析: 大量のフィールドを持つログデータを長期間保存する際、ストレージ容量を節約しつつ検索機能を維持する。
- コスト最適化: 読み取り頻度が低く保存量が多いインデックスにおいて、ストレージコストを最小限に抑える。
_source フィールドの保存を明示的にスキップ設定することで機能します。検索や取得の際、OpenSearch は内部の doc_values や stored fields を用いて、必要なフィールドをオンデマンドで復元します。
Aurora DSQL、PHPアプリケーション開発を簡素化する専用コネクタをリリース #
投稿日: 2026年04月13日
何ができるようになったのか #
PostgreSQL 互換の分散型サーバーレスデータベース「Aurora DSQL」において、PHP 用の専用コネクタ(PDO_PGSQL 拡張)がリリースされました。このコネクタは、IAM トークンベースの認証、SSL 設定、コネクションプーリングを自動的に処理し、PHP アプリケーションからの接続を安全かつ容易にします。
何が嬉しいのか #
従来のパスワード認証に伴うセキュリティリスクや管理の負担を排除できます。また、オプティミスティック並行性制御(OCC)によるリトライ処理と指数バックオフが組み込まれており、分散データベース特有の競合が発生した際も、アプリケーション側で複雑なリトライロジックを実装する必要がなくなります。
これまでとどう変わるのか #
- これまで: 2025年5月の Aurora DSQL 一般提供開始以来、PHP からの利用には手動での IAM トークン生成や SSL 設定が必要でした。
- これから: 専用コネクタを使用することで、標準的な PDO インターフェースを維持したまま、Aurora DSQL の分散アーキテクチャに最適化された認証とエラーハンドリングが自動的に適用されます。
具体的なユースケース #
- 高可用性 Web サービス: PHP (Laravel, Symfony 等) で構築された Web アプリケーションのバックエンドとして、グローバルにスケールする Aurora DSQL を安全に利用する。
- サーバーレス API: 短期間で実行される PHP スクリプトから、認証オーバーヘッドを最小限に抑えてデータベースにアクセスする。
AWS Elastic Disaster Recovery、IPv6をサポート #
投稿日: 2026年04月13日
何ができるようになったのか #
AWS Elastic Disaster Recovery (AWS DRS) が、データレプリケーションおよびコントロールプレーンの両方で IPv6 をサポートしました。IPv6 のみのネットワーク環境、またはデュアルスタック環境において、IPv4 アドレスを介さずにディザスタリカバリの設定が可能になります。
何が嬉しいのか #
企業のネットワーク近代化(IPv6 移行)の取り組みに合わせ、DR 構成をシンプルに保つことができます。IPv4 アドレスの枯渇やコスト、制限がある環境でも、確実にデータの保護と復旧体制を構築できます。
これまでとどう変わるのか #
- これまで: すべてのレプリケーションおよびサービス間通信において IPv4 接続が必須でした。
- これから: レプリケーション設定でプロトコルに IPv6 を指定することで、エージェントとサービス間の通信、およびデータ転送にデュアルスタックエンドポイントを利用できます。既存の設定はデフォルトで IPv4 を継続利用し、影響はありません。
具体的なユースケース #
- IPv6 専有ネットワークの保護: セキュリティや運用上の理由で IPv6 のみに制限されているオンプレミス環境や VPC のサーバーを AWS に保護・移行する。
- ネットワークコストの削減: IPv4 アドレスの使用に関連する追加費用や複雑な NAT 設定を排除した DR 構成を構築する。
AWS IoT Core / Device Management、イスラエルおよびミラノリージョンで提供開始 #
投稿日: 2026年04月13日
何ができるようになったのか #
AWS IoT Core および AWS IoT Device Management が、イスラエル(テルアビブ)および欧州(ミラノ)リージョンで利用可能になりました。これにより、世界中で合計27のリージョンで AWS IoT サービスが提供されることになります。
何が嬉しいのか #
これらのリージョンで活動する組織は、デバイス接続のレスポンスタイム短縮、強力なデータレジデンシー(居住性)コントロールの実現、およびリージョン内でのデータ転送によるコスト削減の恩恵を受けることができます。
これまでとどう変わるのか #
- これまで: イスラエルやイタリア周辺のデバイスは、近隣の欧州リージョン(アイルランド、フランクフルト等)を経由して接続する必要がありました。
- これから: 現地リージョンを直接利用することで、低レイテンシな双方向通信(MQTT, HTTPS 等)と効率的なデバイス管理が可能になります。
具体的なユースケース #
- スマートシティ・インフラ: イスラエル国内の公共インフラ設備を低遅延でクラウドに接続し、リアルタイム監視を行う。
- 製造業の IoT 化: イタリア国内の工場設備から生成される大量のデータを、データ居住性の要件を満たしながら管理・分析する。
Amazon EC2 M8i / M8i-flex、AWS GovCloud (US-West) で利用可能に #
投稿日: 2026年04月13日
何ができるようになったのか #
最新の Intel Xeon 6 プロセッサを搭載した汎用インスタンス「M8i」および「M8i-flex」が、AWS GovCloud (US-West) リージョンで利用可能になりました。
何が嬉しいのか #
第7世代(M7i)と比較して最大20%のパフォーマンス向上、前世代の Intel ベースインスタンスと比較して最大2.5倍のメモリ帯域幅を実現します。特に PostgreSQL データベースで最大30%、NGINX で最大60%の高速化が期待でき、GovCloud を利用する政府機関や機密データを扱う組織は、より高いコストパフォーマンスを享受できます。
これまでとどう変わるのか #
- これまで: GovCloud 環境では前世代のインスタンスが主流でしたが、2025年8月に GA された最新の第8世代 Intel インスタンスが導入されました。
- これから: 「M8i-flex」により、リソースをフルに活用しない一般的なワークロードにおいて、より安価に高性能なコンピューティングを利用できるようになります。
具体的なユースケース #
- 政府機関の Web アプリケーション: NGINX やマイクロサービスを最新の M8i-flex インスタンスで稼働させ、コストを抑えつつレスポンスを向上させる。
- 大規模データベース運用: 高いメモリ帯域幅を必要とする PostgreSQL などのミッションクリティカルなデータベースを M8i インスタンスで実行する。
Amazon EC2 R8i / R8i-flex、AWS GovCloud (US-West) で利用可能に #
投稿日: 2026年04月13日
何ができるようになったのか #
メモリ最適化インスタンスの最新世代「R8i」および、同世代で初のメモリ最適化 Flex インスタンス「R8i-flex」が、AWS GovCloud (US-West) リージョンで提供開始されました。Intel Xeon 6 プロセッサを搭載しています。
何が嬉しいのか #
前世代(R7i)と比較してパフォーマンスが20%向上し、メモリ帯域幅は2.5倍に拡大しています。R8i インスタンスは最大 3 TB のメモリと 384 vCPU(96xlarge サイズ)を提供し、SAP 認定も受けているため、GovCloud における大規模なインメモリデータベースやデータ分析ワークロードに最適です。
これまでとどう変わるのか #
- これまで: メモリ集中型のワークロードには R7i 等が使用されていましたが、より高速なメモリ帯域と大容量サイズが GovCloud でも利用可能になりました。
- 将来: R8i-flex の導入により、メモリ容量は必要だが CPU リソースを常に 100% 使用しないようなワークロードにおいて、コスト効率を最適化できます。
具体的なユースケース #
- 大規模 SAP ワークロード: SAP 認定済みの R8i インスタンスを使用して、GovCloud 上でミッションクリティカルな業務システムを安定稼働させる。
- インメモリデータストア: 高いメモリ帯域幅を活かし、Redis や Memcached などのキャッシュ層を最新世代に移行してパフォーマンスを改善する。