Storage teams building for AI are not short of ways to make data move faster. The question they are increasingly asked is a different one, which is whether the data behind training, retrieval-augmented generation (RAG), and inference will still be reachable and intact when a node fails, a rebuild drags on, an agent misbehaves, or someone captures traffic they should not have.
At F5, we believe resiliency and security are key aspects of AI storage infrastructure architecture. They are one design problem, and the right place to solve both is a front door that understands S3. This post explains why we hold that view, how F5 addresses it, and where we recently made the case to the storage developer community.
Resiliency and security are the same problem
Each stage of retrieval-augmented generation (RAG), from native to advanced, modular, and graph RAG, returns richer answers by pulling more vectors and documents from the object store. That makes storage availability and access latency as much a part of time-to-token as generation speed.
At the same time, S3-compatible storage still does not mean interoperable, even after all these years, which is a practical argument for placing a consistent front door ahead of the storage so that the client speaks to one predictable endpoint and never has to care which vendor’s system is answering behind it. Storage clusters also degrade and fail for many reasons, from node outages and network faults to the longer rebuilds that come with denser drives, and when that happens, a traffic manager needs to route storage calls to the nodes that are still healthy and performant so that clients never notice.
“Once the traffic layer does understand S3, resiliency and security stop being two projects and become one control point.”
Autonomous agents are also reaching storage directly now, and once non-human callers can open a bucket on their own, access controls belong at the S3 layer itself rather than somewhere downstream, after the request has already been served. The problem is that most of the load balancers currently sitting in front of object storage clusters were never built with S3 in mind and cannot see any of this. Once the traffic layer does understand S3, resiliency and security stop being two projects and become one control point.
Protecting data in flight before the storage platform can
Consider harvest now, decrypt later, the attack pattern in which an adversary records encrypted traffic today in the expectation of decrypting it once quantum computing makes that practical. Most object storage platforms cannot yet protect data in flight with quantum-resistant encryption. F5 BIG-IP with post-quantum cryptography capabilities can sit ahead of the storage and close that window without waiting for every storage vendor to ship an implementation of its own. It is a clear example of security that is native to the storage path rather than attached somewhere else in the stack, and it is the kind of control a storage team can adopt without changing anything about the cluster behind it.
“Once the throughput penalty is gone, the proxy stops being a tax on the pipeline.”
That is possible because of the research and lab testing F5 has done to establish S3-specific TCP profiles for BIG-IP, and it was independently confirmed when SecureIQLab validated BIG-IP in front of a Dell ObjectScale cluster. With S3-optimized TCP profiles, S3 throughput stays in low single digits of the baseline with no BIG-IP in the path across every tested combination of object size and network latency, while the same deployment contained disruptive client traffic and kept S3 service running during a simulated DDoS attack. Once the throughput penalty is gone, the proxy stops being a tax on the pipeline and becomes the place where failure domains, encryption, and policy are controlled at a single point in the path.
Tuned TCP flows and test tools the ecosystem trusts
The S3 TCP profiles now defined on BIG-IP are a starting point rather than a fixed setting. They can be customized and tuned further for the characteristics of a particular production deployment, which is the detail storage developers most want to hear when they consider introducing BIG-IP into the data path to optimize the TCP flows between their various sources of S3 traffic and their object storage.
F5 also intends to contribute to the testing methodologies and the open-source tooling that S3 storage vendors and their customers rely on to generate S3 traffic, because a proxy that is meant to sit in every S3 data path should be measured with the same tools the rest of the ecosystem trusts.
What this means for the architect designing the pipeline
All of this points to a hierarchy that we think most storage architects already apply instinctively, where resiliency comes first, security comes second, and performance is a constraint that any component in the path has to satisfy rather than a reason to add one. The question the C-Suite is asking storage teams is what their organization gets for the money spent on each component in the I/O stream and what that component contributes under the failure and attack conditions described above.
The broader industry conversation about data fabrics and data intelligence makes the same point from another direction, because once the question becomes how data is discovered, governed, and acted on rather than where it lives, a front door that presents one endpoint and one policy surface across every S3-compatible backend becomes a prerequisite regardless of which storage platform wins the next procurement cycle.
That is the problem F5 describes as AI data delivery. An application delivery controller that understands S3 earns its place in the path not as another performance feature competing for attention, but as the point where availability, access control, and encryption are enforced for the data that training, RAG, and inference depend on.
Keeping AI data reachable and trustworthy
This is why global enterprises deploy F5 in front of S3-compatible storage for resiliency and security in AI data delivery. BIG-IP keeps the object store reachable when nodes fail or ingest spikes, places security controls at the S3 layer so that bad traffic never reaches the data, and does both without slowing the pipeline, which is what the independent SecureIQLab testing with Dell ObjectScale confirmed. For a storage architect, the outcome is one layer in the data path that keeps AI pipelines running on data the organization can trust.
We recently shared these ideas at SNIA SDC 2026
F5 presented this argument to a storage developer audience at the SNIA Storage Developer Conference in Santa Clara, where F5 Principal Solutions Architect Paul Pindell walked through how a tuned proxy in the S3 path delivers resiliency, failure domain control, and TLS offload without a throughput penalty.
The questions that followed, on S3 TCP profiles, on post-quantum protection for data in flight, and on how a proxy should be measured against ecosystem test tools, reinforced that storage teams are already asking for a front door that understands S3-compatible storage. For more information on how F5 provides resilient and secure access to storage clusters, explore the AI data delivery use case page.
About the Authors
Florin Meilescu is a Senior Principal Software Engineer and Test Architect at F5, where he serves as the solution test architect for BIG-IP across hardware, software platforms, and public cloud environments. He brings more than 20 years of experience in the application delivery controller (ADC) market, including at Citrix NetScaler. His expertise spans L2 to L7 protocols and the systems that carry them, from Linux servers to the networking gear he supported early in his career. Florin holds a Bachelor’s degree in Engineering from the Polytechnic University of Bucharest.
More blogs by Florin MeilescuPaul Pindell is a Principal Architect at F5, where he works in Technology Alliances and oversees technical partnerships across F5’s product portfolio. Since 2019, he has also played a key role in corporate strategy initiatives, including helping launch F5’s first innovation project. Paul led F5’s AI strategy tiger team, focused on defining how F5’s existing products can help secure and deliver AI applications. He later helped develop F5’s AI Reference Architecture, outlining the core building blocks, challenges, risks, and partner solutions required to support AI application delivery and security. Paul is a frequent keynote and breakout speaker at industry events, including OPI Summit, OCP Global Summit, Intel InnovatiON, Open Source Summit, Red Hat Tech Exchange, and multiple VMworld conferences across the U.S. and EMEA. He is also the founder and maintainer of open source projects, serves as Chair of the Outreach Committee for the Open Programmable Infrastructure Project, and previously led data center operations for Symantec’s Antivirus Response Data Centers and security software testing labs.
More blogs by Paul PindellSandeep Agarwal is a Senior Software Architect at F5, where he leads core infrastructure and network security for high-performance distributed systems and enterprise AI pipelines. He drives low-latency AI training and inference architectures, along with token governance and dynamic AI load balancing. He is also responsible for hardware-accelerated data pipelines using eBPF, FPGA offload, and DPUs, and he guides architecture for Kubernetes, Cloud-Native Network Functions, and L2–L7 security. Earlier in his career, he was a Staff Software Engineer at Juniper Networks, a Senior Principal Software Engineer at Symantec, and a Member of Technical Staff at Sun Microsystems. Sandeep holds a Master's in Computer Engineering from Oregon State University and a Bachelor's in Electronics & Communication from the Birla Institute of Technology, Mesra.
More blogs by Sandeep AgarwalJonathan Chen is a software development architect for SSL Orchestrator at F5, where he leads work on TLS interception, forward proxy policies, and service chaining of third-party security devices. He is also responsible for integrating data loss prevention and a new programmability runtime into the BIG-IP data plane, and he guides architecture and roadmap for both. Earlier in his career, he was a US architect at Trend Micro, focused on breach detection and prevention. During his first tenure at F5, he worked on high-performance SSL-VPN, application rewrite proxy, network optimization, and secure web gateway. Jonathan holds a Master’s and a Bachelor’s degree with special honors in Computer Sciences from the University of Texas at Austin.
More blogs by Jonathan ChenRelated Blog Posts
Securing the new control points in the AI journey
AI architecture is fundamentally different than traditional IT environments and requires a different security strategy to protect critical AI workloads.
The patch window has closed. Here is how F5 is built for what comes next.
As AI models have changed software security, the industry needs to adapt.
Best practices for optimizing AI infrastructure at scale
Optimizing AI infrastructure isn’t about chasing peak performance benchmarks. It’s about designing for stability, resiliency, security, and operational clarity
Datos Insights: Securing APIs and multicloud in financial services
New threat analysis from Datos Insights highlights actionable recommendations for API and web application security in the financial services sector
Secrets to scaling AI-ready, secure SaaS
Learn how secure SaaS scales with application delivery, security, observability, and XOps.
How AI inference changes application delivery
Learn how AI inference reshapes application delivery by redefining performance, availability, and reliability, and why traditional approaches no longer suffice.