This article is a machine translation of the contents of the following URL, which I wrote in Japanese:

【AWS】結果を返すか、答えを返すか。Web SearchとWeb Answerの使い分け【AgentCore】 #AIエージェント - Qiita

はじめに AIエージェントに最新のウェブ情報を渡したい場面は多いです。これまでは、検索APIを呼び、ページを取得し、要約して、出典を付ける、というパイプラインを自分で組む必要がありました。 Amazon Bedrock AgentCoreには、この部分をマネージドで提供す...

favicon qiita.com

Introduction

There are many situations where you want to give an AI agent up-to-date web information. Until now, you had to build the pipeline yourself: call a search API, fetch pages, summarize them, and attach sources.

Amazon Bedrock AgentCore offers two managed features for this part.

  • Web Search is a tool that returns ranked search results. It was introduced in June 2026
  • Web Answer is a tool that returns a finished answer with citations. It became generally available (GA) on November 5, 2026

Both are added as connectors on AgentCore Gateway and called via MCP. AWS describes them as "complementary", but when you actually have to choose, questions like these come up.

  • If the only difference is what comes back, can't I do the same things with either one?
  • If I want to control which domains are referenced, how far can each tool go?
  • Which one can I use in the Tokyo Region? (As of 2026-11-08. Supported Regions may increase.)

This article organizes the specifications from the official documentation in tables, adds the results I confirmed on a real environment, and summarizes criteria for choosing between them.

So that readers who are new to Web Answer can follow along, the first half compares the two in tables, and the second half shows the verification results.

Key differences between Web Search and Web Answer

Here are the key points as a table first. The "Confirmed on a real environment" column shows what I confirmed in us-east-1 on 2026-11-08.

Criterion Web Search Web Answer Confirmed on a real environment
What it returns Ranked results (text, url, title, publishedDate) A synthesized answer with citations Confirmed (Verification 1). Search has no structuredContent, and publishedDate is in a custom format or unknown. Answer's citation markers map to the order of first appearance after removing duplicates
Who composes the answer The model of your own agent The Web Answer side Confirmed (Verification 1). Web Search returned only results (snippets), and Web Answer returned an answer with citations
Price (tool side) $7 / 1,000 queries $10 / 1,000 invocations Official documentation (see below)
Regions (as of 2026-11-08) 7 Regions including Tokyo us-east-1 only (the blog says "more AWS Regions coming soon") Official documentation
Domain control Two layers: administrator and request (100 entries each) Two layers: administrator and request (50 entries each) Confirmed (Verification 3). Both kept to the administrator's boundary, but violations look different (Answer returns an error; Search narrows the results or returns an empty result)

The choice is almost entirely decided by two questions: "Do you want to handle the results with your own model, or do you want a finished answer?" and "Do you need to keep everything in Tokyo?" For domain control, both could be fixed on the administrator side, but they behave differently when a request goes outside the boundary. Note that Web Search returns an empty result without an error.

Overview

First, here is the architecture as a diagram. The calling agent goes through the Gateway and calls two targets (connectors). The web index is operated by Amazon and sits outside your own account. The answer from Web Answer is written by a model on the Amazon side, and you cannot choose that model. The results from Web Search are turned into an answer by your own model, which you choose on the calling side.

Overview diagram (Japanese labels)

Specification comparison by aspect

No. Aspect Web Search Web Answer
1 What it returns Ranked results A synthesized answer with citations
2 connectorId web-search web-answer
3 Query length Up to 200 characters 1 to 30,000 characters
4 Result count control maxResults 1 to 25 (default 10) None
5 Domain lists 100 each (request side) 50 each (100 for exclude after merging)
6 Date filter Yes (1.2.0 or later) Yes (1.1.0 or later)
7 Location None userLocation.country
8 Regions (as of 2026-11-08) 7 Regions (including Tokyo) us-east-1 only
9 Price $7 / 1,000 queries $10 / 1,000 invocations
10 IAM permission on the service role (independent per tool) InvokeWebSearch InvokeWebAnswer

Detailed explanation of each aspect

Aspect 1: What each tool returns

AWS positions Web Search as follows.

"Web Search Tool on Amazon Bedrock AgentCore is different — it is backed by a web index that Amazon builds and operates directly."
—— Web Search Tool (AgentCore Developer Guide)

