DEV Community: AWS Community Builders

Hands-On with the New Amazon CloudFront Support for AWS Lambda Web Functions

Irfan Satrio — Sun, 18 Oct 2026 12:41:41 +0000

On October 12, 2026, Amazon Web Services introduced support for using AWS Lambda Web Functions as origins for Amazon CloudFront. This capability allows web applications running on Lambda Web Functions to be delivered through CloudFront's global edge network without requiring changes to application code.

By placing CloudFront in front of a Lambda Web Function, applications can benefit from caching, custom domains with managed TLS certificates, and additional security through AWS WAF. CloudFront Origin Access Control (OAC) can also restrict access to the Lambda Web Function so that requests reach the origin through CloudFront.

In this post, I explored the new integration by configuring a Lambda Web Function as a CloudFront origin and verifying the setup using HTTP requests.

Setup

To test the new feature, I created a Lambda Web Function in ap-southeast-1 using Node.js 24.x and the default Hello World template. For CloudFront OAC integration, the endpoint must use IAM authentication (IamAuth). I configured an endpoint named web-function-endpoint with the Home-Region endpoint type, IAM authentication enabled, and automatic deployment enabled.

The Home-Region endpoint is a regional endpoint for the Lambda Web Function. The endpoint type is selected during creation and cannot be changed afterward. With IamAuth enabled, requests to the endpoint must be authenticated before the endpoint can be invoked.

I then created a CloudFront distribution and configured the Lambda Web Function endpoint as its origin. Under Origin access, I enabled Allow private Lambda function access to CloudFront to use Origin Access Control (OAC).

To allow CloudFront to invoke the endpoint, I configured a resource-based policy on the Lambda Web Function. The policy grants the CloudFront service principal permission to invoke the endpoint and restricts access to the specific distribution using aws:SourceArn.

Example policy:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowCloudFrontOACAccess",
      "Effect": "Allow",
      "Principal": {
        "Service": "cloudfront.amazonaws.com"
      },
      "Action": "lambda:InvokeWebFunctionEndpoint",
      "Resource": "arn:aws:lambda:ap-southeast-1:<ACCOUNT_ID>:web-function/lab-web-function/endpoint/web-function-endpoint",
      "Condition": {
        "StringEquals": {
          "aws:SourceArn": "arn:aws:cloudfront::<ACCOUNT_ID>:distribution/<DISTRIBUTION_ID>"
        }
      }
    }
  ]
}

I applied the policy using the AWS CLI:

aws lambda-web put-resource-policy \
  --resource-arn "arn:aws:lambda:ap-southeast-1:<ACCOUNT_ID>:web-function/lab-web-function" \
  --policy file://policy.json \
  --region ap-southeast-1

Replace <ACCOUNT_ID> and <DISTRIBUTION_ID> with your actual values. Note that the policy uses the endpoint ARN, while the CLI command uses the Lambda Web Function ARN.

According to AWS documentation, several configuration details are important when using a Lambda Web Function as a CloudFront origin with OAC:

IAM authentication: The endpoint must use IamAuth so that requests are authenticated and authorized through the Lambda Web Function's resource-based policy.
OAC signing protocol: sigv4 for regional endpoints (Home-Region and Per-Region) and sigv4a for global endpoints (Multi-Region).
Signing behavior: Lambda Web Function origins support always-amz-auth (Always sign, preserve viewer authorization), which signs origin requests while preserving the viewer's original Authorization header.
Origin request policy: If you use an origin request policy, it must exclude the viewer's Host header. If you use a managed policy, use AllViewerExceptHostHeader instead of AllViewer to avoid 404 responses caused by forwarding the viewer's Host header.
Authorization header: If the application uses the viewer's Authorization header, include it in the cache policy for every cache behavior that uses the origin.
Global endpoints: OAC does not support global endpoints that include opt-in Regions. All associated Regions must be enabled by default.
Lambda@Edge: Origin request and origin response triggers are not supported on cache behaviors that use a Lambda Web Function origin with OAC.

Verification

To verify the configuration, I first sent a request directly to the Lambda Web Function endpoint using curl.

curl -i https://<LAMBDA_WEB_FUNCTION_ENDPOINT>

Output:

The 403 Forbidden response is consistent with the endpoint requiring IAM-signed requests. The direct request did not return the default application response.

I then sent a request through the CloudFront distribution.

curl -i https://<CLOUDFRONT_DOMAIN>

Output:

The successful 200 OK response confirms that the request through CloudFront received a successful response from the configured origin. The response also included X-Cache: Miss from cloudfront, consistent with the managed CachingDisabled policy used during testing.

Analysis

From testing, direct requests to the Lambda Web Function endpoint returned 403 Forbidden, while requests through CloudFront returned 200 OK. These results are consistent with OAC restricting the origin to requests from the configured CloudFront distribution through signed origin requests and the resource-based policy.

This integration allows serverless web applications running on Lambda Web Functions to use CloudFront's content delivery and security capabilities while restricting direct access to the origin through Origin Access Control (OAC).

Based on the capabilities AWS describes, this setup suits workloads such as:

Serverless web applications that need custom domains and managed TLS certificates
Web applications that benefit from CloudFront caching
Applications that need additional application-layer protection through AWS WAF
Applications that require controlled access to the origin through OAC

According to AWS, OAC restricts access to the Lambda Web Function so that it is reachable only through CloudFront. This allows CloudFront to serve as the entry point while keeping direct access to the origin restricted.

Conclusion

Based on this hands-on test, Amazon CloudFront support for AWS Lambda Web Functions allows CloudFront to serve as the entry point for serverless web applications while restricting direct access to the origin through Origin Access Control (OAC). The successful HTTP response through CloudFront and the rejected direct endpoint request match the expected behavior of the configured setup.

For applications built on Lambda Web Functions, this integration provides a way to use CloudFront's delivery and security capabilities without requiring changes to application code.

CloudFront support for AWS Lambda Web Functions is available worldwide except in the CloudFront China Regions, with no additional fees for the integration.

An Agent That Remembers: Short-Term and Long-Term Memory on AgentCore

Pin Xiong — Sun, 18 Oct 2026 04:51:01 +0000

An agent that forgets when the reply finishes is the right default and the wrong behaviour for a reorder assistant. This article adds memory to one and proves it three ways: a preference survives into a new session, three managers never see each other's memory, and a failed restock is quoted back seventeen minutes later. Every number was measured in one account, in us-east-1.

The use case

Northwind Gear runs forty stores and restocks them every Monday. A store manager told the reorder assistant, once, that only the North China region matters to them. The next Monday, in a new session, the assistant asked which region again. Nothing was wrong with the model: the sentence never left the session it was said in.

What AgentCore does here

Three of the nine capabilities carry this use case.

Memory: one resource holds both halves. Short term is an append-only event log keyed by actor and session; long term is what the service extracts from those events into namespaces. This article goes deep on that split.
Runtime: hosts app/aia_uc02/ as a managed endpoint, one microVM per session, which is why the session id matters.
Identity, lightly: the actor id becomes the partition key of the namespace and travels as --user-id. No Cognito pool here.

The other six stay off: no Gateway, no Policy, no Evaluations, no Code Interpreter, no Browser, and no Observability beyond the traces the runtime emits.

Requirements

Node.js 20 or newer (22.22.2 here), the AgentCore CLI 0.31.1, AWS CLI 2.x, uv 0.11.9
Python 3.10 to 3.14 on the host; the runtime target is PYTHON_3_13, set in the contract
An AWS account with Bedrock model access; region us-east-1 for everything
Model deepseek.v3.2, passed to the code through MODEL_ID
IAM permissions to create a runtime, its role, and a memory resource with an execution role; the CLI writes both roles

The code

https://github.com/pinxiong/bedrock-agentcore-in-action/tree/master/usecases/02-memory

02-memory/
├── agentcore/
│   ├── agentcore.json         # the runtime plus one memory with three strategies
│   └── aws-targets.json       # account 123456789012, region us-east-1
├── app/aia_uc02/
│   ├── main.py                # the agent: prompt, tool, actor resolution, entrypoint
│   ├── memory.py              # the only file that knows short term from long term
│   ├── model/load.py          # MODEL_ID -> BedrockModel
│   └── pyproject.toml         # dependencies packaged into the zip
└── tests/
    └── test_sanitize.py       # offline unit tests for the sanitizer, no AWS

memory.py is the subject of the article; agentcore.json decides the namespace layout.

How it works

The memory resource is declared once, and the strategies decide what long-term records exist at all:

"memories": [{
  "name": "aia_uc02_mem",
  "eventExpiryDuration": 30,
  "strategies": [
    {"type": "USER_PREFERENCE", "namespaceTemplates": ["/users/{actorId}/preferences"]},
    {"type": "EPISODIC",        "namespaceTemplates": ["/episodes/{actorId}/{sessionId}"],
                                "reflectionNamespaceTemplates": ["/episodes/{actorId}"]},
    {"type": "SEMANTIC",        "namespaceTemplates": ["/users/{actorId}/facts"]}
  ]
}]

The actor id sits inside the namespace, so isolation is a property of the key space rather than a filter some code path has to remember. The reflection namespace sits one level up, so a prefix read of /episodes/{actorId}/ reaches a single episode and the lessons written across all of them.

The agent never stores a preference itself. It appends the turn and asks a question:

def remember(self, actor, session_id, turns):
    # ... the real one wraps this in try/except and returns None on failure
    event = self.client.create_event(
        memory_id=self.memory_id, actor_id=actor,
        session_id=session_id, messages=turns)
    return event.get("eventId")

def recall(self, actor, query):
    # ... condensed: the real one also drops records whose text is empty,
    # and continues past a namespace that failed instead of falling through
    found = []
    for label, ns, by_path in (("preference", f"/users/{actor}/preferences", False),
                               ("fact", f"/users/{actor}/facts", False),
                               ("episode", f"/episodes/{actor}/", True)):
        try:
            kwargs = {"memory_id": self.memory_id, "query": query, "top_k": TOP_K}
            kwargs["namespace_path" if by_path else "namespace"] = ns
            found += [{"kind": label, "text": _text(r)}
                      for r in self.client.retrieve_memories(**kwargs)]
        except Exception as exc:  # one bad namespace is not fatal
            log.warning("uc02 recall failed for %s: %s", label, exc)
    return found

Writing the event starts extraction, which is how a later session finds a sentence the earlier one said. It is not part of the invoke: the call returned in 17 seconds, the record arrived later.

Retrieval runs before the model, because the records become part of the system prompt:

records = store.recall(actor, prompt) if store else []
agent = Agent(
    model=load_model(),
    system_prompt=f"{SYSTEM_PROMPT}\n\nWhat you remember about this manager:\n{render(records)}",
    # ... tools=list(TOOLS) and conversation_manager=NullConversationManager() too
)

A fresh Agent per invoke: a cached one would keep serving the first turn's memories. A retrieval failure is logged and swallowed.

Deploy it

From the use case folder:

agentcore deploy -y --target default

Wall clock: 4 minutes 20 seconds, ending in a memory id and a runtime ARN.

agentcore status

One contract, so one deploy creates both halves, and the memory names its three strategies: the cheapest proof the extraction was requested.

agentcore invoke --user-id store_manager_south --session-id 7d1f4a0c9b2e4d38a5c6e7f801234567-229cdb2d \
  --prompt "From now on, only reorder for the South China region. Ignore every other region."

A new session, four minutes later:

agentcore invoke --user-id store_manager_south --session-id 8b2c5d1e0f3a4b6c9d8e7f6054321098-33438667 \
  --prompt "Draft this week's reorder list."

255 seconds separate the event from the answer, and this session never saw the sentence. Only the memory resource could have supplied it.

agentcore invoke --user-id store_manager_east --session-id 9c3d6e2f1a4b5c7d8e9f0a1b23456789-584aa045 \
  --prompt "From now on, only reorder for the East China region. Ignore every other region."

agentcore invoke --user-id store_manager_east --session-id 0d4e7f3a2b5c6d8e9f0a1b2c34567890-37ad719d \
  --prompt "Draft this week's reorder list."

236 seconds after its own event, the eastern manager is answered for East China. Now the same question to the southern one, seconds later:

agentcore invoke --user-id store_manager_south --session-id 1e5f8a4b3c6d7e9f0a1b2c3d45678901-4a0d1bea \
  --prompt "Draft this week's reorder list."

Two actors, one prompt, two answers, no overlap: the actor id is part of the key.

agentcore invoke --user-id store_manager_east --session-id 2f6a9b5c4d7e8f0a1b2c3d4e56789012-0fa33c38 \
  --prompt "I tried restocking my stores from the Guangzhou warehouse last month. It failed: the lead time was 9 days and three stores stocked out. Make a note of it."

Seventeen minutes later, nobody re-sends that sentence:

agentcore invoke --user-id store_manager_east --session-id 3a7b0c6d5e8f9a1b2c3d4e5f67890123-31527d8a \
  --prompt "Is it a good idea to ship this week's East China restock from the Guangzhou warehouse?"

1,022 seconds after the episode was written, the answer recommends against Guangzhou and names the 9-day lead time: the episodic strategy recalling an event by meaning.

Every invoke left a trace:

agentcore traces list

agentcore traces get 6ad46781381df402758baa6d42b96dd3

Three RetrieveMemoryRecords calls at 349, 268 and 262 milliseconds, one per namespace, then invoke_agent at 2,228 milliseconds with 1,400 input and 94 output tokens. Memory work happens before the model runs, which is what the code promises.

aws resourcegroupstaggingapi get-resources --tag-filters Key=Project,Values=agentcore-in-action --region us-east-1

Four resources, all this use case.

Teardown is two commands, and the second one deletes:

agentcore remove all -y
agentcore deploy -y --target default
agentcore status

remove all empties the local contract and deletes nothing on AWS; the deploy after it reconciles the stack to nothing in 4 minutes 13 seconds, and the tag query then returns zero rows. Both JSON files are emptied, so restore them from git.

What it produced

Three actors, three namespaces, one prompt producing two different lists. Extraction lag was 255 seconds for a preference and 1,022 for an episode, which decides every deadline you write.

A prefix read of /episodes/store_manager_east/ returns a BASE episode filed under its session and a REFLECTION written one level up, hence the {sessionId} in one template and not the other.

Troubleshooting

Invalid length for parameter runtimeSessionId, value: 22, valid min length: 33. Short readable session ids fail before they are sent. Build them from two uuid4 halves, because one hex uuid is 32 characters, one short of the minimum.
The actor id sent as -H x-amzn-bedrock-agentcore-runtime-custom-actor-id: ... never reached the agent, and the reply described the northern manager's memory because the code fell back to its default actor. Send it as --user-id, which arrives as x-amzn-bedrock-agentcore-runtime-user-id, and log the header names you receive once. This cost one deploy to find and is kept in evidence/27.
Episodic extraction took 17 minutes, so a 300-second deadline can only fail. Choose the deadline from a measurement.
remove all needs -y in any non-interactive shell, and it empties agentcore.json and aws-targets.json. Restore both from git before deploying again.

Takeaways

Memory is two mechanisms: an event log you write, and records the service extracts. Only the second reaches a new session.
Put the actor id inside the namespace template. Isolation then costs nothing and cannot be forgotten in a code path.
Extraction is asynchronous and slow, and strategies differ. Every assertion needs a deadline longer than the slowest one.
Send the actor id with --user-id and verify it arrived. A silent fallback to a default actor looks like working memory and is the opposite.
Teardown is real: remove all empties the contract, the deploy after it does the deleting.

Your First Agent as a Service: Deploying a Support Agent on AgentCore

Pin Xiong — Sun, 18 Oct 2026 02:43:35 +0000

A support team wants its first automation. This article is the walkthrough: one folder, one contract, and the agentcore and aws commands that deploy it, prove it, and delete it again. Every command below was run while writing this, and every figure is that command's captured output.

The use case

A three-person support desk answers the same questions all day: refund totals, return windows, policy lines. They want a first automation, and nobody on the team has ever put a service in production. The ask is not intelligence, it is a loop they can trust: write something small, make it callable from anywhere, see what it did afterwards, and be able to delete it the same day.

What AgentCore does here

Two of the nine AgentCore capabilities carry this use case.

Runtime: hosts app/aia_uc01/ as a managed endpoint. The build is CodeZip, so nothing is containerized; each session gets its own microVM; the protocol is plain HTTP over /ping and /invocations.
Observability: every invoke emits OpenTelemetry spans into X-Ray, so the tool call is visible as its own span and not just as text in a log.

The other seven stay off. No Memory, so the agent keeps nothing between turns. No Gateway and no Identity, because the desk has no external systems to reach yet. The runtime is version 1 behind the DEFAULT endpoint; changing the JSON and redeploying produces version 2, which is the whole versioning story at this level.

Requirements

Node.js 20 or newer (22.22.2 here), the AgentCore CLI 0.31.1, AWS CLI 2.x, jq 1.7.1, uv 0.11.9
Python 3.10 to 3.14 on the host; the runtime target is PYTHON_3_13, set in the contract
An AWS account with Bedrock model access; region us-east-1 for everything
Model: deepseek.v3.2, passed to the code through the MODEL_ID environment variable

The code

https://github.com/pinxiong/bedrock-agentcore-in-action/tree/master/usecases/01-first-agent

01-first-agent/
├── agentcore/
│   ├── agentcore.json         # the contract: what gets deployed
│   └── aws-targets.json       # account 123456789012, region us-east-1
├── app/aia_uc01/
│   ├── main.py                # the agent: prompt, tool, sanitizer, entrypoint
│   ├── model/load.py          # MODEL_ID -> BedrockModel
│   ├── model/sanitize.py      # strips chat-template scaffolding from the stream
│   └── pyproject.toml         # dependencies packaged into the zip
└── tests/
    └── test_sanitize.py       # six offline cases for the sanitizer, no AWS

Two JSON files are the whole contract; main.py is the whole agent. The folder ships no script of its own: every operation below is an agentcore or aws command.

How it works

The whole agent surface fits in one screen of main.py:

SYSTEM_PROMPT = """You are the first-line assistant for the Northwind Gear
support desk. Answer in one short sentence.
When a question involves arithmetic, call the add_numbers tool instead of
working it out yourself, then state the result in one short sentence.
You have no order database, no ticket history and no account lookup. When a
question needs one of those, say you cannot see it instead of guessing."""

@tool
def add_numbers(a: int, b: int) -> int:
    """Return the sum of two numbers."""
    return a + b

@app.entrypoint
async def invoke(payload: Any, context: Any):
    session_id = getattr(context, "session_id", "default-session")
    agent = get_or_create_agent(session_id)
    scrub = StreamSanitizer()
    async for event in agent.stream_async(extract_prompt(payload)):
        ...  # every text delta passes through scrub.feed() before it is yielded

The prompt is the product. The tool exists so the trace has something to show; an agent that never calls a tool produces a single span and proves little. The entrypoint is an async generator, which is why streaming is the default shape here rather than an add-on.

The part worth copying is the filter around the stream. DeepSeek models sometimes write fragments of their own chat-template markers, such as <|DSML|function_calls, into the ordinary text channel. The sanitizer holds back a short suffix that could still grow into a marker, resets once per assistant message, and flushes what is left when the message ends:

if "messageStart" in inner:
    scrub = StreamSanitizer()      # one clean filter per assistant message
    block_index = 0
    yield event
    continue
...
clean = scrub.feed(delta["text"])  # tool-use deltas pass through untouched
if clean:
    yield _text_delta(clean, block_index)

Its six cases live in tests/test_sanitize.py and run offline, no AWS involved, because a filter you cannot test cheaply is a filter you will delete.

