AWS News - 2026-08-20

Amazon WorkSpaces Applications now offers a native monitoring experience embedded directly in the service console. Administrators can now access real-time session-level metrics, instance-level resource data, and network performance metrics without requiring third-party monitoring tools or Amazon CloudWatch expertise.

Previously, enterprise customers managing large WorkSpaces Applications deployments relied on external solutions or built complex custom CloudWatch dashboards. Now, comprehensive monitoring is available with zero configuration required. The WorkSpaces Applications in-console monitoring provides fleet-level capacity visibility showing active sessions and resource utilization, customizable session tables with filtering by user ID, performance metrics, and instance ID, and correlated graphical views displaying session metrics such as frame rate, input latency, bandwidth, and CPU/memory/GPU usage on shared timelines. All these metrics are also available in Amazon CloudWatch giving customers the flexibility to pick the right experience for monitoring their WorkSpaces Applications resources.

This functionality is available today in all AWS Regions where Amazon WorkSpaces Applications is offered.

To learn more, visit the Amazon WorkSpaces Applications documentation OR log on to Amazon WorkSpaces Applications Console, navigate to the fleets menu, and select a fleet to monitor the active session metrics. 

AWS Identity and Access Management (IAM) has increased the default quota for managed policies per role from 10 to 20.

This higher default quota reduces the need to make Service Quota requests when following IAM best practices like separating permissions into purpose-specific policies or when onboarding to AWS Partner products that require attaching additional managed policies. If you need more than 20 managed policies per role, you can request a quota increase up to 25 using Service Quotas.

This change is available in all commercial AWS Regions, AWS GovCloud (US) and China Regions and applies automatically to all IAM roles in your account with no action required. To learn more, see IAM and AWS STS quotas in the IAM User Guide.

Amazon Quick custom permissions now include deny by default, a governance setting that automatically restricts new AI capabilities before they reach users.

Previously, new AI capabilities were available to all users on release, requiring administrators to react after the fact. With deny by default, administrators restrict the AI capability category in a custom permissions profile and assign it to users, roles, or the entire account. Quick then denies any new AI capability at launch for those users. Restricting a category also restricts existing capabilities in it. Administrators explicitly allow each capability when ready. The restriction applies only to the profile you configure.

Configure deny by default in Manage account in Amazon Quick or through the AWS CLI. To learn more, see Custom permissions deny by default. Deny by default is available in all AWS Regions where Amazon Quick is available.

AWS has added a fourth Availability Zone to the Europe (London) Region (eu-west-2), expanding infrastructure capacity to meet growing demand for cloud compute in the Region. The new Availability Zone delivers next-generation AI and ML capacity, including Amazon EC2, Trn3, and P6 accelerated instances, alongside general-purpose compute. The new Availability Zone gives AWS customers in eu-west-2 greater capacity for AI and ML workloads and additional fault isolation for building highly available, resilient architectures.

With this new Availability Zone (eu-west-2d), customers can distribute applications across four Availability Zones in eu-west-2, improving fault tolerance and supporting high availability architectures. AI and ML teams can now run model training and inference workloads on the latest accelerated instance types entirely within the London Region. The new Availability Zone is accessible through the AWS Management Console, APIs, and existing workflows with no changes to tooling. Standard Europe (London) Region pricing applies.

To get started, visit AWS Global Infrastructure to learn more about Regions, Availability Zones, and how efficient data center designs and sustainability practices power AWS cloud infrastructure. Explore the AWS Builder Center for hands-on resources, the EC2 Trainium page for AI and ML workloads, and Regional Product Services for a full list of services available by Region.

AWS has added a fourth Availability Zone to the Europe (London) Region (eu-west-2), expanding infrastructure capacity to meet growing demand for cloud compute in the Region. The new Availability Zone delivers next-generation AI and ML capacity, including Amazon EC2, Trn3, and P6 accelerated instances, alongside general-purpose compute. The new Availability Zone gives AWS customers in eu-west-2 greater capacity for AI and ML workloads and additional fault isolation for building highly available, resilient architectures.

With this new Availability Zone (eu-west-2d), customers can distribute applications across four Availability Zones in eu-west-2, improving fault tolerance and supporting high availability architectures. AI and ML teams can now run model training and inference workloads on the latest accelerated instance types entirely within the London Region. The new Availability Zone is accessible through the AWS Management Console, APIs, and existing workflows with no changes to tooling. Standard Europe (London) Region pricing applies.

