AWS What's New Digest

Appearance

2026年10月15日 ​

[S3] Amazon S3 Metadata now available in six additional AWS Regions ​

概要 ​

Amazon S3 Metadata（S3 Metadata） が、アジア太平洋およびメキシコの6つの追加リージョンで利用可能になりました。これにより、S3オブジェクトに対する自動生成メタデータと大容量アノテーションを近リアルタイムで利用・検索できるリージョンが拡大します。

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

S3 Metadata は、S3内のデータを自動で記録・更新するクエリ可能なメタデータ機能です。今回、以下の6リージョンで利用可能になりました：Asia Pacific (Hyderabad)、Asia Pacific (Malaysia)、Asia Pacific (New Zealand)、Asia Pacific (Taipei)、Asia Pacific (Thailand)、Mexico (Central)。

主な機能:

  • 自動メタデータ生成: 新規オブジェクトだけでなく既存オブジェクトについてもメタデータが自動で補遺・更新され、オブジェクトのプロパティやコンテンツに関する情報を近リアルタイムで反映します。
  • アノテーション: JSON／XML／YAML形式でオブジェクトにリッチなビジネスコンテキストを付与可能。各オブジェクトあたり最大1 GBまでのアノテーションをサポートします。
  • クエリ可能性: アノテーションは S3 Metadata のアノテーションテーブルとしてサーフェスでき、大規模にクエリして検索・集計できます（対応するリージョンで利用可能）。

運用面では、データカタログ作成、ビジネス属性付与、アドホック検索、分析パイプラインやリアルタイム推論向けのデータ選別が容易になります。今回の追加により、S3 Metadata は合計38リージョンで一般提供（GA）されています。価格や詳細は S3 の料金ページ、製品ページ、ドキュメントを参照してください。

影響範囲・利用シーン ​

  • 対象ユーザー: データエンジニア、データサイエンティスト、SRE／運用チーム、アプリケーション開発者
  • 利用シーン: 大量のS3オブジェクトに対するメタデータ検索・フィルタリング（分析対象の選別、データカタログ、ビジネス属性付与、リアルタイム推論向けデータ抽出）
  • 運用効果: データ発見と分類が自動化されて検索時間を短縮、分析パイプラインやML推論の前処理コストを低減し、ガバナンスやデータ管理の精度向上に寄与

技術的な注意点 ​

  • IAM権限: S3オブジェクトの読み書き権限に加え、S3 Metadata／アノテーション関連のAPI呼び出し権限（管理コンソール・API操作）を付与する必要があります。詳細はドキュメントで必ず確認してください。
  • リージョン制限: 今回の追加で6リージョンが対象になり合計38リージョンでGAですが、全リージョンで利用可能なわけではありません。利用前に対象リージョンでS3 Metadataとアノテーションテーブルが有効か確認してください。
  • コスト: S3 Metadataの利用・アノテーション保持・クエリ（アノテーションテーブルへのアクセス）は追加料金が発生する可能性があります。使用量によって課金されるため、S3の料金ページで詳細を確認してください。
  • アノテーション制限: アノテーションはJSON／XML／YAML形式をサポートし、各オブジェクトで最大1 GBまで格納可能（設計上は大きなペイロードをサポートするが、パフォーマンスやコスト影響に注意）。
  • 既存オブジェクトへの適用: S3 Metadata は既存オブジェクトにも自動でメタデータを付与しますが、適用完了のタイミングは近リアルタイムとされており、一時的な遅延が発生する場合があります。
  • セキュリティ/暗号化: アノテーションやメタデータが機密情報を含む場合は、S3の暗号化・アクセス制御ポリシーで保護することを推奨します。

参考情報 ​

[Security Hub] AWS Security Hub CSPM now supports the Cyber Risk Institute profile version 2.2 ​

概要 ​

AWS Security Hub の CSPM が Cyber Risk Institute (CRI) Profile v2.2 に対応しました。CRI Profile v2.2 に整合する自動化されたセキュリティチェック（404個の自動コントロール）を提供します。全リージョン（AWS GovCloud (US) と中国リージョンを含む）で利用可能です。

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

Security Hub の CSPM（Cloud Security Posture Management）は、金融機関向けに作られた Cyber Risk Institute (CRI) のプロファイル v2.2 に合わせた自動評価コントロールを追加しました。今回提供されるのは、CRI v2.2 要件のうち自動化で検出可能な項目に相当する404個のコントロールで、手動確認が必須の要件は自動コントロールには含まれません。新しい標準は、Security Hub が利用可能な全リージョン（AWS GovCloud (US) と中国リージョンを含む）で有効化可能です。複数アカウント／複数リージョンに対しては、Security Hub の central configuration（管理アカウントを通じた一括有効化）を使用すると、単一操作で特定の組織アカウント群や全リージョンに展開できます。なお、アップデートや新機能の通知は Security Hub の SNS トピック購読で受け取れます。また、CSPM は 30 日間の無償利用枠（Free Tier）で試用可能です。