Model selection is one function, because the default matters:

def load_model() -> BedrockModel:
    return BedrockModel(model_id=os.environ.get("MODEL_ID", DEFAULT_MODEL_ID))

If MODEL_ID is missing, an SDK default can pick a model your region refuses; passing the id explicitly is what keeps the first deploy from failing on geography.

Deploy it

From the use case folder, one command builds the zip, synthesizes the CloudFormation and creates the stack:

agentcore deploy -y --target default

The stack this contract produces is four resources: an AWS::BedrockAgentCore::Runtime, the AWS::IAM::Role it runs as, that role's AWS::IAM::Policy, and AWS::CDK::Metadata (recorded in evidence/23-stack-resources.txt). The deploy log splits the total: 4.1 s synthesizing CloudFormation, 1 m 17 s creating the stack, 1 m 31 s end to end. Then status, and one real invoke:

agentcore status

agentcore invoke --prompt "A customer returns two items priced 21 each. What refund total should I quote? Use the tool."

What the deploy produced is provable from the CLI alone; the four things an assertion script used to check are four things this output shows.

agentcore status printed Deployed - Runtime: READY and the runtime ARN, so the runtime exists in us-east-1 and can serve traffic.
agentcore invoke answered a tool-using prompt with the right arithmetic and no model scaffolding in the reply.
The invoke left a trace, listed below, whose span tree contains an execute_tool span.
aws resourcegroupstaggingapi get-resources returned three rows, all tagged UseCase=01: no other use case's resources are in the account.

agentcore traces list

agentcore traces get 6ad45817558974710d8c3b6d35f5a089