To get started, visit AWS Global Infrastructure to learn more about Regions, Availability Zones, and how efficient data center designs and sustainability practices power AWS cloud infrastructure. Explore the AWS Builder Center for hands-on resources, the EC2 Trainium page for AI and ML workloads, and Regional Product Services for a full list of services available by Region.

Today, AWS Marketplace announces support for launching select Amazon Machine Images (AMIs) on Amazon Lightsail. Customers who want simple, predictable pricing and a streamlined instance-creation experience can now easily deploy eligible AWS Marketplace AMIs on Amazon Lightsail in just a few clicks. Lightsail instance bundles include compute, storage, and a generous data transfer allowance at a fixed monthly price. Lightsail also offers managed databases, containers, load balancers, and more, making it easy for customers to scale their applications as they grow.

When subscribing to a supported AWS Marketplace product - including Microsoft Windows Server, Microsoft SQL Server Express, Ubuntu, cPanel & WHM, and Plesk - customers will now have the option to select Amazon Lightsail in addition to Amazon EC2. Selecting Lightsail takes customers to the Lightsail console with the selected AMI and region pre-configured, providing a path to deploy at a predictable monthly price in just a few clicks.

The "Launch on Lightsail" deployment option is available for eligible products in all AWS Regions where Lightsail is available. To get started, visit AWS Marketplace and subscribe to a compatible product. For more information about Amazon Lightsail, visit the Amazon Lightsail product page.

Starting today, customers can use Amazon OpenSearch Ingestion in AWS GovCloud (US-East) and AWS GovCloud (US-West), for ingesting data into their Amazon OpenSearch Service managed clusters or serverless collections.

Amazon OpenSearch Ingestion is a fully managed data ingestion tier that allows you to ingest and process data before indexing it in Amazon OpenSearch managed clusters or serverless collections. Amazon OpenSearch Ingestion provides a no-code experience to filter, transform, redact, and route data into Amazon OpenSearch Service. Amazon OpenSearch Ingestion automatically provisions and scales the underlying resources to meet the fluctuating demands of your workloads.

With this launch, Amazon OpenSearch Ingestion is now generally available in 19 AWS regions: US East (Ohio), US East (N. Virginia), US West (Oregon), US West (N. California), Europe (Ireland), Europe (London), Europe (Frankfurt), Europe (Spain), Europe (Paris), Asia Pacific (Tokyo), Asia Pacific (Sydney), Asia Pacific (Singapore), Asia Pacific (Mumbai), Asia Pacific (Seoul), Canada (Central), South America (Sao Paulo), Europe (Stockholm), GovCloud (US-East) and GovCloud (US-West).

To learn more, see the Amazon OpenSearch Ingestion webpage and the Amazon OpenSearch Ingestion Developer Guide.

AWS Cost Anomaly Detection now monitors spend on third-party foundation models running on Amazon Bedrock, such as Anthropic Claude and other provider-hosted models. Cost Anomaly Detection uses machine learning to detect and alert on unusual spend, and this launch extends that coverage to third-party model usage on Amazon Bedrock. Teams running production generative AI workloads now get automatic anomaly detection on their Amazon Bedrock model spend alongside the rest of their AWS costs.

With this launch, Cost Anomaly Detection automatically evaluates your third-party Amazon Bedrock model costs through your AWS managed service monitor, with no setup required. When spend on a model changes unexpectedly, you receive an alert and a root-cause breakdown ranked by dollar impact across AWS service, account, Region, and usage type, so you can understand and act on generative AI cost changes as quickly as you do for any other AWS spend.

This feature is available in all AWS commercial regions, except the AWS GovCloud and the China Regions.

To learn more, see Detecting unusual spend with AWS Cost Anomaly Detection in the AWS Billing and Cost Management User Guide.

AWS Elemental MediaConnect Router now enables customers to configure latency settings, providing control over the internal connection latency between inputs and outputs within the router. Previously, the protocol latency inside the router was set automatically by the service and could not be adjusted.

MediaConnect Router now offers two latency configuration options on router outputs: balanced mode and low-latency mode. The balanced mode maintains the existing behavior for general use cases, while the low-latency mode optimizes the internal connection recovery time for latency-sensitive workflows. The appropriate mode is configured per router output, allowing the same input to feed multiple outputs with different latency requirements. A new CloudWatch metric, RouteFabricRecoveryLatency, provides visibility into the configured recovery latency for each route.

