みなさん、こんにちは。ソリューションアーキテクトの古屋です。今週も 週刊AWS をお届けします。 AWS 初学者向けイベント「 AWS JumpStart 2026 」が今年も開催されます。事前学習用動画と 2 日間のオンラインワークショップを通じて、AWS の基礎から実践的なアーキテクチャ設計までを集中的に学べるプログラムです。全 4 回開催で、初回は 5 月 11 日（月）〜 12 日（火）です。参加費無料で、参加登録は こちら からお申し込みいただけます。AWS をこれから学びたい方やチームの新メンバーにぜひご紹介ください！ それでは、先週の主なアップデートについて振り返っていきましょう。 2026年4月6日週の主要なアップデート 4/6(月) Amazon S3 が新規および既存バケットに対してデフォルトでSSE-C を無効化する新しいセキュリティ設定の展開を開始 Amazon S3 で、顧客提供キーによる暗号化 (SSE-C) がデフォルトで無効化される新しいセキュリティ設定の展開が開始されました。新規作成される汎用バケットでは、顧客提供キーによる暗号化 (SSE-C) がデフォルトで無効化されます。SSE-C 暗号化オブジェクトが存在しない AWS アカウントでは、既存バケットについても SSE-C が無効化されます。一方、SSE-C を既に使用している AWS アカウントでは、既存バケットの暗号化設定は変更されません。この変更により、セキュリティリスクの軽減と管理の簡素化が期待できます。詳細は こちらの S3 ユーザーガイドをご参照ください。 Smithy-Java クライアントフレームワークの一般提供開始を発表 Smithy-Java クライアントフレームワークの一般提供を開始しました。Smithy モデルから型安全な Java クライアントコードを自動生成できるフレームワークで、シリアライゼーションやプロトコル処理などのボイラープレートコードを手書きする必要がなくなります。プロトコルに依存しない設計で、AWS JSON や REST-JSON、Smithy RPCv2 CBOR などを実行時に切り替え可能です。Java 21 の仮想スレッドを基盤に構築されており、複雑な非同期処理を書かずにシンプルなブロッキング API で高パフォーマンスなアプリケーションを構築できます。詳細は こちらの Blog 記事をご参照ください。 Amazon WorkSpaces Personal が PrivateLink の一意な DNS 名をサポート Amazon WorkSpaces Personal で PrivateLink の各 VPC エンドポイントに個別の DNS 名が付与されるようになりました。従来は共通の DNS 名を使用していたため、複数の AWS アカウントや VPC で WorkSpaces を利用する際に DNS 名の衝突が発生し、同時利用が困難でした。今回のアップデートにより、各エンドポイントが独自の DNS 名を持つため、企業の複数アカウント環境でも安全に WorkSpaces を分離して運用できます。DNS 名は AWS が自動管理するため Route 53 の追加設定は不要です。詳細は こちらのドキュメントをご参照ください。 4/7(火) AWS Transfer Family がコネクタと Web アプリで IPv6 をサポート AWS Transfer Family で IPv6 サポートが開始されました。SFTP コネクタ、AS2 コネクタ、ウェブアプリで IPv6 対応の取引先やサーバーへの接続が可能になり、これまで IPv4 しか対応していなかった環境でも柔軟にファイル転送できます。また IPv6 ネイティブネットワークからウェブアプリへのアクセスも可能です。デュアルスタック対応により IPv4 と IPv6 の両方で通信でき、段階的な移行が実現できます。詳細は こちらのドキュメントをご参照ください。 Amazon S3 Files の発表、S3 バケットをファイルシステムとしてアクセス可能に Amazon S3 Files の一般提供を開始しました。これまで S3 に保存されたデータをファイルベースのアプリケーションで直接扱うことができず、データの重複や複雑な同期処理が必要でした。S3 Files は Amazon EFS を基盤に構築された共有ファイルシステムで、S3 バケットをNFS v4.1+ 互換のファイルシステムとして直接マウントでき、既存のファイルベースのアプリケーションやツールからコード変更なしで S3 データを扱えます。AI エージェントのパイプライン間での状態共有や ML チームのデータ前処理などのユースケースにも適しています。34 のリージョンで利用可能です。詳細は こちらの Blog 記事をご参照ください。 Amazon Bedrock で Claude Mythos Preview (限定研究プレビュー) の提供を開始 Amazon Bedrock で Claude Mythos Preview（限定研究プレビュー）の提供が開始されました。Anthropic 社のサイバーセキュリティイニシアチブ「Project Glasswing」の一環として提供される最先端 AI モデルで、サイバーセキュリティ、ソフトウェアコーディング、複雑な推論タスクにおいて高い能力を持ちます。従来のモデルより少ない手動ガイダンスでセキュリティ上の脆弱性を発見でき、防御的サイバーセキュリティ作業を加速できます。現在は限定的なプレビューとして、事前承認された組織のみがバージニア北部リージョンで利用可能です。詳細は こちらの Blog 記事をご参照ください。 4/8(水) Amazon Bedrock AgentCore Browser が OS レベルのインタラクション機能を追加 Amazon Bedrock AgentCore Browser で OS レベルの操作機能が追加されました。従来の CDP に加え、マウス操作やキーボード操作、デスクトップスクリーンショットが可能になりました。システムダイアログ処理や複雑な UI 操作の自動化が実現し、AI エージェント開発やテスト自動化でより高度なワークフローを構築できます。詳細は こちらのドキュメントをご参照ください。 Amazon EKS マネージドノードグループが EC2 Auto Scaling ウォームプールをサポート Amazon EKS managed node groups で EC2 Auto Scaling warm pools がサポートされました。これまでスケールアウト時にはインスタンスの初期化に時間がかかっていましたが、事前に初期化済みのインスタンスをプールしておくことで、急激なトラフィック増加時のスケールアウトにかかる時間を大幅に短縮できます。インスタンスを Stopped (低コスト) または Running (高コスト・高速) で待機させることが可能で、突発的なワークロードや起動時間の長いアプリケーションに特に効果的です。北京リージョンと寧夏リージョンを除く全リージョンで利用可能です。詳細は こちらのドキュメントをご参照ください。 4/9(木) Amazon EC2 Capacity Manager でタグベースディメンションがサポート開始 Amazon EC2 Capacity Manager でタグベースの分析機能が利用可能になりました。これまでリージョンやインスタンスタイプでしか分類できなかったキャパシティデータを、環境やチーム、コストセンターなどの独自タグで整理・フィルタリングできます。最大 5 つのカスタムタグキーを設定でき、組織全体でのリソース管理が格段に効率化されます。詳細は こちらのドキュメントをご参照ください。 エージェントの一元的な発見とガバナンスのための AWS Agent Registry がプレビューで利用可能に AWS Agent Registry がプレビュー開始しました。Amazon Bedrock AgentCore を通じて、組織内の AI エージェントやツールを一元管理・発見できるサービスです。これまで各チームが個別に開発していたエージェントを検索・再利用できるため、重複開発を避けてコストと時間を削減できます。自然言語での検索も可能で、用途を説明するだけで適切なエージェントを発見できます。承認ワークフローによるガバナンス機能も搭載し、組織の AI 資産を統制管理できます。現在、オレゴン、東京、シドニー、アイルランド、バージニア北部リージョンで利用可能です。詳細は こちらの Blog 記事をご参照ください。 Amazon Bedrock が IAM ユーザーとロールによるコスト配分をサポート Amazon Bedrock で IAM ユーザーやロール単位でのコスト配分がサポートされました。IAM プリンシパルにチームやプロジェクト、コストセンターなどのタグを設定してコスト配分タグとして有効化することで、Bedrock のモデル推論コストを組織構造に沿って追跡・分析できます。CUR 2.0 では呼び出し元の IAM プリンシパル ARN が自動的に記録され、Cost Explorer でもタグによるグルーピングやフィルタリングが可能です。詳細は こちらのドキュメントをご参照ください。 4/10(金) Amazon RDS が Microsoft SQL Server の最新 CU および GDR アップデートをサポート Amazon RDS for SQL Server で Microsoft SQL Server の最新セキュリティアップデートが利用可能になりました。SQL Server 2016 から 2019 では CU+GDR、SQL Server 2022 では CU24 に対応しています。GDR アップデートではセキュリティ脆弱性 CVE-2026-21262 と CVE-2026-26115 が修正されます。RDS コンソールや AWS SDK、CLI からアップグレード可能です。詳細は こちらのドキュメントをご参照ください。 それでは、また来週お会いしましょう！ 著者について 古屋 楓 (Kaede Koya) / @KaedeKoya35328 AWS Japan のソリューションアーキテクトとして、多種多様な業界のお客様をご支援しています。特定の技術やサービスに偏らず、幅広い分野のご相談に対応し、技術相談会や各種イベントにて登壇しています。好きな AWSサービスは Amazon Lightsail と Kiro で、シンプルかつ柔軟にクラウドの力を活用できる点がお気に入りです。休日は愛犬 2 匹と静かに過ごしています。

