AWS What's New Digest

Appearance

2026年08月20日 ​

[General] Launching External Web Access for Web Search on Amazon Bedrock ​

概要 ​

Amazon BedrockのWeb Searchが外部Webアクセス（external_web_access）をサポートするようになりました。これによりモデル応答を最新の公開ウェブ情報でグラウンドでき、必要に応じてAWS境界内のみで完結させる設定も可能です。

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

新しく追加された external_web_access パラメータにより、Web Searchが公開ウェブからライブにコンテンツを取得して基礎モデルの応答に反映できます。外部取得を有効にするには、リクエストを行う主体（IAMエンティティ）に bedrock-websearch:ExternalWebAccess IAM権限を付与し、external_web_access をデフォルトの true のままにします。external_web_access=true の場合、最新のスポーツスコア、ライブ価格、公開されたばかりのドキュメントなど“最新性”が重要なユースケースで外部Webを参照します。一方、外部アクセスを完全にAWS内部に限定したい場合は external_web_access=false を設定すると、Web SearchはAmazonのAWS内部のウェブインデックスとナレッジグラフのみを参照し、リクエストデータがAWS境界外へ出ることはありません（データエグレスなし）。現在、この外部Webアクセスの有効化は US East (N. Virginia)、US East (Ohio)、US West (Oregon) のリージョンで提供されています。料金や詳細な設定方法についてはAmazon Bedrockのドキュメントと料金ページを参照してください。

影響範囲・利用シーン ​

  • 対象ユーザー: LLMを利用するアプリ開発者、データサイエンティスト、SRE/セキュリティチーム
  • 利用シーン: 最新ニュース、スポーツ結果、商品価格やリリースノートなど“最新情報”を回答に反映させたいアプリケーション
  • 運用効果: モデル応答の鮮度向上によりユーザー体験が改善される。必要に応じて外部アクセスを遮断することでデータ主権やコンプライアンス要件を満たしやすくなる
  • セキュリティ/コンプライアンス影響: external_web_access=true の場合、公開Webへの問い合わせが発生するため機密データや個人情報の取り扱いに注意が必要。機密性が高い用途は false にしてAWS内インデックスのみを利用推奨
  • リージョン制限: 現時点での有効リージョンは US East (N. Virginia)、US East (Ohio)、US West (Oregon) のみ

技術的な注意点 ​

  • IAM権限: external_web_access を有効にするにはリクエスト主体に bedrock-websearch:ExternalWebAccess 権限を付与する必要があります
  • デフォルト設定: external_web_access はデフォルトで true（外部アクセス有効）。外部アクセスを無効化するには explicit に external_web_access=false を設定してください
  • データ転送/機密性: external_web_access=true の場合は公開Webからのライブ取得が行われ、リクエストやメタデータが外部とやり取りされる可能性があります。機密データは送信しない設計を推奨します。external_web_access=false にするとリクエストデータはAWS境界内で処理され、外部へのエグレスはありません
  • リージョン制限: 現在は US East (N. Virginia), US East (Ohio), US West (Oregon) のみ対応。他リージョンでは利用できません
  • コスト: 外部Web取得を行う際は追加の料金が発生する可能性があります。実行頻度やデータ量により課金が変わるため、Bedrockの料金ページで確認してください
  • 監査/ロギング: Web Searchの呼び出しや外部アクセスに関する監査はCloudTrail/サービスログで確認可能にする運用を推奨します
  • 失敗時の挙動: 必要なIAM権限が付与されていない、あるいは外部アクセスが制限された環境では外部取得が行えないため、アプリ側でフォールバック（AWS内インデックス利用やユーザー通知）を用意してください

参考情報 ​

[Bedrock] Web Search in Amazon Bedrock AgentCore adds domain and published date filtering, expands to Europe and Asia Pacific ​

概要 ​

Amazon BedrockのAgentCoreにおけるWeb Searchツールが、ドメインフィルタ（include/exclude）と公開日（published-date）の範囲フィルタをリクエスト単位で指定できるようになり、欧州（アイルランド）とアジア太平洋（東京）リージョンへ拡張されました。これにより、ソース信頼性や情報の新しさを厳密に制御できます。

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

AgentCoreのWeb Searchツールは、各ツール呼び出しごとに以下を指定可能になりました：

  • ドメインフィルタ（includeおよびexcludeリスト）: 実行時に特定ドメインのみを検索対象にしたり、特定ドメインを除外したりできる。管理者による設定変更を伴わずにエージェント単位・リクエスト単位で制御可能。管理用のゲートウェイレベルのallowlist機能も追加され、管理者は中央で許可ドメインを設定できる。
  • 公開日フィルタ（published-date range）: inclusiveなfrom/to日付境界を使って、検索結果を指定した時間ウィンドウ内に制限できる（例: 2024-01-01 から 2024-06-30 まで）。 その他の強化点として、ドメインリストあたりの上限が増加（最大100ドメイン/リスト）しました。これらは、エージェントのツール呼び出しパラメータとして渡され、エージェントは結果のソースと時系列を厳密に管理して応答を生成できます。さらに、Web Searchの提供リージョンがこれまでの米東（北バージニア）に加えて欧州（アイルランド、eu-west-1）とアジア太平洋（東京、ap-northeast-1）へ拡張されました。技術詳細や実装例は技術ブログと製品ドキュメントを参照してください。

