AWS What's New Digest

Appearance

2026年02月07日 ​

[Workspaces] Amazon WorkSpaces Secure Browser now supports custom domain ​

概要 ​

Amazon WorkSpaces Secure Browserがポータルにカスタムドメインを設定できるようになりました。組織のブランドに合わせた独自ドメインでSecure Browserポータルへアクセスさせることで、ユーザー体験を統一できます。

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

管理者はWorkSpaces Secure Browserポータルにカスタムドメインを追加し、リバースプロキシ（例: Amazon CloudFront）を設定してポータルエンドポイントへトラフィックをルーティングします。認証・認可後、WorkSpaces Secure Browserは自動的にユーザーを設定したカスタムドメインにリダイレクトします。認証はAWS Identity Centerまたは外部IdPが利用可能で、IdP発行フロー（IdP-initiated）およびサービスプロバイダー発行フロー（SP-initiated）の両方をサポートします。本機能自体に追加料金は不要で、WorkSpaces Secure Browserは従量課金（pay-as-you-go）モデルです。現時点で使用可能なリージョンは10リージョン（US East (N. Virginia), US West (Oregon), Canada (Central), Europe (Frankfurt, London, Ireland), Asia Pacific (Tokyo, Mumbai, Sydney, Singapore)）です。セットアップはSecure Browserコンソールからカスタムドメインを登録し、DNSやTLS証明書、リバースプロキシ設定を行うことで開始できます。

影響範囲・利用シーン ​

  • 対象ユーザー: セキュアブラウザを利用するエンドユーザー、クラウド/セキュリティ管理者、SRE/ネットワーク運用チーム
  • 利用シーン: 企業ブランドに合わせたポータル公開、社内シングルサインオン（SSO）統合、外部IdPと連携したブラウザセッションの提供
  • 運用効果: ユーザー体験の一貫化（ドメイン名による信頼感向上）、既存の認証基盤の再利用、リバースプロキシでのトラフィック制御によりセキュリティポリシーやコンテンツ配信最適化が可能

技術的な注意点 ​

  • IAM権限: カスタムドメインの登録やSecure Browserの設定変更は適切なWorkSpaces/管理コンソール権限が必要です。事前に役割と権限を確認してください。
  • リバースプロキシ: CloudFrontなどのリバースプロキシを用いてポータルエンドポイントへルーティングする必要があります。プロキシ側でHostヘッダーや必要なヘッダーを適切に転送する設定を行ってください。
  • TLS/証明書: カスタムドメイン向けの有効なTLS証明書を用意し（ACM等で管理可）、リバースプロキシに適用してください。証明書の更新運用を設計してください。
  • DNS: カスタムドメインのDNSはリバースプロキシ（例: CloudFront）へのCNAME/エイリアスを指すように設定します。
  • 認証フロー: AWS Identity Centerおよび外部IdP（SAML/OIDC等）をサポートします。IdP-initiated/ SP-initiatedの両方に対応していますが、IdP側のリダイレクト設定やAudience/Assertionの整合性を確認してください。
  • リージョン制限: 本機能は公開された10リージョンで利用可能です。利用予定リージョンが未対応の場合は利用できません。
  • コスト: カスタムドメイン機能自体に追加料金はありませんが、CloudFrontや他のリバースプロキシ、証明書管理（ACM）などのサービス利用に伴う料金が発生します。
  • 運用上の注意: リダイレクトやセッション管理の挙動、ヘッダー／Cookieの取り扱いによっては正しく認可されないケースがあるため、テスト環境で動作確認を行ってから本番適用してください。

参考情報 ​

[ECS] Amazon ECS Managed Instances now available in AWS European Sovereign Cloud ​

概要 ​

Amazon ECS Managed Instances（ECS MI）がAWS European Sovereign Cloudで利用可能になりました。ECS MIはEC2ベースの完全マネージドなコンピュートオプションで、インフラ運用をAWSに委任しつつEC2のフル機能を利用できます。

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

ECS Managed Instancesは、タスク要件（vCPU数、メモリ、CPUアーキテクチャなど）を指定すると、AWSが最適なEC2インスタンスをお客様のアカウント内にプロビジョニング、構成、運用する機能です。特徴としては、ワークロードに合わせた動的スケーリング、タスク配置の継続的最適化によるインフラコスト削減、そして14日ごとの定期的なセキュリティパッチ適用があります。Managed InstancesのCapacity Provider構成では、GPUアクセラレーション、ネットワーク最適化、バースタブル性能といった望むインスタンスタイプを指定可能です。導入はAWSコンソール、Amazon ECS MCP Server、または既存のインフラストラクチャー・アズ・コード（IaC）ツールを通じて、新規または既存のECSクラスターで有効化できます。利用料は通常のAmazon EC2コストに加え、Managed Instancesの管理料金が発生します。今回のリリースにより、この機能がEU向けの主権（Sovereign）クラウド領域でも利用できるようになり、EUのデータ主権要件を持つ組織でも採用しやすくなっています。