影響範囲・利用シーン ​

  • 対象ユーザー: 金融機関のセキュリティ／コンプライアンス担当者、クラウドセキュリティチーム、SRE／運用チーム
  • 利用シーン: CRI Profile に基づくセルフアセスメントと規制報告準備（複数規制への同時対応を目指す場合）
  • 運用効果: 自動検出による恒常的なコンプライアンス評価で手作業と重複評価を削減し、運用コストと人的ミスを低減
  • 制約: CRI の全要件をカバーするわけではなく、手動レビューが必要な要件は引き続き人的対応が必要
  • 導入可否判断: 既に Security Hub を運用している組織は central configuration で短時間に展開可能。新規の場合は管理アカウント設定とアカウント連携が前提

技術的な注意点 ​

  • IAM権限: Security Hub の有効化や標準の有効化には管理者レベルの権限が必要（例: securityhub:EnableSecurityHub、securityhub:BatchEnableStandards など）。central configuration を使う場合は管理アカウント側での権限設定と各メンバーアカウントの連携許可が必要です
  • リージョン制限: 全リージョンで利用可能と発表されています（AWS GovCloud (US)、中国リージョンを含む）が、Security Hub 自体が未対応のリージョンでは利用不可です。導入前に対象リージョンで Security Hub が有効化可能か確認してください
  • コスト: 404 の自動コントロール評価は通常の Security Hub/CSPM の料金体系に従います。30日間の試用枠がありますが、試用後は料金が発生するため事前に料金ページで確認してください
  • 手動確認: CRI プロファイルの一部要件は自動評価でカバーできないため、ドキュメントや運用プロセスで手動チェック項目を明確にして補完する必要があります
  • 通知／連携: 更新情報は Security Hub の SNS トピックで通知可能。SNS の購読設定や必要な IAM 権限（sns:Subscribe 等）を準備してください
  • 互換性: 他のコンプライアンス標準（例: CIS、PCI など）と併用可能ですが、マッピング状況や重複する所見の取り扱いを運用ルールで整理することを推奨します

参考情報 ​

[General] Amazon Managed Service for Prometheus Collector now available in Asia Pacific (New Zealand) Region ​

概要 ​

Amazon Managed Service for Prometheus のエージェント不要コレクタ（collector）がアジアパシフィック（ニュージーランド）リージョンで利用可能になりました。これによりNZ内でPrometheus互換のメトリクス収集を行い、低レイテンシーかつデータの国内保持が可能になります。

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

Amazon Managed Service for Prometheus collector は、ユーザー側で収集エージェントをデプロイ・運用することなくコンテナワークロードからPrometheus形式のメトリクスを検出・収集するフルマネージドサービスです。収集されたメトリクスはAmazon Managed Service for Prometheusのワークスペースへ取り込まれ、クエリ・分析が行えます。今回の対応により、Asia Pacific (New Zealand) リージョン内のワークロードはリージョン内で収集・保管できるため、ネットワーク遅延の低減やデータ主権（データを国内に留める要件）の対応が容易になります。従来必要だったコレクタのスケーリングや運用管理が不要になり、運用負荷と可用性リスクを低減できます。

影響範囲・利用シーン ​

  • 対象ユーザー: クラウド/プラットフォームエンジニア、SRE、DevOps、Kubernetes/ECSなどのコンテナ運用チーム
  • 利用シーン: NZリージョン内のコンテナワークロード（EKS、ECS、自己管理Kubernetes等）からPrometheusメトリクスをエージェントレスで収集してAMPワークスペースに取り込み、監視・アラート・分析を行う場面
  • 運用効果: エージェント運用や収集インフラのスケーリング負荷を削減し、低レイテンシーかつデータ国内保持によりコンプライアンス対応や高速なモニタリングが可能になる
  • 移行効果: 既存の自己管理Prometheusやサードパーティ収集基盤からの移行により運用コストと障害面のリスクを低減できる

技術的な注意点 ​

  • IAM権限: AMPワークスペースへの書き込み等、必要なIAMロール／権限を設定する必要があります（詳細はドキュメントで確認してください）
  • ネットワーク接続: Collectorが各コンテナのPrometheus互換エンドポイントへ到達できる必要があります。VPC設定、セキュリティグループ、サービスディスカバリ／DNS設定等を確認してください
  • リージョン制限: 本リリースはAsia Pacific (New Zealand) リージョンでの新規対応です。他リージョンの可用性は既存の公開情報を参照してください
  • コスト: メトリクスの取り込み量・保存量に基づくAMPの通常課金が適用されます。Collector自体の利用料金やデータ転送量もコストに影響する可能性があるため見積りを確認してください
  • 互換性: Prometheus互換のメトリクスエンドポイントを前提とします。カスタムメトリクスのフォーマットやラベル構成は互換性を確認してください
  • 既存エージェント移行: エージェントレス化は運用負荷を下げますが、移行時に集約ポイントやメトリクスラベル、アラートルールの整合性を確認する必要があります
  • データ保護/コンプライアンス: NZリージョン内での収集と保存によりデータ主権要件に対応できますが、保存期間やアクセス制御の設定はワークスペース側で適切に管理してください