影響範囲・利用シーン ​

  • 対象ユーザー: AIエージェントを構築する開発者、SRE/運用チーム、セキュリティ・ガバナンス担当
  • 利用シーンまたは効果: 規制業界や研究ワークフローで、信頼できる特定のサイトのみを参照させたり、最新情報のみを根拠に応答を生成したりする用途に有効
  • 運用効果: 管理者の設定変更なしでリクエスト単位にソースを制御可能になり、誤情報や望ましくないドメインの混入を抑制してコンプライアンス遵守やQAの効率化を図れる

技術的な注意点 ​

  • IAM権限: Web SearchツールやAgentCoreを呼び出すために必要なBedrock関連のIAM権限を付与しておく必要がある（実行・管理用の権限分離を検討してください）
  • リージョン制限: 本機能は現時点で us-east-1（既存）、eu-west-1（アイルランド）、ap-northeast-1（東京）で利用可能。他リージョンでは未対応の可能性あり
  • ドメイン制限（キャップ）: include/excludeリストは最大100ドメイン/リストに増加。大規模リストを扱う場合はこの上限に注意
  • 管理者設定: 管理者はゲートウェイレベルのallowlistを設定可能。エージェント側のリクエストで許可/除外と整合しない場合の優先度を運用ルールで定義しておくことを推奨
  • 公開日フィルタ仕様: from/toはinclusive（境界を含む）で指定する必要がある。日時フォーマットやタイムゾーンの扱いはドキュメントに準拠してください
  • パフォーマンス/レイテンシ: フィルタ処理による追加の問い合わせや絞り込みコストが発生し得るため、レイテンシへの影響を検証してください
  • コスト: BedrockのAPI呼び出しやWeb Searchの利用に伴う通常の料金（APIリクエスト数、データ転送等）が発生する可能性があります。大量検索や高頻度呼び出し時はコスト影響を評価してください
  • プライバシー/コンプライアンス: 外部Webソースを参照するため、利用するドメインや取得するデータの取扱い（個人情報、ライセンス等）について社内ガバナンスを確認してください

参考情報 ​

[CloudWatch] Amazon CloudWatch log Centralization now supports log group tag propagation ​

概要 ​

Amazon CloudWatch Centralization が、ソースアカウントのロググループに付与されたタグを中央集約先のロググループへコピーし、選択した伝播設定に従って同期を維持できるようになりました。これにより、コスト配分や所有権・コンプライアンス情報を保ったままログを集中管理できます。

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

CloudWatch Centralization は複数アカウント／リージョンのログを1つの宛先アカウントに集約します。本アップデートにより、各ソースのロググループに付与されているタグを、中央集約ルールで作成される対応する宛先ロググループへコピーします。タグのコピーは集約ルール設定時に選択する "tag propagation" 動作（例: 継続的同期／一度だけコピー 等）に従って行われ、ソース側でのタグ変更や削除の反映方法もその設定で制御されます。運用例としては、Application や CostCenter タグを保持して IAM ポリシー条件でアクセススコープを制御したり、AWS Cost Explorer で中央集約されたログのコストをチーム単位で集計することが可能です。タグ伝播は CloudWatch Centralization が利用可能な全リージョンで有効です。設定は CloudWatch コンソールまたは AWS CLI / SDK から、各中央集約ルール単位で有効化できます。なお、AWS のタグ制限（例: リソースあたりのタグ上限など）は引き続き適用されます。

影響範囲・利用シーン ​

  • 対象ユーザー: ログ管理者、プラットフォーム／SRE チーム、セキュリティ・コンプライアンス担当、コスト管理担当者
  • 利用シーン: 複数アカウント／リージョンのログを中央集約しつつ、アプリケーション／コストセンター等のタグでアクセス制御や課金配分を行いたい場合
  • 運用効果: タグ付けの手作業削減、Centralized ログに対する IAM 条件や Cost Explorer によるチーム別コスト集計が可能になり、所有権・コンプライアンス追跡が容易になる