jq -r '[.[] ."@message" | select(type == "object" and .name != null)] as $spans
  | ($spans | map({(.spanId): .name}) | add) as $parent
  | $spans | sort_by(.startTimeUnixNano) | .[] | (.attributes // {}) as $a
  | [.name, .kind, (((.durationNano // 0) / 1000000 | floor | tostring) + " ms"),
     (if $a["gen_ai.usage.input_tokens"] then ($a["gen_ai.usage.input_tokens"] | tostring) + " in / " + ($a["gen_ai.usage.output_tokens"] | tostring) + " out" else "-" end),
     ($parent[.parentSpanId // ""] // "root")] | @tsv' \
  agentcore/.cli/traces/aia_uc01-6ad45817558974710d8c3b6d35f5a089.json | column -t -s $'\t'

aws resourcegroupstaggingapi get-resources --tag-filters Key=Project,Values=agentcore-in-action \
  --region us-east-1 --query 'ResourceTagMappingList[].{arn:ResourceARN,tags:Tags[?Key==`UseCase`].Value|[0]}' --output text

Teardown is two commands, and the second one does the deleting. agentcore remove all empties the local contract; the deploy that follows reconciles the stack to nothing:

agentcore remove all -y
agentcore deploy -y --target default
agentcore status

Six commands, and the loop closes where it started: nothing deployed, nothing tagged, one trace kept.

What it produced

The invoke is unremarkable on purpose: one sentence, the right arithmetic, nothing else. The interesting artifact is the span tree, and it reads like the agent loop drawn by the runtime itself:

The execute_tool span is the point. It is what separates "the model said 42" from "the tool computed 42 and the model reported it", and it only exists on the deployed runtime; traces from a local agentcore dev session record the tool call in logs but not as a span.

Cost, measured on this run: the traced invoke used 955 input and 81 output tokens, which at deepseek.v3.2 prices in us-east-1, 0.62 and 1.85 USD per million tokens, is 0.00074 USD of model calls. The runtime bills per use, so an idle deployed agent costs nothing, and the teardown leaves nothing tagged behind.

Troubleshooting

agentcore remove all without -y dies in a non-interactive shell with "This command requires an interactive terminal". Any piped or CI run hits this. The fix is the -y flag, and it is not optional in a script.
agentcore remove all -y resets every schema in agentcore.json and empties aws-targets.json, so the next deploy has no target and agentcore status answers No resources match the given filters. Restore both files from git before you deploy again.

Takeaways

The contract is two JSON files; everything else on the AWS side is generated, so the deploy is reproducible and the teardown is real.
CodeZip means no Dockerfile: the platform zips codeLocation, and the runtime version and endpoint come from the same contract.
An agent is not observable until a tool call has its own span; agentcore traces get plus jq is the whole proof, no test harness required.
A stream sanitizer belongs in the entrypoint from day one, because scaffolding leaks are intermittent and a test-only filter rots.
The full loop, measured: deploy 1 m 31 s, invoke 9 954 ms, teardown 1 m 40 s, and remove all -y to deploy -y in that order.

Mastering Amazon EC2: Compute, Storage, Networking and Recovery

Venkata Pavan Vishnu Rachapudi — Sat, 17 Oct 2026 16:41:22 +0000

Amazon EC2 is still one of the most important building blocks of AWS. But working with EC2 is about much more than launching an instance.

I'm excited to share my book, Mastering Amazon EC2: Compute, Storage, Networking and Recovery, a practical guide to how EC2 works in real-world environments.

It covers EC2 fundamentals, secure access, IAM, VPC networking, EBS, AMIs, load balancing, Auto Scaling, monitoring with CloudWatch and Amazon Q, backup with AWS Backup, migration with AWS Transform MGN, and disaster recovery.

Every chapter ends with a hands-on lab in your own AWS account, and field stories from production work show what happens when things break.

It's written for cloud engineers, DevOps engineers, platform engineers, AWS learners, and anyone preparing for AWS certifications, in India and across the global AWS community.

The goal is simple: help you move from launching EC2 instances to securing, scaling, monitoring, and recovering production workloads.

📘 Available on Amazon:
🇮🇳 India: https://www.amazon.in/dp/B0HN5TCVML
🌍 Global: https://www.amazon.com/dp/B0HN5TCVML

Would love you're views

What does your CDK app cost when nobody is using it?

kazuho cryer-shinozuka — Sat, 17 Oct 2026 13:44:59 +0000

Here is a sample CDK app with four stacks. Nobody is calling it. No requests, no data, no users.

ap-northeast-1 · 4 stacks · idle ≈ $382/mo

DataStack                                    $196/mo
  Aurora/writer                 ×0.5 ACU      $55  Serverless v2 minimum capacity
  Search                        ×1            $41  t3.small.search data nodes
  Search                        ×20 GB gp3  $2.93  EBS storage
  Db                            ×1            $36  db.t4g.micro postgres Multi-AZ
  Db                            ×20 GB gp3  $5.52  storage
  ...

NetworkStack                                  $69/mo
  Vpc/PublicSubnet1/NATGateway  ×1            $45  NAT Gateway
  Vpc/SsmEndpoint               ×2 AZ         $20  interface endpoint
  Vpc/PublicSubnet1/EIP         ×1          $3.65  public IPv4 address

? could not estimate: 1
  AppStack  ParamInstance  InstanceType is Parameter WorkerType

prices: bundled snapshot 2026-10-15 · on-demand list prices, 730 h/mo, USD, free tier ignored

It still costs about $382 a month. That output came from two commands:

cdk synth
npx cfn-idle-cost

cfn-idle-cost reads your cdk.out and prints the idle cost of the app: what you pay even when nobody uses it.

Why idle cost?

Most surprise AWS bills I have seen were not caused by traffic. They were caused by things that bill by the hour whether or not anyone uses them:

a NAT Gateway in every AZ of a dev VPC
interface endpoints, billed per AZ
an ALB in front of a service that gets ten requests a day
an RDS instance someone set to Multi-AZ "to be safe"
an Aurora Serverless v2 cluster that never scales below its minimum ACU
KMS keys, Secrets Manager secrets and CloudWatch alarms that add up one dollar at a time

In CDK, a single new ec2.Vpc(this, 'Vpc') creates NAT Gateways for you. That default is reasonable for production, but it is easy to miss when you copy the same stack into a sandbox account or a per-developer environment.

Cost Explorer tells you about this after the bill arrives. The AWS Pricing Calculator can tell you before, but you have to enter every resource by hand. cfn-idle-cost reads the template you already have.

What it does

Reads cdk.out directly, including Stages and nested stacks. Plain CloudFormation templates (JSON or YAML) work too.
Names each line by construct path (Vpc/PublicSubnet1/NATGateway), so you know which line of CDK code to change.
Runs offline with no AWS credentials. Prices come from a snapshot of the public AWS Bulk Price List bundled in the package and refreshed weekly. The same cdk.out gives the same numbers for a given version. Pass --live if you want current prices from the Price List Query API instead.
Never guesses. If a value can't be read from the template, such as a Parameter without a default or a reference to another stack, the resource is listed under ? could not estimate with the reason. A Parameter with a Default is estimated with that default, and the line says so.

It covers more than 70 resource types: NAT Gateways, EIPs, VPC endpoints, load balancers, EC2 and Auto Scaling groups, RDS and Aurora, OpenSearch, ElastiCache, DynamoDB provisioned capacity, Kinesis, Fargate services, EFS and FSx, EKS, Network Firewall, WAF, Lambda provisioned concurrency, Transit Gateway attachments, MWAA, and more. The full list is in the README.

Usage-only charges are left out on purpose: S3, Lambda invocations, Aurora storage and I/O, CloudWatch Logs, data transfer, requests. Those depend on traffic, and this tool answers a different question: what is the floor?

Catch it in the pull request

Knowing the current idle cost is useful. Knowing that a pull request is about to add $300 a month is more useful.

--base compares two synthesized apps and prints only what changes:

npx cfn-idle-cost --base cdk.out.main cdk.out

ap-northeast-1 · idle ≈ $382 → $682/mo (+$300)

  ~ DataStack     Db                              $42 →  $322   +$280  db.t4g.micro postgres Multi-AZ → db.t4g.large postgres Multi-AZ
  + NetworkStack  Vpc/PublicSubnet2/NATGateway  $0.00 →   $45    +$45  NAT Gateway
  - DataStack     Stream                          $28 → $0.00    -$28  provisioned shards
  + NetworkStack  Vpc/PublicSubnet2/EIP         $0.00 → $3.65  +$3.65  public IPv4 address

There is a GitHub Action that posts this as a pull request comment, updates it on every push, and fails the check when the increase is over your budget:

name: idle-cost
on: pull_request
permissions: { contents: read, pull-requests: write }
jobs:
  idle-cost:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v7
        with: { path: head }
      - uses: actions/checkout@v7
        with: { path: base, ref: "${{ github.base_ref }}" }
      - uses: actions/setup-node@v7
        with: { node-version: 22 }
      - run: npm ci && npx cdk synth -q
        working-directory: head
      - run: npm ci && npx cdk synth -q
        working-directory: base
      - uses: badmintoncryer/cfn-idle-cost@v1
        with: { base: base/cdk.out, path: head/cdk.out, max-increase: 50 }

Now the reviewer sees "+$280/mo: db.t4g.micro → db.t4g.large" next to the diff, instead of finding out from the bill a month later. Commit cdk.context.json so the synth doesn't need AWS credentials for lookups.

Outside GitHub Actions, --max <usd> and --max-increase <usd> make the CLI exit with code 3 when the budget is exceeded, so it fits into any CI.

What the numbers mean

On-demand list prices in USD, 730 hours a month.
Savings Plans, Reserved Instances and the free tier are ignored.
EC2 is priced as Linux with shared tenancy, because the AMI is not read.
An Auto Scaling group uses DesiredCapacity when set, otherwise MinSize.

In other words, it is the price list applied to your template, not a forecast of your bill. If you have a Savings Plan, your real number will be lower. That is fine: the point is to see what you are paying for and which construct it comes from.

Try it

cdk synth
npx cfn-idle-cost

You can also install it with Go (go install github.com/badmintoncryer/cfn-idle-cost@latest), and cdk-idle-cost is the same tool under another name. The npm packages cover Linux and macOS; on Windows, use go install or the binary from the GitHub Release.

I'd love to hear what number your app prints. If it lists a resource under ! not counted yet that matters to you, or if a price looks wrong, please open an issue. And if it saves you a NAT Gateway or two, a ⭐ on GitHub helps others find it.

I also maintain two other tools that read cdk.out before you deploy: cdk-preflight fails cdk synth on templates that are known to fail at deploy time, and cfn-exec-policy generates a least-privilege IAM policy for the CloudFormation execution role, so cdk bootstrap doesn't have to use AdministratorAccess. More on those in later posts.

Una novedad en Serverless bajo la lupa: AWS Lambda Web Functions

Laura Bolaños — Fri, 16 Oct 2026 19:52:02 +0000

Introducción

AWS anunció Lambda Web Functions, una forma de ejecutar aplicaciones web y APIs sobre Lambda ejecutando directamente un servidor HTTP de Node.js, sin adaptadores ni handlers por evento. Aquí te describo mi propio análisis.
Este artículo no pretende ser una guía de cómo usar Lambda Web Functions. Hago un recorrido corto por las características que importan, referencio blogs de colegas y muestro mi propio enfoque de cuándo utilizarla y cuando No.
Para no quedarme en la teoría, armé un pequeño playground con ejemplos: desde un agente de IA con streaming hasta microservicios simulando alto tráfico. Además, hice algunos experimentos de concurrencia y comportamiento de escalado.

Qué es una Lambda Web Function

Una Lambda Web Function es cómputo serverless que corre un servidor HTTP normal. Tu aplicación escucha en el host y puerto que Lambda te pasa en la variable AWS_LAMBDA_HTTP_ENDPOINT, exactamente el mismo código que correrías con node index.js en tu máquina. AWS te da el endpoint HTTPS, el TLS y el escalado; de tu parte toca escribir Express (o el framework que uses) sin adaptadores.

NO es un reemplazo universal de la Lambda de siempre que devuelve un event handler. Esta sigue siendo la opción natural para lo que es dirigido por eventos: procesar mensajes de una SQS, reaccionar a un evento de S3, consumir un stream. Tampoco es un servidor que tengas "siempre encendido": escala a cero cuando no hay tráfico. Y por ahora solo soporta runtime Node.js.

Lo que cambia de verdad

Muchos de los protocolos que vas a ver en las demos (REST, SSE, streaming, webhooks) ya se podían hacer antes de otra forma. Lo que cambia no son los protocolos, sino la forma de la Lambda:

Modelo de programación. Antes escribías un handler que recibía un evento; ahora escribís un servidor HTTP común que escucha en un puerto.
Concurrencia. En una Event Function, cada entorno atiende una petición a la vez. En una Web Function, un mismo entorno atiende varias en simultáneo, como un servidor Node común. Para algo que pasa casi todo el tiempo esperando (una base de datos, una API, un LLM), eso significa que muchas peticiones comparten un proceso en lugar de ocupar un entorno cada una.
Parámetros importantes

Parámetro	descripción
`maxConcurrencyPerEnvironment`	tope por entorno, 1–128, se configura en la revisión. El límite real puede ser menor, nunca mayor. Cambiarlo crea una nueva revisión
`maxEnvironments`	tope de entornos por región, se configura en el endpoint.
`rateLimit`	peticiones por segundo que acepta el endpoint, por región. Lo que supera rateLimit recibe 429. Lo mismo ocurre si no puede escalar más, pero mientras un entorno nuevo se inicializa, las requests esperan en cola. rateLimit se aplica por región, y sus valores deben ser múltiplos de 100 (hasta 1.000) o de 1.000 (por encima).
`maxEnvironments` y `rateLimit`	se cambian en caliente con `aws lambda-web update-web-function-endpoint`, sin redeployar; en cambio `maxConcurrencyPerEnvironment` sí obliga a hacer una nueva revisión de la Lambda.

Entrada y salida: HTTP crudo, no un payload. Una Event Function recibe un event (un JSON ya parseado) y devuelve otro JSON; nunca tocás HTTP a mano. Una Web Function recibe y devuelve HTTP/1.1 crudo: Lambda reenvía a tu app el método, el path, la query string, el body y casi todos los headers, y tu servidor (Express, Fastify, Hono o el framework de Node que prefieras) ve un Request/Response normal. Soporta GET, HEAD, POST, PUT, PATCH, OPTIONS y DELETE, solo HTTP/1.1 (un HTTP/1.0 lo rechaza con 505), y agrega headers de contexto como lambda-web-request-id. Es justo lo que te deja usar tu framework sin adaptador, pero el parseo y la validación del request quedan de tu lado.
Seguridad: el endpoint es público, el modo de auth define quién valida. Todo endpoint es alcanzable desde internet, tenga el auth que tenga. Hay dos modos: con IamAuth, Lambda valida la firma SigV4 y remueve el header Authorization antes de reenviar (la autorización la hace la plataforma); con ApplicationManaged, Lambda no auténtica nada y reenvía todo a tu app, así que conocer la URL alcanza para llegar y es necesario implementar la autenticación. Sumá a eso que algunos headers no son de fiar (X-Forwarded-Host llega sin validar; el cliente real está en el último valor de X-Forwarded-For) y que validar input, tamaño de request y abuso es responsabilidad de tu código o de un front door.
Facturación: Pagás CPU activa y memoria mientras el entorno exista. No se cobra tiempo de reloj. Una petición que espera a una base de datos o a una API externa consume poca CPU, y esa espera casi no se cobra.
Proceso de larga vida. El entorno no se congela entre peticiones → hay estado global, conexiones reutilizadas y tareas en segundo plano.

⭐ Para el detalle de cada protocolo, el recorrido de edjgeek lo cubre muy bien, y el repositorio de ejemplos que acompaña ese blog muestra REST, SSE, NDJSON y webhooks funcionando.

Dónde NO lo usaría

Hay varios escenarios donde esta tipo de Lambda no aplica:

Request/response simple y de bajo volumen. Un formulario que dispara un mail, o una Lambda que devuelve un JSON corto cada tanto. Ahí una Event Function con su function URL es más simple y suficiente; migrar no te da ningún beneficio.
Trabajo dirigido por eventos. Procesar una cola SQS, reaccionar a un archivo en S3, consumir un stream. Eso es territorio de las Event Functions, y la propia documentación lo recomienda así.
Tareas largas. El timeout de una petición llega hasta 900 s (15 min). Si tu proceso puede tardar más, no entra en una sola petición: hay que partirlo o usar otro mecanismo.
WebSockets o HTTP/2. no mantiene conexiones bidireccionales persistentes de tipo TCP Upgrade abiertas directamente hacia el entorno de ejecución de la Lambda de forma continua. Si este es tu caso no se resuelve por aquí.
En Tareas multi-paso elegimos Lambda durable functions. Pensadas para flujos de trabajo resilientes de varios pasos que pueden durar hasta un año, con checkpoints, reintentos y estados de espera que no consumen cómputo mientras aguardan. Casos de uso: procesar pagos, orquestar pedidos, flujos con aprobación humana o workflows de IA de varios pasos.

⭐ La regla práctica: si tu carga no es "un servidor HTTP que atiende tráfico concurrente", probablemente Lambda Web Functions no corresponda a tu caso de uso.

¿Reemplaza a API Gateway / function URLs?

Una Web Function ya trae su propio endpoint HTTPS. Pero reemplaza en los casos simples, no es un reemplazo directo.

Pensemos primero en las function URLs, la URL pública de una Lambda común. Desde el lado del cliente, para un request/response sencillo, casi no hay diferencia: hacés una petición HTTP y recibís una respuesta. Si lo que tenés es una Lambda con su URL devolviendo un JSON corto, migrar a Web Functions no te cambia nada visible. Donde empieza a tener sentido es cuando aparece concurrencia con mucha espera, streaming, o una app con framework y varias rutas.

Con API Gateway la cuestión es diferente, porque son de distinta naturaleza: una Web Function es cómputo con un endpoint incluido, y API Gateway es una puerta de entrada que se pone delante del cómputo.

Si tenés una app con su propio router (Express, Hono, Fastify), antes necesitabas API Gateway para exponerla; ahora el endpoint ya viene con HTTPS, autenticación y un límite global de peticiones. Para APIs internas o servicios entre equipos, eso suele alcanzar.

Pero API Gateway sigue teniendo sentido como front door. La propia documentación de buenas prácticas recomienda poner CloudFront o API Gateway delante del endpoint cuando necesitás dominio propio, inspección con WAF, caché o controles centralizados en el borde. Y hay features que API Gateway te da y la Web Function no: planes de uso y API keys por cliente, authorizers (JWT, Cognito), cuotas por consumidor. El límite de peticiones de la Web Function es un tope por endpoint y región, no por cliente.

⭐ Para una app o microservicio con su propio router, Lambda Web Functions te AHORRA una capa. Para una API pública con múltiples consumidores, cuotas y políticas en el borde, seguís necesitando API Gateway o CloudFront según el caso.

Casos de Uso del playground

Construí ejemplos sencillos que pueden servirte para llevar a la práctica rápidamente tus casos de uso.

📦 Aquí vas encontrar ejemplos con dos maneras de desplegar: manualmente por la CLi o via SAM : github.com/reinalau/lambda-web-functions-playground

Lambda Web Functions ya es compatible con IaC:
AWS CloudFormation ( "AWS::Lambda::WebFunction resource").
AWS CDK (L2 constructs available)
AWS SAM

Un agente strands harness con streaming

Es un agente de IA hecho con strands harness, que responde preguntas sobre el clima y ayuda a planificar viajes. Recibe un mensaje, llama a herramientas que consultan una API pública (Open-Meteo), razona sobre los datos y devuelve la respuesta al navegador token a token por SSE. Mantiene la conversación entre turnos, recuerda lo que ya le dijiste.

%%{init: {"theme": "base", "themeVariables": {"fontSize": "30px"}}}%%
flowchart LR
    Client["Client / browser"] -->|"POST /chat"| Agent["weather-agent<br />Lambda Web Function (Express)<br />Strands harness"]
    Agent -->|"SSE: stream tokens"| Client
    Agent -->|"InvokeModelWithResponseStream"| Bedrock["Amazon Bedrock<br />Nova 2 Lite"]
    Agent -->|"tools (no API key)"| OpenMeteo["Open-Meteo API<br />geocode + forecast"]
    Agent -->|"SessionManager<br />by conversationId"| S3[("Amazon S3<br />session state")]

    style Client fill:#2563eb,stroke:#1e40af,color:#ffffff
    style Agent fill:#f59e0b,stroke:#b45309,color:#ffffff
    style Bedrock fill:#15803d,stroke:#0f5027,color:#ffffff
    style OpenMeteo fill:#64748b,stroke:#475569,color:#ffffff
    style S3 fill:#4ade80,stroke:#16a34a,color:#063d1e

Por qué con Web Functions y no con otra cosa → Este caso pasa casi todo el tiempo esperando al modelo y a las herramientas, consumiendo muy poca CPU, y esa espera casi no se cobra. Además:

El modelo de servidor HTTP me deja usar el harness de Strands y Express tal cual, sin reescribir nada como handler ni armar un adaptador.
El streaming de tokens por SSE es nativo: devuelvo la respuesta a medida que se genera, sin esperar a tenerla completa.
La concurrencia por entorno significa que muchas conversaciones conviven en el mismo proceso mientras esperan al LLM, en vez de ocupar un entorno entero cada una (como pasaría con una Event Function).

En una Event Function con function URL pagaría el tiempo de reloj completo de cada conversación y ocuparía un entorno por request. Acá no.

La implementación: Es Express corriendo como Web Function. El agente usa el harness de Strands (TypeScript) con builtinTools: [] para dejar solo las dos herramientas de clima (nada de shell ni acceso a archivos: menor superficie), sobre un modelo Amazon Nova en Bedrock.

El punto fino es el estado: como el entorno es efímero y no hay afinidad de sesión, la conversación no puede vivir en memoria; se persiste fuera, en S3, usando el SessionManager del SDK. Cada conversación se identifica por un id, y cualquier entorno puede retomarla. El detalle completo lo encontrás en el README del ejemplo.

Un BFF con microservicios (pedidos + inventario)

Este ejemplo consta de dos Lambda Web Functions que modelan un patrón BFF + microservicios, sin IA: solo API y DynamoDB. Un servicio orders (el BFF, público) recibe un pedido, reserva stock llamando a un servicio inventory (privado) y persiste el pedido. inventory expone el stock y lo reserva con un UpdateItem condicional que nunca lo deja en negativo (devuelve 409 si no alcanza).

Este caso es de un "backend de alto tráfico que espera mucho I/O": cada pedido llama a otro servicio y a una base de datos, y pasa la mayor parte del tiempo esperando esas dos cosas.

%%{init: {"theme": "base", "themeVariables": {"fontSize": "28px"}}}%%
flowchart LR
    Client["Client"] -->|"POST /orders (no signing)"| Orders["orders BFF<br />Lambda Web Function<br />ApplicationManaged"]
    Orders -->|"SigV4-signed call<br />service: lambda<br />x-amz-content-sha256"| Inventory["inventory<br />Lambda Web Function<br />IamAuth (private)"]
    Orders -->|"PutItem"| OrdersDB[("DynamoDB<br />orders table")]
    Inventory -->|"conditional UpdateItem<br />reserve stock or 409"| InventoryDB[("DynamoDB<br />inventory table")]

    style Client fill:#22c55e,stroke:#15803d,color:#ffffff
    style Orders fill:#f59e0b,stroke:#b45309,color:#ffffff
    style Inventory fill:#f59e0b,stroke:#b45309,color:#ffffff
    style OrdersDB fill:#3b82f6,stroke:#1d4ed8,color:#ffffff
    style InventoryDB fill:#3b82f6,stroke:#1d4ed8,color:#ffffff

Algunas características:

El servidor HTTP deja usar Express con su router tal cual; orders enruta por dentro y no necesito una función por ruta ni API Gateway delante.
La concurrencia por entorno deja que muchas peticiones convivan en el mismo proceso mientras esperan a inventory y a DynamoDB.
Cada servicio escala por separado: un pico en el BFF no obliga a sobredimensionar el inventario.

Comunicación entre servicios con IamAuth. La mayoría de las reseñas lo pasa por alto: inventory es privado (IamAuth), así que orders no lo invoca con un SDK → tiene que firmar la petición HTTP con SigV4 usando el servicio lambda, e incluir siempre la cabecera x-amz-content-sha256 (Lambda la usa como hash del payload en vez de leer el body).

El rol de orders necesita el permiso lambda:InvokeWebFunctionEndpoint sobre el endpoint de inventory, y Lambda elimina la cabecera Authorization antes de reenviar la request a la aplicación. Para endpoints multi-región la firma pasa a SigV4a.

La implementación: Dos servicios Express en TypeScript, cada uno su propia Web Function con su rol de mínimo privilegio. inventory guarda el stock en DynamoDB y hace la reserva atómica; orders firma su llamada a inventory, y si la reserva sale bien persiste el pedido en otra tabla. El detalle (despliegue ordenado, IAM y la receta de firma) está en el README del ejemplo.
Hice dos experimentos de caga sobre el BFF. Los números salen de los eventos de CloudWatch (invokeReport / initReport).

Experimento 1 ➡ Carga: ¿cuánta CPU se cobra?

Objetivo: analizar con tráfico concurrente qué fracción del tiempo del entorno se factura como CPU. 500 pedidos, 50 en paralelo (no 500 a la vez: 500 en total).

Métrica	Valor
Pedidos (todos `201`)	500
Tiempo de reloj	15 s
Entornos creados	61
Pico de concurrencia por entorno	2
CPU activa de serving (toda la flota)	~49 s
CPU de arranque (toda la flota)	~22 s
Vida de servicio sumada	~24.461 s

Análisis: la CPU de serving (~49 s) es ~0,2% de la vida de servicio sumada (~24.461 s). Cuidado con la lectura: ese 99,8% restante no es todo "espera de I/O". La carga duró 15 s, pero cada entorno siguió vivo ~400 s hasta escalar a cero, así que la mayor parte es ocio del entorno después de la carga, no espera por request. El punto importante, ese tiempo no se cobra como CPU (la memoria sí se cobra mientras el entorno exista). Medir la espera de I/O por request requiere los eventos requestComplete (nivel DEBUG), que no lo activé acá.

⭐ Un detalle de la concurrencia: 50 pedidos en paralelo deberían caber en pocos entornos (uno atiende hasta 64), pero se abrieron 61 con un pico de solo 2 por entorno. No es un parámetro que faltó setear como maxConcurrencyPerEnvironment porque solo fija el techo. Por debajo, Lambda usa un límite dinámico por entorno que ajusta según el uso de recursos, y lo baja cuando cada request consume CPU (acá, la firma SigV4). Con poca concurrencia por entorno, Lambda abre más entornos, y cada uno paga su arranque: eso explica el costo del Experimento 2. La ventaja de "menos entornos por concurrencia compartida" frente a una Event Function es real, pero el reparto lo decide la plataforma, no tu config.

Experimento 2 ➡ ¿Cuánto cuesta un pedido?

Objetivo: separar el costo de arranque del trabajo real por pedido. Dos corridas: 1 pedido en un entorno frío, y 200 pedidos secuenciales en el mismo entorno caliente.

Corrida	Pedidos	CPU total
Entorno frío	1	~780 ms
Entorno caliente	200	~2.600 ms

Análisis: el costo marginal por pedido es (2.600 − 780) / 199 ≈ 9 ms. O sea, un pedido en caliente cuesta ~9 ms de CPU (SigV4 + JSON + la parte de CPU del I/O), pero el primer pedido de un entorno frío cuesta ~780 ms (arranque de Node + carga del SDK + primera conexión), unas 85 veces más. En una Web Function, lo que domina el costo de CPU es cuántos entornos se abren, no cuántos pedidos se atienden.

Conclusiones

Lambda Web Functions no viene a reemplazar a la Lambda de siempre, suma una forma más, junto a las Event Functions y las durable functions. Su enfoque es claro: cargas que son, en esencia, un servidor HTTP atendiendo tráfico concurrente que pasa la mayor parte del tiempo esperando I/O. Ahí el modelo encaja muy bien.

Las ventajas que comprobé en el playground

Código de servidor común (Express) sin adaptadores, que corre igual en local y en AWS.
Concurrencia por entorno: cada entorno atiende varias peticiones mientras esperan I/O.
Facturación por CPU activa: en la prueba del BFF, la CPU de serving fue ~0,2% de la vida de los entornos; la espera de I/O casi no se cobra.
Streaming nativo (el SSE del agente) sin configuración extra.
Controles en el endpoint (rateLimit, maxEnvironments) para proteger a las dependencias que están detrás, como una base de datos.
Comunicación privada entre servicios con IamAuth, aunque exige firmar las peticiones a mano con SigV4.

Sobre migrar

Si ya tenés una app Express o Hono corriendo en Lambda con un adaptador, la migración es mayormente quitar el adaptador y escuchar en AWS_LAMBDA_HTTP_ENDPOINT. Si viene de handlers por evento, hay que reescribirla como servidor. En los dos casos no conviene cambiar todo de golpe: las revisiones y los pesos por revisión del endpoint permiten hacer un canary (mandar un porcentaje del tráfico a la versión nueva y volver atrás si algo falla), que es lo que recomienda la guía de buenas prácticas para producción. Y antes de migrar, conviene preguntarse si hay algo para ganar: un endpoint de bajo volumen con request/response simple no mejora.

Un punto importante, aunque lo nombre muchas veces en estas notas, es que hoy solo ofrece runtime con node.js.

Medir antes de decidir

Los números del playground salen de una simulación. Sirven para entender el modelo, no para cotizar. La documentación recomienda hacer pruebas de carga con las mismas dependencias que en producción, subiendo la concurrencia hasta ver qué se agota primero (latencia, CPU, memoria o la base de datos), y revisar antes las cuotas de la cuenta y de la región. Con esos resultados se ajustan maxConcurrencyPerEnvironment, maxEnvironments y rateLimit. El costo real hay que verlo en la factura: la memoria se cobra durante toda la vida del entorno, y lo que más mueve la CPU no es el trabajo por pedido (~9 ms en caliente en el BFF) sino cuántos entornos se abren, porque cada uno paga su arranque (~780 ms el primer pedido de un entorno frío).

Lecciones aprendidas

La plataforma importa tu módulo a través de un wrapper, no lo ejecuta como entrypoint: el servidor tiene que arrancar al importarse.
/ping está reservado por la plataforma; para el health check hay que usar otra ruta.
Toda dependencia que use el código, incluido el AWS SDK, tiene que estar declarada en el package.json; si no, falla recién en runtime.
No hay afinidad de sesión y el entorno puede desaparecer en cualquier momento: el estado va afuera (S3, DynamoDB).
Los log groups se crean sin expiración; conviene fijar la retención.
Con SAM, CodeUri tiene que ser un objeto en un bucket S3 versionado: sam build no empaqueta código local para este recurso.
Es un servicio nuevo: hacen falta versiones recientes del AWS CLI y de SAM CLI.

Referencias

Serverless Highlights: October 2026 Week 1 AWS Announcements

Nadtakan Futhoem (Nad) — Fri, 16 Oct 2026 18:24:40 +0000

📅 Covering AWS announcements from **Oct 10, 2026, 00:00 – Oct 16, 2026, 23:59* (UTC).*

This week in AWS, we saw exciting developments across the serverless landscape! From new regional availability and feature enhancements to innovative use cases and integrations, the announcements promise to empower serverless developers like never before.

AI and Machine Learning Enhancements

AI AgentCore and Bedrock

AI and Data Processing

Data and Storage Enhancements

DynamoDB

S3 and EMR

Lambda Enhancements

Durable Functions

General Lambda

AWS Lambda durable functions increases durable operation and checkpoint payload limits

Application Recovery and Management

Security and Compliance

Regional Availability and Integrations

Your Serverless Guide to re:Invent 2026

Your serverless attendee’s guide to AWS re:Invent 2026

Disaster Recovery and Multi-Region Solutions

AWS Agent Registry

AWS Agent Registry now supports custom metadata for registry records

What this means

This week's announcements showcase AWS's continuous commitment to enhancing serverless capabilities and expanding regional availability. From AI and ML advancements to data processing improvements and security enhancements, developers now have more tools and options than ever to build, deploy, and manage serverless applications efficiently and securely. Whether you're looking to scale AI across your development lifecycle, improve data quality checks, or secure your applications with enhanced secrets management, AWS has you covered.

📦 New Releases This Week

Additional announcement(s) from 2026-10-10 – 2026-10-16 (UTC) not covered above:

What's New

AWS News Blog

Architecture Blog

Bulk Executor for Amazon DynamoDB, Part 2: Lessons we learned the hard way

Compute Blog

Exploring AWS Lambda Web Functions for building web applications

🤖 This post was automatically generated by AI using Amazon Bedrock (model amazon.nova-lite-v1:0). It summarizes recent AWS announcements and may contain inaccuracies — please verify details against the official AWS sources linked above.

I measured the speed and monthly cost of Amazon S3 Files, which lets you use S3 as files (and how it differs from FSx for ONTAP)

Yoshiki Fujiwara(藤原善基)@AWS Community Builder — Fri, 16 Oct 2026 11:20:30 +0000

Conclusion first: the one-client speed limit, scaling with client count, and a monthly cost order that splits by object size

Amazon S3 Files lets you open, read, and write the data in S3 like an ordinary folder. With plain S3, a program has to call S3-specific APIs. With S3 Files, tools built to open files can work on your S3 data as they are.

This post is a record of measurements and estimates for people who do not run storage performance tests as a routine job, to help decide whether S3 Files belongs in a design. I built the environment myself in ap-northeast-1 and measured speed on 2026-10-10. The monthly cost is not a measurement. It is arithmetic from list prices read on 2026-08-09. When I re-read the 2026-08-09 record with the Price List API on 2026-10-16, the values were the same (it covers 10 items and does not include the two PUT request prices).

Three things came out of it.

One server has a read speed limit. On a c5n.9xlarge (a 36 vCPU server) it was about 1.1 GB per second (1,104.9 MB/s). It stops when the relay program running on the server (efs-proxy) uses up one CPU core (96.8 to 97.9%). One run.
Adding servers raises the total. Going from 1 to 8 c5n.2xlarge servers raised the total from 784.4 MB/s to 6,282.6 MB/s (8.01x). All servers read the same 600 GiB file.
Under this model's base assumptions, the monthly cost order against FSx for ONTAP splits by object size. Amazon FSx for NetApp ONTAP (FSx for ONTAP below) is an AWS managed service that provides NFS and SMB shared folders, and with S3 Access Points attached it also serves the same data through the S3 API. I fixed the stored volume at 20 TiB and estimated five patterns that differ in monthly read and write volume (P1, P4, P5, P6, P8; the contents are in the table in the chapter "Monthly cost estimate"). At 64 KiB, FSx for ONTAP was cheaper in all five ($1,783.11 to $2,218.13 a month, against $7,928.32 to $12,030.81 via S3 Files). At 4 MiB, S3 Files was cheaper in all five ($512.14 to $543.52 a month, against $1,781.28 to $1,788.08 on FSx for ONTAP).

The monthly amounts are subtotals of the main line items for ap-northeast-1, with prices read on 2026-08-09. A main-line-item subtotal is the sum of storage, S3 Files high-performance storage (a low-latency layer inside the file system; you pay storage charges for what it holds), fixed bandwidth, requests, and so on, and it leaves out any item that is not in the tables. They are price x quantity arithmetic, not measurements, and they are not invoices. The FSx for ONTAP capacity pool (the tier that holds data that does not fit on SSD) read request count is an assumed value that I have not confirmed. The P5 write volume and the read and write volumes of P1, P6, and P8 are placeholders with no source.

Because the order was the same in all five patterns, what splits the order in this model is the object size, not the read and write volume. The candidate for the dividing line is the S3 Files import threshold (the file-size boundary for importing into high-performance storage; default 128 KiB). I estimated only two sizes, 64 KiB and 4 MiB, and I did not estimate the sizes at the boundary.

The takeaways: when one server is not fast enough, add servers (confirmed up to 8). Under the base assumptions, FSx for ONTAP was cheaper at 64 KiB and S3 Files was cheaper at 4 MiB. The order can flip when the assumptions change, so replace them with your own values and check. The assumptions to replace are the share of data on the capacity pool, the storage efficiency of the SSD tier, the active share of S3 Files high-performance storage, the S3 Files import threshold, and the FSx for ONTAP deployment. This post does not give the values at which the order flips. The estimate itself is in the chapter "Monthly cost estimate".

How to read this post by goal

You only want the conclusion: this chapter is enough.
You want to know whether it works in your setup: "The value of S3 Files and four prerequisites"
The mount does not proceed: "A hung mount"
You want to know how it differs from FSx for ONTAP: "Comparing two ways to use the same data through two entry points"
You want the cost: "Monthly cost estimate"
You want to know which setup to consider first: "Choosing between S3 bucket first and file system first" at the end of the "Monthly cost estimate" chapter, and "Closing"
You want the measurement conditions and limits: "The single-mount ceiling", "An aggregate that scales with client count", "An invalid warm / cold comparison", "Status of the four stated values", "What I have not measured"
You want to reproduce it: "Reproducing it yourself"

Introduction

There are times when you want to handle S3 data as files: an existing script that opens the files in a folder one by one, or a business tool built around a shared folder. Amazon S3 Files became generally available in April 2026, and it lets you mount an S3 bucket as an NFS file system (the network shared-folder mechanism of Linux) without migrating data.

Before using it, I think you wonder about three things.

What is it good for, in the end?
How fast is it, and what does it cost?
How does it differ from a file-server type of service (FSx for ONTAP)?

This post answers the second and third. The speeds are values I measured in my own environment, and the monthly cost is a unit price x quantity estimate. For the differences from FSx for ONTAP, I put my past measurement records (the environment differs per measurement) and the official documentation side by side in a table. I do not cover the first, the introduction. The Classmethod article (Japanese) compares I/O performance and sync lag with Amazon EFS, and the Serverworks article (Japanese) sorts out five services, including Mountpoint for Amazon S3.

In the previous post (S3 Burst Part 2: "The throughput ceilings of three paths") I compared three paths, S3 Files among them, side by side and asked where each one tops out. This time I narrow down to S3 Files alone. Last time the question was which path tops out where. This time it is how S3 Files behaves as a file system.

The mount failed before I could measure anything, so I recorded the cause first. Someone else can hit the same wall. After reading, you can decide, on numbers that come with their environments, whether S3 Files is a candidate, how far the number of servers can carry your speed, and which of S3 Files and FSx for ONTAP with S3 Access Points (the S3 API entry point that you attach to a volume) fits better.

What I cover / do not cover

Covered

The prerequisites of S3 Files and the value AWS states for it. Prerequisites decide first whether you can use it at all.
Why the mount failed. It was missing permissions, not the network, and knowing in advance avoids it.
The single-mount ceiling (c5n.9xlarge). The per-client ceiling is the starting point of capacity planning.
Aggregate growth with client count (c5n.2xlarge, 1 to 8 clients). It shows how far clients can carry you past one mount's limit.
The comparison with FSx for ONTAP S3 Access Points. Both give you the same data through files and the S3 API, but the source of truth, the speed of propagation, the growth with client count, and the billing items differ.
The monthly cost estimate. With the stored volume fixed at 20 TiB, five read and write patterns, and two object sizes, I line up the main-line-item subtotals of S3 Files and FSx for ONTAP. It separates this model's result, in which the size splits the order, from the assumptions under which the order can flip.
The accounting assumption for S3 Files metadata charges, and one observation. Whether including them in the subtotal matches the bill is unconfirmed.
Reading data on the capacity pool. It separates the existence of billing items from how far a latency observation can be read.
How my warm / cold comparison failed. Warm means reading data that sits in S3 Files' high-performance storage; cold means reading straight from the bucket. Someone repeating the measurement can fall into the same trap.
Which of the four values AWS states I could confirm, and which I could not. It separates what is safe to base an adoption on.
What I have not measured. It lets you judge where the numbers apply.
How to reproduce it in your environment. It points to the runbooks so you can follow the measurements.

Not covered

An introduction to S3 Files, and how it differs from Mountpoint for Amazon S3 and Amazon EFS. Articles already cover that, and it is outside this post's subject, measured speed and monthly cost.
Which configuration is faster. The paths were measured in different environments (NFS version, instance type, configuration), so no same-conditions winner exists.
Measurements that separate the propagation conditions. The window of about 60 seconds between writing a file and reading it through the S3 API appears as two rows in the comparison table of "Comparing two ways to use the same data through two entry points", and I explain it in four stages. Measurements that separate conditions, such as long continuous appends and concurrent updates, exist only as a plan and have no measured results. The conditions of that window are in another verification record (Japanese). It is outside this post's subject, which is throughput and client count, and that measurement covers a single condition.
The values at which the order flips. I did not calculate where the order flips at the boundary object size, the capacity pool share, and so on.
Invoiced amounts. The monthly cost is a unit price x quantity estimate, and I have not confirmed that it matches a bill.
A correct same-conditions measurement of the warm / cold difference. The first comparison was invalid and I have not re-measured.
Multi-AZ configurations, clients outside AWS, and tiering differences inside a VPC. I measured in a single-AZ environment in ap-northeast-1. The chapter "What I have not measured" lists the scope in a table.

Terms used in this post

Each term is explained at first use in the text. This table is an index for rereading.

Term	Meaning	Where it appears
S3 Files	A service that mounts an S3 bucket as an NFS file system. Built on Amazon EFS; the bucket remains the source of truth	All chapters
High-performance storage	The low-latency layer inside the S3 Files file system. It holds the data and metadata of files in active use, and you pay storage charges for what it holds	"The value of S3 Files and four prerequisites", "Comparing two ways to use the same data through two entry points", "Monthly cost estimate", "An invalid warm / cold comparison"
efs-proxy	A local proxy that runs on the mounting client's EC2 instance. The mount target is 127.0.0.1, and in the verification records this one process handles TLS termination and NFS translation	"The value of S3 Files and four prerequisites", "A hung mount", "The single-mount ceiling", "An aggregate that scales with client count", "Comparing two ways to use the same data through two entry points"
Mount target	The NFS endpoint of the file system that you create in a VPC (port 2049). One per AZ at most	"The value of S3 Files and four prerequisites", "A hung mount"
nconnect	A Linux NFS mount option that opens several TCP connections to one server. S3 Files does not support it, and specifying it hung the mount	"The value of S3 Files and four prerequisites", "The single-mount ceiling", "Comparing two ways to use the same data through two entry points"
warm / cold	In this post, used only for S3 Files reads. Warm is a read of data held in high-performance storage; cold is a read straight from the bucket. For FSx for ONTAP I write "on SSD" and "on the capacity pool"	"An invalid warm / cold comparison", "Status of the four stated values", "What I have not measured"
Capacity pool	The tier where FSx for ONTAP keeps data that does not fit on SSD. Its storage price is lower than SSD (Single-AZ, ap-northeast-1: $0.0238 vs. $0.15 per GB-month, read 2026-08-09)	"Comparing two ways to use the same data through two entry points", "Monthly cost estimate", "What I have not measured"
Tiering All	One of the tiering policies of an FSx for ONTAP volume. It places the data on the capacity pool	"Comparing two ways to use the same data through two entry points", "Monthly cost estimate"
FlexCache / Origin	FlexCache is an ONTAP feature in which a Cache volume holds only the data read from the Origin volume that owns the original data. This post uses it only to say that the FSx for ONTAP propagation measurement read the Origin volume directly	"Comparing two ways to use the same data through two entry points"
S3 Access Points	In this post, the S3 API entry point attached to an FSx for ONTAP volume. The same data can be read and written over NFS / SMB and the S3 API	"Comparing two ways to use the same data through two entry points", "Monthly cost estimate"
Import threshold	The size at which S3 Files decides whether to import a file into high-performance storage (`sizeLessThan`). The default is 128 KiB, and sizes below it are imported. Exactly 128 KiB is treated as not imported	"The value of S3 Files and four prerequisites", "Monthly cost estimate", "An invalid warm / cold comparison", "Closing"
Pattern (P1, P4, P5, P6, P8)	A name for a combination of monthly read and write volumes. The numbers follow the cost model's numbering, and the figures and tables carry five of them (P2, P3, and P7 are left out because they cost the same as P4 and P6)	"Monthly cost estimate", "Closing"
Working set / working-set ratio	The working set is the part that is read within the month. The working-set ratio is its share of the stored volume (10% for P4)	"Monthly cost estimate"
Churn rate	The share of the stored volume that is rewritten in a month (5% for P5)	"Monthly cost estimate"
Main-line-item subtotal	The sum of storage, S3 Files high-performance storage, fixed bandwidth, requests, and so on. Items not in the tables are not included. It is price x quantity arithmetic, not a measurement, and not an invoice	"Monthly cost estimate", "Closing"
Placeholder	A value with no source, put in to make the arithmetic work. It is not taken from a real workload	"Monthly cost estimate"
VDBENCH	A tool that generates storage I/O load (distributed by Oracle). The S3 Files measurements here used 5.04.07	"The single-mount ceiling", "An aggregate that scales with client count"
o_direct	A setting that reads and writes without the OS page cache. In VDBENCH it is `openflag=o_direct`	"The single-mount ceiling", "An aggregate that scales with client count"
disjoint / same	Disjoint: each client reads a non-overlapping range. Same: all clients read the same file	"An aggregate that scales with client count"
shared epoch	All clients wait until the same UNIX time (90 seconds after launch) and start measuring together	"An aggregate that scales with client count"

The value of S3 Files and four prerequisites

S3 Files lets Linux compute mount a bucket as an NFS file system and read and write it while the bucket stays the source of truth. It is built on Amazon EFS and became generally available in 34 regions in April 2026 (What's New). Four prerequisites decide first whether you can use it.

Four prerequisites

Prerequisite	Detail	Source
Bucket versioning	Required. Encryption is SSE-S3 or SSE-KMS	Prerequisites for S3 Files
Client compute	Linux on AWS (EC2 / Lambda / ECS / EKS / Fargate / Batch). I could not find documentation for mounting from outside AWS	S3 Files product page
Protocol	NFSv4.1 and NFSv4.2 only. NFSv3 and SMB are not listed as supported. nconnect (a Linux mount option that opens several TCP connections to one server) is unsupported; in my verification, specifying it timed out the mount after 90 seconds (one observation, c5n.2xlarge, 2026-09-02)	Unsupported features, limits, and quotas, verification record
File-to-bucket propagation	After you change a file, S3 Files waits about 60 seconds before copying it to the bucket	Performance specifications

How the mount works

When you mount, efs-proxy (the local proxy mentioned in the summary) starts on the client's EC2 instance. Your application mounts 127.0.0.1, and efs-proxy connects to the mount target in the VPC. The mount target is the NFS endpoint of the file system (port 2049), with a limit of one per AZ. In the verification records, this efs-proxy handles TLS termination and NFS translation in one process (verification record, Japanese). This structure sets the single-mount ceiling measured in a later chapter.

Reads take one of two paths. Small files (under 128 KiB by default) are imported asynchronously into high-performance storage, the low-latency layer inside the file system, on first access, and later reads are fast. Reads of 1 MiB or more go straight to the bucket even when the data sits in high-performance storage. The source is Performance specifications.

Values AWS states

The following four points are AWS's statements. I could get numbers for the second point, propagation time between files and the S3 API, and for the fourth point, single-mount throughput and aggregate growth with client count (up to 8). I did not measure the first, and the comparison for the third was invalid.

Existing file-based tools work as they are. The product page says "No code changes, no custom connectors, and no new APIs to learn" (product page).
The same data is usable from both files and the S3 API at the same time. The product page's wording is "nothing to reconcile between two separate systems", meaning you do not have to reconcile two systems.
Only frequently read data sits in high-performance storage, and you pay for what it holds. Reads of 1 MiB or more cost only the standard S3 GET price (product page).
Many clients can use it at once. The limit is 25,000 connections per file system, and the aggregate read throughput is "up to terabytes per second" in the AWS pages' wording (quotas, Performance specifications).

If your requirements include NFSv3 or fixed SMB devices or Windows workflows, S3 Files drops out at the prerequisites table. The AWS documentation does not mention mounting from outside AWS that I could find. If you need it, check in your own environment before you put S3 Files on the candidate list. If none of those apply, read the following chapters on the mount failure, the single-mount ceiling, and client scaling, and use them for capacity planning.

A hung mount: missing CloudWatch permissions on the client's IAM role

mount -t s3files timed out every 15 seconds. The cause was not the network or DNS. The IAM role on the client EC2 instance lacked logs:CreateLogGroup and cloudwatch:PutMetricData. Adding the permissions let the mount complete.

The environment was a c5n.9xlarge (Amazon Linux 2023, amazon-efs-utils 3.3.2) in a dedicated measurement VPC in ap-northeast-1 (a public subnet with an internet gateway). It happened while I prepared the measurement, and my troubleshooting notes carry no date. The throughput measurements in the same environment ran on 2026-10-10.

Symptom: timeouts every 15 seconds with a healthy network

efs-proxy: running, with a TCP connection to port 2049 on the mount target (ESTAB in ss)
Reachability: both S3 on 443 and the service endpoint on 2049 were reachable
Mount: mount.nfs4 127.0.0.1:/ still did not finish

Cause: efs-proxy restarting over and over because log creation failed

The efs-proxy log contained these lines.

WARN  cw_publisher Failed to create log group: AccessDeniedException ... logs:CreateLogGroup
ERROR nfs::nfs_reader Error sending message batch to dispatcher DispatchingFailure
INFO  controller Proxy incarnation restarted, restart_count=3

Before establishing the NFS connection, the mount helper tries to create a CloudWatch Logs log group (/aws/efs/utils). When that call fails for lack of permissions, efs-proxy keeps restarting and the mount never finishes. An AWS article names the same behavior as the root cause when a mount hangs forever without an obvious reason (Mounting S3 Files on EC2 in private subnets).

My subnet has an internet gateway, so CloudWatch Logs was reachable. Permissions were the blocker, not reachability. In a private subnet with no CloudWatch Logs VPC endpoint, unreachability produces the same symptom.

Original record: Mount pitfalls (causes and fixes) (Japanese)

Fixes: any of three options works

#	Fix	Fits when
1	Grant the IAM role `logs:CreateLogGroup`, `logs:CreateLogStream`, `logs:PutLogEvents`, and `cloudwatch:PutMetricData`	You have an internet gateway or CloudWatch endpoints and also want CloudWatch metrics. I used this one
2	Disable CloudWatch logging in the mount helper (`/etc/amazon/efs/s3files-utils.conf`)	You do not want to add permissions or endpoints
3	Create a CloudWatch Logs VPC endpoint (`com.amazonaws.<region>.logs`)	A private subnet with neither an internet gateway nor a NAT

I did not pick option 2 because the next chapter's measurement uses efs-proxy's CloudWatch metrics (connectivity and byte counts) to isolate the cause of the ceiling.

Pre-mount checks: three items

IAM role: it carries the permissions from fix 1.
botocore: installed with dnf install python3-botocore (pip3 does not work). Without it, the mount either stopped with access denied by server while mounting, or went through but CloudWatch metrics were unavailable. The two verification records show different symptoms, and neither records the condition that decides which one you get.
Mount target: it is in the same AZ as the client, and the security group allows 2049 from the client.

Check these three items before you mount, and decide beforehand whether to grant the CloudWatch permissions or disable logging.

The single-mount ceiling: one efs-proxy core saturated

A single mount stopped at 1,104.9 MB/s for 1 MiB sequential reads (c5n.9xlarge, one run). The limiter was the efs-proxy process's CPU: one core of 36 vCPU was full (96.8 to 97.9%). As noted in the prerequisites chapter, S3 Files does not support nconnect, so no mount option can add connections to efs-proxy and move this ceiling.

Measurement conditions

Environment: ap-northeast-1, 2026-10-10 (UTC), single AZ, c5n.9xlarge (36 vCPU), Amazon Linux 2023
Mount: nfs4 vers=4.2, rsize=wsize=1048576, hard. The server is 127.0.0.1 (through efs-proxy, TLS and IAM authentication always on)
Load: VDBENCH 5.04.07 (an I/O load generator distributed by Oracle), 512 threads, o_direct (bypasses the OS page cache)
Data: a single uncompressible 600 GiB file. 60 seconds of warmup, then 300 seconds measured

Results: four workloads

Workload	Throughput	IOPS
1 MiB sequential read	1,104.9 MB/s	1,105
1 MiB sequential write	852.0 MB/s	852
4 KiB random read	61.9 MB/s	15,839
4 KiB random write	14.4 MB/s	3,688

Each row is one run; I did not repeat any condition. Source of this table: Results (S-1 + S-2) (Japanese)

Isolating the cause: efs-proxy CPU saturated at one core

I re-measured 1 MiB sequential reads for 60 seconds and sampled CPU three times.

Sample	efs-proxy CPU	VDBENCH and java CPU
1	96.8%	near 0
2	97.4%	near 0
3	97.9%	near 0

The re-measured throughput was 1,109.4 MB/s, 0.4% away from the main run's 1,104.9 MB/s. The mount target is a local proxy at 127.0.0.1, and efs-proxy handles TLS termination and NFS translation in one process, so one mount tops out at one core of that process. Source of this table: Ceiling confirmation (Japanese)

Differences by instance type: three values under different conditions

Even on the same c5n.2xlarge the value changes with how I measured, so here are three side by side.

Measurement	Instance	Conditions	Read	Date
Stream-count sweep	c5n.2xlarge	8 streams, 1 GiB per stream, `O_DIRECT`	451.3 MB/s	2026-09-02
One client in the client-count test	c5n.2xlarge	VDBENCH, 64 threads, 1 MiB sequential, 600 GiB file	784.4 MB/s	2026-10-10
Single-mount test	c5n.9xlarge	VDBENCH, 512 threads, 1 MiB sequential, 600 GiB file	1,104.9 MB/s	2026-10-10

The three differ in conditions, so this is not a comparison that changes only the instance type. I have no measurement that varies only the instance type under the same conditions. I also did not isolate whether efs-proxy CPU or the client's network bandwidth sets the roughly 785 MB/s per c5n.2xlarge. Source of this table: Stream-count measurement (Japanese)

When one mount is not enough bandwidth, design for adding clients (the next chapter).

An aggregate that scales with client count: 8.01x at 8 clients

Going from 1 to 8 c5n.2xlarge clients raised the aggregate read from 784.4 MB/s to 6,282.6 MB/s (8.01x). Per client it stayed roughly constant at 784.4 to 802.2 MB/s. That fits the structure in which each client has its own efs-proxy.

Measurement conditions

Environment: ap-northeast-1, single AZ, 2026-10-10 (UTC), up to 8 c5n.2xlarge, Amazon Linux 2023
Mount: each client mounts S3 Files on its own (one efs-proxy per client)
Load: VDBENCH, 1 MiB sequential read, o_direct, fixed at 64 threads per client (only the client count changes)
Simultaneous start: shared epoch. All clients wait until the same UNIX time (90 seconds after launch) and start measuring together. 60 seconds of warmup, then 180 seconds measured
Range read: two patterns, same (all clients read the same 600 GiB file) and disjoint (each client reads a non-overlapping range)

Results: all clients read the same file

Clients	Aggregate	Per client	Ratio to 1 client
1	784.4 MB/s	784.4 MB/s	—
2	1,604.5 MB/s	802.2 MB/s	2.05x
4	3,148.4 MB/s	787.1 MB/s	4.01x
8	6,282.6 MB/s	785.3 MB/s	8.01x

Source of this table: Client-count measurement (same) (Japanese)

Results: each client reads a non-overlapping range

I measured disjoint at 8 clients only. The aggregate was 7,210.0 MB/s, and per client 901.3 MB/s (a spread of 770 to 1,332), higher than the 8-client same result of 6,282.6 MB/s. Each client reads different data, so sharing and fanning out one read cannot explain the number. I did not measure disjoint at 1, 2, or 4 clients, so the shape of disjoint scaling is unconfirmed.

Source of this table: Client-count measurement (disjoint) (Japanese)

Measurement limit: client-side totals only

The numbers are the sum of what the clients reported. I could not reconcile them with CloudWatch DataReadBytes: on the day, metrics arrived sparsely and did not land in the measurement window. The record also has no spread across repeated runs for each client count.

high-performance storage and direct bucket reads. A single mount tops out at one efs-proxy core, and the aggregate grows in proportion to client count up to 8 clients" width="800" height="686">

Figure 1: The internals of S3 Files. Each client has its own efs-proxy. A single mount tops out at one efs-proxy core, while the aggregate grows in proportion to client count (measured up to 8). The figure says the same thing as the tables above.

For capacity planning up to 8 clients, multiply roughly 785 MB/s per client (785.3 MB/s at 8 clients; c5n.2xlarge, all clients reading the same file) by the client count. I have not measured 9 or more, so check the conditions in the chapter "What I have not measured" before relying on that range.

Comparing two ways to use the same data through two entry points: where the source of truth sits

Both S3 Files and FSx for ONTAP with S3 Access Points let you use the same data through a file mount and the S3 API. What differs is the source of truth: an S3 bucket for S3 Files, an ONTAP volume for FSx for ONTAP. That difference bears on the speed of propagation, how throughput grows as you add clients, and how the bill comes out. The measured values do not share an environment, though, so this post does not isolate whether the differences come from where the source of truth sits.

The two setups compared in this chapter are as follows.

S3 Files: attach S3 Files to an S3 bucket and mount it over NFS from EC2. The S3 API reaches the bucket directly.
FSx for ONTAP: use an ONTAP volume over NFS / SMB and attach S3 Access Points (the S3 API entry point attached to the volume) to the same volume. Data that does not fit on SSD can sit on the capacity pool, a tier with a lower storage price. Tiering All, one of the volume's tiering policies, places the data on the capacity pool.

The table below lines up the two setups by aspect. I wrote "not measured" where I did not measure. Measured values come from different environments, so each cell carries its environment.

Aspect	S3 Files (S3 bucket first)	FSx for ONTAP + S3 Access Points (file system first)	Source
Source of truth	The S3 bucket. Objects and files point at the same bucket	The ONTAP volume	Design differences
File-side entry	NFSv4.1 / 4.2 only, through a per-client efs-proxy. nconnect is unsupported	ONTAP serves NFS (v3, v4.0 to 4.2) and SMB directly	Protocol comparison, S3 Files quotas
S3 API-side entry	The bucket itself	An S3 Access Point attached to the volume	Design differences
Propagation: write as a file, read with the S3 API	p50 63,769.3 ms (a window of about 60 seconds). t3.small, NFSv4.2, 64 B, concurrency 1, n=30, 2026-09-01	p50 44 ms. NFSv3, 128 MBps Single-AZ, 64 B, concurrency 1, n=30, 2026-08-09	S3 Files measurement, FSx for ONTAP measurement
Propagation: write with the S3 API, read as a file	p50 1,533.1 ms (same environment as above)	p50 3 ms. A direct NFS read of the Origin volume that received the write (it does not go through a FlexCache Cache volume; same environment as above)	Same as above
Conflict and locking	When the same key is changed from the file side and the S3 API side, the S3 bucket side became the source of truth (3/3 converged on the S3 content). The file-side version was moved to `.s3files-lost+found-<fs-id>`. Only conflicts inside the window (5 seconds later) were measured	Not measured. I did not measure what happens when the same key is changed from the file side and the S3 API side, nor reconcile it with ONTAP-side file locking	Conflict behavior (Japanese)
Supported APIs, conditional writes, copy scope	The S3 bucket API. I did not measure conditional writes or copy scope in this post	Presigned URLs through S3 Access Points (`PutObject` / `HeadObject` / `GetObject`) are verified (2026-08-19, n=30x4, succeeded under both SigV4 and SigV2). The official support table also lists `Presign` as Supported (confirmed 2026-10-08, documented). Uploads are single `PutObject` 5 GiB and whole object 50 GiB, with the limit judged at `CompleteMultipartUpload`. The read side is asymmetric: a GET of 50 GiB + 1 byte succeeded (537 seconds, 2026-09-11)	Verification status (Japanese)
Versioning / Object Lock / Lifecycle	Bucket versioning is required. I did not measure Object Lock or Lifecycle in this post	On the S3 Access Points side, S3 event notifications, lifecycle, and versioning are not supported (documented). ONTAP-side data protection (SnapLock and the like) is a separate mechanism; do not equate it with S3 Object Lock	Design differences (Japanese)
IAM vs. file-side permissions	An object written through the S3 API appears as `root:root` on the file system (file 0644, directory 0755). A client mapped to non-root at the access point cannot write into a directory the S3 API created (reads go through). The official Synchronization page says POSIX permissions are stored in the S3 object's user-defined metadata, and that objects without metadata get default permissions. I have not found the specific values `root:root` or 0644 / 0755 in the pages I read	ONTAP NFS / SMB file permissions and the IAM on the S3 Access Points side are separate paths. I did not run a reconciling measurement in this post	Owner of S3-API writes (Japanese)
Where unread data sits	The S3 bucket. Reads of 1 MiB or more go to the bucket even when the data is in high-performance storage	SSD. Depending on the tiering policy, the capacity pool (Tiering All places everything there)	Performance specifications, Billing items table
Read billing items	S3 GET plus metadata reads ($0.04 / GB; the model counts 4 KiB x operations). Small files held in high-performance storage also incur a data read charge ($0.04 / GB). For 4 MiB reads, CloudWatch `MetadataReadBytes` registered about 6.0 times per object, with an average of about 4.1 KiB each (one observation, m5.large, 2026-10-16). The origin is unknown, and whether it reaches the bill is unconfirmed	GET through S3 Access Points ($0.000029 / 1,000). Data on the capacity pool can incur a read request charge ($0.00037 / 1,000). Requests per GetObject: not confirmed (`CapacityPoolReadOperations` was 0 in the measured window)	Billing items table
Latency of reading data that is not held in the fast tier	Not confirmed. 64 KiB p50 was 5.33 ms from high-performance storage and 4.05 ms straight from the bucket (c5n.9xlarge, n=30, one run, 2026-10-10). A separate t3.small record shows 10.8 ms vs. 55.0 ms (2026-09-01), which did not reproduce on c5n.9xlarge	Not measured. There is one observation of +5.3 to +15.4 ms against the SSD side, but the reads did not reach the capacity pool, so it cannot be read as that delay	Three reads, Reads by tier
Adding clients: file path	1 to 8 clients: 784.4 to 6,282.6 MB/s (8.01x). c5n.2xlarge, all clients read the same file, 2026-10-10. 9 or more: not measured	1 to 8 clients: 2,664.58 to 11,916.29 MB/s (4.47x, all clients read the same file). With non-overlapping regions it does not grow, from 2,299.05 MB/s at 2 clients to 2,173.37 MB/s at 8. c5n.2xlarge, nconnect=16, second generation, 2,048 MBps, 2026-09-05	S3 Files client count, FSx for ONTAP client count
Adding clients: S3 API path	The S3 API reaches the bucket directly. Reads from Amazon S3 went from 495.4 to 2,030.5 MB/s at 1 to 4 clients (4.10x, c5n.2xlarge, 2026-09-01 to 02). Not measured on a bucket with S3 Files attached	At 1 to 4 clients, writes went 129.4 to 131.0 MB/s (1.01x) and reads 480.9 to 612.3 MB/s (1.27x). 128 MBps configuration, nearly flat from 2 clients. Clients share the purchased throughput capacity	Measurement record of the previous post
Published limits	25,000 connections per file system, 3 GiB/s read per client. Aggregate read is "up to terabytes per second" in AWS's wording	You buy throughput capacity. The minimum for Single-AZ first generation is 128 MBps	quotas, Performance specifications, Fixed-cost floor
Fixed cost	None. S3 storage plus what you use	Floor of $269.57 a month for Single-AZ first generation (SSD 1,024 GiB + 128 MBps, prices read 2026-08-09)	Fixed-cost floor
Prerequisites and constraints	Bucket versioning required. Clients are Linux on AWS. NFSv4.1 / 4.2 only. About 60 seconds from file to bucket	On the S3 Access Points side, S3 event notifications, lifecycle, and versioning are not supported. Capacity pool read charges. Clients share the throughput capacity	Design differences, Performance specifications

The propagation rows are not a same-conditions comparison, because the NFS version, client, and configuration differ. The client-count rows differ too: S3 Files used VDBENCH with 64 threads per client, and FSx for ONTAP used a second-generation 2,048 MBps configuration with nconnect=16. I read in full on 2026-10-16 the two AWS documents this chapter relies on: the S3 User Guide pages Performance specifications and Understanding how synchronization works.

Source of this table: Design differences table. For the measured rows, the sources are the links in the "Source" column.

The four stages of file-to-bucket propagation, and how to treat the maximum reflection time

The "window of about 60 seconds" in the propagation rows is not one wait but four stages. The measured p50 of 63,769.3 ms is the whole span from (a) to (d).

Stage	Definition	Category
(a) File write complete and persisted	The moment the write to NFS finishes through efs-proxy. Separate from propagation to S3	NFS semantics
(b) No-write wait	The wait counted from when writes to the same file stop. The official Synchronization page states the "60 seconds with no writes" condition	Documented
(c) Export start	The moment a file that satisfies the wait condition becomes an export target. The official Performance page states the roughly 60-second aggregation	Documented
(d) Visible through the S3 API	After the export completes. The measured p50 of 63,769.3 ms is this whole (a) to (d)	Measured (t3.small, 64 B, concurrency 1, n=30, 2026-09-01)

The export side agrees across two sources. Against the client-side max of 66.33 seconds, the CloudWatch ExportAge peak was 66.06 seconds, a 0.27-second difference (all 30 runs fell in 63.8 to 66.3 seconds).

The maximum reflection time cannot be used as a guaranteed value. On the import side (S3 to file), the client-side max of 14.36 seconds and the CloudWatch ImportAge peak of 62.80 seconds do not agree. I could not find a maximum reflection time in the official documentation, so I do not treat it as an upper bound, and I write the representative value as the client-side p50. I do not write "reflected within 60 seconds", "reflected every minute even under continuous updates", or "never synchronized" either, because none has grounds. This explanatory model (wait, then aggregate, then export) is not an SLA.

Three notes follow.

In a conflict (the same key changed from the file side and the S3 API side), the S3 bucket side became the source of truth (3/3 converged on the S3 content). The file-side version was moved to .s3files-lost+found-<fs-id> (matching the CloudWatch LostAndFoundFiles peak of 3.00).
That directory is not created on conflict; it is present from the start (0700 root:root), and what happens on conflict is the eviction event. The official Synchronization page says files in this directory are not copied to the S3 bucket (I did not measure this).
For large rename / move operations, a rename on the file side finishes immediately, while on the S3 side it becomes a per-object copy and delete. AWS says a rename of 100,000 files takes several minutes to reflect on the S3 side, and that the prefixes from before and after the rename are both visible midway. I have not measured this behavior separately.

Measurements that separate the propagation conditions (long continuous appends, after updates stop, while another file is being updated, concurrent updates) are deferred to a separate verification plan (a plan, not a new measurement).

What this comparison can settle is two things: whether the source of truth lives in an S3 bucket or an ONTAP volume, and whether you can accept the roughly 60 seconds from file to bucket. I estimate the monthly cost in the next chapter.

Monthly cost estimate: an order that splits by object size, and room for assumptions to move it

I apply the same list prices to the two setups from the previous chapter, with the stored volume fixed at 20 TiB. I estimated 10 cells: 5 patterns that differ in monthly read and write volume (P1, P4, P5, P6, P8) times 2 object sizes (64 KiB and 4 MiB). The amounts in this chapter are list price x quantity for ap-northeast-1, with prices read on 2026-08-09, and they are subtotals of the main line items. The subtotals add up the line items shown in the tables, and some items are not included. They are not measurements and not invoices. "Base assumptions" below means the values in the common-assumptions table in the next section, "Five patterns".

Under this model's base assumptions, in all 10 cells, the subtotal is lower on FSx for ONTAP at 64 KiB and lower via S3 Files at 4 MiB. At 64 KiB, FSx for ONTAP comes to $1,783.11 to $2,218.13 a month and S3 Files to $7,928.32 to $12,030.81. At 4 MiB, S3 Files comes to $512.14 to $543.52 a month and FSx for ONTAP to $1,781.28 to $1,788.08. Because the order was the same in all five patterns, what splits the order in this model is the object size, not the read and write volume. The candidate for the dividing line is the S3 Files import threshold (default 128 KiB). I estimated two sizes, 64 KiB and 4 MiB, so the tables have no rows near 128 KiB or at 1 MiB. The reading that the dividing line sits at the threshold comes from those two points and from how the price works (high-performance storage is charged only for sizes below the threshold), and I did not estimate sizes at the boundary. The import condition is sizeLessThan, so I treat exactly 128 KiB as not imported. This order is a result under the base assumptions, and it can flip when they change, so check the section "Assumptions under which the order can flip" in this chapter against your own values.

Five patterns: total monthly reads and writes

Writing "read N times a month" alone does not fix the total volume read. Whether the N reads cover all objects or only some of them changes the total several times over. I define each pattern with three numbers: the working-set ratio, the number of reads per working-set object, and the write volume. The table shows the monthly read and write volumes derived from them. The working set is the part that is read within the month. The working-set ratio is the working set's share of the stored volume, and the number of reads per working-set object is how many times each of its objects is read in a month. I set the write volume as a share of the stored volume (the churn rate).

Take P4 as an example. 10% of the 20 TiB stored (2 TiB) is the working set, and each of its objects is read 10 times a month. The volume read is 2 TiB x 10 = 20 TiB, which is 1.0x the stored volume. The other 90% (18 TiB) is not read at all within the month. With 4 MiB objects, that is 524,288 objects read 10 times each, or 5,242,880 reads. P4 has no writes, so the stored volume stays at 20 TiB.

Pattern	Working-set ratio	Reads per working-set object	Monthly read volume (multiple of stored volume)	Monthly write volume (multiple of stored volume)	Basis of the values
P1 Cold archive	5% (1 TiB)	1	1 TiB (0.05x)	None	Placeholder (no source)
P4 Re-read a small working set heavily	10% (2 TiB)	10	20 TiB (1.0x)	None	This model's estimate assumption (not a measurement)
P5 Read-mostly with light ingest	10% (2 TiB)	10	20 TiB (1.0x)	1 TiB (0.05x, churn rate 5%)	Reads as in P4. The write volume is a placeholder
P6 Mixed read and write	50% (10 TiB)	4	40 TiB (2.0x)	20 TiB (1.0x)	Placeholder (no source)
P8 Write-centred	10% (2 TiB)	1	2 TiB (0.1x)	20 TiB (1.0x)	Placeholder (no source)

Source of this table: The patterns

The placeholder values are numbers I put in to make the arithmetic work. They are not taken from a real workload. Replace them with your own monthly read and write volumes. The cost model also has P2, P3, and P7, but I left them out of the figures and tables because they have the same monthly read and write volumes, and so the same amounts, as P4 and P6 (P4 matches P2 and P3, and P6 matches P7).

The following assumptions are common to all 10 cells.

Item	Value
Region	ap-northeast-1
Prices	List prices read on 2026-08-09 (on-demand, excluding tax). I re-read the 2026-08-09 record with the Price List API (read-only) on 2026-10-16, and the values were the same. It covers 10 items and does not include the two PUT request prices
Stored volume	20,480 GiB (20 TiB). Common to all cells
FSx for ONTAP	Single-AZ first generation, 128 MBps. Storage efficiency 40% on the SSD tier and 20% on the capacity pool tier. 30% of the data on the capacity pool (common to all patterns). Reads are served from the file system, and writes are charged as PUT through S3 Access Points
S3 Files	Import threshold 128 KiB. For sizes below the threshold, the whole stored volume is assumed to be held as active in high-performance storage. Expiry is the default 30 days

Source of this table: Common baseline

Cost figure 1: monthly cost of P1 and P4, which have no writes

Cost figure 1: breakdown of the monthly cost of P1 and P4, which have no writes (ap-northeast-1, list price x quantity, not an invoice). The horizontal axis is shared with cost figure 2. The working-set ratio and read count of P1 are placeholders with no source. "Figure 1" and "Figure 2" inside the images mean these two cost figures, not the internals figure in a preceding chapter. The figure shows the same numbers as the table below (dark theme version).

Pattern / size	Monthly operations	Setup	Storage	S3 Files high-performance storage	Fixed bandwidth	Requests etc.	Of which S3 Files metadata charges	Main-item subtotal
P1 / 64 KiB	16,777,216 reads, no writes	Direct read with the S3 API	$512.00	—	—	$6.21	—	$518.21
P1 / 64 KiB	16,777,216 reads, no writes	Via S3 Files	$512.00	$7,372.80	—	$43.52	$2.56	$7,928.32
P1 / 64 KiB	16,777,216 reads, no writes	FSx for ONTAP	$1,665.28	—	$115.97	$1.86	—	$1,783.11
P1 / 4 MiB	262,144 reads, no writes	Direct read with the S3 API	$512.00	—	—	$0.10	—	$512.10
P1 / 4 MiB	262,144 reads, no writes	Via S3 Files	$512.00	$0.00	—	$0.14	$0.04	$512.14
P1 / 4 MiB	262,144 reads, no writes	FSx for ONTAP	$1,665.28	—	$115.97	$0.03	—	$1,781.28
P4 / 64 KiB	335,544,320 reads, no writes	Direct read with the S3 API	$512.00	—	—	$124.15	—	$636.15
P4 / 64 KiB	335,544,320 reads, no writes	Via S3 Files	$512.00	$7,372.80	—	$870.40	$51.20	$8,755.20
P4 / 64 KiB	335,544,320 reads, no writes	FSx for ONTAP	$1,665.28	—	$115.97	$37.25	—	$1,818.50
P4 / 4 MiB	5,242,880 reads, no writes	Direct read with the S3 API	$512.00	—	—	$1.94	—	$513.94
P4 / 4 MiB	5,242,880 reads, no writes	Via S3 Files	$512.00	$0.00	—	$2.74	$0.80	$514.74
P4 / 4 MiB	5,242,880 reads, no writes	FSx for ONTAP	$1,665.28	—	$115.97	$0.58	—	$1,781.83

Source of this table: P1 / 64 KiB, P1 / 4 MiB, P4 / 64 KiB, P4 / 4 MiB

"Requests etc." is the sum of S3 requests, S3 Files read and write charges (metadata charges included), and FSx for ONTAP capacity pool read requests and PUT. It is the purple category in the figure. "Storage" for FSx for ONTAP is SSD and capacity pool storage added together.

The FSx for ONTAP rows assume reads are served from the file system, and they do not include read charges through S3 Access Points. The direct-read rows for the S3 API appear only for P1 and P4, which have no writes. In the patterns with writes, the write path differs by setup (S3 API PUT, NFS write plus sync, PUT through S3 Access Points), and putting them in one table would mix the write assumptions.

In the 4 MiB rows, the S3 Files subtotal is nearly the same as the direct S3 API read subtotal ($512.14 vs. $512.10 for P1, and $514.74 vs. $513.94 for P4). 4 MiB is at or above the threshold, so the data is not held in high-performance storage and is read straight from the bucket. In the 64 KiB rows, S3 Files adds $7,372.80 of high-performance storage.

Cost figure 2: monthly cost of P5, P6, and P8, which have writes

Cost figure 2: breakdown of the monthly cost of P5, P6, and P8, which have writes (ap-northeast-1, list price x quantity, not an invoice). The horizontal axis is shared with cost figure 1. The write volume of P5 and the working-set ratio, read count, and write volume of P6 and P8 are placeholders with no source. The figure shows the same numbers as the table below (dark theme version).

Pattern / size	Monthly operations	Setup	Storage	S3 Files high-performance storage	Fixed bandwidth	Requests etc.	Of which S3 Files metadata charges	Main-item subtotal
P5 / 64 KiB	335,544,320 reads, 16,777,216 objects written	Via S3 Files	$512.00	$7,372.80	—	$990.66	$55.68	$8,875.46
P5 / 64 KiB	335,544,320 reads, 16,777,216 objects written	FSx for ONTAP	$1,665.28	—	$115.97	$55.36	—	$1,836.61
P5 / 4 MiB	5,242,880 reads, 262,144 objects written	Via S3 Files	$512.00	$0.00	—	$4.04	$0.87	$516.04
P5 / 4 MiB	5,242,880 reads, 262,144 objects written	FSx for ONTAP	$1,665.28	—	$115.97	$0.87	—	$1,782.11
P6 / 64 KiB	671,088,640 reads, 335,544,320 objects written	Via S3 Files	$512.00	$7,372.80	—	$4,146.01	$192.00	$12,030.81
P6 / 64 KiB	671,088,640 reads, 335,544,320 objects written	FSx for ONTAP	$1,665.28	—	$115.97	$436.88	—	$2,218.13
P6 / 4 MiB	10,485,760 reads, 5,242,880 objects written	Via S3 Files	$512.00	$0.00	—	$31.52	$3.00	$543.52
P6 / 4 MiB	10,485,760 reads, 5,242,880 objects written	FSx for ONTAP	$1,665.28	—	$115.97	$6.83	—	$1,788.08
P8 / 64 KiB	33,554,432 reads, 335,544,320 objects written	Via S3 Files	$512.00	$7,372.80	—	$3,229.53	$94.72	$11,114.33
P8 / 64 KiB	33,554,432 reads, 335,544,320 objects written	FSx for ONTAP	$1,665.28	—	$115.97	$366.11	—	$2,147.36
P8 / 4 MiB	524,288 reads, 5,242,880 objects written	Via S3 Files	$512.00	$0.00	—	$26.32	$1.48	$538.32
P8 / 4 MiB	524,288 reads, 5,242,880 objects written	FSx for ONTAP	$1,665.28	—	$115.97	$5.72	—	$1,786.97

Source of this table: P5 / 64 KiB, P5 / 4 MiB, P6 / 64 KiB, P6 / 4 MiB, P8 / 64 KiB, P8 / 4 MiB

Adding writes adds, on the S3 Files side, PUT to the S3 bucket and, at 64 KiB, import writes to high-performance storage. On the FSx for ONTAP side it adds PUT through S3 Access Points. For P6 at 64 KiB, "Requests etc." is $4,146.01 via S3 Files and $436.88 on FSx for ONTAP. Across the three patterns of cost figure 2, the 4 MiB subtotals stay within $516.04 to $543.52 via S3 Files and $1,782.11 to $1,788.08 on FSx for ONTAP.

Items that push up the S3 Files subtotal at 64 KiB: high-performance storage and the number of writes

S3 Files imports files below the threshold (default 128 KiB) into high-performance storage and charges $0.36 / GB-month for the amount held. Files at or above the threshold are not held and are read straight from the bucket. The model assumes the whole stored volume (20,480 GiB) is active at the small size. That makes high-performance storage $7,372.80 in all five 64 KiB cells and $0.00 in all five 4 MiB cells.

On the FSx for ONTAP side, storage of $1,665.28 and fixed bandwidth of $115.97 are the same in all 10 cells. Only the "Requests etc." column moves with size and with read and write volume.

Why the S3 Files subtotal is higher at 64 KiB splits into two cases by pattern. In P1, P4, and P5, the S3 Files subtotal falls below FSx for ONTAP once the $7,372.80 of high-performance storage is removed. In P6 and P8 it stays higher even after the removal. Those two write 335,544,320 objects, and the S3 bucket PUT price ($0.0047 / 1,000) is higher than the PUT price through S3 Access Points ($0.00108 / 1,000), which also contributes. Those two PUT prices are still the values read on 2026-08-09 and were not part of the 2026-10-16 re-read.

The high-performance storage amount follows from assuming a 100% active share. It is not a measurement.

Metadata charges: the accounting assumption and one observation

The model counts S3 Files metadata as 4 KiB x operations, in separate import-side and read-side lines, and includes both in the subtotal. The column "Of which S3 Files metadata charges" in the tables is the sum of those two lines. Whether metadata charges also apply to reads of 1 MiB or larger is unconfirmed, because the wording of AWS's metering page and pricing page does not agree. I left them in, so if they do not apply, the subtotal falls by the amount in that column.

I have one observation (2026-10-16, ap-northeast-1, m5.large, not reproduced). I read 1,000 4 MiB objects once each with dd, and CloudWatch MetadataReadBytes registered about 6.0 times per object, with an average of about 4.1 KiB each. Changing the I/O size to 1 MiB or 4 MiB made no difference. The 64 KiB control with the same procedure registered about 2.0 times. I do not know where the roughly 6 comes from, so I have not applied that count to the "4 KiB x operations" count in the model. DataReadBytes for 4 MiB had 0 data points, so I could not confirm whether the reads went through NFS or directly to the bucket. For the ingest of 4 MiB objects written through the S3 API, MetadataWriteBytes had 0 data points. I cannot tell whether no ingest happened or whether it is not metered.

What registered is a CloudWatch metric. I have not confirmed whether it is the same as the billing meter or whether this count reaches the bill. Cost Explorer right after the measurement showed no usage. That is within the reflection delay, so it is not evidence that nothing is billed. I plan to re-check in Cost Explorer after a few days. I did not measure other instance types, nconnect, multiple processes, or other object sizes. Until I can confirm, the metadata column in the tables keeps the assumption of one operation per read, and it may not match the actual bill.

Assumptions under which the order can flip: what to replace with your values

The order in this chapter is a result under fixed assumptions. If you replace the following assumptions with values from your environment, the amounts and the order move. This post does not state at which values the order flips.

Share of data on the capacity pool: fixed at 30% in every pattern.
Storage efficiency of the SSD tier: fixed at 40%.
Active share of S3 Files high-performance storage: fixed at 100%.
S3 Files import threshold: the default 128 KiB.
FSx for ONTAP deployment: Single-AZ first generation, 128 MBps.

The capacity pool share and the active share of high-performance storage are fixed values decoupled from the working-set ratio. In P1, P4, and P5 the data touched within the month (the working set plus writes) does not reach the whole stored volume, so the two shares can be set again to match the volume actually touched. Fitting the active share of high-performance storage would lower the S3 Files subtotal at 64 KiB. For the FSx for ONTAP subtotal when the capacity pool share is fitted, the generated document only says that the two together would go down, and I have not checked each one separately. In P6 and P8 the data touched within the month adds up to the stored volume or more, so if the capacity pool share is assumed to cover the whole volume, the FSx for ONTAP subtotal would rise. The directions come from the generated document, and I have not calculated the change in amounts. One more point: for S3 Files at 64 KiB in P1 and P4, which have no writes, the model counts no first-read stream (the GET from the bucket and the import write into high-performance storage) and counts all reads as high-performance storage reads. Counting it would add some items and remove others, and the model does not settle the net direction.

The capacity pool read requests included in "Requests etc." for FSx for ONTAP assume one request per GET on the 30% of reads that hit the capacity pool. The actual count is unconfirmed.

An observation that helps comes from an adjacent repository (the FSx for ONTAP monitoring integrations). On a file system of the same type (Single-AZ first generation, 128 MBps, SSD 1,024 GiB), on 2026-10-11, I read volumes that had been created with ALL and written to directly, from a Lambda function outside the VPC. CloudWatch CapacityPoolReadOperations came to 0 per object at 64 KiB, about 5.4 to 5.6 at 1 MiB, and about 29.8 to 33.2 at 5 MiB (source: per-invocation reads, Japanese). The 1 MiB and 5 MiB values are for cases where operations registered, and 2 of the 8 runs built the same way registered none. The sizes measured were 64 KiB, 1 MiB, and 5 MiB; 4 MiB was not measured. What was counted is the CloudWatch operation count, not a billed count, and that record also leaves the relation between the two unconfirmed. The measurement date, the volume, and the client all differ from this post's measurements. For these reasons I did not apply these operation counts to the model's count (one request per GET). The capacity pool read request amount that follows from the count the model assumed is $0.03 to $1.16 across the five 4 MiB cells.

Reading data on the capacity pool: billing items exist, latency is unmeasured

Reading an object on the capacity pool of a Tiering All volume through S3 Access Points can incur two billing items: GET through S3 Access Points and capacity pool read requests (documented). This post's measurements did not produce the number of requests per GetObject or the latency of reading from the capacity pool. The capacity pool storage price is lower than SSD, $0.0238 vs. $0.15 per GB-month (Single-AZ, ap-northeast-1, read 2026-08-09).

These are the p50 observations of GET through S3 Access Points from a local machine.

Object size	SSD side	After changing to Tiering All	p50 difference
64 KiB	46.5 ms	56.4 ms	+9.9 ms
1 MiB	58.6 ms	74.0 ms	+15.4 ms
5 MiB	116.0 ms	121.3 ms	+5.3 ms

The environment was 2026-10-10, ap-northeast-1, FSx for ONTAP Single-AZ first generation, 128 MBps, SSD 1,024 GiB, from a local machine outside AWS over the internet (round-trip time included), concurrency 1. It is one measurement: 166 to 407 requests on the SSD side and 10 requests after the change.

I cannot read this difference as a delay from reading the capacity pool, for three reasons.

In the read window after the change, the per-volume CapacityPoolReadOperations was 0. The reads did not reach the capacity pool.
The 5 MiB difference (+5.3 ms) is smaller than the spread from p50 to p90 on the SSD side (9.0 ms).
I did not alternate SSD-side and post-change reads, and the request counts are asymmetric.

Source of this table: Reads by tier (Japanese)

Before you read much Tiering All data through S3 Access Points, look at the per-volume CapacityPoolReadOperations one-minute values in your own environment and then estimate.

Choosing between S3 bucket first and file system first

Laid out at the same granularity, the constraints of the two setups are as follows. For monthly cost, treat the rows as guidance under the base assumptions of the estimate above.

Setup	Fits when	Constraints
S3 Files (S3 bucket first)	You want the source of truth in an S3 bucket. Clients are Linux on AWS and speak NFSv4.1 or later. Objects of 128 KiB or more dominate. You do not want a fixed cost	Bucket versioning required. Linux on AWS only. NFSv4.1 / 4.2 only (NFSv3, SMB, and nconnect unsupported). About 60 seconds from file to bucket. Objects below 128 KiB incur high-performance storage charges
FSx for ONTAP + S3 Access Points (file system first)	You want the source of truth in an ONTAP volume. You have NFSv3 or SMB clients. You read from outside AWS by mounting over NFS or SMB (I did not measure this). Objects below 128 KiB dominate	A fixed cost of $269.57 a month or more. Capacity pool read latency is unmeasured, and read request charges can apply. Clients share the throughput capacity. S3 event notifications, lifecycle, and versioning are not supported on the S3 Access Points side

If your clients are Linux on AWS and you handle objects of 128 KiB or more while keeping the source of truth in an S3 bucket, start evaluating with S3 Files. If you have NFSv3 or SMB clients, read from outside AWS by mounting over NFS or SMB (I did not measure this), or mostly have objects below 128 KiB, start with FSx for ONTAP and S3 Access Points.

The object-size conditions are guidance drawn from the 64 KiB and 4 MiB results I estimated. I did not estimate sizes near 128 KiB. Decide the monthly order only after you replace the values in "Assumptions under which the order can flip" with those of your environment and check.

An invalid warm / cold comparison: lowering the threshold does not evict data already loaded

My first warm / cold comparison was invalid because both reads were warm. I have not confirmed the latency difference between warm and cold. Here warm means reading data held in high-performance storage, and cold means reading straight from the bucket.

The goal was to check the claim that only frequently read data becomes low-latency. I assumed that lowering the import threshold (sizeLessThan, default: import files under 128 KiB) and then reading the same file would make the read cold, and I measured on that assumption.

Why it was invalid: the threshold only decides what the next first access imports

The threshold decides what gets imported the next time a directory is accessed for the first time. Data already in high-performance storage is not evicted when you lower it. Even in the window I meant to be cold, CloudWatch DataReadBytes (bytes read from high-performance storage) was nonzero, so both reads came from high-performance storage.

The numbers gave it away. The supposedly cold read was faster than the warm one, at 2.94 ms, which cannot be right. The record reads that difference as run-to-run variation and remount differences.

Three reads: two are valid

The environment was ap-northeast-1, 2026-10-10, c5n.9xlarge, 64 KiB, o_direct, concurrency 1, p50 of n=30.

Read	p50	Valid
High-performance storage (threshold 131072, 64 KiB already imported)	5.33 ms	Valid
Same file after lowering the threshold to 1024	2.94 ms	Invalid (both warm)
A newly created 64 KiB file with the threshold left at 1024 (direct from the bucket)	4.05 ms	Valid

Source of this table: Three reads (Japanese)

The two valid rows, 5.33 ms and 4.05 ms, differ by an amount within run-to-run variation. A separate t3.small record showed 10.8 ms from high-performance storage and 55.0 ms straight from the bucket (2026-09-01), but that did not reproduce on c5n.9xlarge. The environments and methods differ, so it is not a comparison that varies only the path in one environment.

To measure cold, read a new file that has not been imported after lowering the threshold, and confirm the path with DataReadBytes. The 2.94 ms in this post cannot serve as evidence for a warm / cold difference.

Status of the four stated values: I got numbers for two

Of the four values AWS states, I got numbers for two: propagation time when using both files and the S3 API, and aggregate growth with client count (up to 8). The comparison for "only frequently read data becomes low-latency" was invalid, so I cannot confirm it. I did not measure "existing tools work as they are".

Stated value	What I confirmed	Status
Existing file-based tools work as they are	The measurement tool, VDBENCH, ran on the mount. I did not look at compatibility with existing applications	Not measured
The same data is usable from both files and the S3 API	Propagation p50 was 63,769.3 ms (a window of about 60 seconds) from writing a file to reading it with the S3 API, and 1,533.1 ms from writing with the S3 API to reading it as a file (t3.small, NFSv4.2, 64 B, concurrency 1, n=30, 2026-09-01)	Measured. File to S3 has a window of about 60 seconds
Only frequently read data sits in high-performance storage and gets low latency	64 KiB p50 was 5.33 ms from high-performance storage and 4.05 ms straight from the bucket (c5n.9xlarge, n=30, 2026-10-10), within run-to-run variation. The first comparison was invalid	Not confirmed
Many clients can use it at once	Aggregate 784.4 to 6,282.6 MB/s (1 to 8 clients, 8.01x, c5n.2xlarge, 2026-10-10). I did not measure the 25,000-connection and TB/s-class limits	Measured up to 8 clients

Sources of this table: Propagation measurement, Three reads, Client-count measurement (same) (Japanese)

The values come with costs. Propagation from file to bucket takes about 60 seconds, the supported protocols are only NFSv4.1 and NFSv4.2, bucket versioning is required, and clients are limited to Linux on AWS. The two confirmed points are usable as grounds for adoption. Treat the low-latency value as an assumption only after you measure a cold read in your own environment.

What I have not measured

This post's measurements cover a single S3 Files mount (c5n.9xlarge), S3 Files client count (c5n.2xlarge, 1 to 8 clients), and latency by tier when reading through FSx for ONTAP S3 Access Points (one measurement). I did not measure the following five things.

What I have not measured (subject and object stated)	Why not	When not knowing hurts	How to measure
For S3 Files, I did not compare, under the same conditions, the read latency of data held in high-performance storage with the read latency of a first read straight from the bucket (the warm / cold difference).	The first comparison read from high-performance storage both times, because lowering the threshold did not evict the loaded data. See the chapter "An invalid warm / cold comparison".	You design on the assumption that only frequently read data is low-latency and do not budget for first-access latency.	In order: (1) lower the import threshold; (2) after lowering it, create a new file that has not been imported yet; (3) read that file and check that `DataReadBytes` (reads from high-performance storage) is not rising in the window, to confirm the path. Under the same conditions, also read a file held in high-performance storage and take the difference.
For S3 Files, I did not measure where the aggregate throughput stops growing when 9 or more clients read at once. I measured 1, 2, 4, and 8 c5n.2xlarge clients. The published limits are 25,000 connections per file system and an aggregate read of "up to terabytes per second" (quotas, Performance specifications).	My measurement plan stopped at 8 clients, and instance costs grow with the client count.	You design for dozens of clients sharing it and multiply roughly 785 MB/s per client by the client count as is.	With the same procedure (`s4-ladder.sh`), raise the client count to 16 and 32 and look for the count where per-client throughput starts to fall.
For S3 Files metadata charges, I could not confirm where the number of operations per read comes from, whether it reaches the bill, or how metadata writes on import are metered. All I know is one observation (m5.large, 2026-10-16): for a 4 MiB read, `MetadataReadBytes` registered about 6.0 times per object.	I did not capture the breakdown of the roughly 6 (open, getattr, or others), and I have not confirmed whether the reads went through NFS or directly to the bucket. Cost Explorer right after the measurement showed no usage, so I cannot tell whether it is the same as the billing meter. `MetadataWriteBytes` on import had 0 data points, and I could not tell whether no ingest happened or whether it is not metered.	You use the "Of which S3 Files metadata charges" column of the cost tables as a bill estimate.	After a few days, reconcile the Cost Explorer usage (`APN1-Files-Read`) against the sum of `DataReadBytes` and `MetadataReadBytes`. Take the per-operation breakdown from NFS operation statistics. For ingest, also compare the increase in `Inodes` before and after.
For FSx for ONTAP S3 Access Points, I did not confirm how many read requests one `GetObject` of an object on the capacity pool generates on the capacity pool.	In the measured window (33 reads), the per-volume `CapacityPoolReadOperations` was 0. The reads did not reach the capacity pool, so there is no numerator to derive a count from. This is not something waiting for Cost Explorer to fill in.	You build an estimate that puts read-heavy data on a Tiering All volume.	First confirm the conditions under which reads reach the capacity pool. In a window where they do, read the per-volume `CapacityPoolReadOperations` one-minute values and divide by the number of reads. Use `CPoolStdRd` in Cost Explorer for the later reconciliation.
I did not measure the latency difference of reading capacity pool data in a Multi-AZ configuration, from an on-premises client, or from inside a VPC (no internet round trip). I measured one time, from a local machine outside AWS over the internet.	My test environment was a single Single-AZ file system, and the client was one machine outside AWS.	Your configuration (client location, AZ layout) differs from my measurement, and you apply +5.3 to +15.4 ms as is.	Put the client on EC2 in the same VPC and alternate reads of the same size from an SSD volume and a capacity pool volume.

If any row has conditions that differ from yours, measure that row first.

Reproducing it yourself: three runbooks from creation to teardown

You can follow this post's measurements in your own AWS account with the same steps. I put runbooks from creating the environment to tearing it down on GitHub. The links are pinned to the commit of the measurement.

Create the environment and mount: S3 Files verification environment setup (Japanese). It builds with CloudFormation and runbook.sh. The most frequent cause of a silently hanging mount (missing CloudWatch permissions on the host role) is written at the start of these steps.
Measure throughput and client count: from the section "Measuring throughput and client count" on the same page, go to throughput-runbook.sh (single mount) and s4-ladder.sh (1 to 8 clients). VDBENCH requires accepting Oracle's license, so obtain it separately.
Results and conditions: S3 Files file system performance (Japanese). This is where this post's numbers come from, each with its environment. It also states that each is a single sample.

Leaving the verification environment up keeps billing. When you finish measuring, tear it down with the runbook's destroy and stop, then confirm by count that nothing remains.

Closing

Two things hold from the measurements, and one from the estimate.

The single-mount ceiling was one efs-proxy CPU core. It was 1,104.9 MB/s for 1 MiB sequential reads on a c5n.9xlarge (one run, 2026-10-10, ap-northeast-1).
When bandwidth falls short, adding clients raised it. From 1 to 8 c5n.2xlarge clients, the aggregate went from 784.4 MB/s to 6,282.6 MB/s (8.01x). I have not measured 9 or more.
In the estimate, under this model's base assumptions, the monthly cost order split by object size, not by read and write volume. The candidate for the dividing line is around the S3 Files import threshold (128 KiB), and I estimated only two sizes, 64 KiB and 4 MiB. With the stored volume fixed at 20 TiB and five patterns (P1, P4, P5, P6, P8), 64 KiB comes to $1,783.11 to $2,218.13 a month on FSx for ONTAP and $7,928.32 to $12,030.81 via S3 Files, and 4 MiB comes to $512.14 to $543.52 via S3 Files and $1,781.28 to $1,788.08 on FSx for ONTAP (ap-northeast-1, subtotals of the main line items with prices read on 2026-08-09; list price x quantity, not an invoice). This order is a result under the model's base assumptions and can flip when they change, so check it against your own values.

Which one to consider first narrows down by where the source of truth lives and where clients read from. Because the monthly order by object size can change with assumptions, treat the object-size conditions in the next table as guidance under the base assumptions of the estimate.

Condition	Setup	Check first
The source of truth is an S3 bucket. Clients are Linux on AWS and can use NFSv4.1 or later. Objects of 128 KiB or more dominate	S3 Files	Bucket versioning, about 60 seconds from file to bucket, and that NFSv3 and SMB are not supported
The source of truth is an ONTAP volume. You have NFSv3 or SMB clients, read from outside AWS by mounting over NFS or SMB (I did not measure this), or mostly have small objects below 128 KiB	FSx for ONTAP with S3 Access Points	A fixed cost of $269.57 a month or more, capacity pool read request charges, and that clients share the throughput capacity
Warm / cold latency, 9 or more clients, or the capacity pool read count will decide your design	Measure in your own environment, then decide	The rows of the "What I have not measured" table whose conditions differ from yours

I keep every measured value, each with its environment, on GitHub. I hope this helps anyone with a similar need (collect in S3, read as files).

Until next time.

Yoshiki Fujiwara

How AWS Bedrock AgentCore Actually Works

Pin Xiong — Fri, 16 Oct 2026 09:20:35 +0000

Originally published on xiongpin.dev.

AWS Bedrock AgentCore replaces Dockerfiles, instance sizing and hand-rolled IAM with a single JSON file. One command turns that file into a running, observable endpoint. This walkthrough covers the full path from project creation to trace analysis.

What AgentCore is and is not

AgentCore is a family of managed runtimes for AI agents: nine managed services covering hosting, memory, access control, tool integration, code execution, browser automation, quality and observability. This article covers two of them: Runtime and Observability.

What it is not:

Not a new agent framework. You still write your agent in Strands, LangChain, the OpenAI SDK or raw Python.
Not container orchestration. Each session gets its own microVM and the platform handles scaling.
Not a model router. Your code calls Bedrock the way it would anywhere else.

AgentCore hosts that code and adds an HTTP endpoint, an IAM role and a trace pipeline. Readers who have run ECS or Fargate will notice the difference at once: no Dockerfile, no task definition, no target group.

Three layers, one direction

You write agent code. You write two JSON files. The CLI generates everything else. AWS runs a CloudFormation stack that you never have to look at.

Layer	What lives there	Who maintains it
Business code	`app/<AgentName>/` with the agent entrypoint	you
The contract	`agentcore.json` and `aws-targets.json`	you, by hand
The plumbing	a CDK project under `agentcore/cdk/`	the CLI, on every deploy

The design follows one principle: declared resources live in JSON; everything the CLI generates is regenerable.

The environment you need

Requirements:

Tool	Version used	Notes	Check
Node.js	24.x	20+ required by the CLI	`node --version`
AgentCore CLI	0.31.1	install below	`agentcore --version`
AWS CLI	2.x	any recent build	`aws --version`
uv	0.11.9	the CLI builds the Python environment for template agents with it	`uv --version`
Git	2.39	`create` runs `git init` in the new project	`git --version`
Python	3.12 in the app venv	3.10 to 3.14 supported by CodeZip; the runtime target is the CLI's default, not your interpreter	`python3 -V`
AWS account	any	with permissions below	`aws sts get-caller-identity`
Region	us-east-1	the whole series uses it	`aws configure get region`
Docker	not needed	this series uses CodeZip builds	n/a

Install the CLI and set the region:

npm install -g @aws/agentcore@latest
aws configure set region us-east-1

Self-check commands and expected output:

node --version
# v24.14.0

uv --version
# uv 0.11.9

git --version
# git version 2.39.5

agentcore --version
# 0.31.1

aws sts get-caller-identity --query '[Account,Arn]' --output text
# 123456789012    arn:aws:iam::123456789012:user/yourname

aws configure get region
# us-east-1

aws bedrock list-foundation-models --region us-east-1 \
  --query 'modelSummaries[?modelId==`deepseek.v3.2`].modelId' --output text
# deepseek.v3.2

Runtime IAM role. The CLI generates an IAM role for the runtime. The policy carries three permission groups: bedrock:InvokeModel*, logs:* for the group under /aws/bedrock-agentcore/runtimes/, and xray:PutTraceSegments. It is a least-privilege template for later.

Known issue: if agentcore --version errors but the command exists, an old Python package (bedrock-agentcore-starter-toolkit) is shadowing the npm one. pip uninstall bedrock-agentcore-starter-toolkit fixes it.

Step 1 · Scaffold the project

agentcore create --name hello_agent --project-name helloagent \
  --framework Strands --model-provider Bedrock --memory none --defaults

[done]  Create helloagent/ project directory
[done]  Prepare agentcore/ directory
[done]  Initialize git repository
[done]  Add agent to project
[done]  Set up Python environment

Created:
  helloagent/
    app/hello_agent/  Python agent (Strands)
    agentcore/        Config and CDK project

Project created successfully!

To continue, navigate to your new project:

  cd helloagent
  agentcore

The command produces three categories of files:

The project root gets AGENTS.md, README.md and git init. agentcore/ gets the contract (agentcore.json), the targets file (aws-targets.json), .env.local for secrets and the vendored cdk/ app. app/hello_agent/ gets the agent: main.py (entrypoint), a model/ package, pyproject.toml and helper packages (mcp_client/, skills/). The contract points codeLocation at app/hello_agent/ and entrypoint at main.py; the platform zips, deploys and starts what codeLocation names.

Inside agentcore/, only agentcore.json and aws-targets.json are yours to edit; the rest is regenerated on every deploy. The CLI detects a project by walking up from the current directory until it finds a folder holding both agentcore/ and agentcore/agentcore.json (missing either reports No agentcore project found).

Every resource array except runtimes starts empty, and aws-targets.json is []. You fill both next.

Step 2 · Write the contract: two JSON files

The deployment definition, trimmed to the fields that matter:

{
  "$schema": "https://schema.agentcore.aws.dev/v1/agentcore.json",
  "name": "helloagent",
  "version": 1,
  "managedBy": "CDK",
  "runtimes": [
    {
      "name": "hello_agent",
      "build": "CodeZip",
      "entrypoint": "main.py",
      "codeLocation": "app/hello_agent/",
      "runtimeVersion": "PYTHON_3_14",
      "networkMode": "PUBLIC",
      "protocol": "HTTP",
      "envVars": [{ "name": "MODEL_ID", "value": "deepseek.v3.2" }]
    }
  ],
  "memories": [],
  "knowledgeBases": [],
  "agentCoreGateways": []
}

create writes this file with every resource array empty; agentcore add (add agent, add memory, add gateway) pushes entries in.

Four fields in the runtime block cannot be wrong without a failed deploy: entrypoint (the file the platform calls), codeLocation (app/hello_agent/), build (CodeZip, meaning no container) and protocol (HTTP). The rest have defaults. envVars is how MODEL_ID reaches your code, so switching models is a JSON edit rather than a code change.

Check that model/load.py reads the model from the MODEL_ID environment variable rather than a hardcoded ID (the generated template sometimes defaults to a Claude model):

import os
from strands.models.bedrock import BedrockModel

def load_model() -> BedrockModel:
    model_id = os.environ.get("MODEL_ID", "deepseek.v3.2")
    return BedrockModel(model_id=model_id)

Validate the contract before deploying:

agentcore validate
# Valid

The second file decides where the deployment lands:

[
  { "name": "default", "account": "123456789012", "region": "us-east-1" }
]

create writes only an empty array. The first deploy fills it in: it calls STS, learns who you are and writes the target back into the file. There is no --region flag on deploy, status or remove, so the file is the only source of truth for where your agent lands.

Step 3 · Deploy: one command, six steps

From the project root:

agentcore deploy -y --target default

Between the command and the last checkmark, six things happen:

Package the code. The CLI zips whatever codeLocation names, with platform dependencies, into one asset. A hello-world agent produces a 41 MB zip; the local .venv is excluded. No image is built anywhere in the project.
Synthesize. The vendored CDK app (node dist/bin/cdk.js) reads both JSON files and emits a CloudFormation template into cdk.out/.
Upload the asset. The zip lands in the S3 bucket that cdk bootstrap created once per account and region. Without that one-time bootstrap, no CDK deployment can store an asset.
Create the stack. CloudFormation provisions four resources: the runtime, an IAM role for it, a Bedrock model-access policy and a CDK metadata resource.
Record the state. The CLI writes agentcore/.cli/deployed-state.json with the runtime ARN and endpoint.
Print the endpoint.

The synthesis step is where schema-first becomes visible. The generated app reads your files by path and carries no project knowledge of its own:

// agentcore/cdk/bin/cdk.ts, verbatim from the generated project
async function main() {
  const configRoot = path.resolve(process.cwd(), '..');
  const configIO = new ConfigIO({ baseDir: configRoot });

  const spec = await configIO.readProjectSpec();             // agentcore.json
  const targets = await configIO.readAWSDeploymentTargets(); // aws-targets.json
  ...
}

The generated CDK app reads agentcore.json and aws-targets.json by path and carries no project-specific logic; it is a compiler driven entirely by the two files.

Measured timings: this deploy took 3 minutes 29 seconds. The CLI's step log says where it went: building the CDK project 25 s, synthesizing CloudFormation 1 m 3 s, creating the stack 1 m 51 s. The first deploy ever in this account took 9 minutes 49 seconds; the one-time cdk bootstrap and the CDK project's first npm install account for the difference. A code-only redeploy took 1 minute 26 seconds, because the stack already exists and only the asset hash changes. Verify with agentcore status, which reports Runtime: READY plus the endpoint URL.

Step 4 · Run the same code locally

agentcore dev -l runs the same app locally on localhost:8080. Model calls still go to Bedrock, so credentials are needed but no deployment is. Edits to main.py trigger hot reload without a restart.

Step 5 · Invoke the deployed runtime

The deployed runtime answers through the data plane. The CLI wraps it:

agentcore invoke --prompt "What is 17 plus 25? Use the tool."

The answer is correct and the tool ran, but the reply carries model scaffolding around it: the I'll use the addition tool preamble and a <|DSML|>function_calls marker precede the final text. That is model behavior, not a platform bug; the troubleshooting section explains the fix.

agentcore dev and the deployed runtime are two hosts for the same app: the local server on localhost:8080, and a managed microVM behind https://bedrock-agentcore.<region>.amazonaws.com/runtimes/<runtime-arn>/invocations. Both expose the same two routes (/ping, /invocations); routing, scaling and TLS stay on the platform side, so the code is unaware which host it runs on. agentcore invoke is a CLI client for the hosted /invocations.

Cost per invoke: DeepSeek V3.2 in us-east-1 charges $0.62 per million input tokens and $1.85 per million output. A two-cycle invoke used 846 input and 82 output tokens: about $0.0007 of model calls plus $0.0002 of runtime compute. For a tutorial-grade agent, the infrastructure bill rounds to zero.

Under the hood I: the HTTP contract

The runtime makes two requests to your code: GET /ping for health checks and POST /invocations for work. BedrockAgentCoreApp is a thin adapter mapping those routes onto an async generator:

from bedrock_agentcore.runtime import BedrockAgentCoreApp
from strands import Agent, tool

app = BedrockAgentCoreApp()

@tool
def add_numbers(a: int, b: int) -> int:
    """Return the sum of two numbers."""
    return a + b

@app.entrypoint
async def invoke(payload, context):
    session_id = getattr(context, "session_id", "default-session")
    agent = get_or_create_agent(session_id)
    async for event in agent.stream_async(extract_prompt(payload)):
        yield event

Three design details:

The entrypoint is an async generator. Every yielded dict becomes one server-sent event, so streaming is the platform's default shape, not an add-on.
context.session_id is the only state key you manage. Each session runs in its own microVM; the platform handles scaling.
A production entrypoint also filters text deltas through a stream sanitizer; this demo runs without one, so the leak is visible in the invoke screenshot (see Troubleshooting).

Under the hood II: what observability records

A deployed invoke produces this span tree in X-Ray. The output is real, including the token counts:

agentcore traces list          # lists recent traces (2-3 min after the invoke)
agentcore traces get <trace-id>

invoke_agent Strands Agents              gen_ai.agent.tools=["add_numbers"]  tokens=902
├── execute_event_loop_cycle  (cycle 1)
│   ├── execute_tool add_numbers         gen_ai.tool.status=success  span_kind=TOOL
│   └── chat  deepseek.v3.2 (LLM, 435 tokens)
│       └── chat deepseek.v3.2 (Bedrock)   finish_reason=tool_use
└── execute_event_loop_cycle  (cycle 2)
    └── chat  deepseek.v3.2 (LLM, 467 tokens)
        └── chat deepseek.v3.2 (Bedrock)   finish_reason=end_turn

The structure teaches the agent loop without reading framework source: one cycle per model round trip, the tool call as its own span inside the cycle, and a second cycle that consumes the result.

Two caveats from measurement:

Spans are asynchronous. Transaction search takes about ten minutes before anything is queryable, so a test that invokes and greps CloudWatch immediately will fail.
Local agentcore dev traces record tool calls in logs but not as spans. Only the deployed runtime emits the execute_tool span. A smoke test that asserts on a tool span must run against the deployment.

Cleanup

Two commands bring the whole thing down, run from the project root:

agentcore remove all -y     # empties every resource array in agentcore.json
agentcore deploy -y         # converges the stack to an empty one
agentcore status            # nothing deployed should be listed

remove all edits the JSON; it does not touch AWS on its own. The deploy that follows deletes the runtime, its IAM role and the stack. Two things survive on purpose: the CDK bootstrap stack (CDKToolkit) and its asset bucket, reused by every future deployment in that account, and the CloudWatch log group under /aws/bedrock-agentcore/runtimes/ holding the traces. Delete those by hand if finished with the account. AgentCore bills per use, not per hour, so a deployed project left idle costs nothing.

Troubleshooting

Stale cdk.out fails the next deploy. The CLI deletes cdk.out before each synth, so leftover state from a previous run can kill it with Subprocess exited with error 1. Running cdk synth by hand still works, confirming the project itself is fine. rm -rf agentcore/cdk/cdk.out fixes it.
Renaming is destroying. The name field becomes the CloudFormation logical ID. Changing it does not rename the runtime; it deletes the old one and creates a new one.
Models leak scaffolding into the text channel. deepseek.v3.2 emits fragments of internal chat-template markers as ordinary text (visible in the invoke screenshot); Nova models emit <thinking> blocks. Calling Bedrock's converse_stream with Strands removed proves this is model behavior, not a framework bug. The fix is a stream-safe filter in the entrypoint that holds back marker prefixes and resets once per assistant message; the official 01-features/06-observe sample ships a reference implementation.
The region is not a flag. Every --region guess fails with unknown option. The targets file decides.
Model fallback to Claude triggers geographic restriction. If MODEL_ID is not properly loaded from the envVars, the Strands SDK defaults to a Claude model. Readers in regions where Anthropic models are unavailable see Access to Anthropic models is not allowed from unsupported countries. Verify MODEL_ID is in agentcore.json envVars and that model/load.py passes it to the BedrockModel constructor explicitly, not relying on the SDK default.

Takeaways

The JSON file is the interface. Everything downstream (the CDK project, the template, the stack) is regenerable plumbing driven by it.
CDK appears as a vendored compiler. No constructs to write, no generated project to edit. Change the schema and the same code compiles a different stack.
Local and deployed share one HTTP contract. /ping and /invocations behave identically, so code that passed locally deploys without a shim.
Observability is real but asynchronous. The tool call gets its own span in the cloud and spans take minutes to become queryable. Write tests accordingly.

In AgentCore, your infrastructure is not code you maintain. It is code that compiles.

Streaming Salesforce Events to AWS with Event Relay and EventBridge

Sabarish Sathasivan — Thu, 15 Oct 2026 18:46:34 +0000

Background

Many organizations keep data in Salesforce and run their applications on AWS. Keeping the two in sync often goes through an integration platform such as Boomi or MuleSoft, which adds licensing cost and another system to run.

This article shows how to use Salesforce Event Relay and the Amazon EventBridge partner integration for Salesforce to synchronize data from Salesforce to AWS through EventBridge, without middleware.

In the example, when a customer is created in Salesforce, the customer details are sent to EventBridge and stored in DynamoDB for the AWS applications to use. The full code, including the Salesforce metadata and the CDK stack for the AWS side, is in the GitHub repo.

Architecture

Salesforce

When a record is created, updated, or deleted, Salesforce can publish a platform event. A platform event is a message that systems outside Salesforce can subscribe to. Salesforce doesn't publish it on its own: a record-triggered Flow or an Apex trigger publishes the event when the record changes.

Published events go to the Salesforce event bus. Subscribers read events from the bus. The bus keeps events for 72 hours, which makes replay possible in case of an outage.

In this example, when a customer is created, Salesforce publishes a platform event called Customer_Created__e with these fields:

Field	Type	Description
`Account_Id__c`	Text(18)	Salesforce ID of the Account (customer) record
`Name__c`	Text(255)	Customer name
`Industry__c`	Text(40)	Customer industry
`CreatedDate`	Date/Time	Standard field, set by Salesforce when the event is published
`CreatedById`	Lookup(User)	Standard field, the user who published the event

Salesforce Event Relay

Event Relay is a Salesforce feature that reads events from the Salesforce event bus and delivers them to Amazon EventBridge in your AWS account. Salesforce keeps track of the last event it delivered. After a transient error, such as a connectivity issue, the relay resumes from where it left off.

A relay is built from three Salesforce components:

Named credential. It tells Salesforce where to deliver: your AWS account ID and region, written as a URL such as arn:aws:US-EAST-1:123456789012. It contains no AWS keys and no IAM role. Salesforce is a registered EventBridge partner, so no AWS authentication is involved. The region must be uppercase. Once a relay uses the credential, you can't change the account or region without deleting and recreating the relay.
Channel. It decides what to deliver. A channel groups one or more event types, and each event type is added as a channel member. In this example the channel has one member, Customer_Created__e.
Event relay. It connects one channel to one named credential, and it holds the recovery setting described in Recovery after an outage. A new relay starts out stopped. After it's created, you can change only its state and recovery setting. A wrong channel or credential means deleting the relay and creating it again.

When you create the relay, Salesforce registers a partner event source in your AWS account, in a pending state. You associate that source with an event bus in AWS, then start the relay in Salesforce. Events start flowing at that point. That bus is a partner event bus, and it receives only the events from this relay. One relay maps to one channel, one partner event source, and one partner bus.

To configure each piece, follow Salesforce's guide Relay Events from Salesforce to Amazon EventBridge.

What arrives in AWS

This is a relayed event as EventBridge delivers it:

{
  "version": "0",
  "id": "6f33d717-8e35-4488-5690-89e681b5737c",
  "detail-type": "Customer_Created__e",
  "source": "aws.partner/salesforce.com/00D.../0YL...",
  "account": "123456789012",
  "time": "2026-10-13T19:23:23Z",
  "region": "us-east-1",
  "resources": [],
  "detail": {
    "payload": {
      "CreatedById": "005...",
      "CreatedDate": "2026-10-13T19:23:22.686Z",
      "Account_Id__c": "0015g00000AbCdEAAV",
      "Name__c": "Example Corp",
      "Industry__c": "Manufacturing"
    },
    "schemaId": "mVBhpA7tU9MCtBEbqjycBQ",
    "id": "118dab75-7b45-498e-8478-52d0324c1060"
  }
}

source contains the Salesforce org ID and channel ID.
detail-type is the Salesforce event name, which is what the rule matches on.
The fields are under detail.payload, with their Salesforce API names.
The top-level id comes from EventBridge. detail.id comes from Salesforce.

EventBridge rule

The rule matches detail-type = Customer_Created__e and sends those events to the SQS queue.

Amazon SQS queue and DLQ

The rule sends events to an SQS queue instead of invoking the Lambda directly, with a DLQ for messages that can't be processed. The queue absorbs bursts, lets you cap Lambda concurrency so DynamoDB isn't overloaded, and retries failed messages. Messages that keep failing stay in the DLQ, so you can redrive them after a fix.

Lambda and DynamoDB

The Lambda reads the customer details from the event and writes them to DynamoDB. That is where the AWS applications read the data from.

Design decisions

Recovery after an outage

If the relay hits an error it can't resume from, a recovery setting decides what happens (Error Recovery):

LATEST (the default) skips events published during the outage.
EARLIEST re-sends everything still retained on the Salesforce event bus, up to 72 hours.

For business data, EARLIEST is usually the right choice, because a missed event means a customer the AWS applications don't know about. The cost is duplicates. Between EARLIEST recovery, EventBridge retries, and SQS retries, the same event can be delivered more than once, so the application must be designed to process duplicate messages. In this example, the Lambda writes with a conditional put keyed on the Account ID and treats an existing record as success, so duplicates never reach the DLQ.

Small payloads

Salesforce documents a 256 KB limit for relayed events. Larger events aren't delivered to EventBridge. Hence, the event should carry only the record ID and the fields the AWS applications need.

Monitoring the relay

If the relay goes into an error state, delivery stops until Salesforce recovers. It retries periodically and resumes from where it left off, but it doesn't notify anyone (Relay status). Monitor the relay by querying EventRelayFeedback, a Salesforce object that holds the relay's status and error details.

Cost

On the Salesforce side, Event Relay is included at no extra cost. Relayed events count toward the org's daily event delivery allocation. By default, that's 50,000 events a day for Unlimited and Performance editions and 25,000 for Enterprise Edition. If you need more, Salesforce sells a platform events add-on that raises it by 100,000 events a day.

On the AWS side, events arriving on the partner event bus are billed as partner events, at $1.00 per million events. Each 64 KB chunk of an event counts as one event.

Limits

Salesforce edition. Event Relay is available in Enterprise, Unlimited, and Developer editions. It isn't available in Government Cloud. A free Developer Edition org is enough to build and test this example.
Event types. Event Relay works with custom high-volume platform events, which is the default for any new custom platform event such as Customer_Created__e. It also works with Change Data Capture and Real-Time Event Monitoring events.
AWS region. Event Relay can deliver only to default AWS regions. Default regions, such as us-east-1, are enabled in every AWS account. Opt-in regions, such as Europe (Milan), have to be enabled first, and Event Relay doesn't support them.
Delivery allocation. Salesforce limits how many events an org can deliver in 24 hours, and every event the relay sends to EventBridge counts toward that limit. Other integrations that subscribe to events in the same org share it, so relay only the events AWS needs.

Hands-On with AWS DevOps Agent: Changing DevOps Work Without Replacing Engineers

Matheus das Mercês — Thu, 15 Oct 2026 09:22:27 +0000

Introduction

When an AI agent can investigate incidents, read operational context, query systems, and suggest what might be wrong, it is natural to ask whether this kind of capability will eventually replace part of the work DevOps engineers do today.

In this article, I will share how we experimented with AWS DevOps Agent, why we wanted to bring the investigation flow closer to engineers through Slack. The goal is not to argue that AI agents should replace DevOps engineers, but to show how they can change the type of work engineers spend time on.

The most important part is: what the engineer asks, what context the agent needs, which skills make the investigation useful, and where human judgment should remain in control.

The turning point

Generative AI focuses on creating new content based on an input. The output can be text, images, audio, video, software code, or any other artifact generated from a prompt. That is already useful in many engineering workflows, especially when the task is about explaining, summarizing, drafting, or creating something from existing context.

Agentic AI has a different goal. Instead of only generating content, an agent is expected to work toward an outcome. In the DevOps context, this means the agent needs to understand what is happening, use tools, inspect data, reason over the environment, and come back with findings that help the engineer decide what to do next.

This difference becomes important when the problem is not “write me a summary,” but something closer to “investigate why this service is failing.” In that case, the useful output is not only a nice explanation. The useful output is a hypothesis supported by evidence from logs, metrics, topology, recent changes, known incidents, and operational knowledge.

The DevOps problem we wanted to solve

At the AI Center of Excellence team at PostNL, we build and operate AI capabilities used by multiple teams and applications. These services do not live in a single cloud environment. A single user-facing capability can depend not only on AWS services, but also services in other cloud providers, services, external APIs, networking, authentication, model providers, and internal platform components.

The complexity is not necessarily the number of services involved. The real complexity appears when something goes wrong, and the engineer needs to understand where to look first. During an incident, this can easily become a manual process of opening dashboards, checking the AWS Console, searching logs, inspecting metrics, comparing timestamps, and trying to form a hypothesis from many disconnected signals.

This is especially painful during on-call situations. When an engineer is woken up at night, the first minutes are often spent collecting evidence instead of making decisions. The engineer still needs to own the decision, but there is a lot of repetitive investigation work before reaching the point where human judgment is most valuable.

Why we chose AWS DevOps Agent

When you look at this kind of problem, it is tempting to say that you should simply build an agent. However, building an agent is not only about sending a prompt to a model. You need to define, among other things:

What the agent should achieve;
Which systems it can access;
Which tools it can use;
What information it should remember;
How much autonomy it should have;
Which actions require approval;

In our case, we wanted the benefit of an operational investigation agent, but we did not want to become the team responsible for maintaining the entire investigation engine ourselves. We needed something that could understand resources, dependencies, operational patterns, and topology, while still allowing us to shape the workflow around our own environment.

This is where AWS DevOps Agent became interesting. Instead of building the investigation engine from scratch, we could use the managed capability as the core and focus on the thin layer around it. That layer was still important, but it was much closer to our actual problem: making the investigation accessible from where engineers already work and giving the agent the right operational context.

What we built around it

One of the decisions we made early was that we did not want another dashboard. During incidents, engineers are already communicating in Slack, so asking them to open another tool just to start the investigation did not feel like the right experience.

The idea was to create a Slack bot that could act as the entry point for investigations. An engineer could ask something like /watchdog investigate the 429s we are seeing, and the bot would trigger the investigation flow with AWS DevOps Agent. The result was not meant to remove the engineer from the process, but to reduce the amount of manual evidence gathering before the engineer could make a decision.

The architecture was intentionally thin around the managed capability:

Slack was the interface where engineers already worked.
The /watchdog command was the trigger for the investigation.
A small Lambda function behind an API Gateway translated the Slack request into an investigation request.
AWS DevOps Agent performed the investigation using the operational context available to it.
The Slack thread became the place where findings and updates were shared back with the engineer.

The agent itself was also defined as infrastructure. The important part was to define the AWS DevOps Agent space and the role it could assume to investigate the AWS account. The cool thing is that you can control exactly what resources the agent is allowed to investigate.

One limitation we had to account for is that not everything in AWS DevOps Agent was available through CDK or CloudFormation. The Agent Space and AWS account association could be defined as infrastructure, but skills still had to be configured outside CDK at that point. That means the infrastructure could create the managed agent foundation, while the operational knowledge attached to the agent still required a separate setup step in the console.

In a simplified version of the CDK code, the core definition of the AWS DevOps Agent space looked like this:

import * as cdk from 'aws-cdk-lib';
import * as iam from 'aws-cdk-lib/aws-iam';
import { Construct } from 'constructs';

export class DevOpsAgentStack extends cdk.Stack {
  constructor(scope: Construct, id: string, props?: cdk.StackProps) {
    super(scope, id, props);

    const agentSpaceArnPattern = `arn:aws:aidevops:${this.region}:${this.account}:agentspace/*`;

    const monitorRole = new iam.Role(this, 'MonitorRole', {
      assumedBy: new iam.ServicePrincipal('aidevops.amazonaws.com', {
        conditions: {
          StringEquals: { 'aws:SourceAccount': this.account },
          ArnLike: { 'aws:SourceArn': agentSpaceArnPattern },
        },
      }),
      managedPolicies: [
        iam.ManagedPolicy.fromAwsManagedPolicyName('AIDevOpsAgentAccessPolicy'),
      ],
    });

    monitorRole.addToPolicy(
      new iam.PolicyStatement({
        actions: ['iam:CreateServiceLinkedRole'],
        resources: [
          `arn:aws:iam::${this.account}:role/aws-service-role/resource-explorer-2.amazonaws.com/AWSServiceRoleForResourceExplorer`,
        ],
      })
    );

    const agentSpace = new cdk.CfnResource(this, 'AgentSpace', {
      type: 'AWS::DevOpsAgent::AgentSpace',
      properties: {
        Name: 'example-devops-agent',
        Description: 'DevOps investigation agent',
      },
    });

    new cdk.CfnResource(this, 'AwsMonitorAssociation', {
      type: 'AWS::DevOpsAgent::Association',
      properties: {
        AgentSpaceId: agentSpace.ref,
        ServiceId: 'aws',
        Configuration: {
          Aws: {
            AccountId: this.account,
            AccountType: 'monitor',
            AssumableRoleArn: monitorRole.roleArn,
          },
        },
      },
    });
  }
}

This gave us a workflow where the agent could do the first investigation pass, but the engineer still owned the interpretation and the next step. That distinction was important because the goal was not to create a fully autonomous incident response system, but to reduce the repetitive work required to understand what was happening.

The skills we defined for the agent

The Slack bot request handler was only one part of the solution. The more important part was the context we provided to the AWS DevOps Agent space. A generic investigation agent can be useful, but real environments have details that are specific to the organization, the platform, the architecture, and the way teams operate.

For that reason, we defined custom skills and knowledge sources to help the agent understand our environment better. This can be easily created in the AWS DevOps agent space web app. Some examples were:

sample-skip-scheduled-maintenance: used to skip low-priority incidents during a scheduled maintenance window and avoid unnecessary investigations for expected disruptions.
azure-troubleshooting-guide: used to give the agent troubleshooting context for Azure-related incidents, performance issues, and dependencies.
understanding-ai-toolkit-architecture: used to document the architecture on Azure, workloads, resource groups, Function Apps, Cognitive Services, networking, and related components.
understanding-lpe-architecture: used to document the LandingZone PostNL Engineering infrastructure, including networking, IAM, monitoring, and alerting context.

These are the kinds of details that an engineer usually learns over time, but that an agent also needs if we expect it to produce useful findings.

This is where DevOps engineers still play a critical role. The value is not only in connecting an agent to tools, but in deciding which context the agent needs, which operational assumptions are safe, which sources of information are reliable, and which parts of the investigation should remain read-only or require approval.

AWS released native Slack support

There is an interesting detail in this story. We built the Slack bot because we wanted to bring the investigation flow to where engineers already work, and at that moment this meant creating our own thin integration between Slack and AWS DevOps Agent.

Later, AWS released native bidirectional Slack communication for AWS DevOps Agent. According to the AWS DevOps Agent What's New page, on September 1, 2026, AWS announced that you can start and continue conversations with AWS DevOps Agent directly from a private Slack channel by enabling bidirectional communication when associating a channel.

At first glance, it might look like this makes the custom Slack bot unnecessary. In practice, it makes the communication layer simpler, which is a good thing. The bot solved the interface gap we had at the time, but the reusable part of the work was not only the bot implementation. It was the understanding of how engineers wanted to interact with an investigation agent during an incident.

We still needed to define what engineers ask during incidents, what the agent should know, which skills improve investigations, and where the boundary between recommendation and action should be. If the native Slack integration covers the communication layer, the surrounding concepts can still help with additional context, specialized knowledge, Bedrock-based extensions, knowledge bases, or other systems that provide the agent with better input for the investigation, for example:

Before and after

The most important change is not that the engineer disappears from the workflow. The change is that the engineer starts from a better point in the investigation.

Before, the engineer had to manually collect evidence across multiple systems. That meant opening dashboards, checking cloud consoles, searching logs, comparing timestamps, and trying to understand whether the issue was related to AWS, Azure, an external dependency, networking, authentication, or something else. This work is important, but it is also repetitive and time-sensitive.

The old flow looked closer to this:

Wake up because something might be wrong or the engineer got a phone call.
Open dashboards and cloud consoles.
Check logs, metrics, alarms, and recent signals.
Compare timestamps across systems.
Build a first hypothesis manually.
Decide what to investigate next.

After introducing the agentic investigation flow, the engineer can ask the agent to investigate and then review the findings. The agent can search logs, query resources, correlate signals, and build an initial hypothesis. The engineer still evaluates the result, considers the business impact, and decides what should happen next.

The new flow became closer to this:

Ask the agent to investigate in Slack.
Let the agent collect operational signals and context.
Review the findings and hypothesis.
Decide what action, if any, should be taken.

This is the part of DevOps work that I think is worth changing. We should not try to automate judgment without understanding the risk, but we should reduce the amount of manual work required before judgment can happen.

What should stay human

Even if an agent can investigate an issue, not every action should be delegated without approval. There is a big difference between collecting evidence and changing production systems.

In a DevOps workflow, humans should remain responsible for decisions where context, risk, and business impact matter. For example, I would not put these actions in the same category as querying logs or summarizing metrics:

restarting critical services
changing infrastructure
disabling alarms
modifying permissions
applying mitigations that affect customers

These actions require a different level of control.

This is why I believe the most useful agentic workflows are not necessarily the ones with full autonomy. A workflow where the agent investigates, correlates, and proposes a hypothesis can already remove a lot of toil. The engineer can stay responsible for the decision while spending less time collecting the evidence manually.

Conclusion

AWS DevOps Agent is interesting to me because it can change the kind of DevOps work engineers spend time on. The goal is not to remove engineers from the process, but to reduce the repetitive investigation work that happens before engineers can make good decisions.

In our experiment, the Slack bot was a way to bring the investigation flow closer to where engineers already work. With the native bidirectional Slack support now available in AWS DevOps Agent, that communication layer can become simpler, but the core lessons remain useful. The operational context, the skills, the knowledge sources, and the approval boundaries are still the parts that make the workflow valuable.

The opportunity is to let the agent help with logs, signals, topology, and hypotheses while keeping engineers responsible for context, risk, and business impact. In other words, use AWS DevOps Agent to change DevOps work, not to replace DevOps engineers.

Using Firehose as a Lambda Log Destination

Sunny Bhambhani — Thu, 15 Oct 2026 07:43:05 +0000

Using Firehose as a Lambda Log Destination

The last logging option available in the Lambda configuration is Amazon Data Firehose.

This option becomes interesting when CloudWatch Logs is not the final destination and you want Lambda logs to keep moving through a delivery pipeline.

Instead of just storing logs in one place, Firehose is built to receive data, optionally transform it, and then deliver it to another system.

How Firehose works at a high level

The flow is fairly straightforward:

Ingest: choose where the incoming data comes from, such as Amazon Kinesis Data Streams, Amazon MSK, or Direct PUT
Transform: optionally process or enrich the data before delivery
Deliver: send the data to a destination such as Amazon S3, Splunk, Dynatrace, and others

That flexibility is the main reason Firehose is useful. It can sit between the source and the final storage or observability platform without needing you to build the delivery logic yourself.

For this example, I kept things simple and used Amazon S3 as the destination.

If you want to see the full list of supported destinations, AWS documents them here:

https://docs.aws.amazon.com/firehose/latest/dev/create-destination.html

The Firehose stream

Before sending Lambda logs to Firehose, I created a delivery stream with the following setup:

Source: Direct PUT
Destination: Amazon S3
ARN: arn:aws:firehose:eu-central-1:ACCOUNT_ID:deliverystream/PUT-S3-QdzyI

Make sure the status is Active after it is created.

Destination settings

The S3 delivery stream was configured like this:

S3 bucket: s3-lambda-logs
S3 bucket error output prefix: fh_err_
S3 bucket prefix: fh_
S3 bucket and error output prefix time zone: UTC
New line delimiter: Enabled

This setup is useful because it separates normal output from delivery errors and keeps the objects written to S3 organized under a predictable prefix.

Where the logs land in S3

After the stream is configured and Lambda starts sending logs through Firehose, the delivered files appear in S3 under a path like this:

Amazon S3 -> Buckets -> s3-lambda-logs -> fh_2026/ -> 10/ -> 11/ -> 12/

That structure makes it easier to find logs by date and process them later with downstream tools.

A quick note about delivery log classes

If you send logs to Amazon S3 or Amazon Data Firehose, Lambda requires a log group with the delivery log class.

That is an important detail because this log class is designed for delivery, not for the full CloudWatch Logs experience. In other words, you trade some CloudWatch features for simpler forwarding.

For example, delivery log class does not support standard CloudWatch Logs features such as Logs Insights and Live Tail.

It is also worth remembering that log events are only kept in CloudWatch Logs for two days when this class is used. That retention period is fixed and cannot be changed.

Function

The function remains the same which we discussed in the first article.

def lambda_handler(event, context):
    print("Dummy Lambda output")
    return {
        "statusCode": 200,
        "body": "Dummy Lambda output",
    }


if __name__ == "__main__":
    print(lambda_handler({}, None))

In this example:

A new log group is created named dummy_lambda_logs_to_firehose
I also created an IAM role for the Lambda function. The trust relationship and permissions are defined below:
- 03_iam_role_trust_relationships.json

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Service": "logs.amazonaws.com"
            },
            "Action": "sts:AssumeRole",
            "Condition": {
                "StringLike": {
                    "aws:SourceArn": "arn:aws:logs:eu-central-1:ACCOUNT_ID:*"
                }
            }
        }
    ]
}

03_iam_role_permissiones.json

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "firehose:PutRecord",
                "firehose:PutRecordBatch"
            ],
            "Resource": "arn:aws:firehose:eu-central-1:ACCOUNT_ID:deliverystream/*"
        }
    ]
}

Notes:

Log delivery to Amazon Data Firehose requires using a log group with the delivery log class. This enables efficient routing, but it does not support standard CloudWatch Logs features such as Logs Insights and Live Tail.

Final thought

If CloudWatch Logs is where you troubleshoot, S3 is where you archive, then Firehose is the option you use when logs need to travel.

For a simple demo, using Firehose with S3 keeps the architecture easy to understand.

In a larger environment, the same pattern can be extended to feed analytics, security, or observability platforms without changing the Lambda function itself.

Feel free to add your thoughts, happy learning!