参考情報 ​

[Mwaa] Amazon Managed Workflows for Apache Airflow now offers AI agent skills ​

概要 ​

Amazon MWAAがAgent Toolkit for AWSと統合され、AIエージェントスキルを提供開始しました。自然言語でMWAAワークフローの作成・デバッグ・テスト・環境アップグレードが可能になります。

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

今回追加された4つのAIエージェントスキル（authoring-mwaa-workflow、debugging-mwaa-workflow、testing-mwaa-workflow、upgrading-mwaa-environments）は、Agent Toolkit for AWS経由で動作し、AIコーディングアシスタントが自然言語でMWAAへ直接操作や問い合わせを行えるようにします。たとえば「このETLを実装して」と指示するとauthoringスキルがDAG（タスク依存・リトライ・エラーハンドリング含む）を生成し、debuggingスキルはエラー箇所の特定や修正提案、testingスキルは単体テストや実行シミュレーションの支援、upgradingスキルはProvisioned/Serverless環境のバージョンや設定変更を自動化します。これらはAmazon MWAAのProvisionedおよびServerless環境で利用可能で、MWAAが提供されているすべてのリージョンで使用できます。開始手順としてはaws-data-analyticsプラグインをインストールし、利用するAIアシスタント側でMWAAエージェントスキルを有効化・設定します。内部的にはAgent ToolkitがAWS APIやS3のDAGストア、CloudWatchログなどと連携してワークフローの作成・検証・環境操作を行います（AIは実行前に生成コードのレビューを行うことが推奨されます）。

影響範囲・利用シーン ​

  • 対象ユーザー: データエンジニア、ETL開発者、SRE/運用、MLエンジニア、AIコーディングアシスタントの導入担当者
  • 利用シーン: 自然言語でDAGの自動生成（新規パイプライン作成）／実行エラーの原因解析と修正提案／テストケースの生成と実行支援／MWAA環境のバージョンアップや設定変更の自動化
  • 運用効果: 開発・レビュー工数の削減、パイプライン導入の高速化、デバッグとテストの効率向上。ただし自動生成コードの品質管理・セキュリティレビューは必須で人的レビューが残る点に注意

技術的な注意点 ​

  • IAM権限: Agentが実行するAPI（MWAA: Create/Update/List/GetEnvironment等）、S3（DAGアップロード/取得）、CloudWatch Logs、CloudTrail等への適切な権限が必要です。最小権限のロール設計を行ってください。
  • リージョン制限: Amazon MWAAが提供されている全リージョンで利用可能とされていますが、事前に対象リージョンでMWAAとAgent Toolkitのサポート状況を確認してください。
  • コスト: エージェントによるAPI操作自体は通常のAWS APIコスト体系に従います。環境アップグレードやProvisioned環境の変更・長時間実行などにより追加の実行コストが発生する可能性があります。
  • プラグイン/設定: 利用にはaws-data-analyticsプラグインのインストールと、AIアシスタント側でAgent Toolkitを用いたスキル設定が必要です。プラグインのバージョン依存に注意してください。
  • 互換性: ProvisionedおよびServerlessの両環境をサポートします。使用するDAGやライブラリの互換性は従来通り確認してください。
  • セキュリティ: 自動生成コードにシークレットや誤ったアクセス設定が含まれるリスクがあります。CI/CDやコードレビュー、シークレット管理（AWS Secrets ManagerやIAMロール付与）を組み合わせて運用してください。
  • 監査とログ: Agentの操作はCloudTrailやCloudWatch Logsで監査可能です。変更履歴やAPI呼び出しのログ収集を有効にしておくことを推奨します。
  • 運用推奨: まずは開発/ステージング環境で試験運用し、生成DAGの自動デプロイは段階的に導入してください。AI生成物は必ず人間のレビューを組み込んでください。

参考情報 ​

[VPC] Oracle Database@AWS supports aggregate and default routes for ODB peering ​

概要 ​

Oracle Database@AWS (ODB) が ODB ピアリングで集約ルートおよびデフォルトルート(0.0.0.0/0)のアドバタイズをサポートしました。これにより、複数の VPC やオンプレミスネットワークをデータベースへ接続する際のルート管理が簡素化されます。

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

