Mastering AWS FSx Encryption: The Case for Customer-Managed Keys

Overview

Amazon FSx for Windows File Server provides a powerful, managed file storage solution on AWS. By default, AWS encrypts all data at rest, a crucial baseline for security. However, the type of encryption key used is a critical decision that has significant implications for security, compliance, and cost management. While AWS offers a default, AWS-managed key for convenience, relying on it can create significant governance gaps.

The more robust and secure approach is to use a Customer-Managed Key (CMK) through the AWS Key Management Service (KMS). This shifts control of the cryptographic lifecycle from the service provider to your organization. Opting for a CMK allows you to define who can use the key, audit its usage, and control its rotation and retirement schedule.

This choice is not merely a technical detail; it’s a foundational element of a mature cloud security posture. Failing to use a CMK for sensitive workloads can introduce unnecessary risk and lead to expensive remediation efforts down the line, turning a simple configuration choice into a major operational incident.

Why It Matters for FinOps

The decision to use AWS-managed keys versus Customer-Managed Keys has a direct and often overlooked financial impact. The primary cost is not in the key itself, but in the remediation of a non-compliant file system. The encryption key for an Amazon FSx file system is immutable; it cannot be changed after the resource is created.

If a compliance audit or a new security policy requires a CMK on a file system that was deployed with the default key, the only solution is to provision a new file system and perform a full data migration. This process introduces significant waste and operational drag, including:

• Engineering Hours: Migrating data, reconfiguring applications, and validating the new setup consumes valuable engineering time that could be spent on innovation.
• Downtime: The cutover process often requires scheduled downtime for production applications, impacting business operations.
• Duplicate Costs: During the migration period, the organization pays for both the old and the new file system, doubling the storage costs for that workload.

From a FinOps perspective, enforcing the use of CMKs from the start is a preventative control that avoids future financial waste and operational disruption. It aligns cloud spending with best practices and reduces the total cost of ownership by eliminating the need for costly, reactive fixes.

What Counts as “Idle” in This Article

In the context of this article, we aren’t focused on resources that are “idle” in the traditional sense of being unused. Instead, we are identifying resources that are cryptographically non-compliant. A non-compliant Amazon FSx file system is one that is configured to use the default AWS-managed encryption key instead of a Customer-Managed Key (CMK).

This configuration is flagged as a risk because it fails to provide the granular control, auditability, and lifecycle management required by most security and compliance frameworks. Signals of this non-compliant state are found in the resource’s configuration attributes, specifically the ID of the KMS key associated with it. If the key is an AWS-managed alias (e.g., aws/fsx), the resource is considered a security risk that requires remediation.

Common Scenarios

Scenario 1

Regulated Industries: A financial services or healthcare company stores sensitive customer data or Protected Health Information (PHI) on an FSx file system. Regulators and auditors require the company to demonstrate full control over the key lifecycle, including the ability to revoke access and audit all usage. Using a CMK is a non-negotiable requirement to meet PCI DSS or HIPAA compliance.

Scenario 2

Multi-Tenant SaaS Platforms: A software provider uses FSx to store file data for its customers. To ensure strict data isolation, the provider uses a separate CMK for each tenant’s file system. This allows them to cryptographically segregate customer data and manage the key lifecycle based on individual customer contracts or security needs.

Scenario 3

Sensitive Intellectual Property: A media or research company stores valuable intellectual property on FSx. The ability to perform “cryptographic erasure” by disabling or deleting a CMK serves as a kill switch. This provides a critical layer of defense against insider threats or a severe data breach, rendering the data unrecoverable even if an attacker gains access to the storage.

Risks and Trade-offs

Opting for the default AWS-managed key might seem simpler during initial setup, but it involves significant trade-offs. The primary risk is the loss of control. With an AWS-managed key, your organization cannot define granular access policies, control the key’s rotation schedule, or disable the key in an emergency. This violates the principle of least privilege, as any IAM principal with sufficient FSx permissions can effectively use the key.

Using a CMK introduces a minor operational step—creating and managing the key—but provides immense security benefits. It allows you to enforce a separation of duties, where access to storage (FSx permissions) and access to the data (KMS key permissions) are two distinct and independently managed controls. While managing your own keys requires diligence, the risk of being unable to respond to a security incident or failing a compliance audit far outweighs the convenience of using the default setting.

Recommended Guardrails