Customers can configure and view the latency setting using the MediaConnect API or AWS Management Console and AWS CLI.

Configurable recovery latency is available in all regions where MediaConnect Router is currently deployed. To learn more about latency modes, visit the AWS Elemental MediaConnect documentation.

AWS Security Agent (now part of AWS Continuum) has a on-demand penetration testing service that uses an AI agent to autonomously test web applications for vulnerabilities, billing based on cumulative task hours consumed across parallel testing tasks. Security teams and DevSecOps engineers previously had no built-in way to cap test costs or efficiently confirm that a remediated vulnerability had been resolved. These two new capabilities address these use cases. 

You can now set a maximum task-hours limit on any penetration test, choosing a preset value (for example, 20 or 30 hours), a custom value, or no limit at all. When the limit is reached, the test stops gracefully and preserves all findings discovered up to that point and because billing reflects only task hours actually used, a higher limit does not increase cost unless the test requires that additional time. You can also revalidate individual findings after deploying a fix, without re-running a full penetration test. Select one or more findings from a completed run and AWS Security Agent re-tests only those specific findings against your live application, returning a clear Active (still exploitable) or Resolved (fix confirmed) status with full revalidation history linked to the original finding.

To learn more about revalidating findings, visit the AWS Security Agent Revalidation documentation. To learn more about setting a maximum task-hours limit, visit the AWS Security Agent Penetration Test documentation.

Amazon CloudWatch pipelines now includes three new processors that parse and enrich log data as it's ingested: an Amazon RDS log parser, an XML parser and a GeoIP enrichment processor. CloudWatch pipelines is a fully managed service that ingests, transforms, and routes telemetry to CloudWatch without managing infrastructure.

Log sources often produce data that isn't immediately queryable without reprocessing the data. RDS Aurora logs arrive in their native engine format, application logs carry embedded XML, and IP addresses lack location context. The new processors address each case. The Amazon RDS processor parses Aurora audit and error logs into structured fields, the XML parser converts a field containing an XML string into JSON, and the GeoIP processor enriches any IP address field with geographic context such as city, country, and coordinates. For example, you can parse an Aurora audit log into structured fields for compliance reporting. In a separate pipeline, you can extract the XML payload from a Windows Event Log into JSON and resolve its source IP to a city and country for security analysis. You can use these processors independently or combine them in one pipeline.

These processors are available at no additional cost in all AWS Regions where CloudWatch pipelines is generally available. CloudWatch logs ingestion and storage rates apply. You can add these processors to your pipelines using the AWS Management Console, AWS CLI, or AWS SDKs. To get started, see the Amazon CloudWatch pipelines documentation.

Amazon SageMaker Notebooks now support Trusted Identity Propagation (TIP) with Amazon Athena, Amazon Redshift, and Amazon EMR Serverless, enabling per-user access control for data analytics.

When connected to a TIP-enabled compute in a TIP-enabled Project, each notebook user's IAM Identity Center identity flows through to AWS Lake Formation, ensuring they see only the tables, columns, and rows their permissions allow, without sharing a single broad execution role. With TIP, enterprises get per-user data boundaries enforced based on who is running the query, full audit attribution with CloudTrail recording which user accessed data, and reduced admin friction since identity propagates automatically through the existing compute connection with no extra login, token, or role management required.

To get started, use a notebook in a TIP enabled Project with the supported engines.  This feature is available in all AWS Regions where Amazon SageMaker Unified Studio is available. To learn more, see Trusted identity propagation in the Amazon SageMaker Unified Studio Administrator Guide and Notebooks in the Amazon SageMaker Unified Studio User Guide.

Amazon DynamoDB Streams now supports attribute-based access control (ABAC), enabling you to use tag-based conditions in your Identity and Access Management (IAM) policies to control access to your data streams. ABAC is an authorization strategy that simplifies access management by allowing you to enforce different access levels for multiple teams and applications using fewer IAM policies. This capability is built for teams that manage DynamoDB Streams access across multiple applications and environments and need finer-grained, scalable access control.

With ABAC for DynamoDB Streams, you can attach up to 50 tags to each stream and use these tags in IAM policy conditions to grant or deny access to specific actions. For example, you can allow users to read records only from streams tagged with "environment:production" while restricting access to other environments. Stream tags are managed independently from their parent table tags, giving you flexibility to implement environment segregation, team-based isolation, and compliance requirements without creating numerous individual IAM policies.