Web Answer is described as searching the web, reading pages, and answering with citations.

"searches the web, reads relevant pages to ground its answer, and includes citations."
—— Web Answer (AgentCore Developer Guide)

Here is the difference in response format, field by field.

Web Search (content[0].text is a JSON string)

{ "id": "824f89d0", "results": [ { "text": "...", "publishedDate": "2024-10-07", "url": "...", "title": "..." } ] } 

Web Answer (content[0].text is Markdown, and structuredContent holds the list of citations)

{ "isError": false, "content": [{"type": "text", "text": "... [[1](https://example.com/basel-iii)]..."}], "structuredContent": { "answer": [ { "text": "...", "citations": [{"domain": "example.com", "url": "https://example.com/basel-iii"}] } ] }, "_meta": {"latencyMs": 5210} } 

Both of the above are examples from the official documentation. When I checked on a real environment (us-east-1, 2026-11-08, connectors Search 1.3.0 / Answer 1.1.0), I found the following differences (details in Verification 1).

  • Web Search results have no structuredContent; only the JSON string in content[0].text is returned
  • Web Search's publishedDate is not ISO-8601. It is a string such as 05:00PM, Wednesday, September 09 2026, PDT, or unknown
  • Web Answer's citation marker [[N]] did not correspond to citations[N-1]. It corresponded to the Nth URL in order of first appearance after removing duplicates (looking up by index mismatched in 7 of 9 runs, while the deduplicated order matched in all 9)

Aspects 2 to 4: Differences from the caller's point of view

  • Web Search is meant to be given short search keywords (up to 200 characters), and maxResults lets you limit the number of results
  • Web Answer accepts a longer natural-language question (up to 30,000 characters). There is no way to specify the number of results
  • Tool names have the form <target name>___<tool name> (three underscores). On the real environment they were web-answer-tool___WebAnswer and web-search-tool___WebSearch. On a Gateway with semantic search enabled, tools/list can also include another tool (x_amz_bedrock_agentcore_search), so you need to pick by the end of the name (the Gateway I used for verification had semantic search disabled, so it was not included)
  • tools/list and tools/call succeeded when I sent SigV4-signed HTTP requests without initialize. Web Search's tools/list includes title and annotations (readOnlyHint: true, openWorldHint: true) (connector 1.3.0)

Aspects 5 and 6: Domain and date filters

Both have two layers: a boundary that the administrator sets on the target, and conditions that the agent specifies on each call.

"Request-level filters cannot override the target-level exclude list or expand results beyond the target-level include list."
—— Web Search Tool (AgentCore Developer Guide)

Rule Web Search Web Answer
Request-side list limit 100 each 50 each
Handling of exclude The administrator's exclude and the request's exclude are merged, and domains in the merged list are excluded Same as left. Up to 100 entries after merging
When both sides have include Only the intersection is used. An empty intersection is an error Officially "only the intersection is used; an empty intersection is an error". In my tests, even with a non-empty intersection, it returned an error if even one non-permitted domain was included
Date specification ISO-8601, UTC, both ends inclusive Date only, or date-time (Z or +HH:mm allowed)
Required connector version Filters from 1.2.0 Filters from 1.1.0

In practice, if a regulated-industry customer wants the agent to reference only trusted domains, you can pin that with the administrator-side include. In Verification 3, I confirmed that domains outside the boundary specified from the request side, and domains that hit the administrator's exclude when included on the request side, did not appear in the results (one observation per pattern).

Aspect 8: Regions and data handling

Item Web Search Web Answer
Supported Regions (as of 2026-11-08) us-east-1, us-east-2, us-west-2, eu-west-1, ap-southeast-2, ap-northeast-1 (Tokyo), us-gov-west-1 us-east-1 only
Scope of processing Amazon-operated web index Amazon-operated web index and knowledge graph. Answers are generated by a model on Bedrock using geographic cross-Region inference

The supported Regions above are as of 2026-11-08. "us-east-1 only" for Web Answer describes the current situation, and the blog says "more AWS Regions coming soon". Because the supported Regions may increase, check the latest Region table before use. The verification in this article was done in us-east-1, which Web Answer supports.

If you want to keep everything within the Tokyo Region, Web Search is the only choice at present (2026-11-08). If you use Web Answer in us-east-1, you need to check the customer's requirements, because data processing involves a US Region.

