使用 Amazon Nova Act 实现合成监控

Synthetic monitoring emulates real user journeys through automated transactions. Rather than waiting for customers to encounter problems, teams continuously validate critical workflows (logins, purchases, form submissions) on a scheduled basis. With this approach, you detect problems faster when performance degrades or UI interactions break.

For customer-facing businesses, especially in ecommerce, synthetic monitoring safeguards interactions that matter most. Organizations validate that product search works correctly, pricing and inventory display as expected, cart operations succeed, and checkout confirmations complete without error. Continuous testing identifies problems before customers encounter them.

The same approach applies across industries. Financial services organizations make sure account access and transaction flows remain functional. Travel and hospitality providers monitor booking and reservation journeys. Software as a service (SaaS) companies validate signup and subscription upgrade paths. Healthcare organizations monitor appointment scheduling portals where availability and transaction health are essential.

This post walks through an agent-driven approach to synthetic monitoring using Amazon Nova Act and Amazon Bedrock AgentCore . Together, with these services you can move beyond brittle UI scripts toward resilient, managed journey validation. The post describes the architecture and patterns for agent-driven synthetic monitoring, with a sample repository containing the complete implementation.

Most organizations monitor infrastructure health through metrics, logs, traces, and API-level checks. However, high-impact failures often occur at the user journey level, where backend signals may not immediately reveal the problem. Common examples: a frontend deployment breaks a checkout button, a third-party login page changes unexpectedly, or a UI regression makes critical elements unresponsive.

Traditional browser automation frameworks like Selenium and Playwright rely on explicit Document Object Model (DOM) locators and selectors, which creates brittleness. Even small UI changes can break tests and require constant maintenance. Teams invest significant ongoing effort managing selectors, handling timing-related instability, and updating scripts as applications evolve, often spending more time on maintenance than on building new automations.

Traditional approach

# Breaks when CSS class changes driver.find_element(By.CLASS_NAME, "checkout-button").click() driver.find_element(By.ID, "payment-form").submit() driver.find_element(By.XPATH, "//button[@data-test='complete-order']").click() # Requires 10+ lines of explicit selectors per workflow

Nova Act approach

# Adapts to UI changes in most cases nova_act.act("Click the checkout button") nova_act.act("Complete the payment form") nova_act.act("Confirm the order") # 3 lines, no selectors to maintain

Amazon Nova Act uses a multimodal large language model (LLM) that processes UI screenshots rather than DOM selectors, making it significantly more resilient to UI changes. Because the model reasons from what it sees on screen (not from CSS classes or element IDs), it adapts when styling changes without requiring script updates. In early enterprise customer use cases, Amazon Nova Act has demonstrated over 90% accuracy on browser workflows. This is a meaningful improvement over selector-based approaches that fail immediately on any element change. Teams should test on their own sites and design monitors with retry logic for cases where adaptation does not succeed.

Enterprise monitoring platforms compound the maintenance challenge by pricing browser checks as premium add-ons. This forces teams to choose between monitoring breadth and budget, all separate from the real goal of validating critical customer journeys.

This solution combines the following AWS services, each handling a distinct responsibility:

The architecture follows this flow:

The following diagram illustrates the architecture.

Figure 1: Synthetic monitoring architecture with Amazon Nova Act and Amazon Bedrock AgentCore

This architecture provides fully managed synthetic monitoring. Teams avoid maintaining brittle scripts or browser infrastructure.

The following sections walk through setup requirements, journey definition, agent deployment, and scheduling infrastructure.

Before implementing, confirm the following:

Implementation begins by defining the most important customer journeys to validate. For ecommerce applications, these typically include homepage load, product search, product detail navigation, add-to-cart validation, and checkout readiness.

Rather than focusing only on workflow completion, validate outcomes explicitly. The monitor should confirm that search results appear correctly, the cart contains items, and no error banners display. Explicit outcome validation reduces false positives from incomplete checks and false negatives from overly permissive assertions.

The agent groups natural-language actions into logical journey steps and uses assertions at key checkpoints. Actions use act() to drive the UI through natural language. Assertions use act_get() with a boolean schema to validate outcomes. When a journey fails, the agent publishes the journey type, target URL, duration, completed steps, and failed steps. Detailed exception information remains in the runtime logs.

The code uses the Nova Act SDK directly. When deployed to AgentCore Runtime, the execution environment manages browser session lifecycle through the Browser tool. In testing, a typical six-step journey completes in 2 to 4 minutes depending on page load times. Refer to the Nova Act User Guide for current method signatures and SDK version. The sample repository includes the complete agent definition with error handling and single-attempt step execution.

Before the Amazon EventBridge schedule can invoke the agent, deploy it to AgentCore Runtime using the Nova Act CLI. The act workflow commands package the agent code, push the container image to Amazon ECR, and provision the runtime. Once deployed, the endpoint Amazon Resource Name (ARN) remains constant. Updates create new runtime versions without requiring you to update your Scheduler target.

act workflow create --name synthetic-monitoring-workflow act workflow deploy --name synthetic-monitoring-workflow --source-dir . --entry-point workflow.py act workflow show --name synthetic-monitoring-workflow

The act workflow show command returns the AgentCore Runtime ARN that you reference as the Scheduler target. The sample repository’s deploy.py script wraps these commands with prerequisite checks (Docker, AWS credentials), creates the SNS alert topic, and wires the Amazon EventBridge schedule, so a single python deploy.py performs an end-to-end deployment. (AgentCore also provides its own agentcore CLI for agent development. This sample standardizes on the Nova Act act workflow commands.)