影響範囲・利用シーン ​

  • 対象ユーザー: コンテナプラットフォーム管理者、SRE、クラウド基盤チーム、EU域内のパブリックセクターや規制業界のユーザー
  • 利用シーン: EC2での最適なインスタンスタイプ選定とスケーリングをAWSに委任したいワークロード（バッチ処理、機械学習推論、ネットワーク集約型アプリ、可変負荷のサービス）
  • 運用効果: インスタンス管理やパッチ適用の手間を削減し、タスク配置の最適化でインフラコストを低減可能
  • コンプライアンス効果: AWS European Sovereign Cloud対応により、EU内のデータ主権や規制要件を満たすケースでの利用が容易に
  • コスト影響: EC2利用料に加えManaged Instancesの管理料金が発生するため、コスト構造が変化。最適化効果と管理料金のトレードオフ検討が必要

技術的な注意点 ​

  • IAM権限: Managed Instancesを有効化・管理するための権限が必要。AWSがインスタンスをプロビジョニングするためのアクセスモデルを事前に確認すること
  • リージョン制限: 本リリースはAWS European Sovereign Cloudでの提供。全リージョンで利用可能という訳ではないため、対応するソブリンリージョンを確認してください
  • コスト: 通常のAmazon EC2料金に加え、Managed Instancesの管理料金が別途発生します。コスト見積もりはワークロードのスケーリング特性を基に実施してください
  • セキュリティ/アクセス: AWSが定期的にインスタンスのパッチ適用と運用を行うため、運用上のアクセスモデルと監査要件（ログ・証跡）を確認すること
  • 既存クラスター対応: 新規・既存のECSクラスターに対して有効化可能。ただし有効化手順や既存のCapacity Provider設定との互換性を事前に検証してください
  • パッチ頻度: セキュリティパッチは14日ごとに適用されるため、パッチ適用ウィンドウや再起動ポリシーがワークロードに与える影響を評価してください
  • モニタリング/可視化: EC2インスタンスはお客様のアカウントに存在するため、CloudWatchやログ収集の設定で可視化とアラートを適切に構築してください

参考情報 ​

[Bedrock] Amazon Bedrock AgentCore Browser now supports browser profiles ​

概要 ​

Amazon Bedrock AgentCore Browserがブラウザプロファイルをサポートしました。認証状態（CookieやlocalStorageなど）をプロファイルとして永続化・再利用でき、繰り返しログインすることなく複数の自動ブラウザセッションを高速に開始できます。

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

ブラウザプロファイル機能は、ブラウザの認証状態（Cookie、localStorage等）を保存して複数セッションで再利用する機能です。ユーザーは1回サイトへ認証すればそのセッションをプロファイルとして保存でき、新しいセッション開始時にそのプロファイルを指定すると認証状態が復元されログイン済みのまま処理が可能になります。モードは読み取り専用（read-only）や永続（persistent）など柔軟に選択でき、同一プロファイルを複数セッションで並列利用することも可能です。これにより、エンタープライズ環境で数百〜数千の自動ブラウザセッションを日次で処理する際のセッションセットアップ時間を「数分」から「数十秒」へ短縮できます。本機能はAmazon Bedrock AgentCore Browserが提供される14リージョン（US East (N. Virginia)、US East (Ohio)、US West (Oregon)、Asia Pacific (Mumbai)、Asia Pacific (Singapore)、Asia Pacific (Sydney)、Asia Pacific (Tokyo)、Europe (Frankfurt)、Europe (Ireland)、Europe (London)、Europe (Paris)、Europe (Stockholm)、Asia Pacific (Seoul)、Canada (Central)）で利用可能です。

影響範囲・利用シーン ​

  • 対象ユーザー: 自動化エージェントを使って認証が必要なウェブサイトを巡回・操作する開発者、SRE、データ取得/スクレイピングチーム
  • 利用シーン: 認証済みページのデータ収集、フォーム操作、定期レポート作成、テスト自動化、SaaSのセルフサービス操作をエージェントで自動化する場面
  • 運用効果: セッション確立時間が大幅に短縮されるためスループット向上・コスト効率改善（同じ処理量をより短時間で実行可能）
  • 並列処理への影響: 同一プロファイルを複数セッションで並列利用できるためスケールアップが容易。ただし対象サイト側の同時セッション制限やセッション取り扱い（IP/UAの突合せ等）に注意が必要
  • セキュリティ/コンプライアンス: 認証情報が含まれるプロファイルを扱うため取り扱い・保管ポリシーの整備、アクセス制御、ログ管理が必要