今回の機能追加により、ODB とアプリケーションが存在する Amazon VPC 間の ODB ピアリング設定で、単一の集約 CIDR（例: 大きなプレフィックス）やデフォルトルート(0.0.0.0/0)を広告（アドバタイズ）できるようになりました。従来は ODB ネットワーク側に到達させたい各ネットワークごとに個別の CIDR を広告する必要があり、VPC を拡張したり AWS Transit Gateway 経由で複数ネットワークを接続するたびに広告リストを更新する必要がありました。今回の変更により、ピア接続先 VPC を通じて到達可能な全ネットワークを単一の集約ルートまたはデフォルトルートでカバーできるため、経路管理が大幅に簡便化されます。なお、この機能は「複数の ODB ピアリング接続をサポートする ODB ネットワーク」で利用可能で、Oracle Database@AWS が提供されているすべてのリージョンで利用できます。また、利用を開始するには AWS Marketplace 経由でのサブスクリプションが必要です。

影響範囲・利用シーン ​

  • 対象ユーザー: ネットワークエンジニア、クラウドアーキテクト、DB 管理者
  • 利用シーン: 新しい VPC やオンプレミスネットワークを ODB に接続する際、各ネットワークごとの個別 CIDR の広告を省略して単一の集約ルートやデフォルトルートでカバーする場合
  • 運用効果: ルート一覧管理の工数削減、VPC/TGW を経由したネットワーク拡張時の設定変更頻度低下、ピアリング運用の簡素化により展開スピード向上
  • セキュリティ/ガバナンス影響: デフォルトルートや広域集約を広告すると到達範囲が拡大するため、アクセス制御やルートフィルタリングの設計見直しが必要

技術的な注意点 ​

  • 対応条件: この機能は「複数の ODB ピアリング接続をサポートする ODB ネットワーク」で有効です
  • リージョン制限: Oracle Database@AWS が提供されているリージョンで利用可能（ただしリージョン毎のサービス可否は事前確認推奨）
  • ルーティング制約: 広域集約や 0.0.0.0/0 の広告はルーティング優先度や重複 CIDR の扱い（最長プレフィックスマッチなど）に影響します。既存のルートとの競合やブラックホール化を避ける設計が必要です
  • セキュリティ: デフォルトルート広告は想定外のトラフィック経路を生成する可能性があるため、セキュリティグループ、ネットワーク ACL、経路フラップ・フィルタリングの確認を行ってください
  • コスト: AWS Transit Gateway やデータ転送にかかる通信コスト、Oracle Database@AWS の Marketplace サブスクリプション費用が発生する可能性があります
  • 導入手順: 利用開始には AWS Marketplace でのサブスクリプションが必要です。実運用前にテスト環境で集約ルート/デフォルトルートの挙動を検証してください
  • 運用監視: ルートの変更やトラフィックパターン変化を CloudWatch/Network ACL ログ等で監視し、想定外の経路流出がないか確認することを推奨します

参考情報 ​

[Resilience Hub] Launch AWS DevOps Agent to review findings and test results from AWS Resilience Hub ​

概要 ​

AWS Resilience HubがAWS DevOps Agentと統合され、障害モード評価の所見や耐障害性テストの結果をエージェントで観察・解析し、緩和策の作成・検証が可能になりました。コンソールから直接エージェントを起動して対話的に調査できます。

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

次世代のAWS Resilience HubはAWS DevOps Agentとの統合を提供します。これにより、耐障害性テスト実行時にResilience HubがDevOps Agentの調査を起動してテストを観察し、構造化された解析（症状、根本原因、影響、観測された回復アクション例：ARCリージョンスイッチ等）を返します。また、障害モード評価の所見からそのコンテキストを引き継いでオンデマンドでDevOps Agentを起動し、質問や追加調査を行いながら緩和プランを作成できます。利用開始はResilience Hubコンソールで対象サービスを選択し、サービス構成でDevOps Agentを設定した後、所見または耐障害性テストから直接エージェントを起動します。Resilience Hub自体は自動依存関係検出、生成AIを用いた障害モード分析、モジュール化されたレジリエンスポリシー、耐障害性テスト、組織全体の耐障害性ポスチャー報告を提供します。

影響範囲・利用シーン ​

  • 対象ユーザー: プラットフォームエンジニア、SRE、DevOpsチーム、クラウドアーキテクト
  • 利用シーン: 耐障害性テスト実行時の自動観察・解析、障害モード評価の所見に対する追加調査と緩和策立案
  • 運用効果: 根本原因や影響の可視化が迅速化され、MTTR短縮や緩和策の確度向上につながる
  • 導入効果: 手動調査の工数削減と、テスト結果から直接アクションに繋げられるワークフロー整備が可能