技術的な注意点 ​

  • IAM権限: 宛先アカウント／ルールを作成・変更する権限と、ロググループの作成・タグ付与に関する CloudWatch Logs の権限（例: CreateLogGroup、TagResource 等）が必要です。クロスアカウント設定を行う場合は関連するロール／信頼ポリシーの設定確認も必要です。
  • リージョン制限: CloudWatch Centralization が提供されているリージョンで利用可能です。利用前に AWS Regions 表で対象リージョンの対応状況を確認してください。
  • コスト: Centralization に伴うログ転送・集約の料金および宛先での保存コストが発生します。タグ伝播自体に別料金は発生しない可能性がありますが、集約対象や保存量に基づく追加コストは見積もってください（詳細は CloudWatch の料金ページ参照）。
  • タグ制限と注意点: AWS のタグ制限（例: リソースあたりのタグ数上限、キー／値の文字数制限、予約プレフィックス aws: の使用不可など）は適用されます。ソース／宛先でタグが競合する場合の上書きルールや、削除時の同期挙動は中央集約ルールの伝播設定に依存します。
  • 同期動作: 伝播設定で「継続的同期」か「一度だけコピー」等を選択可能です。運用要件に応じて、タグ変更・削除の反映ポリシーを明確に設定してください。
  • 設定方法: 各中央集約ルール単位でタグ伝播を有効化します。コンソールの UI、または AWS CLI / SDK の API 操作により設定可能です。

参考情報 ​

[SageMaker] Amazon SageMaker notebooks now support trusted identity propagation ​

概要 ​

Amazon SageMaker NotebooksがTrusted Identity Propagation (TIP)をサポートしました。これにより、Athena、Redshift、EMR Serverlessと接続したノートブックで各ユーザーのIAM Identity CenterアイデンティティがLake Formationまで伝搬し、ユーザー単位のテーブル/カラム/行レベルのアクセス制御と監査が可能になります。

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

TIP対応のProjectとTIP対応のコンピュート（Amazon Athena、Amazon Redshift、Amazon EMR Serverless）に接続したSageMakerノートブックでは、ノートブックを実行する各ユーザーのIAM Identity CenterのIDが実行コンテキストにそのまま伝搬します。結果として、単一の共通実行ロールを共有する代わりに、Lake Formationで設定されたテーブル・カラム・行レベルの権限が実行ユーザー単位で適用されます。CloudTrailはどのユーザーがデータへアクセスしたかを記録するため、フルアトリビューション（監査証跡）が得られます。管理面では、追加のログインやトークン発行、ロール管理を行わずに既存のコンピュート接続経由で自動的にアイデンティティが伝搬されるため、運用負荷が低減します。利用開始は、TIP対応Project内でTIP対応のエンジンに接続してノートブックを使い始めるだけです。なお、この機能はSageMaker Unified Studioが利用可能なリージョンで提供されます。

影響範囲・利用シーン ​

  • 対象ユーザー: データサイエンティスト、データアナリスト、プラットフォームエンジニア、セキュリティ/コンプライアンス担当者
  • 利用シーン: マルチユーザー/マルチテナント環境での共同分析（共有ノートブックや共通コンピュートを使ったクエリ実行）や、データアクセスの厳密な分離が求められる分析ワークフロー
  • 運用効果: ユーザー毎の最小権限適用によりデータ漏洩リスクが低減され、CloudTrailによるユーザー単位の監査が可能になり、管理者のロール・トークン管理工数が削減される

技術的な注意点 ​

  • IAM権限: IAM Identity Center（旧AWS SSO）でのユーザー設定と、Lake Formation上でのテーブル/カラム/行レベルの権限設定が必要です。ノートブックおよびコンピュートに対するProject設定でTIPを有効化する必要があります。
  • リージョン制限: SageMaker Unified Studioが提供されているリージョンで利用可能です。利用前に対象リージョンでUnified Studioと対応するエンジン（Athena/Redshift/EMR Serverless）が利用可能か確認してください。
  • コスト: TIP自体に専用料金はありませんが、Athena/Redshift/EMR Serverlessのクエリ実行コスト、CloudTrailのログ記録（データイベントの有無により追加コストの可能性）等は発生します。
  • 対応エンジン: 本記事時点でのサポート対象はAmazon Athena、Amazon Redshift、Amazon EMR Serverlessです。非対応のコンピュートやTIP未設定のProjectでは伝搬されません。
  • 設定注意: 正しく機能させるためにProject側とコンピュート側の両方でTIPを有効化する必要があります。また、Lake Formation側での行レベル／列レベル権限やGlueデータカタログの設定が結果に影響します。
  • 監査/ログ: CloudTrailによりどのユーザーがいつどのデータへアクセスしたかを記録できますが、CloudTrailの設定や保管ポリシーも合わせて確認してください。

参考情報 ​

[Cloud Financial Management] AWS Cost Anomaly Detection supports third-party models on Amazon Bedrock ​

概要 ​

AWS Cost Anomaly DetectionがAmazon Bedrock上で動作するサードパーティ製ファウンデーションモデル（例: Anthropic Claude等）の利用料金を自動的に監視・異常検出できるようになりました。生成AIのモデル利用に伴う想定外の支出を、既存のAWSコストと同様にアラートで把握できます。

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