技術的な注意点 ​

  • IAM権限: AgentCoreの実行に必要なBedrock/AgentCore関連の権限を事前に確認・最小権限で設定してください（具体的なポリシーはドキュメント参照）
  • リージョン制限: 本機能は記事記載の14リージョンで利用可能です。東京リージョン（Asia Pacific (Tokyo)）含むが、それ以外のリージョンでは未対応の可能性があります
  • コスト: 記事ではプロファイル自体の追加料金は言及されていませんが、AgentCoreの実行（コンテナ/インスタンス/呼び出し回数）やストレージに関する通常のコストは発生します。大規模並列実行を行う場合は実行リソースコストが増加する点に注意してください
  • セキュリティ注意点: プロファイルには認証状態（Cookie等）が含まれるため機密データ扱いです。保存場所・転送経路の暗号化、アクセス制御、プロファイルの寿命管理（有効期限や回転）を実装してください
  • 互換性/制約: 一部のサイトは多要素認証、デバイス紐付け、IP固着、短命トークン等を使っており、プロファイルを復元しても自動的に常時ログインできない場合があります。SSOやMFAが絡むフローは追加の設計が必要です
  • 同時使用のリスク: 同一プロファイルを複数セッションで同時に使うと、サイト側のセッション管理により予期せぬログアウトやセッション競合が発生する可能性があります。並列利用時は事前に対象サイトの挙動を検証してください

参考情報 ​

[Config] AWS Config now supports 30 new resource types ​

概要 ​

AWS Configが30種類の新しいAWSリソースタイプをサポートしました。Amazon EKS、Amazon Q、AWS IoTなどを含むこれらのリソースは、記録設定が「すべてのリソースタイプ」を有効にしている場合は自動的に追跡され、Configルールやアグリゲータでも利用可能です。

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

今回追加されたのは、CloudFormation リソースタイプ名で表現される30のリソースタイプ（例：AWS::EKS::Nodegroup、AWS::QuickSight::DataSet、AWS::Glue::Crawler、AWS::IoT::TopicRule、AWS::Route53::DNSSEC、AWS::SSM::PatchBaseline など）です。主なポイント:

  • 記録設定が「すべてのリソースタイプ」を有効化しているアカウントでは、これら新規タイプは自動的に追跡されます。個別タイプのみを記録している場合は、Configuration Recorderの設定を更新して対象に追加する必要があります。
  • 追加されたリソースタイプは、Config Rules（準拠性チェック）やAggregators（複数アカウント／リージョン集約）でも利用可能になり、監査や自動修復ワークフローに組み込めます。
  • 監視は「該当リソースが利用可能なAWSリージョン」で有効です。リージョンでそのサービス／リソースが提供されていない場合は追跡対象外になります。
  • 新しいタイプの監視により、構成変更履歴の収集、監査ログ、ルール評価、スナップショットやS3への配信、Aggregatorによる横断的可視化が可能になります。

影響範囲・利用シーン ​

  • 対象ユーザー: クラウド運用者、セキュリティ／コンプライアンス担当、SRE、クラウドアーキテクト
  • 利用シーン: EKSノードグループやIoTリソース、QuickSightやGlueなど多様なサービス構成の変更履歴監査、Configルールによる準拠性評価、複数アカウント横断の構成可視化
  • 運用効果: 監査カバレッジの拡大により、不正な変更や設定の逸脱をより広範囲に検出できる。Configルール／Aggregatorとの連携で自動検出・集約・自動修復の仕組みを構築しやすくなる

技術的な注意点 ​

  • IAM権限: Configの設定変更（例: config:PutConfigurationRecorder, config:StartConfigurationRecorder, config:PutDeliveryChannel）やリソース表示（config:GetResourceConfig等）に必要な権限を確認・付与してください。Aggregatorやルール管理には追加権限が必要です。
  • サービスリンクロール: AWS Configのサービスリンクロール（例: AWSConfigRole）が正しく設定されていることを確認してください。追加のサービス固有の役割や許可が必要になる場合があります。
  • リージョン制限: 新規リソースは「そのリソースが利用可能なリージョン」でのみ監視されます。リージョンごとのサービス提供状況に注意してください。
  • 記録設定: 「すべてのリソースタイプ」を有効にしている場合は自動的に追跡されますが、個別指定で記録している環境ではConfiguration Recorderの記録対象にこれらタイプを追加する必要があります。
  • Configルール／アグリゲータ: 新しいリソースタイプはルール評価およびアグリゲータで利用可能ですが、既存のカスタムルールやマネージドルールで対応が必要な場合は、ルール定義の更新を検討してください。
  • コスト: 監視対象リソース数の増加に伴い、AWS Configの課金（記録対象リソース数、ルール評価、Aggregatorの使用、S3への配信等）に影響する可能性があります。コスト見積りを再確認してください。

参考情報 ​

AI要約はOpenAI GPT-5-miniによって生成されています。

Copyright © 2026