Introducing FSx Compliance Enforcement: an AWS Config custom rule for Amazon FSx governance

Important: FSx Compliance Enforcement is sample code provided for demonstration purposes. It is not intended for production use without thorough testing, security review, and validation for your specific use case and environment. You are responsible for evaluating whether this solution meets your requirements before deploying it.

If you run Amazon FSx at scale across multiple teams, you may want to standardize on specific filesystem types, or require a customer-managed AWS KMS key at creation. Today we're sharing FSx Compliance Enforcement, a small AWS Config custom rule that layers this kind of policy on top of FSx — detecting non-compliant filesystems after creation and quarantining them automatically.

What it adds

AWS Identity and Access Management (IAM) gives you fine-grained control over who can call fsx:CreateFileSystem, and AWS Config gives you powerful, resource-aware compliance evaluation. This sample extends that combination with two additional checks that are useful in multi-team FSx environments:

• Restrict which FSx filesystem types can exist in a region (for example, Lustre and ONTAP only).
• Require that every filesystem is encrypted with a customer-managed KMS key.

Both checks live as a few lines of Python and are easy to adapt.

How It Works

AWS::FSx::FileSystem is not currently a resource type recorded by AWS Config, so the rule watches AWS::EC2::NetworkInterface instead. Every FSx filesystem creates ENIs during provisioning, and each one carries an AmazonFSx.FileSystemId tag. When an ENI appears, the Lambda uses that tag to describe the parent filesystem and evaluate it.

The rule runs in two modes, deployed together:

• Near-real-time — triggered by ENI configuration changes. Effective within minutes when your Config recorder uses continuous recording for AWS::EC2::NetworkInterface.
• Periodic — an hourly full scan, as a safety net for anything the change-triggered path misses.

Because ENIs appear while the filesystem is still in CREATING state, the Lambda cannot always act immediately. Non-compliant filesystems that are not yet AVAILABLE go onto an Amazon SQS queue with a 5-minute delivery delay and get re-evaluated on a loop. The queue retries for roughly four hours before messages land in a dead letter queue.

When a filesystem is confirmed AVAILABLE and non-compliant, the Lambda renames it with a QUARANTINED- prefix and replaces the security groups on every one of its ENIs with a per-VPC QUARANTINED security group — created on demand, with no ingress or egress rules, which produces an implicit deny-all in both directions. Compliance status is reported back to AWS Config for dashboards and audit.

What Makes It Different

Three design choices worth calling out.

First, it uses ENIs as a proxy for filesystems. The AmazonFSx.FileSystemId tag on every FSx ENI makes the indirection clean, and lets the rule piggy-back on Config's existing change-recording pipeline.

Second, evaluation and remediation are intentionally combined in the same Lambda. The standard AWS Config pattern is to report NON_COMPLIANT and fire an AWS Systems Manager Automation document for remediation. Here the remediation — tag + security group swap — is tightly coupled to the evaluation logic, and splitting them would add moving parts without meaningful benefit.

Third, quarantine preserves data. The filesystem is never deleted. Renaming and network isolation give you a loud, visible, reversible state that's easy to investigate before deciding what to do next.

Customizing the Checks

Out of the box, two rules are enforced: filesystem type must be LUSTRE or ONTAP, and encryption must use a customer-managed KMS key. Both live as a few lines of Python in template.yaml. Changing the allowed types is a one-line edit; disabling the KMS check is deleting a block.

Prerequisites

• AWS Config enabled in the target account and region
• For near-real-time detection: continuous recording enabled for AWS::EC2::NetworkInterface on the Config recorder — an account-level setting
• Deployment via AWS CloudFormation in every region where FSx filesystem creation is permitted

Considerations

This rule operates in detective mode. There is a short window — minutes with near-real-time enabled, up to an hour in periodic-only mode — between a non-compliant filesystem becoming available and being quarantined. Pair it with your existing preventive controls (IAM policies, Service Control Policies, pipeline checks) rather than replacing them.

Continuous ENI recording applies to all ENIs in the account, not just FSx ones. If your account has heavy ENI churn (many EC2 scaling events, Lambda VPC functions, NAT gateways), review the AWS Config configuration item pricing before enabling it.

Getting Started

The sample is available at github.com/aws-samples/sample-fsx-compliance, as a single AWS CloudFormation template covering the Lambda function, IAM role, SQS queues, and the AWS Config custom rule:

aws cloudformation deploy \
  --template-file template.yaml \
  --stack-name fsx-compliance \
  --capabilities CAPABILITY_IAM

Deploy it per region, or roll it out across an AWS Organization with AWS CloudFormation StackSets. Stack-level costs are around $0.72 per filesystem per month for AWS Config evaluations, plus whatever continuous ENI recording adds if you don't already have it enabled.

Who Should Use This

FSx Compliance Enforcement is a good fit if you want to enforce filesystem-type or customer-managed-key policies on Amazon FSx with deterministic detection and containment, and an audit trail in AWS Config. It complements — rather than replaces — preventive controls at the IAM, SCP, or pipeline layer.

Reminder: this is sample code. Review the IAM permissions, the quarantine behavior, and the cost implications of continuous ENI recording before deploying into production. Feedback, issues, and pull requests welcome at github.com/aws-samples/sample-fsx-compliance.