For a production-grade, repeatable deployment, the sample includes a CDK stack as a standalone alternative to deploy.py . It provisions the Amazon EventBridge schedule with least-privilege IAM permission, the SNS alert topic, and an SQS dead-letter queue that captures failed InvokeAgentRuntime calls from the Scheduler.

The stack also creates two Amazon CloudWatch alarms: one on dead-letter-queue depth (failed Scheduler invocations), and one on missing scheduled runs (using the AWS/Scheduler InvocationAttemptCount metric, treating missing data as breaching). Note that these alarms detect infrastructure failures, such as a delivery failure to the agent or the schedule not firing. A functionally broken customer journey that still returns at the HTTP level surfaces through the agent’s SNS publish, not through these CloudWatch alarms.

Focus synthetic monitors on high-value customer journeys rather than exhaustive page coverage. Over-monitoring creates noise that desensitizes teams to real failures. Start with 3-5 critical workflows (login, checkout, account access) and expand based on actual failure patterns and business impact. Monitor journeys that directly affect revenue or customer trust, not every possible user path.

Similarly, avoid over-asserting on every page element. Validate meaningful outcomes (whether search results appear, whether the cart contains items) rather than checking every DOM element on the page. Overly granular assertions increase false positives without improving failure detection.

The sample agent code uses single-attempt execution per step, which minimizes Browser session cost. Since the natural language adaptation of Nova Act succeeds in approximately 90% of cases, a single-attempt approach may occasionally produce false alerts when Nova Act fails to locate a UI element that is actually present. Teams requiring lower false-positive rates can add step-level retry (re-run a failed step once before declaring failure) at the cost of longer session durations.

Once deployed, two operational concerns require attention: observing the monitoring system itself and managing cost.

AgentCore Runtime publishes agent invocation metrics to Amazon CloudWatch, so you can track execution frequency and duration. On success, the agent completes without publishing to SNS. Journey failures surface through the agent’s SNS publish. Configure SNS topics with dead-letter queues to detect failed agent invocations.

Costs come from five components: AgentCore Runtime invocations, Browser tool sessions, Nova Act inference, Amazon EventBridge Scheduler invocations, and SNS notifications. The primary cost drivers are Browser session duration and Nova Act inference calls per journey step.

The following table provides a cost approximation for the sample’s six-step ecommerce journey running every 5 minutes (approximately 8,640 invocations per month):

Organizations adopting agent-driven synthetic monitoring with Nova Act and AgentCore can expect measurable improvements across key operational dimensions:

Synthetic monitoring must produce reliable results without introducing false positives or masking real failures. AgentCore Runtime provides session isolation for each test execution using a strict one-session-one-microVM model built on Firecracker microVMs. By default, each session terminates with full memory sanitization, preventing cookies, browser cache, and LocalStorage from persisting between runs. This helps prevent false positives caused by state leakage across tests. For synthetic monitoring, ephemeral sessions are the recommended pattern to maintain test independence. AgentCore does offer persistent browser profiles through the SaveBrowserSessionProfile API for other use cases, but synthetic monitors should always use ephemeral sessions.

For network access, the Browser tool operates in public network mode by default, providing internet access appropriate for synthetic monitors that validate customer-facing websites. For environments requiring egress control, AgentCore supports Browser with Amazon Virtual Private Cloud (Amazon VPC) configuration, allowing teams to restrict network access to specific domains when monitoring internal applications.

Teams integrate synthetic monitoring with AWS Identity and Access Management (IAM) to enforce least-privilege permissions. IAM roles define which resources the agent can access, including SNS publishing permissions and Browser tool invocation.

When synthetic tests require authentication, teams should store credentials in AWS Secrets Manager, which keeps sensitive information encrypted and access is auditable through AWS CloudTrail.

Organizations with users around the world can deploy Nova Act synthetic monitoring in multiple AWS Regions to test user experiences from different geographic locations. This helps validate user experiences and identify issues across multiple Regions.

Use infrastructure as code (IaC) to deploy the solution consistently and repeatably across supported Regions. For current Region availability, see the Amazon Bedrock AgentCore and Amazon Nova Act product pages.

To avoid ongoing charges from the resources created in this post, remove them when they are no longer needed:

Synthetic monitoring has traditionally required a tradeoff between brittle scripts and the ongoing effort needed to maintain them as applications change. Amazon Nova Act and Amazon Bedrock AgentCore reduce this burden. Nova Act uses natural-language actions that are more resilient to routine UI changes, while AgentCore Runtime provides the infrastructure to run workflows at scale.

For the complete working implementation, see the sample repository: github.com/aws-samples/sample-nova-act-synthetic-monitoring

Sarath is a Senior Gen AI/ML Specialist Solutions Architect at Amazon Web Services, where he helps enterprise customers design and deploy generative AI and machine learning solutions that deliver measurable business outcomes. He brings deep expertise in Agentic AI, machine learning, and MLOps to build scalable, secure, and production-ready AI systems.

Matthew is a Customer Solutions Manager at AWS focused on Retail and Consumer Goods enterprises. He works with engineering leaders and their teams to adopt AI-native development practices and helps organizations close the gap between AI investment and end-to-end delivery improvement. He partners with executive stakeholders to connect modernization outcomes to business priorities. Prior to AWS, he led global enterprise teams across Services, Support, and Customer Success.

Karen is an AI/ML Specialist at Amazon Web Services with a background in engineering, IoT, and AI/ML. She partners with enterprise customers to turn AI ambition into measurable business outcomes — working at the intersection of bold ideas and real-world impact.