Cost Anomaly Detection（CAD）は機械学習を用いて異常な支出を検出・通知するサービスで、今回の拡張によりAmazon Bedrock上で提供されるサードパーティのファウンデーションモデルに対する課金（プロバイダーホステッドモデルの利用料）も自動的に評価対象になります。追加のセットアップは不要で、AWSのマネージドモニタリング経路を通じて自動的にコストデータを評価します。支出が予想外に変動した場合はアラートが送信され、影響額順にランク付けされたルートコーズの内訳（AWSサービス、アカウント、リージョン、usage type等）を受け取れるため、生成AIのコスト変動を他のAWSコストと同様に迅速に把握・対応できます。対応リージョンはすべての商用リージョン（ただしAWS GovCloudおよび中国リージョンは除く）です。通知先には既存のSNS等を利用できますし、必要に応じてカスタムモニターやしきい値設定と組み合わせて運用できます。

影響範囲・利用シーン ​

  • 対象ユーザー: 生成AI/MLを本番利用している開発チーム、SRE、クラウドコスト管理チーム
  • 利用シーン: Amazon Bedrockでサードパーティモデル（例: Anthropic Claude）を使った推論/トレーニングの利用コスト監視、予期しないコスト増加の早期検知
  • 運用効果: 異常支出発生時に自動アラートと金額影響の内訳が得られるため、原因特定と対応時間が短縮され、予算超過やサービス停止リスクを低減できる

技術的な注意点 ​

  • IAM権限: コスト関連情報の閲覧やCost Anomaly Detectionのアラート受信設定にはBillingやCost Explorer、CADへの適切なIAM権限（例: aws-portal:ViewBilling、ce:GetCostAndUsage、ce:GetAnomalySubscriptions 等）が必要です
  • リージョン制限: 商用リージョンで利用可能。AWS GovCloudおよび中国リージョンでは未対応です
  • コスト: CAD自体の基本的な検出は追加設定不要ですが、SNSやCloudWatchイベント、外部通知経路の使用に伴う通常の運用コスト（SNS配信、Lambda実行等）が発生する可能性があります
  • 設定/運用: 本リリースはデフォルトのマネージドモニターによる自動評価が有効になりますが、必要に応じてカスタムモニターや通知設定を作成して閾値やスコープを調整してください
  • 請求の帰属: Bedrock経由のサードパーティモデル利用料はAWS請求に統合されるため、アカウント/リージョン/usage type単位での内訳がCADの分析に含まれます
  • データソース: CADはCost and Usageデータ（CUR）等を基に分析を行うため、CURやタグの整備により原因特定が容易になります

参考情報 ​

[Opensearch Service] Amazon OpenSearch Ingestion is now available in GovCloud Regions ​

概要 ​

Amazon OpenSearch IngestionがAWS GovCloud (US-East)およびAWS GovCloud (US-West)で利用可能になりました。これにより、政府向け/制約のある環境でもOpenSearchへのフルマネージドなデータ取り込みと前処理が利用できます。

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

Amazon OpenSearch Ingestionは、OpenSearch Service（マネージドクラスターおよびサーバーレスコレクション）向けのフルマネージドなデータ取り込み層です。ノーコードUIでフィルタリング、変換、マスキング（機密データの赤字化）、ルーティングを行い、インデックス作成前にデータを処理できます。基盤リソースはワークロードに応じて自動プロビジョニングおよびスケーリングされ、ピーク/アイドル時の容量管理を透明化します。本リリースでOpenSearch Ingestionは19リージョンでGAとなり、新たにGovCloud (US-East)とGovCloud (US-West)が追加されました（他リージョン例: us-east-2, us-east-1, eu-west-1, ap-northeast-1 など）。管理クラスターとサーバーレスの両方に対応するため、既存のOpenSearch運用フローへ容易に統合できます。

影響範囲・利用シーン ​

  • 対象ユーザー: 政府機関・契約事業者、セキュア環境でOpenSearchを使う組織、セキュアなデータパイプラインを求めるSRE/データエンジニア
  • 利用シーン: 機密情報を含むログや監査データの取り込み前処理（フィルタ／マスキング）、複数ソースからのデータ集約とルーティング、サーバーレスコレクションやマネージドクラスターへの配信
  • 運用効果: データ前処理をサービス側で一元化できるため、クライアント側の実装負荷が低減し、スケーリングやリソース管理の運用工数が削減される
  • セキュリティ/コンプライアンス効果: GovCloudでの提供により、データ主権や政府向けコンプライアンス（例: 政府契約の要件）への対応が容易になる可能性がある