ABAC for DynamoDB Streams is in all commercial AWS Regions and AWS GovCloud (US) Regions where Amazon DynamoDB Streams is available. There is no additional cost to use ABAC for DynamoDB Streams. To learn more, visit the Amazon DynamoDB page and see the Amazon DynamoDB Streams ABAC.

Amazon CloudWatch Centralization now copies log group tags from source accounts to the destination log groups created by centralization rules. CloudWatch Centralization aggregates log data from multiple accounts and Regions into one destination account. With tag propagation, the cost, ownership, and compliance tags you maintain at the source now apply to the copied log groups.

With today's launch, CloudWatch copies the tags of each source log group to its destination log group and keeps them in sync based on the tag propogation behaviour selected as part of the centralization rule setup. For example, a platform team can preserve Application and CostCenter tags on centralized log groups, then use those tags to scope access with IAM conditions and report centralized log spend by team in AWS Cost Explorer.

Tag propagation is available in all AWS Regions where CloudWatch Centralization is available. For a list of Regions, see the AWS Regions table.

To get started, turn on tag propagation for a centralization rule in the Amazon CloudWatch console, or by using the AWS CLI or AWS SDKs. To learn more about centralizing logs while preserving their tags, see Log Centralization User Guide. For Centralization pricing, see Amazon CloudWatch pricing.

Amazon EC2 now supports creating Amazon Machine Images (AMIs) with local snapshots from instances running on AWS Outposts. This capability makes it easier for customers to create AMIs while storing snapshots directly on the Outpost to meet data residency requirements.

Customers can now create AMIs with snapshots stored either on the Outpost itself or in the parent AWS Region. When keeping data local, EC2 automatically determines the target Outpost from the instance's location — no need to manually specify an Outpost ARN. This also enables customers to integrate AMI creation into their existing backup and lifecycle workflows for instances on Outposts while ensuring data residency requirements are met.

This feature is available in all AWS Regions in which AWS Outposts supports local snapshot storage. To learn more, visit the documentation.

Web Search in Amazon Bedrock AgentCore now supports domain filtering and published-date filtering, giving agents per-request control over which web sources and time windows they search. Amazon Bedrock AgentCore provides the infrastructure to build, connect, and optimize AI agents, and Web Search enables those agents to ground responses in current web data.

With runtime domain filtering, agents can narrow search results to trusted sources or block unwanted domains on a per-call basis without requiring admin reconfiguration. Published-date filtering allows agents to constrain results to a specific time window using inclusive from and to date bounds, ensuring responses reflect only timely, relevant content.

With this launch, agents can pass include and exclude domain lists and a published-date range directly in each tool call, while admins gain new gateway-level allowlist support and an increased domain cap of up to 100 domains per list. These capabilities are ideal for regulated industries, research workflows, and applications that require strict control over information sources and recency.

The Web Search Tool is also expanding to Europe (Ireland) (eu-west-1) and Asia Pacific (Tokyo) (ap-northeast-1), joining the existing US East (N. Virginia) (us-east-1) availability. To learn more, read the technical blog about domain and published date filters , and review the Amazon Bedrock AgentCore product documentation.

Earlier this month, we announced Web Search on Amazon Bedrock, a built-in server-side tool that allows you to ground model responses with current web knowledge, while maintaining data within your secured AWS environment with zero data egress. Today, we are expanding Web Search to enable the external_web_access parameter allowing Web Search to retrieve content directly from the public web so models can ground responses in the latest information.

To enable external_web_access, grant the bedrock-websearch:ExternalWebAccess IAM permission to the request identity and leave the external_web_access parameter at its default of true.  In doing so, Web Search can then fetch content live from the public web for use cases that need the freshest possible information, such as latest sports score, live pricing, or newly released documentation. If handling sensitive data, to keep retrieval entirely within your AWS boundary, set external_web_access: false. By setting it false, Web Search serves results only from Amazon's in-AWS web index and knowledge graph, with no request data leaving the AWS boundary.  

Enabling External Web Access is available in the following AWS Regions: US East (N. Virginia), US East (Ohio), and US West (Oregon). To learn more, read our blog post Introducing Web Search on Amazon Bedrock for foundation model grounding, review Controlling external web access in the Amazon Bedrock User Guide, and visit the Amazon Bedrock pricing page for cost details.

 

本ブログは、コニカミノルタ株式会社と Amazon Web Services Japan が共同で執筆しました […]

AI コーディングエージェントのチーム展開に向けた段階的な環境整備の実践例を紹介しています