技術的な注意点 ​

  • IAM権限: DevOps Agentはテレメトリやリソース情報へアクセスするため、CloudWatch、X-Ray、EC2、ELB、RDS、S3等への読み取り権限や、Resilience Hub関連の実行権限を付与する必要があります。詳細は最小権限を設計してください。
  • リージョン制限: Resilience Hubは記事記載のリージョンで利用可能です（US East (N. Virginia), US East (Ohio), US West (Oregon), Canada (Central), Europe (Ireland), Europe (London), Europe (Frankfurt), Europe (Paris), Europe (Stockholm), Asia Pacific (Mumbai), Asia Pacific (Singapore), Asia Pacific (Sydney), Asia Pacific (Tokyo), Asia Pacific (Seoul), South America (São Paulo)）。DevOps Agentの機能はリージョン依存の可能性があるため、利用前に対象リージョンでのサポート状況を確認してください。
  • コスト: Resilience HubやDevOps Agentの実行そのものや、観察で利用されるCloudWatchログ、X-Ray、追加ストレージやテスト実行に伴うリソース使用分について料金が発生する可能性があります。事前に関連サービスの料金を確認してください。
  • データ取り扱い: エージェントはログ・トレース・メトリクス等を収集して解析します。機密データが含まれる場合の取り扱いポリシーや保持期間を確認してください。
  • 起動手順: Resilience Hubコンソールでサービス選択 → サービス構成でDevOps Agentを設定 → 耐障害性テスト実行時または障害モード所見から「DevOps Agentを起動」。事前にエージェント設定（アクセス許可や観察対象の指定）を行っておく必要があります。

参考情報 ​

[CloudWatch] Amazon CloudWatch announces log routing and chained log parsers ​

概要 ​

Amazon CloudWatch Pipelinesが条件付きログルーティングとチェインドパーサーをサポートしました。これにより、同一パイプライン内で複数フォーマットのログを順次解析し、解析結果に基づいて適切なCloudWatchロググループへ振り分けられます。

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

CloudWatch Pipelines（フルマネージドなログ受信・変換・ルーティングサービス）に新たに「条件付きログルーティング」と「チェインドパーサー」が追加されました。条件付きログルーティングでは、パイプライン内で処理・抽出されたフィールドの値に基づきルート（route）を定義し、イベントごとに別々のCloudWatchロググループへ振り分けできます（例：severity、source、typeによる分離）。チェインドパーサーでは複数のパーサープロセッサを順に適用でき、先のパーサーが生成したフィールドを後続のパーサーが消費します（例：まずJSONエンベロープをパースして内部フィールドを取り出し、そのフィールドに対してGrokや正規表現パーサーを適用する）。これらを組み合わせることで、多様なネストされたログ形式を1つのパイプラインで構造化・振り分けし、各ロググループごとに適切な保持期間やアクセス制御を適用できます。設定はAWS Management Console、AWS CLI、AWS SDKsから行えます。機能はCloudWatch Pipelinesが一般提供されているすべての商用AWSリージョンで利用可能です。

影響範囲・利用シーン ​

  • 対象ユーザー: ログ設計者、SRE、プラットフォーム/インフラ運用者、セキュリティチーム
  • 利用シーンまたは効果: ネストされた/混在フォーマットのログを一つの取り込み経路で解析・分岐し、重複設定なしにログを適切なロググループへ振り分け可能
  • 運用効果: 保持ポリシーやアクセス制御をログ種別ごとに分離できるためコンプライアンス対応が容易になり、検索・監視の効率が向上
  • 開発効果: パーサーを連鎖して細かくデータを抽出できるため、ダッシュボードやアラートの精度が上がる

技術的な注意点 ​

  • IAM権限: CloudWatch Pipelinesの作成・更新・実行、対象ロググループへのPut権限、必要なKMS/ロール権限を事前に確認してください（パイプライン作成には適切なService Roleが必要）
  • リージョン制限: 本機能はCloudWatch Pipelinesが一般提供されている商用リージョンで利用可能です。リージョンによっては未対応の可能性があるため利用前にリージョンのサービス可用性を確認してください
  • コスト: Pipelinesの処理・データ転送・保存に対する通常のCloudWatch Pipelines／Logsの料金が適用されます。ルーティングや複数パーサーの適用により処理量が増えると料金に影響する可能性があるため想定トラフィックでのコスト見積りを推奨します
  • クォータ／制限: 既存のCloudWatch PipelinesおよびLogsのスループット・イベントサイズ・ルート数・パーサー数に関する制限が適用されます。大規模導入時はドキュメントでクォータを確認し、必要ならサポートへ引き上げ依頼してください
  • 挙動／互換性: ルーティング条件は「処理済みフィールド」に対して評価されるため、パーサーの順序がルーティング結果に影響します。チェインドパーサーを設計する際はパーサーの入出力フィールドを明確にし、意図した順序で適用されるよう注意してください
  • デバッグ／テスト: 本番適用前にサンプルイベントでパーサーチェーンとルーティング条件を検証し、期待される抽出結果と送信先ロググループを確認してください

参考情報 ​

[Aiml] Amazon SageMaker Studio simplifies getting started for new AI/ML builders with social sign-in ​

概要 ​

Amazon SageMaker StudioがGoogle/GitHub/Appleのソーシャルサインインに対応し、従来のAWSアカウント作成やクレジットカード登録なしで、事前構成済みのStudio環境に直接遷移してすぐにモデルの微調整・評価・デプロイが行えるようになりました。

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