技術的な注意点 ​

  • IAM権限: OpenSearch Ingestionを操作・設定するための適切なIAMロール/ポリシーが必要です（OpenSearch ServiceおよびIngestion用のAPI操作権限を付与してください）
  • リージョン制限: 本リリースでGovCloud (US-East) と GovCloud (US-West) に拡張されましたが、すべての商用リージョンと同機能の差分がある可能性があるため、利用前に対応リージョンと機能一覧を確認してください
  • コスト: フルマネージドの取り込み層は処理量・スループットに応じた課金が発生します。自動スケーリングによりコストが変動するため、想定トラフィックでのコスト試算を行ってください
  • 互換性: マネージドクラスターとサーバーレスコレクション両方に対応しますが、コネクタやプラグインの対応状況はリージョンやリリースで異なる場合があります
  • コンプライアンス: GovCloud利用時はデータの地理的配置・契約要件（例: ITARなど）を満たす設定と監査ログの設計を確認してください

参考情報 ​

[Lightsail] AWS Marketplace launches support for Amazon Lightsail ​

概要 ​

AWS Marketplace の一部 AMI を Amazon Lightsail から直接起動できるようになりました。これにより、シンプルで月額固定の料金体系と簡易なインスタンス作成フローで Marketplace 製品を Lightsail 上に数クリックでデプロイできます。

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

今回の対応により、AWS Marketplace で提供される対象の AMI（例: Microsoft Windows Server、Microsoft SQL Server Express、Ubuntu、cPanel & WHM、Plesk など）をサブスクライブした上で「Launch on Lightsail」を選択すると、選択した AMI とリージョンが事前設定された状態で Amazon Lightsail コンソールに遷移し、Lightsail のバンドル（コンピュート、ストレージ、一定のデータ転送量を含む）を固定月額で利用してデプロイできるようになります。Lightsail は Managed Databases、コンテナ、ロードバランサー等のマネージド機能も提供しており、成長に応じたスケールや運用を簡易に行えます。本オプションは Lightsail が利用可能な全リージョンで対象製品に対して利用可能ですが、すべての Marketplace 製品が Lightsail 起動に対応しているわけではありません。従来どおり Amazon EC2 からの起動も選択可能です。

影響範囲・利用シーン ​

  • 対象ユーザー: スタートアップ、SMB、開発者、運用チーム、ライトなインフラを好むエンジニア
  • 利用シーンまたは効果: すばやく定額でソフトウェア搭載サーバを立ち上げたい（CMS、コントロールパネル、DB付のアプリ等）の場面で導入コストと運用負荷を低減できる
  • 運用効果: インスタンス作成が簡略化され、月額定額プランによりコスト予測がしやすくなる。Lightsail のマネージド機能で運用負荷を軽減可能
  • 制限・留意点: すべての Marketplace AMI が対応しているわけではない。Lightsail は EC2 に比べてネットワークやインスタンスタイプのカスタマイズ性が限定されるため、細かい制御が必要なワークロードは EC2 のままの方が適する

技術的な注意点 ​

  • IAM権限: Marketplace のサブスクリプション操作（AWS Marketplace 関連の権限）と Lightsail インスタンス作成（lightsail:CreateInstances 等）に対する権限が必要。組織で利用する場合は権限を事前に確認・付与すること
  • リージョン制限: Lightsail が提供されている全リージョンで「Launch on Lightsail」オプションは利用可能。ただし一部製品はリージョンや Marketplace の要件で利用不可の可能性あり
  • コスト: Lightsail の固定月額バンドル料金に加え、Marketplace ソフトウェアのライセンス料（時間課金または月額課金）が別途発生する場合がある。データ転送の無料枠を超えると追加課金あり
  • 機能差異: Lightsail は EC2 に比べてネットワーク（詳細な VPC 設定や高度なセキュリティグループ制御）、インスタンスタイプの選択幅、細かなインフラ制御が限定される点を考慮すること
  • 移行・互換性: 必要に応じて Lightsail スナップショットやエクスポートを用いて EC2 への移行を検討可能。ただし完全自動の移行では追加手順が必要になる場合がある
  • ライセンス: Windows や商用ソフトウェアの AMI はライセンス費用が含まれる/別請求となる場合があるため、料金表示とサブスクリプション条件を確認すること

参考情報 ​

[General] AWS announces a new Availability Zone in the Europe (London) Region ​

概要 ​

AWSはEurope (London) リージョン (eu-west-2) に4つめのアベイラビリティゾーン (eu-west-2d) を追加しました。新AZは次世代のAI/ML向けキャパシティ（Amazon EC2のTrn3、P6などのアクセラレータや汎用コンピュート）を提供します。

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

追加されたAZ (eu-west-2d) はリージョン内のインフラ容量を拡張し、AI/ML向けのトレーニングおよび推論ワークロードをロンドンリージョン内で完結して実行できるようにします。提供される主なリソースは次のとおりです：Amazon EC2（汎用インスタンス）、Trn3（Trainium 系アクセラレータによるトレーニング向け）、P6（GPUアクセラレータによる高性能推論/学習向け）。既存のAWS Management Console、API、既存ワークフローから変更なくアクセス可能で、標準のリージョンプライシングが適用されます。これによりアプリケーションをeu-west-2の4つのAZに分散でき、フォールトトレランスと高可用性設計が強化されます。開始方法やリージョン/AZの設計、各サービスの地域別提供状況はAWS Global InfrastructureやRegional Product Servicesで確認できます。

