AWS Storage Blog
Enable zero-copy access to AWS services on Amazon FSx for NetApp ONTAP with Amazon S3 Access Points
Semiconductor verification teams run thousands of simulation jobs every night using Electronic Design Automation (EDA) tools. A large verification environment can generate logs from 100,000 or more test executions per night. A single regression cycle produces simulation logs, compilation logs, and scheduler logs. For a regression with dozens of failures, manual triage typically takes 45–60 minutes. Identifying the root cause of a systemic issue can take several days. Today, engineers connect through SSH, search simulation outputs with grep, and cross-reference scheduler logs across multiple terminals. Some teams build custom scripts, but these require ongoing maintenance and don’t scale across regression suites. The log files already exist on high-performance shared NFS storage. The challenge is making them accessible to AI services that can read and correlate across files. This requires building ingestion pipelines or copying data to Amazon Simple Storage Service (Amazon S3).
In this post, we walk through an architecture that connects EDA verification workflows to AI-powered analytics without disrupting existing workflows or moving data. The architecture uses Amazon FSx for NetApp ONTAP with Amazon S3 Access Points, Amazon Bedrock AgentCore, and Amazon Quick.
S3 Access Points for FSx for ONTAP make verification logs accessible to AWS services through the S3 API. The data remains on the file system. AgentCore is a managed service for deploying AI agents with tool-use capabilities. Amazon Quick is an AI-powered analytics platform for natural language queries and automated workflows. In Amazon Quick, engineers can ask “What caused last night’s failures?” and receive a correlated analysis across simulation, compile, and LSF logs within minutes. With faster root cause analysis, engineers save time on manual triage, focus more on fixing bugs, and accelerate the tape-out timeline.
Solution overview
Figure 1 illustrates the solution architecture. EDA tools write log data to FSx for ONTAP using NFS. An S3 access point makes that data available through the S3 API. From there, engineers reach the log file in two ways: a knowledge base path for quick summary answers, or an agentic path for deep, multi-file investigation.
Figure 1: The EDA tool writes logs to FSx for ONTAP using NFS. The S3 access point makes the logs available through the S3 API (zero copy, read-only). The engineer reaches the logs through a knowledge base path or an agentic (MCP gateway) path.
Log files stored on FSx for ONTAP
EDA tools run simulation and compilation jobs on a compute cluster. These jobs write log files to FSx for ONTAP volumes using NFS. This is the existing workflow and requires no changes. FSx for ONTAP stores log data as a single source of truth. These logs reside on shared storage under project directories such as /mnt/fsx/logs/.
S3 Access Points for FSx for ONTAP
An S3 access point attached to the log volume makes this data available through the S3 API. You configure the access point with a read-only file system identity to restrict access. EDA tools continue writing using NFS, and AWS services read through the S3 API simultaneously. The S3 access point is created using the create-and-attach-s3-access-point CLI command.
RAG path (knowledge base)
Amazon Quick provides engineers a single interface for natural language queries, visual dashboards, and automated workflows. In the Retrieval Augmented Generation (RAG) path, Amazon Quick syncs and indexes log data from the S3 access point into a knowledge base. The Quick chat agent answers queries from this pre-built index rather than reading log files on each request. This makes it well suited for quick summary questions such as “How many simulations failed last night?”
Agentic path (MCP gateway)
AgentCore hosts an MCP gateway with AWS Lambda functions that read files live from FSx for ONTAP using the S3 access point. The MCP gateway exposes three tools to the agent:
- List – List directories.
- Read – Read S3 files.
- Search – Search across S3 files.
When the agent needs to read a simulation log, the Lambda function calls GetObject on the S3 access point. When it needs to browse available regressions, it calls ListObjects on the volume path. The agent autonomously navigates directories, reads multiple logs, and generates a detailed triage report. This path provides deeper cross-file analysis for questions such as “What is the root cause of the AXI timeout failures?”
How it works
In an example use case, an engineer opens Amazon Quick and asks a question such as “How many simulations failed last night and what are the most common errors?” Amazon Quick routes this to the MCP agent on AgentCore. The agent uses its tools to list the regression directory, identify log files with non-zero exit codes, and read the relevant simulation and LSF logs. It correlates error patterns across files and returns a grouped summary of failure types with counts and affected modules. The agent can also answer follow-up questions. It reads files from FSx for ONTAP through the S3 access point at query time. Results reflect the data as it exists on the file system when the query runs as in Figure 2.
Figure 2: Amazon Quick chat interface showing a sample triage question and AI-generated response
All components run within the customer virtual private cloud (VPC). The S3 access point enforces both AWS Identity and Access Management (IAM) policies and file system permissions. Only authorized services can read the log data. Write access remains exclusively on the NFS path.
The S3 access point makes log data available to AWS analytics or AI services through the S3 API. AgentCore and Amazon Quick are one implementation of this pattern. Other services such as Amazon Athena, AWS Glue, or custom Lambda functions can access the same data through the same access point.
Dashboards and automations
The same S3 access point that enables agentic log analysis also supports visual dashboards and scheduled automations.
Regression health dashboards
Amazon Quick Sight can read structured summary data from FSx for ONTAP through the S3 access point. A verification manager opens a browser each morning and sees the current state of the nightly regression without running any scripts. The dashboard shows pass/fail rates by module, failure type breakdown, coverage heatmaps, and resource utilization trends. It refreshes automatically as new regression data arrives on the file system.
Figure 3: Quick Sight regression dashboard showing pass/fail by module and failure type breakdown
Scheduled automations
Amazon Quick Automate can run automations on a schedule after each nightly regression is complete. For example, a daily triage automation (figure 4) can summarize failures and email the team before they arrive in the morning. A coverage gate alert can fire when a module drops below a defined coverage threshold. A license monitor can detect recurring license checkout failures and notify the infrastructure team.
These automations read the same log data from FSx for ONTAP through the S3 access point. Engineers don’t need to build custom scripts or maintain cron jobs for these workflows.
Figure 4: Quick Sight automation showing automated morning triage report generator
Potential use cases beyond verification triage
The same architecture applies to other EDA workflows that produce log data on NFS storage. These include synthesis timing report analysis, physical verification (DRC/LVS) results, power analysis outputs, and design documentation generation. Workflows that write structured or semi-structured logs to FSx for ONTAP can benefit from this pattern.
Conclusion
EDA verification teams generate large volumes of log data every night. The data exists on high-performance NFS storage, but the effort to analyze it has remained manual. S3 Access Points for FSx for ONTAP make that same data accessible to AI services through the S3 API. No copying or moving is required. Combined with AgentCore and Amazon Quick, engineers can ask natural language questions about their regressions. They receive correlated answers across simulation, compile, and scheduler logs. Daily triage that previously took 45–60 minutes can complete within minutes. The log data stays on FSx for ONTAP, accessible through both NFS and the S3 API simultaneously. The S3 access point provides a separate, read-only path for AI services to consume the same data and generate meaningful insights. The result is faster verification closure, higher engineering productivity, and teams that start each day fixing bugs instead of spending hours triaging bugs.
To get hands-on experience with this architecture, connect with your AWS account team to learn about available workshops covering FSx for ONTAP and S3 Access Points. To learn more about the services in this solution, refer to the following resources: