- Newest
- Most votes
- Most comments
Hello,
frequent read/writes to the same volume from both:
FSx for Windows File Server:
- Good for ease of use & native Windows support (uses SMB).
- Works for both Linux & Windows containers.
EBS with gp2 Volumes:
- More control & potentially lower cost (needs formatting within pods).
- Works for both Linux & Windows containers (requires file system utilities).
Choose FSx for simplicity or EBS for control/cost, considering lifecycle management for short-lived data (1-2h).
Hello,
For a mixed EKS cluster with both Linux and Windows pods needing shared storage, consider the following options:
1. Amazon FSx for Windows File Server (FSx for Windows) Pros:
- Compatibility: Works with both Linux and Windows via SMB protocol.
- Performance: High performance for read/write operations.
- Management: Automatic data deletion policies.
Cons:
- Cost: Generally higher due to managed services.
Steps:
- Create FSx File System
aws fsx create-file-system --file-system-type WINDOWS --subnet-ids subnet-12345678 --windows-configuration ...
Mount FSx:
- Use SMB for mounting on both Windows and Linux pods.
2. Amazon EBS with gp2 Volumes Pros:
- Cost-Effective: Good for temporary storage needs.
- Performance: Burstable performance suited for your workload.
Cons:
- Management: Requires manual setup and management.
Steps: Create EBS Volume:
aws ec2 create-volume --volume-type gp2 --size 100 --availability-zone us-west-2a
Attach EBS Volume:
- Attach and mount the EBS volume on both Linux and Windows nodes in your EKS cluster.
Choose FSx for Windows for ease of management and EBS gp2 for a cost-effective solution.
1. Amazon FSx for Windows File Server (FSx for Windows):
Pros:
- Designed specifically for Windows workloads, offering seamless integration with Windows containers.
- Supports SMB (Server Message Block) protocol, a widely used file sharing standard compatible with both Linux and Windows.
- Delivers high performance for read/write operations, making it suitable for your use case.
- Provides the ability to configure automatic deletion or lifecycle management policies to remove data after a specified duration (1-2 hours in your scenario). Cons:
- Might incur slightly higher costs compared to EBS due to its managed nature.
2. Amazon Elastic Block Store (EBS) with gp2 Volumes:
Pros:
- A cost-effective option for temporary data storage.
- gp2 EBS volumes are optimized for burstable performance, handling your expected write/read activity well.
- You can set up lifecycle rules for automatic deletion of snapshots (backups) after a designated timeframe.
- Choosing the Right Option:
- FSx for Windows: If your primary concern is seamless integration with Windows containers and ease of management with automatic data deletion, FSx for Windows is the better choice.
- EBS gp2: If cost is a major factor and you're comfortable with additional configuration for lifecycle management (e.g., using AWS Lambda to delete snapshots), EBS gp2 can be a viable option.
Additional Considerations:
FSx for Windows requires Windows worker nodes: If your EKS cluster doesn't currently have Windows worker nodes, you'll need to add them to leverage FSx for Windows.
EBS gp2 IOPS: Consider the volume size and expected workload when determining the appropriate EBS gp2 IOPS level to ensure optimal performance. You can find guidelines in the AWS documentation https://docs.aws.amazon.com/ebs/latest/userguide/ebs-volume-types.html.
**EBS Snapshots: **While EBS gp2 can be cost-effective for temporary data, keep in mind that snapshots, if not managed, can accumulate and incur additional charges. Use lifecycle rules or manual deletion to maintain control over costs. Implementation Steps:
Relevant content
- asked 3 years ago
- asked a year ago

Hi, I would also try FSx given your use case. Didier
For EBS volumes, gp2 is nearly always an inferior option compared to gp3. Gp3 is about 20% cheaper at its baseline performance and throughput settings, and the baseline performance of 3,000 IOPS is much higher than what gp2 yields for small volumes. Snapshots are best managed automatically by AWS Backup, not Data Lifecycle Manager which is its more rudimentary predecessor.