本日の主なトピック #
- Amazon Athena: マネージドコネクタの導入により、Lambda のデプロイ・管理不要で外部データへのフェデレーションクエリが可能に。
- Amazon ECS: NVIDIA GPU のハードウェア故障を自動検知し、インスタンスをプロアクティブに置換する自動復旧機能をサポート。
- Amazon Redshift: Apache Iceberg テーブルに対し、Redshift から直接行レベルの UPDATE/DELETE/MERGE 操作が可能に。
- Amazon Quick (旧 Q Business): ナレッジベースの権限検証ツール「Permission Checker」と複数所有者（Co-owners）設定を追加。
- Amazon SageMaker Unified Studio: 同一プロジェクト内での複数コードスペース作成や、ノートブックカーネルの VPC 接続に対応。
¥3,520 Amazonで見る![AWS運用入門 改訂第2版 押さえておきたいAWSの基本と運用ノウハウ [AWS深掘りガイド] 単行本（ソフトカバー） – 2025/7/11](https://m.media-amazon.com/images/I/61ftnZ09WvL._SY522_.jpg)
AWS運用入門 改訂第2版 押さえておきたいAWSの基本と運用ノウハウ [AWS深掘りガイド] 単行本（ソフトカバー） – 2025/7/11
Amazon Athenaがマネージドコネクタによりフェデレーションクエリを簡素化 #
投稿日: 2026年04月23日
何ができるようになったのか #
Amazon Athenaにおいて、12種類のデータソース（Amazon DynamoDB, PostgreSQL, MySQL, Snowflakeなど）に対する「マネージドコネクタ」が提供されました。これにより、ユーザーが自分のAWSアカウント内にコネクタ用のLambdaリソースをデプロイ・管理することなく、外部データソースへのフェデレーションクエリを実行できるようになります。
何が嬉しいのか #
従来はフェデレーションクエリを実現するためにLambda関数のデプロイや監視が必要でしたが、マネージドコネクタを利用することでインフラ管理の負担が完全になくなります。また、AWS Lake Formationと統合されているため、外部データに対しても行・列レベルの細かいアクセス制御が容易に適用できます。
これまでとどう変わるのか #
- これまで: Athena Federated Queryを利用するには、Serverless Application RepositoryなどからLambdaベースのコネクタをデプロイし、その実行環境（メモリ、タイムアウト、VPC設定など）をユーザー自身で管理する必要がありました。
- これから: Athenaがバックエンドでコネクタリソースを自動的にセットアップ・管理するため、ユーザーはデータソースへの接続設定を作成するだけで、すぐにクエリを開始できます。
具体的なユースケース #
- S3上のデータとRDS（PostgreSQL/MySQL）上のデータを、インフラ管理を意識せずにジョインして分析する。
- SnowflakeやDynamoDBにあるデータに対して、Lake Formationを用いた一元的なセキュリティポリシーを適用しつつAthenaから直接クエリする。
Amazon EC2 X8g インスタンスが欧州（アイルランド）リージョンで利用可能に #
投稿日: 2026年04月23日
何ができるようになったのか #
AWS Graviton4 プロセッサを搭載した Amazon EC2 X8g インスタンスが、欧州（アイルランド）リージョンで利用可能になりました。X8g インスタンスは、従来の Graviton2 ベースの X2gd インスタンスと比較して最大 60% のパフォーマンス向上を実現し、最大 3 TiB のメモリを提供します。
何が嬉しいのか #
EC2 X シリーズの中で最高の価格パフォーマンスを誇り、大規模なインメモリデータベースやリアルタイムのビッグデータ分析など、メモリを大量に消費するワークロードにおいてコスト効率を大幅に向上させることができます。また、最大 3 TiB という大容量メモリにより、これまで以上に大規模なデータセットを単一インスタンスで処理可能です。
これまでとどう変わるのか #
- これまで: 欧州リージョンのユーザーが Graviton ベースの X シリーズを利用する場合、Graviton2 世代の X2gd インスタンスが主流であり、メモリ容量や vCPU 数に制限がありました。
- これから: 最新の Graviton4 を搭載した X8g を利用することで、X2gd と比較して最大 3 倍の vCPU とメモリ（最大 48xlarge / 3 TiB）を活用でき、より高いスループットと低レイテンシを実現できます。
具体的なユースケース #
- Redis や Memcached などの大容量インメモリデータベースの運用。
- 半導体設計（EDA）などのメモリインテンシブな計算ワークロード。
- PostgreSQL や MySQL などの大規模リレーショナルデータベースの Graviton 移行。
Amazon ECS マネージドインスタンスで GPU の状態監視と自動復旧が可能に #
投稿日: 2026年04月22日
何ができるようになったのか #
Amazon ECS マネージドインスタンスにおいて、NVIDIA GPU のハードウェア故障を自動的に検出し、異常があるインスタンスを自動で置き換える「状態監視と自動復旧（Auto Repair）」機能が導入されました。NVIDIA Data Center GPU Manager (DCGM) を使用して継続的に GPU の健全性を監視します。
何が嬉しいのか #
生成 AI の推論など、GPU を多用するコンテナワークロードにおいて、ハードウェアレベルの故障によるサービス中断を最小限に抑えることができます。異常が検出されると、ECS がプロアクティブにインスタンスを置き換えるため、管理者が手動で復旧作業を行う必要がなくなります。
これまでとどう変わるのか #
- これまで: GPU のハードウェア故障を検知するには、ユーザー自身が DCGM や CloudWatch Agent を使用して監視の仕組みを構築し、異常時にインスタンスを終了・再起動させるためのカスタムロジック（Lambda や ASG のヘルスチェック）を実装する必要がありました。
- これから: ECS が標準で GPU の健全性を監視し、致命的なエラーを検出した場合には自動的にインスタンスの置換を行うようになります。
具体的なユースケース #
- 大規模な GPU クラスターを使用した生成 AI モデルの推論実行における可用性向上。
- GPU ハードウェア故障に起因するバッチ処理の中断リスクの低減。
Amazon IVS 低遅延ストリーミングがサーバーサイド広告挿入（SSAI）をサポート #
投稿日: 2026年04月22日
何ができるようになったのか #
Amazon Interactive Video Service (IVS) の低遅延ストリーミングにおいて、サーバーサイド広告挿入（SSAI）が可能になりました。AWS Elemental MediaTailor と統合することで、動画ストリームに直接広告を埋め込み、視聴者にシームレスな広告体験を提供できます。
何が嬉しいのか #
サーバー側で広告を動画ストリームに直接結合（マニフェスト編集）するため、クライアント側の「広告ブロッカー」の影響を受けにくくなります。また、視聴者のデバイスごとにパーソナライズされた広告を提供しつつ、再生開始時のバッファリングやカクつきを抑えたスムーズな視聴体験を実現できます。
これまでとどう変わるのか #
- これまで: IVS で広告を挿入する場合、主にクライアント側（アプリやブラウザ）で広告を読み込んで再生する方式（CSAI）が一般的でしたが、開発の複雑さや広告ブロッカーによる回避が課題でした。
- これから: MediaTailor とのネイティブな連携により、API を介してサーバー側で広告を挿入でき、録画されたアーカイブ（S3）にも広告マーカーを含めることが可能になりました。
具体的なユースケース #
- ライブ配信中にクリエイターが任意のタイミングで広告ブレイクを挿入し、収益化を図る。
- 視聴者の属性に合わせてパーソナライズされた動画広告を配信する。
- ライブ配信の録画済みコンテンツ（VOD）に対しても後から広告を挿入し、二次利用を収益化する。
Amazon Quick が ACL 有効なナレッジベースの権限検証をサポート #
投稿日: 2026年04月23日
何ができるようになったのか #
Amazon Quick（旧 Amazon Q Business を含むスイート）において、ACL（アクセス制御リスト）が有効なナレッジベースの権限検証機能「Permission Checker」が導入されました。管理者は特定のドキュメントに対し、特定のユーザーがアクセス権を持っているかどうかをコンソールから即座に確認できます。
何が嬉しいのか #
ナレッジベース上のドキュメントへのアクセス権限に関するトラブルシューティングが大幅に簡素化されます。データソース側での複雑な権限継承を個別に追跡することなく、Amazon Quick 側で最終的なアクセス可否をメールアドレス入力のみで判定できるため、機密情報の保護が適切に行われているかを容易に確認可能です。
これまでとどう変わるのか #
- これまで: ユーザーから「ドキュメントが見つからない」といった報告があった際、管理者はデータソース（SharePoint や S3 など）側の権限設定と、Amazon Quick への ACL 同期状況を個別に調査し、原因を特定する必要がありました。
- これから: コンソールの「Sync reports」タブから特定のドキュメントを選択し、ユーザーのメールアドレスを入力するだけで、「アクセス権あり」「なし」「ACL 未検出」の判定結果を即座に得られます。
具体的なユースケース #
- 特定の機密プロジェクトのドキュメントが、プロジェクト外のメンバーから参照できないことを確認する。
- 権限設定を変更した直後に、期待通りにアクセス制限が適用されているかテストする。
Amazon Quick が SharePoint および Google Drive ナレッジベースの 複数所有者をサポート #
投稿日: 2026年04月23日
何ができるようになったのか #
Amazon Quick において、管理者管理（Admin-managed）の Microsoft SharePoint Online および Google Drive 統合を利用したナレッジベースとデータソース接続に、共同所有者（Co-owners）を追加できるようになりました。
何が嬉しいのか #
チーム間でのナレッジベース管理の共同作業が容易になります。複数のユーザーに「Owner」権限を付与することで、資格情報の再入力をすることなく、ナレッジベースの編集、同期、共有、削除などの管理操作を分担して行えるようになります。
これまでとどう変わるのか #
- これまで: 管理者管理の SharePoint/Google Drive 統合では、ナレッジベースの管理権限を持つユーザーが限定されており、管理作業を他のメンバーに委任することが困難でした。
- これから: ナレッジベースやデータソース接続に対して「Owner（フル管理権限）」または「Viewer（クエリのみ）」のロールを他のユーザーに付与でき、柔軟な運用体制を構築できるようになります。
具体的なユースケース #
- 組織内の複数の管理者が、同じ SharePoint データソースに基づくナレッジベースの同期設定を共同でメンテナンスする。
- 既存のデータソース接続を共有し、他のチームメンバーがその接続を利用して新しいナレッジベースを作成できるようにする。
Amazon RDS Custom for SQL Server が最新の GDR アップデートをサポート #
投稿日: 2026年04月22日
何ができるようになったのか #
Amazon RDS Custom for SQL Server において、Microsoft SQL Server の最新の General Distribution Release (GDR) アップデートがサポートされました。これには、SQL Server 2019 CU32+GDR および SQL Server 2022 CU23+GDR が含まります。
何が嬉しいのか #
CVE-2026-21262 および CVE-2026-26115 として報告されている重大な脆弱性が修正されます。RDS Custom を利用しているユーザーは、OS やデータベースのカスタマイズ性を維持しつつ、最新のセキュリティパッチを適用してデータベース環境を安全に保つことができます。
これまでとどう変わるのか #
- これまで: RDS Custom for SQL Server で最新のセキュリティ修正を適用するには、AWS による公式サポートを待つ必要がありました。
- これから: 最新の GDR アップデートがサポートされたことで、管理コンソール、SDK、または CLI を通じて、推奨されるセキュリティパッチを含む新しいバージョンへのアップグレードが可能になりました。
具体的なユースケース #
- セキュリティコンプライアンス要件を満たすために、SQL Server インスタンスに最新のセキュリティパッチを適用する。
- 既知の脆弱性からデータベースシステムを保護し、サイバー攻撃のリスクを低減する。
Amazon SageMaker HyperPod がオンデマンドの深層健全性チェックをサポート #
投稿日: 2026年04月17日
何ができるようになったのか #
Amazon SageMaker HyperPod において、Amazon EKS および Slurm オーケストレーションされたクラスターに対して、任意のタイミングで実行できる「オンデマンド深層健全性チェック（Deep Health Checks）」がサポートされました。これにより、GPU アクセラレータのハードウェア、ネットワーク接続性、マルチノード通信性能の包括的なストレス、およびテストが可能になります。
何が嬉しいのか #
大規模な AI トレーニングなどの計算負荷が高いジョブを開始する前に、クラスター内の全ノードが正常であることを事前に確認できます。1つでも不健全なノードが含まれていると、ジョブの失敗により数時間の計算時間が無駄になることがありますが、この機能によりそのようなリスクを大幅に軽減できます。
これまでとどう変わるのか #
- これまで: HyperPod には自動ノード復旧機能がありましたが、包括的な深層チェックは特定の条件下（プロビジョニング時など）に限られていました。稼働中のインスタンスに対して、ジョブ投入直前に手動で包括的なハードウェアテストを実行する標準的な手段はありませんでした。
- これから: ジョブのスケジュール前に、特定のインスタンスグループや個別のインスタンスを対象に深層チェックをトリガーできます。チェック中のインスタンスは自動的に隔離（Isolate）され、パスした場合のみサービスに復帰します。失敗した場合は HyperPod の自動復旧機能により再起動や置換が行われます。
具体的なユースケース #
- 数日間に及ぶ大規模言語モデル（LLM）のトレーニングジョブを開始する直前に、全 GPU ノードの健全性を確認する。
- ネットワークパフォーマンスが低下している疑いがある場合に、特定のノード間の通信性能を詳細にテストする。
Amazon SageMaker が IdC ドメインでノートブックとデータエージェントをサポート #
投稿日: 2026年04月23日
何ができるようになったのか #
Amazon SageMaker Unified Studio において、AWS IAM Identity Center (IdC) ドメインを使用している環境でも、サーバーレスノートブックと組み込みの AI データエージェントが利用可能になりました。
何が嬉しいのか #
認証とアクセス管理に IdC を利用している企業や組織のユーザーも、高機能なサーバーレスノートブック環境をシームレスに利用できるようになります。このノートブックでは、SQL、Python、自然言語プロンプトを単一のワークスペースで組み合わせて使用でき、AI データエージェントがコード生成や SQL 作成を支援するため、開発スピードが向上します。
これまでとどう変わるのか #
- これまで: サーバーレスノートブックと AI データエージェントのエクスペリエンスは、IAM ベースのドメインでのみ提供されており、IdC 認証を使用しているユーザーはこの特定の機能にアクセスできませんでした。
- これから: IdC ドメインのユーザーも、Amazon Athena for Apache Spark をバックエンドとした、ペタバイト規模のデータ処理に対応する強力なノートブック環境を活用できるようになります。
具体的なユースケース #
- 自然言語でデータ構造を説明し、AI データエージェントに SQL クエリや分析用 Python コードを自動生成させる。
- 単一のノートブック内で、Athena を使ったデータの探索から、Python による機械学習モデルの構築までを一気通貫で行う。
AWS Partner Central に「属性別収益ダッシュボード」が登場 #
投稿日: 2026年04月23日
何ができるようになったのか #
AWS Partner Central（AWS コンソール内）において、パートナー企業が自社ソリューションによる収益への影響をセルフサービスで確認できる「属性別収益ダッシュボード（Attributed Revenue Dashboard）」が提供開始されました。
何が嬉しいのか #
リソースタグ、ユーザーエージェント文字列、AWS Marketplace メータリングの 3 つの測定手法による収益データを、単一のビューで統合的に把握できるようになります。これにより、パートナーは自社のソリューションがどの AWS サービスの消費に貢献しているかを月単位で詳細に分析し、ビジネス戦略に活かすことが可能です。
これまでとどう変わるのか #
- これまで: パートナーは、自社のソリューションが AWS サービス消費に与えている影響を確認するために、複数のツールやレポートを個別に参照したり、AWS 担当者からのレポートを待つ必要がありました。
- これから: AWS コンソール内のダッシュボードから、製品別、サービス別、請求期間別の収益トレンドや消費パターンを、直接かつ即座に確認・分析できるようになります。
具体的なユースケース #
- 自社ソリューションの導入により、どの AWS サービスの利用が増加しているかを可視化し、次のマーケティング施策を検討する。
- 複数の AWS Marketplace 出品アカウントを接続し、グループ全体の収益貢献度を統合して把握する。
AWS Backup が Amazon Aurora の PITR サポートを 6 リージョンに拡大 #
投稿日: 2026年04月23日
何ができるようになったのか #
AWS Backup による Amazon Aurora のポイントインタイムリカバリ（PITR）サポートが、新たに 6 つのリージョン（マレーシア、タイ、台北、ニュージーランド、カナダ西部、メキシコ）で利用可能になりました。
何が嬉しいのか #
新しくサポートされたリージョンにおいても、AWS Backup のポリシーベースの管理機能を使用して、Aurora クラスターの継続的なバックアップと任意の時点への復元（秒単位）が可能になります。これにより、不慮のデータ削除や破損が発生した場合でも、データ損失を最小限に抑えた復旧が容易になります。
これまでとどう変わるのか #
- これまで: これらのリージョンで Aurora の PITR を利用するには、Aurora 標準のバックアップ機能を使用する必要があり、AWS Backup による他サービスと統合されたポリシーベースの一元管理は利用できませんでした。
- これから: 既存のバックアッププランに Aurora クラスターを追加するだけで、他のリソースと同様のコンプライアンス要件や保持ポリシーに基づいた PITR 保護を適用できます。
具体的なユースケース #
- グローバルに展開するアプリケーションにおいて、新設されたリージョンのデータベースに対しても一貫したバックアップポリシーを適用する。
- 操作ミスによるデータ消失時に、AWS Backup コンソールから数クリックで障害発生直前の状態にデータベースを復元する。
AWS Parallel Computing Service (AWS PCS) が Slurm 25.11 をサポート #
投稿日: 2026年04月23日
何ができるようになったのか #
AWS Parallel Computing Service (AWS PCS) において、ジョブスケジューラー Slurm の最新バージョン 25.11 がサポートされました。これに伴い、Prometheus 互換の OpenMetrics エンドポイントの提供や、スケジューラー監査ログを含む新しいログタイプの追加が行われています。
何が嬉しいのか #
Slurm 25.11 の新機能である「優先再キュー（expedited re-queue）」により、ノードの不具合で影響を受けたジョブを最高優先度で自動的に再スケジュールでき、ワークロードの復旧が早まります。また、OpenMetrics 対応により既存の監視ツールでのリアルタイム可視化が容易になり、ログの細分化によりデバッグ効率の向上とストレージコストの最適化が可能になります。
これまでとどう変わるのか #
- これまで: スケジューラーの監査ログは運用ログに含まれており、特定の情報だけを抽出したり、保存コストを個別に制御したりすることが困難でした。また、ジョブの再実行には手動介入やカスタムスクリプトが必要な場合がありました。
- これから: 監査ログが独立したログタイプとして提供され、CloudWatch Logs や S3 への出力管理が柔軟になります。また、管理された Slurm 環境で最新のスケジューリング最適化機能をすぐに活用できます。
具体的なユースケース #
- HPC クラスターの稼働状況を Prometheus や Grafana でリアルタイムにモニタリングする。
- ノード障害が発生した際に、重要な解析ジョブを優先的に自動再実行させ、研究の遅延を最小限に抑える。
- スケジューラーの動作ログを詳細に分析し、リソース割り当ての最適化や会計（Accounting）の不整合を調査する。
AWS Transform が移行ワークフロー内でのランディングゾーン構築を自動化 #
投稿日: 2026年04月20日
何ができるようになったのか #
AWS Transform において、移行ワークフローの中から直接ランディングゾーン（安全なマルチアカウント環境）を構築できるようになりました。これまで AWS Control Tower や AWS Organizations などで個別に行っていた設定を AWS Transform がオーケストレーションし、自動化します。
何が嬉しいのか #
ターゲット環境の準備が移行プロセスの一環として統合されるため、移行準備にかかる時間を大幅に短縮できます。AWS のベストプラクティスに基づいたアカウント構造やサービスコントロールポリシー（SCP）が自動的に適用され、CloudFormation、CDK、Landing Zone Accelerator (LZA) 形式でのテンプレート出力も可能なため、カスタマイズや再利用も容易です。
これまでとどう変わるのか #
- これまで: サーバーやネットワークの移行を計画する一方で、それらを受け入れるためのセキュアなマルチアカウント環境（ランディングゾーン）の構築は、別の作業ストリームとして手動または別個のツールで進める必要がありました。
- これから: 移行対象のデータやビジネス要件に基づき、AWS Transform が最適なアカウント構造を推奨し、一連のワークフローの中でランディングゾーンをセットアップできます。
具体的なユースケース #
- 大規模なオンプレミス環境の AWS 移行において、移行開始と同時にセキュアなマルチアカウント基盤を自動構築する。
- 既存の AWS Organizations 組織を拡張し、移行専用の新しい組織単位（OU）やアカウントをベストプラクティスに従って迅速に払い出す。
AWS Elastic Beanstalk の AI による環境分析が Windows をサポート #
投稿日: 2026年04月23日
何ができるようになったのか #
AWS Elastic Beanstalk において、Amazon Bedrock を活用した AI による環境分析機能が Windows Server プラットフォームでも利用可能になりました。環境のイベント、インスタンスの状態、ログを AI が分析し、トラブルシューティングのための推奨事項を提示します。
何が嬉しいのか #
.NET アプリケーションなどを Windows 環境で実行している開発者や運用チームは、膨大なログやイベントを手動で確認することなく、問題の根本原因を迅速に特定し、具体的な解決策を得ることができます。これにより、Windows ワークロードのダウンタイム短縮と運用負荷の軽減が期待できます。
これまでとどう変わるのか #
- これまで: AI による環境分析機能は Amazon Linux 2 および AL2023 プラットフォームに限定されており、Windows ベースの環境で問題が発生した場合は、従来通り手動でのログ解析が必要でした。
- これから: Windows 環境でも「AI Analysis」ボタンをクリックするか API を呼び出すだけで、現在の環境状態に合わせたステップバイステップのトラブルシューティング案を受け取れます。
具体的なユースケース #
- Elastic Beanstalk 上で稼働する Windows インスタンスのヘルス状態が「Warning」や「Degraded」になった際、AI に原因分析と復旧手順を依頼する。
- .NET アプリケーションのデプロイ失敗時、関連するエラーログから AI に解決策を提案させる。
Amazon Redshift が Apache Iceberg テーブルの UPDATE、DELETE、MERGE をサポート #
投稿日: 2026年04月23日
何ができるようになったのか #
Amazon Redshift において、Apache Iceberg テーブルに対する行レベルの UPDATE、DELETE、および MERGE（UPSERT）操作が可能になりました。外部の処理エンジンを使用することなく、Redshift から直接データレイク上の Iceberg テーブルを更新できます。
何が嬉しいのか #
Iceberg を利用したデータレイク基盤において、データパイプラインの複雑さが大幅に解消されます。CDC（変更データキャプチャ）の反映や SCD（緩やかに変化するディメンション）の管理などを Redshift 上の標準的な SQL で実行でき、更新されたデータは Athena や EMR などの他の Iceberg 対応エンジンからも即座に参照可能です。
これまでとどう変わるのか #
- これまで: Redshift から Iceberg テーブルを更新する場合、個別の行を直接操作することは困難であり、データを一度別のエンジン（EMR や Spark など）に移動して処理するか、複雑なワークフローを組む必要がありました。
- これから: 標準的な SQL DML コマンドを使用して、パーティション化されたテーブル、されていないテーブル、さらには S3 Tables に対しても直接、行レベルの更新や削除を実行できます。
具体的なユースケース #
- データレイク上の Iceberg テーブルに対し、Redshift から直接 MERGE 文を実行して最新のトランザクションデータを反映する（UPSERT）。
- コンプライアンス対応（GDPR/CCPA 等）のために、特定のユーザーデータをデータレイクから行単位で削除する。
Amazon S3 が 5 つの新しいチェックサムアルゴリズムをサポート #
投稿日: 2026年04月23日
何ができるようになったのか #
Amazon S3 において、MD5、XXHash3、XXHash64、XXHash128、SHA-512 の 5 つの新しいチェックサムアルゴリズムが追加され、合計 10 種類をサポートするようになりました。S3 はアップロードされたデータの整合性をこれらのアルゴリズムで検証・保存します。
何が嬉しいのか #
既存のオンプレミス環境や他のシステムで広く使われているアルゴリズム（MD5 や SHA-512）、または高速な XXHash シリーズを S3 で直接利用できるようになります。追加のツールを使用することなく、アップロードからダウンロード、レプリケーションに至るまでエンドツーエンドでのデータ整合性確認が可能です。
これまでとどう変わるのか #
- これまで: S3 がネイティブにサポートするアルゴリズム（SHA-1, SHA-256, CRC-32 等）以外で整合性を確認する場合、メタデータとして別途保存したり、クライアント側で計算・管理する必要がありました。
- これから: アップロード時にアルゴリズムを指定するだけで、S3 が検証と保存を自動で行います。チェックサムが指定されない場合は、デフォルトで CRC64NVME が適用されるようになり、データ保護が強化されています。
具体的なユースケース #
- 既存システムで MD5 を使用してファイル管理を行っている場合、S3 移行後も同じアルゴリズムで整合性を自動検証する。
- 非常に大きなファイルの整合性を高速に確認するために XXHash シリーズを利用する。
- S3 Batch Operations を使用して、既存の大量オブジェクトに対して一括でチェックサムを計算・付与する。
Amazon SageMaker Unified Studio がプロジェクト内での複数コードスペース作成をサポート #
投稿日: 2026年04月22日
何ができるようになったのか #
Amazon SageMaker Unified Studio（IAM ドメイン）において、単一のプロジェクト内で複数の「コードスペース（個別に構成された開発環境）」を作成・管理できるようになりました。
何が嬉しいのか #
異なるコンピューティングリソースやストレージ設定が必要な複数のワークストリームや実験を、同一プロジェクト内で並行して進めることができます。各コードスペースは独自の永続的な Amazon EBS ボリュームを保持するため、ファイルやセッション状態が互いに干渉することなく独立して保存されます。これにより、大規模なワークロードを扱う開発者の柔軟性が大幅に向上します。
これまでとどう変わるのか #
- これまで: プロジェクトごとに JupyterLab スペースと Code Editor スペースがそれぞれ 1 つずつに制限されており、複数の実験を並行して行うにはリソースを切り替えるか、プロジェクトを分ける必要がありました。
- これから: 同一プロジェクト内で、例えば「長時間実行されるデータ変換用」と「モデルトレーニング用」といった具合に、用途に合わせて個別に構成された複数のスペースを同時に立ち上げて作業できます。
具体的なユースケース #
- データサイエンティストが、重いデータ処理ジョブを 1 つのスペースで走らせながら、別のスペースで新しいモデルのコード作成を並行して行う。
- 実験ごとに異なるライブラリやランタイム環境（カーネル）を個別のコードスペースで管理し、環境の衝突を避ける。
Amazon SageMaker Unified Studio がノートブックカーネルの VPC サポートを開始 #
投稿日: 2026年04月23日
何ができるようになったのか #
Amazon SageMaker Unified Studio において、ノートブックカーネルを Amazon VPC 内で実行できるようになりました。ノートブックの対話型コンピューティング環境がドメインレベルで設定された VPC 設定（サブネット、セキュリティグループ）を継承します。
何が嬉しいのか #
ノートブックからインターネットを経由せずに、社内ネットワークや VPC 内のプライベートリソース（プライベートデータベース、内部 API など）に直接アクセスしてデータを操作できるようになります。ネットワーク的な分離が確保されるため、厳格なセキュリティおよびコンプライアンス要件を持つエンタープライズ企業でも安心して対話型のデータ分析や機械学習ワークロードを実行可能です。
これまでとどう変わるのか #
- これまで: SageMaker Unified Studio のノートブック環境において、対話型コンピューティング（Python コードの実行等）を行うカーネル部分の VPC 隔離を詳細に制御する機能が限定的でした。
- これから: 管理者がドメインレベルで一元的に定義した VPC ポリシーがカーネルに適用され、プライベートなデータソースを安全にクエリできる一貫した開発環境が提供されます。
具体的なユースケース #
- VPC 内に配置されたプライベートな Amazon RDS や Amazon Redshift のデータに対し、ノートブックから直接 SQL や Python でアクセスして分析する。
- 社内の認証済みプロキシや内部 Web サービスのみを許可するセキュリティグループ設定をノートブック環境に適用する。
第 2 世代 AWS Outposts ラックがソウル、シドニー、パリの各リージョンでサポート開始 #
投稿日: 2026年04月23日
何ができるようになったのか #
第 2 世代の AWS Outposts ラックが、アジアパシフィック（ソウル、シドニー）および欧州（パリ）リージョンで新たにサポートされました。これにより、韓国、オーストラリア、フランス国内のオンプレミス環境から、これらのリージョンに接続された Outposts を注文し、運用できるようになります。
何が嬉しいのか #
オンプレミスシステムへの低レイテンシアクセスが必要なワークロードや、データの物理的な所在地（データレジデンシー）を国内に限定する必要がある規制要件に対し、最新世代の Outposts インフラを活用して対応できるようになります。AWS のインフラ、API、ツールを自社のデータセンターで一貫して利用できるハイブリッドクラウド体験が、さらに多くの地域で提供されます。
これまでとどう変わるのか #
- これまで: これらのリージョンのユーザーが Outposts を利用する場合、第 1 世代のハードウェアに制限されるか、他の遠隔リージョンへの接続を考慮する必要がありました。
- これから: 最新の第 2 世代ラックを地元リージョンに接続して利用できるため、パフォーマンスの最適化と運用の簡素化が図れます。
具体的なユースケース #
- 製造現場の工場内システムにおいて、ミリ秒単位の応答が求められるリアルタイム制御をローカルで実行しつつ、管理は AWS クラウドから行う。
- 法的制約により国内での保存・処理が義務付けられている個人情報を、オンプレミスに設置した Outposts 上の AWS サービスで管理する。