新機能により、新規ユーザーは既存の外部ID（Google、GitHub、Apple）でサインインしてSageMaker Studioの個別環境へアクセスできます。サインアップ時の多段階のAWSアカウント作成やクレジットカード登録が不要で、AWS Free Tierの無料クレジットが付与されるため即時にモデルのカスタマイズやデプロイを試せます。Hugging Faceや製品ページからの深いリンクによりモデルをプリロードした状態で起動でき、チームメンバーはメール招待でコラボレーターとして参加し、それぞれのソーシャル資格情報で共有Studio（モデル、ノートブック、エンドポイント）にアクセス可能です。IAMユーザーや個別の権限設定を手動で作る必要はありません。プロジェクトが無料クレジットを超える場合は有料プランにアップグレードでき、利用上限（spend limit）を設定して予算管理が可能です。検証済みユーザーには、エンドポイント、トレーニングジョブ、ノートブックいずれにもデフォルトでG5/G6/G6e/G4dn GPUインスタンスへのアクセスが付与され、クォータ増加申請なしで利用できる点が明記されています。本機能はAmazon SageMaker StudioがサポートされるすべてのAWS商用リージョンで利用可能です。

影響範囲・利用シーン ​

  • 対象ユーザー: AI/MLの新規学習者・開発者、プロトタイプ作成を行う個人や少人数チーム
  • 利用シーン: Hugging Face上のモデルを即座に読み込み、ノートブックで微調整→評価→エンドポイントとしてデプロイするワークフローの短縮
  • 運用効果: アカウント作成やIAM設定の工数削減によりオンボーディング時間が大幅短縮され、非エンジニアやビジネス担当者も迅速に実験・検証を開始できる
  • チーム協働: メール招待＋ソーシャルサインインで共同作業が簡易化され、初期段階のコラボレーション導入障壁が低下する
  • スケーリング時の移行: 無料クレジットから有料プランへの移行と支出上限設定により、コスト過剰発生のリスクを抑えつつ本番移行が可能

技術的な注意点 ​

  • IAM権限: ソーシャルサインインでの利用では個別のIAMユーザー作成が不要だが、組織での利用時は既存のIAM/アクセス管理ポリシーとの整合性を検討してください
  • 認証方式: Google/GitHub/Appleの外部IDとAWS側のフェデレーション連携を利用して環境がプロビジョニングされる想定のため、企業ポリシーで外部ID連携が禁止されている場合は利用できません
  • リージョン制限: 本機能はAmazon SageMaker StudioがサポートされるすべてのAWS商用リージョンで提供されます（リージョンごとのサービス提供状況は要確認）
  • コスト: 初期はFree Tierのクレジットで実行可能だが、クレジット消費後は有料プランとなり支払い方法の登録と実際の利用料金が発生します。利用上限（spend limit）で予算管理可能ですが、割当クォータや追加リソース利用は別途課金対象です
  • GPUアクセス: 記載のG5/G6/G6e/G4dnインスタンスは“検証済み顧客”に対してデフォルトでアクセスが付与されるとあるが、アカウント単位の他クォータや地域の在庫状況により実際の割り当てが変わる可能性があります
  • セキュリティ/コンプライアンス: 共有Studio環境や外部ID連携を利用する場合、データアクセス権限やログ監査、データ保護要件（機密データや顧客データ取り扱い）を事前に確認してください

参考情報 ​

[General] ARC Region switch adds four new capabilities ​

概要 ​

Amazon Application Recovery Controller (ARC) の Region switch に 4 つの新機能が追加されました。SSM Run Command 実行ブロック、カスタム Lambda 実行ブロックへのペイロード渡し、サービスクォータのパリティチェック（および自動引上げ申請）、およびターゲットグループのヘルス待機機能が含まれます。

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

今回の追加機能はフェイルオーバー計画の自動化と信頼性を高めるためのものです。

  • AWS Systems Manager Run Command 実行ブロック: フェイルオーバー中にマネージドインスタンス（EC2 やハイパーバイザー上の VM 等）へ Run Command を送信できるようになります。Recovery Plan の評価段階で、ドキュメントが有効なターゲットを指しているか、必要な IAM 権限が設定されているかを検証します。

  • カスタムアクション Lambda 実行ブロックのペイロード: カスタム Lambda を実行するブロックに対して任意のペイロードを渡せるようになり、同じ Lambda 関数を複数のリカバリプランや状況で再利用しやすくなります。ペイロードにより呼び出し先での処理分岐やパラメータ指定が可能です。

  • サービスクォータチェック（Service quota parity checks）: プライマリ Region とスタンバイ Region 間で主要サービスのクォータ差分を検出します。不足がある場合は自動的にクォータ増加のリクエストを提出でき、フェイルオーバー時にクォータ不足でリカバリが失敗するリスクを低減します（ただしクォータ増加の反映は即時ではない場合があります）。

  • ターゲットグループのヘルス待機（Wait for target group health）: Amazon ECS のサービススケーリングブロックや EC2 Auto Scaling グループの実行ブロックにおいて、起動したインスタンス/タスクが実際にターゲットグループでヘルスチェックをパスしてトラフィックを受けられる状態になるまで待機するオプションを追加。これにより“容量は確保したがサービスがまだ応答できない”という状態を避け、トラフィック切替の精度を向上させます。