はじめに Power BIでレポートを作成する際、データの取り込み元としてExcelやCSV、あるいはSQL Serverなどのデータベースを利用するのが一般的です。 しかし、インポートモードで扱うデータが「数十GBクラスの大容量」になったとき、その運用に頭を抱えたことはありませんか？今回は、30〜60GBという膨大なデータを扱うプロジェクトにおいて、運用効率化のためにSharePoint接続を検証・導入した際の知見を共有します。 対象読者 ・Power BIで扱うデータ量が肥大化し、パフォーマンスや運用に課題を感じている方 ・複数人でダッシュボードを共同開発しており、ファイルの

皆様は、「DataKeeper」という製品をご存知でしょうか。 DataKeeperとは、稼働中のサーバのデータを、リアルタイムで待機系に複製（ミラーリング）し、止めないシステム運用を実現するソフトウェアです。 クラスタノード間でボリュームをミラーリングし、あたかも共有ストレージのように扱うことが可能になります。クラスタリングソフトウェアであるLifeKeeperやWindowsのWSFC（Windows Server Failover Clustering）と連携することにより、高可用性を実現しつつ、データの冗長性を確保することが可能となります。   本記事では、DataKeeperの機能や特徴を解説し、どのような状況で活用していくかについて紹介していきます。   DataKeeperの基本機能・主な特長 基本機能 DataKeeperは、稼働系と待機系のローカルディスク上のボリュームをレプリケーションの技術で同期し、 それらのボリュームを論理的な共有ディスクのように扱い、LifeKeeperおよびWSFCとも連携する機能が特徴です。 DataKeeperの構成イメージ   サーバ毎に接続されたローカルディスク上のボリュームをレプリケーションし、 ミラーボリュームを作成することで、共有ディスクとして扱うことが可能となります。 障害発生時には LifeKeeper と連携してLifeKeeperが監視・フェイルオーバーを実行し、 DataKeeperがデータレプリケーションを担い、論理共有ディスク上のデータをそのまま待機系に引き継ぎます。   主な特徴 ■ブロックレベルのリアルタイム・レプリケーション 同期／非同期に対応しており、WAN向け最適化や圧縮も備え、レイテンシー環境でも帯域効率よく複製します。帯域制御とパフォーマンスについては、ファイル単位ではなく「ブロックレベル」となるため、高速での転送が可能となります。 同期に使うネットワーク帯域を調整できるため、業務ネットワークへの影響を最小限に抑えられます。   ■WSFCとネイティブ連携 DataKeeper VolumeをWSFCのリソースとして扱い、クラスタ側の制御に自然統合することができます。 Windows標準のクラスタ機能（WSFC）が、DataKeeperのボリュームを「物理ディスクリソース」として認識し、SQL Serverやファイルサーバの冗長化をする際、使い慣れた WSFC の管理画面で運用できるため、学習コストを増やさずに導入できます。   ■クラウド/仮想/物理を横断 AWS/Azure/GCPやVMware、オンプレ物理で同じ考え方で設計・展開が可能となります。 AWSやAzureでは、オンプレミスのような「共有ストレージ（SAN）」をマウントしてクラスタを組むのが難しい、または高価なマネージドサービスが必要となりますが、 DataKeeperを使えば、ローカルディスク同士を同期させるだけでクラスタを組むことが可能です。   ■コスト最適化 共有ストレージが不要となり、OSからは「共有ディスク」として認識されるため、アプリケーション側の対応が不要、コストを抑えることができます。   では、これらの特徴が実際の現場でどのように役立つのか、シチュエーションごとに DataKeeper の活用イメージを紹介します。   シチュエーション別、DataKeeperの活用事例 1) クラウド移行を検討中の情シス（AWS） 前提 ：既存オンプレで SQL Server FCI や ファイルサーバクラスタ を利用中 AWS に移行しても ダウンタイムを極小化した高可用性（HA） 構成 を維持したい 課題 ： AWS では、共有ディスク構成が直接使えない/FSx for Windows（共有ファイルサービス）が割高/　　マルチAZをまたいだ共有ストレージ提供が制約多い、という背景がある 解決 ：DataKeeper を使うことで、各ノードのローカル EBS（ディスク）上のボリュームをブロック単位で同期し、 共有ディスクなしでも WSFC）を構築可能。またマルチAZまで柔軟に拡張可能となります。AWS に「オンプレ同等の可用性構成」を持ち込めます。 構成イメージ(AWS)： マルチAZの SQL Server FCI/ファイルサーバ にLifeKeeper + DataKeeper を導入した構成各ノードはローカル EBS を利用 DataKeeper が ブロックレベルで EBS を同期（Sync/Async） LifeKeeper/WSFC によりAZ 障害時は自動フェイルオーバー ➡ 共有ディスクが不要なため、AWS の制約（共有ストレージ/コスト）を解消できます   2) 共有ストレージのコストや仕様で悩むエンジニア 前提 ：オンプレ/仮想環境で NAS/SAN などの共有ストレージ を利用している 課題 ：共有ストレージは高コスト、専用スキルや運用の複雑性、SPOFが気になる。 解決 ：DataKeeperは既存のローカルストレージを活用し、SPOFを排除。 SSD/フラッシュも活かせるため性能面でも優位。 アレイ依存のレプリケーションに比べ、コスト効率の高いHA/DRが構築可能。  構成イメージ ：Azure：ASCS/ERSやDBのWSFCを共有ディスク不要で内部LB・クォーラム設計のガイダンスに沿い、DataKeeperで共有相当を実現。 ➡コストを下げつつ、ストレージの複雑性・制約をすべて解消できます     他方式とのDataKeeperの比較 具体的な活用イメージをご紹介しましたが、他方式と比べてどこが優れているのか？も気になるポイントです。 代表的な方式との比較を整理してみます。  比較対象 DataKeeper導入のメリット DataKeeper導入のデメリット vs クラウド共有ストレージ（FSx/Azure Files等） ・コスト最適化（従量課金を排除） ・マルチAZ対応 ・ローカルI/Oで性能が安定 ・局所レイテンシ低減の余地 ・レプリケーション帯域の確保が必要 ・ローカルディスク障害時の運用が発生 ・一般的に2ノード中心 vs S2D （Storage Spaces Direct） ・WSFC＋既存ディスクで即構成 ・クラウド横断で利用可能 ・専用NIC/ハード不要 ・学習コストが低い ・スケールアウトストレージ機能なし ・大規模分散用途には不向き ・ソフトウェアライセンス費用が発生 vs SQL Server Always On（AG） ・DB以外も保護可能 ・SEでFCIが作れライセンス最適 ・アプリ改修不要 ・フェイルオーバーが単純 ・読み取り専用レプリカ不可 ・全ボリュームレプリケーション ・AGにあるDBレベル機能を持たない   比較を踏まえて理解が深まったところで、 実際の相談でよくいただく質問もまとめておきます。 よくある質問（FAQ） Q1. レプリケーションは同期／非同期を切り替えられますか？ A. はい。ブロックレベルで同期／非同期を選択でき、切り替えも可能です。 Q2. SQL Server Standard EditionでもFCIを構築できますか？ A. 可能です。DataKeeper＋WSFCで共有ディスク相当を提供できるため、Standard EditionでもFCIを構成できます。 Q3. ネットワーク障害でノード間の通信が切断された場合、再同期はどうなりますか？ A. フル同期のやり直しは不要です。通信が途絶えた際、DataKeeperはレプリケーションを一時停止し、変更されたブロック箇所（差分）だけを内部のビットマップメモリに記録し続けます。ネットワーク復旧後は、その差分データのみが自動的に再同期（部分再同期）されるため、システムへの負荷を最小限に抑えて正常な状態に復帰できます。 Q4. DataKeeperでレプリケーションできないデータはありますか？ A. はい。Cドライブなどの「OSシステム領域（システムボリューム）」はレプリケーションの対象外となります。また、DataKeeperはドライブ（ボリューム）単位でのブロック同期を行うため、「特定のファイルやフォルダだけ」を指定して同期することも仕様上できません。   まとめ DataKeeperでは、AWSやAzure等のクラウド・オンプレを問わず、同じアーキテクチャ思想で設計・展開・運用できるのが強みであることをお伝えいたしました。 LifeKeeper連携まで含めた“アプリもデータも守る”設計で、止めないシステム運用を支援します。  詳しい内容をお知りになりたいかたは、以下バナーからお問合せください。