影響範囲・利用シーン ​

  • 対象ユーザー: AI/MLチーム、データサイエンティスト、クラウドアーキテクト、SRE/運用チーム
  • 利用シーン: 大規模モデルのトレーニングや低レイテンシ推論をロンドン内のインフラで実行する際のキャパシティ確保
  • 運用効果: AZを4つ利用可能にすることで障害分散が向上し、単一AZ故障時の影響を低減して高可用性を実現
  • アーキテクチャ効果: トレーニング/推論ワークロードを同リージョン内で完結させることでデータレイテンシとクロスリージョン転送コストを削減可能
  • 制約: 新しいAZのリソースは需要によっては一時的に容量制限があるため、必要なインスタンスタイプの確保やクォータ増加申請が必要になる場合がある

技術的な注意点 ​

  • IAM権限: 特段の専用権限は不要（既存のEC2/関連サービス用の権限で利用可能）。ただしクォータ操作や専用ホストの申請などは追加権限が必要
  • リージョン制限: 本対応は Europe (London) リージョン (eu-west-2) のみ。AZ識別子（例: eu-west-2a/b/c/d）はアカウントごとにマッピングが異なる点に注意
  • クォータ/キャパシティ: 新AZでも特定インスタンスの割当上限（vCPUやインスタンスタイプ別上限）が存在するため、必要に応じてService Quotasやサポート経由で引き上げ申請が必要
  • ツール互換性: AWSコンソール/API/CLI/SDKから既存ワークフローの変更なしに利用可能。ただしテンプレートやオートスケーリングのAZ指定を行っている場合はAZ名（アカウント固有）を確認して調整すること
  • コスト: リージョンの標準料金が適用されるが、Trn3/P6など加速インスタンスは汎用インスタンスより高コスト。AZ間のデータ転送やレプリケーションは場合により追加料金が発生するため設計時に確認すること

参考情報 ​

[Lambda] AWS Lambda MicroVMs is now available in 5 additional AWS regions ​

概要 ​

AWS Lambda MicroVMsが5つの追加リージョン（ムンバイ、シンガポール、シドニー、フランクフルト、ストックホルム）で利用可能になりました。これにより、合計10リージョンでVMレベルの分離と高速起動・状態保持を備えたサーバーレス実行環境を使えます。

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

Lambda MicroVMsは、VMレベルの強い分離（ハードウェア仮想化に近い分離境界）と、ほぼ瞬時の起動・再開、実行状態の保持を組み合わせたサーバーレスのコンピューティングプリミティブです。開発者はDockerfileからMicroVMイメージを作成し、そのイメージからMicroVMを起動できます。各ユーザーやジョブごとに専用のMicroVMを割り当てることで、仮想化インフラの管理なしに「分離性・低レイテンシ・状態保持」を両立できます。MicroVMは専用のHTTPS URLを持ち、HTTP/2、gRPC、WebSocketsなどの一般的な接続プロトコルをサポートします。コンソール、AWS CloudFormation、AWS CDK、またはAgent Toolkit for AWSを通じて管理・起動が可能で、AIコーディングアシスタント、対話型開発環境（IDE）、脆弱性スキャナなど、状態を保持しつつ応答性が求められるアプリケーションに適しています。今回の拡張により、ムンバイ（ap-south-1）、シンガポール（ap-southeast-1）、シドニー（ap-southeast-2）、フランクフルト（eu-central-1）、ストックホルム（eu-north-1）でも利用可能になり、エンドユーザーに近いリージョンでの実行によるレイテンシ改善やデータレジデンシ要件への対応が容易になります。価格や最新のリージョン対応状況は、公式のLambda MicroVMsの価格ページとリージョン対応表を確認してください。

影響範囲・利用シーン ​

  • 対象ユーザー: サーバーレス／コンテナ開発者、AIアプリケーション開発者、SRE/運用チーム
  • 利用シーン: AIコーディングアシスタントや対話型IDEなど『状態を持つ・低遅延』が必要なワークロードの実行
  • 運用効果: ユーザー単位やジョブ単位で隔離された環境を簡単に提供でき、低レイテンシ化・データレジデンシ対応がしやすくなる
  • リージョン効果: ムンバイ、シンガポール、シドニー、フランクフルト、ストックホルムで利用可能になり、これら地域のエンドユーザー向けのレイテンシ改善や法規制対応に寄与