影響範囲・利用シーン ​

  • 対象ユーザー: マルチリージョンで高可用性・障害対策を設計・運用する SRE、クラウドアーキテクト、災対担当者
  • 利用シーンまたは効果: リージョン障害時の自動フェイルオーバー実行（構成変更、インスタンス内コマンド実行、カスタム処理呼び出し、必要クォータの確保、プロビジョニング後のヘルス確認）により、計画通りの復旧時間を達成しやすくなる
  • 運用効果: 手動作業やチェックの削減、クォータ不足による想定外の失敗削減、切り替え時のサービス停止リスク低下、リカバリプランの再利用性向上

技術的な注意点 ​

  • IAM権限: SSM Run Command、Lambda Invoke、Service Quotas へのクォータ申請、ECS/Auto Scaling/ELB の操作とヘルスチェック閲覧など、各機能に応じた細かな権限が必要です（実行前に最小権限ポリシーを確認してください）。
  • リージョン制限: ARC と各実行機能が利用可能なリージョンでのみ動作します。プライマリ／スタンバイ両 Region で対象サービスが利用可能か、クォータリソースが存在するかを事前に確認してください。
  • コスト: SSM Run Command の実行、Lambda 実行、追加インスタンス/タスクのプロビジョニング、ヘルスチェック待機による稼働時間増加などによりコストが発生します。クォータ増加自体は無料申請ですが、増加後のリソース利用は課金対象です。
  • クォータ申請の即時性: 自動でクォータ増加リクエストを提出できますが、承認までは時間を要する場合があり、即時に反映されない点を考慮して計画してください。
  • タイムアウトと待機時間: ターゲットグループのヘルス待機を有効にすると復旧シーケンスが長くなる可能性があります。適切なタイムアウト値とリトライ設定を設計してください。
  • 検証要件: Run Command のドキュメントが正しいターゲット（インスタンス ID、タグ、マネージャー登録状態）を指しているか、Lambda が渡されるペイロードを処理できるか、ターゲットグループのヘルスチェック設定が適切かを事前検証してください。

参考情報 ​

[License Manager] AWS License Manager now supports license type conversions for Ubuntu Pro purchased through AWS Marketplace ​

概要 ​

AWS License Managerで、既存のEC2上のUbuntu LTSインスタンスをAWS MarketplaceのUbuntu Proへインプレースでアップグレード（ライセンスタイプ変換）できるようになりました。再構築やAMI置換を行わずに長期のセキュリティパッチと追加パッケージの保守を受けられます。

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

License Managerの変換ワークフローにより、EC2上のUbuntu LTSインスタンスをそのままCanonicalのUbuntu Proサブスクリプションに登録・有効化できます。変換はコンソール上で実行でき、既にAWS MarketplaceでCanonical Ubuntu Proを購入済みの顧客はワークフロー中に既存サブスクリプションを紐付け可能です。未購読の場合はLicense ManagerコンソールからMarketplace購読が可能です。Ubuntu Proは標準のLTSサポート（最大10年、Legacyアドオンで最大15年に拡張）に加え、NGINX、PostgreSQL、MongoDB、Redisなど多くの追加OSSパッケージへのセキュリティ修正を含みます。また、Kernel Livepatchをサポートしており、重要なカーネル修正を再起動なしで適用してダウンタイムを最小化できます。この機能はAWS License Managerが利用可能な全ての商用リージョンで利用できます。実際の変換では、インスタンスのサブスクリプション登録、リポジトリの有効化やパッケージ適用（apt等）などが行われるため、SSMエージェントやネットワーク接続、必要なIAM権限が前提になります。課金はUbuntu ProのMarketplaceサブスクリプションに基づき発生します。

影響範囲・利用シーン ​

  • 対象ユーザー: クラウド/サーバ運用者、セキュリティ/コンプライアンス担当、SRE
  • 利用シーン: 既存のEC2 Ubuntu LTS環境を再構築せずに長期のセキュリティサポートや追加パッケージのパッチを適用したい場面
  • 運用効果: フリートの再デプロイを避けつつセキュリティポスチャを強化でき、Kernel Livepatchにより再起動を抑えてダウンタイム低減が可能
  • コスト影響: Ubuntu ProのMarketplaceサブスクリプション費用が発生（License Manager自体の機能利用は管理下で行われる）