To ensure consistent and secure deployment of Amazon FSx, organizations should implement strong governance and preventative guardrails.

• Policy as Code: Use Infrastructure as Code (IaC) tools like AWS CloudFormation or Terraform to provision all FSx file systems. Mandate that the KmsKeyId parameter is explicitly defined in all templates and modules.
• Preventative Controls: Implement service control policies (SCPs) or use tools like AWS Config to create rules that block the deployment of any FSx file system that does not specify a valid CMK. This prevents non-compliant resources from being created in the first place.
• Tagging and Ownership: Enforce a strict tagging policy for all CMKs and FSx file systems to clearly identify the data owner, cost center, and application. This simplifies auditing, chargeback/showback, and accountability.
• Lifecycle Management: Establish clear policies for key rotation and deletion. Enable automatic annual rotation for CMKs and use deletion protection to prevent accidents that could lead to permanent data loss.

Provider Notes

AWS

The core services involved in this security control are Amazon FSx for Windows File Server and AWS Key Management Service (KMS). AWS KMS is a managed service that makes it easy to create and control the encryption keys used to encrypt your data. It is essential to understand the difference between the two primary key types available for FSx:

• AWS Managed Keys: These keys are created and managed by AWS on your behalf. You cannot manage their key policies or rotation schedules, limiting your control and audit capabilities.
• Customer Managed Keys (CMKs): These are keys that you create, own, and manage. Customer managed keys give you full control over the key policy, IAM permissions, rotation schedule, and lifecycle. For any FSx file system storing sensitive or regulated data, using a CMK is the recommended best practice.

Binadox Operational Playbook

Binadox Insight: The encryption key setting for an Amazon FSx file system is immutable. Choosing the wrong key type at launch forces a costly and disruptive data migration project to achieve compliance later. Proactive governance is far more efficient than reactive remediation.

Binadox Checklist:

• Standardize the use of Customer-Managed Keys (CMKs) for all new FSx deployments.
• Develop a clear and restrictive key policy for each CMK before deploying resources.
• Enforce the use of CMKs via Infrastructure as Code (IaC) templates and preventative AWS Config rules.
• Enable automatic key rotation and deletion protection on all production CMKs.
• Regularly audit your AWS environment to identify existing FSx file systems using default AWS-managed keys.
• Implement a clear tagging strategy for keys and file systems to assign ownership and track costs.

Binadox KPIs to Track:

• Percentage of FSx file systems encrypted with CMKs.
• Number of non-compliant FSx deployments blocked by preventative guardrails per month.
• Mean Time to Remediate (MTTR) for discovered non-compliant file systems.
• Engineering hours spent on data migration due to encryption misconfigurations.

Binadox Common Pitfalls:

• Overlooking the KMS key selection during manual “click-ops” deployment in the AWS console.
• Creating a CMK but failing to apply a restrictive key policy, negating much of its security value.
• Accidentally deleting a CMK without deletion protection, leading to permanent loss of all data encrypted with that key.
• Neglecting to grant the FSx service-linked role the necessary permissions to use the CMK, causing deployment failures.

How Binadox addresses this challenge

Binadox directly addresses the challenge of identifying cryptographically non-compliant Amazon FSx file systems through its Cloud Advisor tool. This solution scans cloud environments to detect misconfigurations, such as the use of default AWS-managed encryption keys instead of required Customer-Managed Keys. By surfacing these best practice violations, Cloud Advisor helps organizations avoid the significant future costs and operational disruption associated with immutable key settings and forced data migrations for compliance.

Leveraging the insights from Cloud Advisor, Binadox’s Advice capability generates specific recommendations for remediation and proactive governance. This helps teams address existing non-compliant file systems and implement guardrails to prevent new ones from being created with default keys. Implementing these recommendations eliminates duplicate storage costs incurred during migration, frees up valuable engineering hours, and ensures cloud spending aligns with security and compliance best practices from the outset.

Conclusion

Adopting Customer-Managed Keys for Amazon FSx encryption is a critical step toward achieving cryptographic sovereignty over your data in the cloud. It moves your security posture from a passive state of relying on defaults to an active one of defined, auditable control.

By establishing clear guardrails and enforcing this best practice through automation, you can meet stringent compliance requirements, enhance your security posture, and avoid the unnecessary cost and operational drag of future remediation projects. Making the right choice upfront ensures your data remains secure and your cloud environment stays efficient and well-governed.