技術的な注意点 ​

  • IAM権限: Lambdaの実行やイメージ格納先（例: Amazon ECR）へのアクセスを許可するIAMロール/ポリシーを用意する必要があります
  • リージョン制限: 発表時点で追加された5リージョンを含め合計10リージョンで利用可能。全リージョンで未対応の可能性があるため、導入前に「AWS Capabilities by Region」を確認してください
  • コスト: MicroVMsは通常のLambdaやコンテナとは別の料金体系が適用されるため、事前に「Lambda MicroVMs pricing」を確認し、コスト試算を行ってください（追加料金の発生可能性あり）
  • イメージ作成/互換性: DockerfileからMicroVMイメージを作成するワークフローを使用します。イメージ要件やランタイム制約は開発者ガイドに従ってください（イメージサイズやベースイメージの制約がある場合があります）
  • サービスクォータとスケーリング: 同時MicroVM数や起動レートなどの制限（サービスクォータ）を確認し、必要なら引き上げ申請を行ってください
  • 監視とログ: CloudWatchや既存のログ収集パイプラインでMicroVMのログ・メトリクスを収集できるよう設定してください。状態保持を利用する場合はライフサイクル（起動・終了・再開）の挙動を考慮した設計が必要です

参考情報 ​

[General] Amazon Quick adds deny by default for custom permissions ​

概要 ​

Amazon Quick のカスタム権限に「deny by default（デフォルト拒否）」が追加され、管理者が新しくリリースされるAI機能をユーザーに届く前に自動的にブロックできるガバナンス設定が可能になりました。

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

従来は Amazon Quick の新しい AI 機能はリリース時に自動的にユーザーへ有効になり、管理者はリリース後に対処する必要がありました。今回の「deny by default」はカスタム権限プロファイル内で AI 機能のカテゴリを制限することで、そのプロファイルを割り当てられたユーザー／ロール／アカウントに対して、リリースされた新しい AI 機能を自動的に拒否します。カテゴリを制限すると、そのカテゴリに属する既存の機能も制限されるため、管理者は準備ができた個々の能力を明示的に許可する必要があります。設定は Amazon Quick の「Manage account」画面または AWS CLI から行え、適用範囲は設定したカスタム権限プロファイルに限定されます。この記事によれば、deny by default は Amazon Quick が利用可能なすべての AWS リージョンで利用可能です。

影響範囲・利用シーン ​

  • 対象ユーザー: クラウド管理者、セキュリティ／ガバナンスチーム、SRE、アプリ開発チーム
  • 利用シーンまたは効果: 新機能が自動でユーザーに展開されることを防ぎ、事前評価・社内承認・コンプライアンスチェックを経てから個別に有効化する運用（例: 機能リスク評価、段階的ロールアウト、業界規制対応）に有効
  • 運用効果: 新リリースによる想定外の挙動やコンプライアンスリスクを低減し、リリース後の緊急対応を削減。ただし、管理者側で機能ごとの明示的許可が必要になるためプロファイル管理や許可ワークフローの運用コストが増える可能性がある

技術的な注意点 ​

  • IAM権限: カスタム権限プロファイルを作成／編集／割当するための Quick 管理権限が必要です。事前に管理者アカウントや該当ロールの権限を確認してください。
  • リージョン制限: 記事によれば、deny by default は Amazon Quick が利用可能なすべてのリージョンで利用可能です（Quick 非対応リージョンでは当然未対応）。
  • コスト: 公表された内容では deny by default の適用に伴う追加料金は案内されていません。ただし運用体制変更による人的コストが発生する点は考慮してください。
  • 適用範囲: 制限は設定したカスタム権限プロファイル単位で適用されます。アカウント全体のグローバル設定ではないため、複数プロファイル運用時は割り当て状況を確認してください。
  • 既存機能への影響: カテゴリを制限すると、そのカテゴリに属する既存の AI 機能も同時にブロックされます。事前に影響範囲を把握してから適用してください。
  • 監査: 権限変更やプロファイル割当は監査対象となるため、CloudTrail 等で管理操作のログ取得や変更履歴の確認を推奨します。

参考情報 ​

[Appstream 2 0] Amazon WorkSpaces Applications now offers in-console monitoring capabilities ​

概要 ​

Amazon WorkSpaces Applications コンソールにネイティブな監視機能が追加され、サードパーティや複雑な CloudWatch ダッシュボードを構築せずに、セッション単位／インスタンス単位のリアルタイム指標を確認できるようになりました。全リージョン（サービス提供リージョン）で利用可能です。

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

コンソール内監視はゼロコンフィグで有効化され、以下を提供します。リアルタイムのセッションレベル指標（フレームレート、入力レイテンシ、帯域幅など）やインスタンスレベルのリソース使用率（CPU／メモリ／GPU）、ネットワーク性能を参照可能です。フリート全体のキャパシティ表示（アクティブセッション数、リソース利用率）や、ユーザーID／インスタンスID／パフォーマンス指標でフィルタ可能なセッションテーブル、複数指標を同一タイムライン上で相関表示するグラフビューを備えます。加えて、これらのメトリクスは Amazon CloudWatch にも出力されるため、必要に応じて CloudWatch でのアラーム設定やカスタムダッシュボード作成が可能です。外部監視ツールや CloudWatch の専門知識がなくても即時に監視を始められる点が特徴です。