技術的な注意点 ​

  • IAM権限: AWS License ManagerとEC2インスタンスを操作できる権限（License Manager操作、EC2のタグ/インスタンス変更、必要に応じてSSM実行権限など）を用意してください
  • 前提条件: 対象はUbuntu LTSのEC2インスタンスで、インスタンスがネットワークアクセス（インターネットまたは必要なリポジトリへアクセスできる経路）を持ち、必要に応じてSSMエージェントが稼働していることを推奨します
  • 再起動/ダウンタイム: Kernel Livepatchで多くのカーネル修正は再起動不要ですが、すべてのアップデートが再起動不要とは限らないため、重要なワークロードでは事前に影響確認を行ってください
  • サポートされるOSバージョン: 対象はCanonicalが定めるUbuntu LTSリリース（事前にサポート対象のLTSバージョンを確認してください）
  • リージョン制限: AWS License Managerが提供される全ての商用リージョンで利用可能とされていますが、AWS ChinaリージョンおよびAWS GovCloud等の特殊リージョンは別扱いの可能性があるため事前確認を推奨します
  • コスト: Ubuntu ProはMarketplace経由のサブスクリプション課金が発生します。組織のコスト管理ポリシーに合わせて購読前に見積もりを確認してください

参考情報 ​

[General] AWS HealthOmics introduces resource fallback order for Nextflow workflows ​

概要 ​

AWS HealthOmicsがNextflowワークフロー向けに「resource fallback」ディレクティブを導入しました。タスクごとに優先するアクセラレータ（GPU等）を順序指定でき、利用不可時に自動で代替へフォールバックし、最終的にCPUを指定することも可能です。

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

resource fallbackディレクティブにより、Nextflowワークフロー内の各タスクでアクセラレータの優先順を定義できます。指定した優先順に沿ってHealthOmicsが自動的にアクセラレータを探索し、各アクセラレータプロファイルに対して個別のタイムアウトを設定可能です。タイムアウトの値を短く設定するとフォールバック順を速やかに進められ、長く設定すると優先アクセラレータを確保できる確率が高まります。最終フォールバックにCPUプロファイルを含めることで、アクセラレータが全て利用不可でもインスタンスの確保成功率を高められます。フォールバックは再送信（resubmission）を伴わずに実行されるため、ユーザーが手動でジョブを再投入して診断・調整する工数が削減されます。サービスはHIPAA適合（Eligibility）で、以下のリージョンで利用可能です：US East (N. Virginia, Ohio), US West (Oregon), Europe (Frankfurt, Ireland, London), Israel (Tel Aviv), Asia Pacific (Seoul, Singapore, Tokyo)。詳細はAdvanced Resource ConfigurationおよびNextflow向けのドキュメントを参照してください。

影響範囲・利用シーン ​

  • 対象ユーザー: 研究者、バイオインフォマティシャン、クラウド上でNextflowワークフローを運用するSRE/運用チーム
  • 利用シーン: GPU/その他アクセラレータの空きが不安定な大規模ゲノム解析やバッチ解析パイプライン、プロダクションのNextflowジョブの継続実行
  • 運用効果: アクセラレータ不足による手動再投入やデバッグ時間を削減し、ワークフローのスループットと稼働率を向上させる
  • コスト影響: 優先アクセラレータが確保できない場合にCPUへフォールバックすると実行時間が延び、結果としてコストが増加する可能性がある

技術的な注意点 ​

  • IAM権限: HealthOmicsでインスタンス・アクセラレータを予約するためのIAM権限（ジョブ実行、インスタンス割当関連）が必要です。事前に必要権限を確認してください。
  • リージョン制限: 現在利用可能なリージョンは記事記載の通り（US East (N. Virginia, Ohio), US West (Oregon), Europe (Frankfurt, Ireland, London), Israel (Tel Aviv), Asia Pacific (Seoul, Singapore, Tokyo)）です。その他リージョンでは未対応の可能性があります。
  • タイムアウト設定: 各アクセラレータプロファイルに対し探索タイムアウトを設定できます。短いと迅速にフォールバック、長いと優先アクセラレータの確保確率が上がるため、ワークロード特性に応じた調整が必要です。
  • CPUフォールバックの影響: 最終フォールバックでCPUを指定すると高確率でインスタンスが確保できますが、実行時間とコストが大きく変わることがあるため、コスト試算やSLAへの影響を評価してください。
  • Nextflow互換性: Nextflowのresourceディレクティブにフォールバック順を記述する方式のため、既存のNextflowスクリプトへ適用可能ですが、記述方法やプロファイル名はHealthOmicsのNextflow固有仕様に従ってください（公式ドキュメントでの確認を推奨）。
  • コンプライアンス: HealthOmicsはHIPAA適合（Eligibility）であり、医療・ライフサイエンス用途での利用が可能です。
  • コスト: フォールバックに伴う実行時間の変化や異なるインスタンスタイプ利用により課金が変動します。ジョブのコスト見積りを事前に行ってください。

参考情報 ​

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

Copyright © 2026