Amazon Web Services just dropped a detailed playbook for running SQL Server on its FSx for NetApp ONTAP platform, and the top-line directive is unequivocal: stop lumping database files together. Separate your data, transaction logs, and TempDB onto dedicated disk volumes and logical unit numbers (LUNs), or risk sluggish performance and clumsy disaster recovery.
The guidance, published July 30, 2026 on the Microsoft Workloads on AWS blog, is aimed squarely at Windows database teams and architects. It unpacks a series of storage layouts—from simple single-database setups to sprawling multi-filegroup estates—and insists that the old habits of mixing disparate I/O workloads on a single volume will cost you when performance isolation and snapshot-based recovery matter most.
The Core Blueprint: One Volume, One LUN, One Purpose
The centerpiece of the AWS recommendations is a strict 1:1 relationship between ONTAP volumes and LUNs. On its face, that sounds like an administrative detail. But the real payoff is operational: ONTAP snapshots and deduplication operate at the volume level. When each database filegroup or log file lives in its own volume, you can snapshot and restore that single database piece without touching anything else.
For a typical SQL Server instance, that means carving out distinct volumes for:
- User data files (.mdf and .ndf), which handle random, parallel I/O during checkpoints
- Transaction log files (.ldf), which write strictly sequential and are often backed up far more frequently than full databases
- TempDB, SQL Server’s volatile system database that hosts temporary tables, sorts, and version-store traffic
The logic is straightforward, but the operational benefits are stark: AWS says volume-level restores take minutes regardless of database size, a claim that can transform recovery time objectives (RTOs) for mission-critical apps. If you dump multiple databases onto a single volume, you sacrifice that granularity entirely—a restore event drags every database on that volume into the fray, even if only one was affected.
Performance Isolation: Don’t Let Logs and Data Fight for IOPS
Placing .mdf and .ldf files on the same volume forces two radically different I/O patterns to share the same storage container. Data files see bursts of random reads and writes, especially during checkpoint operations, while log writes are a single, sequential stream. That clash can bottleneck performance with no easy fix.
AWS’s recommended split eliminates the contention at the storage layer. More importantly, it lets administrators tune volumes independently: a data volume might prioritize IOPS, while a log volume is optimized for steady throughput. For workloads that outgrow a single file system, the guidance even suggests splitting the two across different FSx for ONTAP file systems—data filegroups on one tuned for random I/O, transaction logs on another built for sequential throughput.
TempDB: The Special Case That Deserves Its Own Volume
TempDB is noisy by design. Sorts, hash joins, and temporary objects can spike unpredictably, and placing it alongside user data or logs invites trouble. AWS reinforces the long-standing database administrator practice of isolating TempDB on its own dedicated volume and LUN.
But the guidance adds a cloud-native twist: if your EC2 instance includes local NVMe instance storage, use it for TempDB instead. Instance store offers lower latency and higher throughput than networked storage, and since SQL Server recreates TempDB every time the service starts, ephemeral storage is a perfect match. The trade-off is obvious: you gain speed but must accept that TempDB data will vanish if the instance stops. That’s a fair bargain for a database that is rebuilt from scratch anyway.
For OLTP workloads, AWS suggests sizing TempDB at 10% to 25% of your total database size, though the precise number depends on your temporary object usage.
Sizing and Tiering: Don’t Treat All Data as Equal
The AWS blog provides a concrete sizing rule: provision the FSx for ONTAP SSD Performance Tier at 1.35 times your total database size. That extra 35% headroom isn’t optional slop—it’s specifically needed to accommodate snapshots, clones, and normal growth without throttling.
Not all data deserves the SSD tier’s high performance. SQL Server databases often contain read-only historical filegroups that are rarely accessed. FSx for ONTAP allows volume-level tiering policies that can push cold blocks to the cheaper Capacity Pool automatically. But there’s a catch: tiering policies can’t distinguish between files inside a single volume. If you want archive data to migrate to lower-cost storage, it must live in a separate volume from your active data.
AWS recommends mapping tiering policies to specific data categories:
| Tiering Policy | Behavior | Best Use |
|---|---|---|
| none | All data remains on SSD | Active data volumes, transaction logs |
| snapshot-only | Only snapshot data moves to Capacity Pool after a cooling period | Volumes with frequent snapshots |
| auto | Hot blocks move to capacity tier; random reads bring them back to SSD, sequential reads keep them in capacity tier | Read-only or archive filegroups |
| all | All data moved to Capacity Pool | Pure archive volumes |
This design means that architects must plan volume boundaries with both performance and cost in mind before provisioning.
Dealing with Consolidation: When Hundreds of Databases Cram into One Instance
Plenty of SQL Server estates run hundreds of databases on a single EC2 instance. Demanding a 1:1 volume-to-LUN ratio for every database would create a provisioning nightmare. AWS offers a practical middle ground: identify the dozen or so databases with the strictest SLAs and give each of them dedicated data and log volumes. The remaining lower-priority databases can share pooled volumes, accepting the trade-offs in I/O isolation and recovery granularity.
This tiered approach keeps management overhead reasonable while still protecting the applications whose recovery time matters most.
Cluster Configurations: Don’t Forget the Initiator Groups
For databases running in Windows Server Failover Cluster Instances (FCIs) with shared storage, iSCSI access control matters. FSx for ONTAP uses initiator groups (igroups) to gate which EC2 instances can see which LUNs. In a two-node FCI, the igroup must contain the iSCSI Qualified Names (IQNs) of both nodes so that either server can access the shared disks during a failover.
Failing to include both IQNs is a common misstep that can break failover entirely. AWS’s guidance calls out this requirement explicitly: both nodes need to be in the same igroup for the mapped LUNs to be accessible post-move.
Why This Matters Now: The Evolution of FSx for ONTAP
AWS launched the second generation of FSx for ONTAP with significantly larger scale. Generation 2 supports up to six high-availability pairs (12 nodes) and 1 PiB of SSD Performance Tier capacity in Single-AZ 2 deployments, with scale-out architecture available in that configuration. Multi-AZ 2 remains scale-up only. This means workloads that previously hit capacity or performance walls can now grow further—but only if you design the storage layout correctly from the start.
The new guidance lands at a time when many organizations are re-platforming critical Windows workloads onto AWS. SQL Server’s I/O patterns haven’t changed in decades, but cloud storage abstraction can tempt teams to treat it as a black box. AWS’s message is a corrective: the fundamentals still apply, and ignoring them leads to performance degradation and recovery headaches that scale with data size.
Action Plan for Windows Database Teams
If you’re running SQL Server on FSx for ONTAP today or planning a migration, the AWS guidance gives you concrete steps:
- Audit current volume layouts. Identify databases where data and log files share the same LUN and mark them for remediation.
- Map SLA tiers. Rank databases by criticality so you know which ones deserve dedicated volumes and which can be pooled.
- Adopt the 1.35x SSD sizing rule. Expand or provision SSD capacity with headroom for snapshots and growth.
- Design volume-level tiering. Separate read-only filegroups into their own volumes with auto or snapshot-only policies to lower costs.
- Plan TempDB placement explicitly. If your instance has NVMe instance store, configure SQL Server to place TempDB on it; otherwise, ensure a dedicated volume.
- Review clustering igroups. For FCI deployments, verify that both nodes’ IQNs are present in the correct igroups.
- Consider multi-file-system scaling. For very large databases, evaluate whether separating data and log traffic across two FSx for ONTAP file systems could improve throughput.
What’s Next
AWS is not likely to stop here. Expect tighter integration between FSx for ONTAP and SQL Server management tools, perhaps automated policy recommendations via AWS Config or Control Tower. The Gen2 platform’s scale-out capability will also push more enterprise workloads toward cloud-native SQL Server deployments, making storage architecture decisions even more critical. In the meantime, database administrators who follow the new playbook will be positioned for faster recovery, lower storage bills, and fewer head-on-desk moments when a snapshot restore is needed.