Amazon Inspector を使用して、組織全体のリソースの統合されたソフトウェア部品表 (SBOM) を CycloneDx や SPDX 形式で Amazon S3 にエクスポートする方法を紹介します。CloudFormation による前提条件のデプロイから、AWS Glue クローラーでのデータカタログ化、Amazon Athena を使用した脆弱性やパッケージの分析クエリまでを解説します。SBOM を活用することで、ソフトウェアサプライチェーンの可視化やコンプライアンス対応を実現できます。

マルチアカウント環境で数千件におよぶ脆弱性の検出結果を効果的に管理するには、適切な優先順位付けが不可欠です。本記事では、AWS Organizations 全体で Amazon Inspector を活用した脆弱性管理のベストプラクティスを紹介します。委任管理者の設定、抑制ルールによる検出結果の大規模な管理、リソースタグを活用したリスクベースの優先順位付け、AWS Security Hub との統合など、7 つの実践的なアプローチを解説します。原文公開後のサービスアップデートは訳注として補足しています。

シーケンスデータの急増により、ゲノムバリアントの解釈は複雑なパイプラインと専門知識を要する作業になっています。本記事では、AWS HealthOmics のワークフローと Amazon S3 Tables、Amazon Bedrock AgentCore 上の Strands Agents を組み合わせ、VCF ファイルの取り込みからアノテーション、自然言語での問い合わせまでを一貫して実行するゲノムバリアント解釈エージェントを紹介します。臨床研究者が SQL を書かずに、対話形式でコホート全体のバリアントを解析できるようになります。

2026 年8 月 10 日週、OpenSearch と Valkey のチームはソウルを訪問し、Open S […]

クラウドコンピューティングの初期の頃、AWS は世界中の都市で AWS Pop-up Lofts と呼ばれる物 […]

本ブログは 株式会社 PKUTECH と Amazon Web Services Japan 合同会社が共同で […]

Gilead 傘下の Kite は、プロジェクトごとに分断されていたバイオインフォマティクスのワークフローを、AWS HealthOmics を軸にした標準化されたクラウド基盤へ移行しました。本記事では、オンプレミスのシーケンサーから電子実験ノート (ELN) を入口にしたワークフロー実行までを自動化したイベント駆動アーキテクチャと、その設計上の判断を紹介します。18 か月以上の本番稼働で 20 個のワークフローを運用し、100 名を超える研究者が ELN からバイオインフォマティクスワークフローを利用できるようになりました。

Many teams now deploy AI agents that pull from Amazon DynamoDB tables, document repositories, software as a service (SaaS) platforms, and internal knowledge bases to answer questions and automate workflows. A key risk in these deployments is that the agent has no awareness of who’s asking, so it might return data the user shouldn’t see. […]

Learn how AgentFlo built always-on AI sales agents on Amazon Bedrock AgentCore and the Strands Agents SDK. Part 1 covers three pillars of production-grade agents—velocity, standardization, and scalability—including recipe-based deployment, tool routing through AgentCore Gateway, and elastic, stateful commerce conversations.

KnowledgeForge mines resolved ITSM incident tickets into new knowledge base articles and automatically curates the existing library by deduplicating, quality-scoring, and improving content, using Amazon Bedrock, Amazon S3 Vectors, and AWS Step Functions in a multi-tenant, closed-loop pipeline.

Fanatics Betting and Gaming built a multi-agent customer support system on AWS to handle the complexity of sports betting: state-specific rules, real-time responsible gaming, and traffic spikes during major sporting events. This post walks through the architecture, the AWS services involved, and the patterns for your own multi-agent support solution.

In this post, you learn three serverless patterns (task-token callback, direct service integration, and durable functions) for invoking Amazon Bedrock AgentCore agents asynchronously from AWS Step Functions pipelines, eliminating idle compute costs while your AI agent processes requests.

Classifying, extracting, and validating high volumes of documents is a challenge across banking, insurance, healthcare, and the public sector. See how a mid-size mortgage lender automates its entire document intake pipeline, from email to validated data, using the AWS GAIIC IDP Accelerator and Amazon Quick Automate.

Web Search on Amazon Bedrock AgentCore now supports runtime domain and published-date filtering. New per-request filters give developers per-call control over which web sources their agents consult and how fresh those sources must be, all enforced server-side. This release also expands Web Search to the Europe (Ireland) and Asia Pacific (Tokyo) Regions.