"Zero data egress" means that queries and results do not leave the AWS environment. The wording differs between the blog (queries and results stay within the AWS environment) and the product page (they can also leave via a VPC or PrivateLink). I did not verify which wording matches the actual behavior. If the data exit point matters for a customer's requirements, check the official documentation or ask AWS.

Aspect 9: Price

Item Web Search Web Answer
Tool unit price $7.00 / 1,000 queries ($0.007 per call) $10 / 1,000 invocations ($0.010 per call)
Gateway API $0.005 / 1,000 calls Same as left (because calls go through the Gateway)

Gateway API charges depend on the number of ListTools, InvokeTool, and Ping calls. The unit prices are listed on the Amazon Bedrock AgentCore pricing page.

Aspect 10: Separation of IAM responsibilities

Target Permission
Gateway service role (Web Search) bedrock-agentcore:InvokeWebSearch (resource: arn:aws:bedrock-agentcore:us-east-1:aws:tool/web-search.v1)
Gateway service role (Web Answer) bedrock-agentcore:InvokeWebAnswer (resource: arn:aws:bedrock-agentcore:us-east-1:aws:tool/web-answer.v1)
Caller (execution role of the agent or harness) bedrock-agentcore:InvokeGateway (Gateway ARN)

Verification 2 showed that InvokeGateway is required on the caller and not on the service role. InvokeWebAnswer and InvokeWebSearch on the service role are each required independently per tool (details in Verification 2).

What I confirmed on a real environment

The following is what I actually confirmed in us-east-1 on 2026-11-08. Each verification is written in this order: what I checked, the measurements, and what can be concluded.

Verification 1: Sending the same question to both and comparing the response formats

I checked the difference in response format and how citations are attached, using actual responses. I sent the same three questions to both Web Search and Web Answer. I fixed the questions to English because Web Answer supported English at launch.

Question Type Question text
Q1 Fact check What is the maximum execution timeout of an AWS Lambda function?
Q2 Regulation / policy What is the minimum Common Equity Tier 1 capital ratio required under Basel III?
Q3 Latest information What are the recent updates to Amazon Bedrock AgentCore?

I sent each question to each tool three times, for 18 calls in total. All returned HTTP 200 with isError false. Web Search used maxResults: 5. I recorded the response format, whether and where citations appear, whether publishedDate is present, and latency. For latency, I recorded both _meta.latencyMs and client-side timing for Web Answer, and only client-side timing for Web Search because it returns no _meta.

Latency (milliseconds; average of 3 runs; client side is the time of the whole HTTP request)

Question Search, client side Answer, client side Answer, server side (_meta.latencyMs)
Q1 (fact check) 1,101 3,122 2,292
Q2 (regulation) 1,136 3,011 2,215
Q3 (latest information) 1,259 6,555 5,744

Differences in the response

Aspect Web Search Web Answer
Top-level keys isError, content isError, content, structuredContent, _meta
Body content[0].text is a JSON string of the form {"id": ..., "results": [...]}, and results has maxResults entries (5) content[0].text is Markdown. Citations are [[N](url)]
Contents of one item text (snippet, about 700 to 5,000 characters), title, url, publishedDate The answer body and a list of citations (structuredContent.answer is one block)
Dates publishedDate is in the form 05:00PM, Wednesday, September 09 2026, PDT, or unknown (0 to 2 of 5 items were unknown) No date is attached
When the same question is sent 3 times The set of result URLs was the same all 3 times. The whole response was not fully identical, though (the length was the same in some runs) The body length changes between runs (whole-response character counts for Q1: 1,947 / 1,485 / 2,313)
Characters in the whole response About 9,600 to 14,100 About 1,400 to 2,500 for Q1 and Q2, about 10,000 to 12,700 for Q3

Actual content returned (Q1 "What is the maximum execution timeout of an AWS Lambda function?", first run)

Web Answer's answer (full content[0].text, 627 characters).