影響範囲・利用シーン ​

  • 対象ユーザー: WorkSpaces Applications を運用・監視する管理者、SRE、デスクトップ仮想化の運用チーム
  • 利用シーン: フリートのキャパシティ管理、ユーザーセッションのパフォーマンス解析（遅延・フレームドロップ原因の切り分け）、リソース不足時のトラブルシューティング
  • 運用効果: 外部ツールや複雑な CloudWatch ダッシュボードを構築する手間を削減し、リアルタイムで問題を検知して対応速度を向上させることが可能

技術的な注意点 ​

  • IAM権限: コンソールで監視を行うには WorkSpaces Applications の閲覧権限が必要です。CloudWatch のメトリクスを確認／利用する場合は CloudWatch の読み取り権限（例: cloudwatch:GetMetricData など）も必要になります
  • リージョン制限: Amazon WorkSpaces Applications が提供されている全ての AWS リージョンで利用可能と明記されています（ただし、利用前に対象リージョンでサービスが有効か確認してください）
  • コスト: コンソール内での可視化自体はゼロコンフィグで提供されますが、CloudWatch に出力されたメトリクスを長期保存したり、GetMetricData やアラームを多用すると CloudWatch の標準料金が発生する可能性があります
  • メトリクス連携: すべての表示指標は CloudWatch にもエクスポートされるため、既存の監視フロー（アラーム、ダッシュボード、外部SIEM/監視ツール連携）は CloudWatch 側で設定可能です
  • 前提条件: 該当フリートおよびセッションが存在していること、監視はコンソールの「fleets」メニューから対象フリートを選択して開始します
  • 注意点: 公開情報ではメトリクスの保持期間やサンプリング間隔の詳細は明記されていません。厳密な要件がある場合はドキュメントまたはサポートで確認してください

参考情報 ​

[Identity And Access Management] AWS IAM now supports 20 managed policies per role by default ​

概要 ​

AWS IAMのロールにアタッチできるマネージドポリシーのデフォルト上限が、従来の10個から20個に引き上げらりました。これにより、用途別ポリシー分割やパートナー製品導入時の追加ポリシー添付でService Quotas申請が不要になるケースが増えます。

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

変更点: IAMロールあたりにアタッチできるマネージドポリシーのデフォルト上限が10→20に増加しました。適用範囲: すべての商用リージョン、AWS GovCloud (US)、Chinaリージョンで自動適用され、アカウント内の既存ロールへ追加の操作は不要です。追加上限: さらに必要な場合はService Quotasを通じて最大25まで引き上げをリクエストできます。考慮事項: この変更は「アタッチされるマネージドポリシー数」に対する上限の変更であり、インラインポリシー数やポリシー本文サイズ、その他のIAM/ST Sの個別クォータ（例: 同時セッション、ポリシーサイズ制限など）には影響しません。運用上は、用途別にポリシーを分割するベストプラクティス（最小権限の実現や再利用性向上）を継続して推奨します。詳細はIAMおよびAWS STSのクォータページを参照してください。

影響範囲・利用シーン ​

  • 対象ユーザー: クラウドエンジニア、IAM管理者、SRE、セキュリティチーム、AWSパートナー製品を導入するチーム
  • 利用シーン: ポリシーを目的別に細かく分割してロールに適用する運用、サードパーティ／パートナー製品が要求する複数のマネージドポリシーをロールに添付する場面
  • 運用効果: Service Quotas申請の頻度低下による運用工数削減と、より細かなポリシー分割による最小権限の実現が容易になる

技術的な注意点 ​

  • IAM権限: ロールのポリシー添付や確認には通常のIAM管理権限が必要です。Service Quotasで上限引き上げを申請する際は servicequotas:RequestServiceQuotaIncrease 等の権限が必要になる可能性があります。
  • リージョン制限: 変更はすべての商用リージョン、AWS GovCloud (US)、Chinaリージョンにて自動適用されます。特定リージョンでの未対応情報はありません。
  • コスト: デフォルト上限の引き上げ自体に直接の追加料金は発生しません。Service Quotasへの申請自体も通常は無償ですが、審査やサポート対応が必要な場合は別途サポート契約が影響する可能性があります。
  • その他の関連クォータ: この変更は「ロールあたりのマネージドポリシー数」にのみ影響します。インラインポリシー、ポリシーサイズ、アカウント全体のマネージドポリシー数、STS関連のクォータなどは別途制限があるため、実施前にIAMクォータ一覧を確認してください。
  • 運用上の注意: ポリシー数が増えると管理複雑性が上がるため、ポリシー命名規則・ドキュメント化・自動化（Infrastructure as Code）を併用して管理することを推奨します。

参考情報 ​

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

Copyright © 2026