The standard maximum timeout for an AWS Lambda function is 900 seconds (15 minutes). [[1](https://docs.aws.amazon.com/lambda/latest/dg/configuration-timeout.html)] There is one exception: for functions on Lambda Managed Instances, asynchronous and event source mapping invocations can be set to up to 5,400 seconds (90 minutes). [[2](https://aws.amazon.com/blogs/compute/announcing-90-minute-function-timeout-on-aws-lambda-managed-instances/)] Synchronous invocations on those instances still cap at 15 minutes. [[2](https://aws.amazon.com/blogs/compute/announcing-90-minute-function-timeout-on-aws-lambda-managed-instances/)] 

Here is the whole response of the same run (the result part of the JSON-RPC response). It shows the actual shape, including _meta and structuredContent. citations has 4 entries, but only 2 unique URLs.

Full response of Web Answer (click to expand)

{ "_meta": { "latencyMs": 2330 }, "content": [ { "text": "The standard maximum timeout for an AWS Lambda function is 900 seconds (15 minutes). [[1](https://docs.aws.amazon.com/lambda/latest/dg/configuration-timeout.html)]\n\nThere is one exception: for functions on Lambda Managed Instances, asynchronous and event source mapping invocations can be set to up to 5,400 seconds (90 minutes). [[2](https://aws.amazon.com/blogs/compute/announcing-90-minute-function-timeout-on-aws-lambda-managed-instances/)] Synchronous invocations on those instances still cap at 15 minutes. [[2](https://aws.amazon.com/blogs/compute/announcing-90-minute-function-timeout-on-aws-lambda-managed-instances/)]", "type": "text" } ], "isError": false, "structuredContent": { "answer": [ { "citations": [ { "domain": "docs.aws.amazon.com", "url": "https://docs.aws.amazon.com/lambda/latest/dg/configuration-timeout.html" }, { "domain": "docs.aws.amazon.com", "url": "https://docs.aws.amazon.com/lambda/latest/dg/configuration-timeout.html" }, { "domain": "aws.amazon.com", "url": "https://aws.amazon.com/blogs/compute/announcing-90-minute-function-timeout-on-aws-lambda-managed-instances/" }, { "domain": "aws.amazon.com", "url": "https://aws.amazon.com/blogs/compute/announcing-90-minute-function-timeout-on-aws-lambda-managed-instances/" } ], "text": "The standard maximum timeout for an AWS Lambda function is 900 seconds (15 minutes). [[1](https://docs.aws.amazon.com/lambda/latest/dg/configuration-timeout.html)]\n\nThere is one exception: for functions on Lambda Managed Instances, asynchronous and event source mapping invocations can be set to up to 5,400 seconds (90 minutes). [[2](https://aws.amazon.com/blogs/compute/announcing-90-minute-function-timeout-on-aws-lambda-managed-instances/)] Synchronous invocations on those instances still cap at 15 minutes. [[2](https://aws.amazon.com/blogs/compute/announcing-90-minute-function-timeout-on-aws-lambda-managed-instances/)]" } ] } } 

Web Search results (maxResults: 5. The 5 snippets total 8,227 characters. The full text is in the collapsible section below).

# Title URL publishedDate Snippet characters
1 Configure Lambda Event Function timeout docs.aws.amazon.com/lambda/latest/dg/configuration-timeout.html 05:00PM, Sunday, October 30 2016, PDT 1,164
2 Troubleshoot configuration issues in Lambda docs.aws.amazon.com/lambda/latest/operatorguide/configurations.html unknown 2,312
3 AWS SDK for Kotlin docs.aws.amazon.com/sdk-for-kotlin/api/latest/lambda/.../timeout.html unknown 1,365
4 Announcing 90-minute function timeout on AWS Lambda Managed Instances aws.amazon.com/blogs/compute/announcing-90-minute-function-timeout-on-aws-lambda-managed-instances/ 12:08PM, Wednesday, September 09 2026, PDT 2,023
5 AWS Lambda vs Step Functions vs EventBridge jayendrapatil.com/aws-lambda-vs-step-functions-vs-eventbridge/ 05:00PM, Wednesday, June 24 2026, PDT 1,363

The full content[0].text of Web Search (Q1, first run, 9,595 characters) follows. Reading it side by side with Web Answer's answer (627 characters) shows how the citations differ.

Full response of Web Search (click to expand)

{ "id": "dafbd346", "results": [ { "publishedDate": "05:00PM, Sunday, October 30 2016, PDT", "text": "Configure Lambda Event Function timeout Lambda runs your code for a set amount of time before timing out. Timeout is the maximum amount of time in seconds that a Lambda function can run. The default value for this setting is 3 seconds, but you can adjust this in increments of 1 second up to a maximum value \n\nof 900 seconds (15 minutes). For functions using AWS Lambda Managed Instances, asynchronous invocations and event source mapping invocations (except Amazon MQ and Amazon DocumentDB) support a maximum allowed value of 5,400 seconds (90 minutes). \n\nConfiguring timeout (AWS SAM) Determining the appropriate timeout value for a Lambda function If the timeout value is close to the average duration of a function, there is a higher risk that the function times out unexpectedly. The duration of a function can vary \n\nUnder General configuration , choose Edit . For Timeout , set a value between 1 and 900 seconds (15 minutes). Choose Save . Configuring timeout (AWS CLI) You can use the update-function-configuration command to configure the timeout value, in seconds. The following example command increases the function timeout to 120 seconds (2 minutes). ", "title": "Configure Lambda Event Function timeout", "url": "https://docs.aws.amazon.com/lambda/latest/dg/configuration-timeout.html" }, { "publishedDate": "unknown", "text": "The following topics provide troubleshooting advice for common issues that you might encounter related to Lambda function configuration settings. Memory configurations You can configure a Lambda function to use between 128 MB and 10,240 MB of memory. By default, any function created in the console is assigned the smallest amount of memory. Many Lambda functions are performant at this lowest setting. However, if you are importing large code libraries or completing memory intensive tasks, 128 MB is not sufficient. \n\nTimeouts Timeouts for Lambda functions can be set between 1 and 900 seconds (15 minutes). For functions using AWS Lambda Managed Instances, asynchronous invocations and event source mapping invocations (except Amazon MQ and Amazon DocumentDB) support a maximum allowed value of 5,400 seconds (90 minutes). By default, the Lambda console sets this to 3 seconds. The timeout value is a safety valve that ensures functions do not run indefinitely. After the timeout value is reached, Lambda stops the function invocation. \n\nIf a timeout value is set close to the average duration of a function, this increases the risk that the function times out unexpectedly. The duration of a function can vary based on the amount of data transfer and processing, and the latency of any services the function interacts with. Common causes of timeout include: \n\n2. Duration – Before the function runs out of memory, it finishes invocations at a steady double-digit millisecond rate. As paging occurs, the duration takes an order of magnitude longer. 3. Error count – As the memory leak exceeds allocated memory, eventually the function errors due to the computation exceeding the timeout, or the execution environment stops the function. \n\nIn JavaScript, asynchronous callbacks are handled with an event loop. Other runtimes use different mechanisms to handle concurrency. When the function's execution environment ends, Lambda freezes the environment until the next invocation. \n\n1. The code calls the asynchronous doWork function using the await keyword in the handler. 2. The doWork function takes some period of time to complete before resolving the promise. 3. The function times out because doWork takes longer than the timeout limit allows and the callback result is not returned in a later invocation. ", "title": "Troubleshoot configuration issues in Lambda", "url": "https://docs.aws.amazon.com/lambda/latest/operatorguide/configurations.html" }, { "publishedDate": "unknown", "text": "If you agree, AWS and approved third parties will also use cookies to provide useful site features, remember your preferences, and display relevant content, including relevant advertising. To accept or decline all non-essential cookies, choose “Accept†or “Decline.†To make more detailed choices, choose “Customize.†\n\nTo opt out of our use of cookies or similar technologies to engage in these activities, select “Opt out of cross-context behavioral ads†and “Save preferences†below. If you clear your browser cookies or visit this site from a different device or browser, you will need to make your selection again. For more information about cookies and how we use them, read our Cookie Notice. \n\nTo opt out of the use of other identifiers, such as contact information, for these activities, fill out the form here. For more information about how AWS handles your information, read the AWS Privacy Notice. \n\nThe amount of time (in seconds) that Lambda allows a function to run before stopping it. The default is 3 seconds, and the maximum allowed value is 900 seconds. For functions using Lambda Managed Instances, asynchronous invocations and event source mapping invocations (except Amazon MQ and Amazon DocumentDB) support a maximum allowed value of 5,400 seconds (90 minutes). For more information, see Lambda execution environment. ", "title": "AWS SDK for Kotlin", "url": "https://docs.aws.amazon.com/sdk-for-kotlin/api/latest/lambda/aws.sdk.kotlin.services.lambda.model/-update-function-configuration-request/-builder/timeout.html" }, { "publishedDate": "12:08PM, Wednesday, September 09 2026, PDT", "text": "Activating 90-minute function timeout You can now configure any Lambda function running on a Managed Instance with a timeout of up to 90 minutes (5,400 seconds) for async and ESM invocations. Synchronous invocations retain the existing 15-minute maximum. The function executes exactly as before: same runtime, same handler, same IAM execution role, same virtual private cloud (VPC) configuration. The only difference is that your function now supports longer continuous execution. Your initialization code (Init phase) is still limited to 15 minutes on Lambda Managed Instances. \n\nThere is no additional charge for using the 90-minute timeout. Standard Lambda Managed Instances pricing applies. 90-minute timeout and durable functions The 90-minute function timeout and durable functions are complementary. The function timeout (--timeout) controls how long each individual invocation can run, while the durable execution timeout (ExecutionTimeout in --durable-config) controls the total elapsed time from execution start to completion. Durable functions use checkpoints to track progress and automatically recover from failures through replay, re-executing from the beginning while skipping completed work. With today’s launch, each asynchronous invocation in a durable function running on a Managed Instance can now execute for up to 90 minutes continuously, while the corresponding durable execution can run for up to 1 year. For synchronous and event source mapping invocations, both the invocation and the corresponding durable execution are limited to 90 minutes. \n\nNote that invocations for Amazon MQ ESM and Amazon DocumentDB (with MongoDB compatibility) ESM remain limited to 15 minutes. Synchronous invocations (15 minutes maximum): Synchronous invocations retain the existing 15-minute maximum timeout. If you set your function timeout to greater than 15 minutes and invoke it synchronously, Lambda continues to apply the 15-minute timeout. The GetFunctionConfiguration API reports the configured timeout value. ", "title": "Announcing 90-minute function timeout on AWS Lambda Managed Instances", "url": "https://aws.amazon.com/blogs/compute/announcing-90-minute-function-timeout-on-aws-lambda-managed-instances/" }, { "publishedDate": "05:00PM, Wednesday, June 24 2026, PDT", "text": "| event_date | 2026-08-11 |\n| title | AWS Lambda vs Step Functions vs EventBridge |\n| original_url | https://jayendrapatil.com/aws-lambda-vs-step-functions-vs-eventbridge/ |\n| source_domain | jayendrapatil.com |\n| search_queries_hash | 187d207b814cb47441a22825e67d4c83 |\n### search_queries (Level 0)\n#### search_queries - Item 1\n- What architecture pattern is best for decoupling microservices that react to a single event? : Amazon EventBridge with a custom event bus and content-based routing rules provides the most decoupled architecture, allowing producers to remain unaware of consumers.\n#### search_queries - Item 2\n- How much does AWS Step Functions Standard Workflow cost? : AWS Step Functions Standard Workflow costs $25.00 per 1 million state transitions.\n#### search_queries - Item 3\n- What is the difference between AWS Lambda, Step Functions, and EventBridge? : Lambda handles compute (executing code), Step Functions handles orchestration (coordinating multiple services into workflows), and EventBridge handles event routing (connecting producers and consumers) — they are complementary services often used together.\n#### search_queries - Item 4\n- What is the maximum execution duration for AWS Lambda? : Standard Lambda functions have a 15-minute timeout, MicroVMs support up to 8 hours, and Lambda Durable Functions can suspend for up to 1 year.", "title": "AWS Lambda vs Step Functions vs EventBridge", "url": "https://jayendrapatil.com/aws-lambda-vs-step-functions-vs-eventbridge/" } ] } 

Comparing the two, you can see the following.

  • Citations are attached differently. Web Answer attaches the source URL to each sentence of the answer (the [[1](...)] and [[2](...)] above). Web Search only attaches url and title to each result, and does not tell you which sentence is based on which result. When you compose an answer, your own model has to add the citations
  • The first Web Search snippet already contains the answer (up to 900 seconds, and 5,400 seconds on Managed Instances). However, the answer sits in the middle of explanatory text about how to configure the setting, and extracting it is the job of your own model
  • The results also include content that is only weakly related to the answer. The third result contains the text of a cookie consent banner with garbled characters, and the fifth is a list of search queries from a third-party blog, which includes a statement that none of the other four contain: "MicroVMs support up to 8 hours". Deciding which to use is also the job of your own model. Web Answer's ans...