Enforce KMS-Backed At-Rest Encryption for EFS File Systems

Overview

Ensure your Amazon EFS file systems use encryption at rest with AWS KMS, and safely migrate any unencrypted file systems to new, encrypted EFS instances. The plan walks through discovering all existing EFS file systems, choosing which ones to migrate and which KMS keys to use, creating equivalent encrypted file systems, migrating data using your preferred method (AWS DataSync or EC2-based tools), updating applications to use the new file systems, and finally validating encryption, application behavior, and decommissioning old unencrypted resources.

The approach emphasizes:

• Full inventory and classification of EFS file systems and their network/access patterns
• User-driven decisions on scope, KMS key usage, and migration method per file system
• Creation of like-for-like encrypted EFS targets (config, tags, network, access points)
• Guided data migration using AWS DataSync or EC2 + rsync-style tools
• Controlled cutover of EC2, ECS, Lambda, and other AWS resources to the new encrypted EFS
• Clean decommissioning of unencrypted file systems and final validation that encryption goals are met

Execution Details

Phase 1: Assessment

1. Inventory EFS file systems and encryption status

This phase starts by discovering all EFS file systems in the in-scope AWS accounts and regions. For each file system, the plan captures:

• Core attributes (ID, creation time, lifecycle state, performance/throughput mode, size metrics)
• Encryption-at-rest status and KMS configuration (AWS-managed vs customer-managed key, KMS key ARN)
• Ownership and context tags (Name, environment, application, owner, etc.)

File systems are categorized as encrypted or unencrypted, with unencrypted ones clearly flagged as migration candidates. Results are stored in a structured format for later steps.

2. Map mount targets, access points, and network access

Next, the plan builds a network and access topology for each EFS file system by:

• Listing all mount targets and capturing their Availability Zones, VPCs, subnets, network interfaces, and security groups
• Listing all access points and recording root directories, permissions, POSIX settings, and tags
• Producing a mapping of each file system to the VPCs, subnets, and security groups that grant access via mount targets

EFS file systems without mount targets or access points are flagged as likely backend-only or inactive. This mapping becomes the template for building equivalent configuration on new encrypted file systems.

3. Guide selection of file systems in scope and KMS keys

Using the inventory, the plan presents you with all unencrypted EFS file systems, surfaced with:

• Size or latest usage metrics
• Environment and application context (tags, ownership)
• Associated VPCs, subnets, and inferred client usage

You are guided to:

• Decide which unencrypted file systems are in scope for migration
• Choose, for each, whether to use the AWS-managed EFS KMS key or a specific customer-managed KMS key
• Provide KMS key ARNs where customer-managed keys are used and confirm they meet policy and compliance needs
• Note any special encryption requirements (e.g., distinct keys for production vs non-production)

The outcome is a structured decision record specifying, per file system, in-scope status, target KMS key, and any special requirements. Exclusions are documented with reasons.

4. Choose migration methods per EFS file system

For each in-scope unencrypted file system, the plan then helps you select a migration method. It:

• Presents each candidate with size, environment tags, network topology, and known connectivity constraints
• Explains supported options: AWS DataSync or EC2-based tools such as rsync (or equivalent)
• Guides you to choose a method per file system and confirm prerequisites:
  
  • For DataSync: viable network paths for agents/endpoints to reach both source and target EFS
  • For EC2+rsync: availability of suitable EC2 instances (or compute) with network access to both source and target

You can note constraints like maintenance windows, large data volume, high change rate, or compliance tooling requirements. Any file systems not yet assigned a method are flagged with required follow-up. The result is a mapping of each in-scope file system to its chosen migration approach and constraints.

Phase 2: Configuration and Migration

5. Create new encrypted EFS file systems with chosen KMS keys

Using your earlier decisions, the plan defines and creates new encrypted EFS file systems for each selected unencrypted source. For each:

• It mirrors key configuration from the source: performance mode, throughput mode, provisioned throughput, and other operational characteristics
• Sets encrypted=true and associates the selected KMS key (AWS-managed or customer-managed)
• Reviews and applies tags from the source, allowing for standardization or updates as needed

After creation, each new file system is checked to ensure encryption is enabled, the correct KMS key is applied, and performance/throughput settings align with expectations. A mapping from each source to its new encrypted FileSystemId and KMS key is recorded.

6. Recreate mount targets and access points for encrypted EFS

To maintain or improve network and access behavior, the plan then:

• Uses the earlier mapping of mount targets, VPCs, subnets, and security groups from each source
• Designs mount targets for the new encrypted file systems so that the same Availability Zones and subnets are covered where appropriate, with equivalent or more restrictive security groups
• Creates matching mount targets and adjusts security group rules (e.g., NFS port 2049 access) as required
• Recreates access points on the encrypted file systems, preserving or intentionally adjusting root paths, permissions, POSIX users/groups, and tags

The mapping between old and new EFS file systems is updated to include mount target IDs and access point IDs, forming the foundation for data migration and application cutover.

7. User-driven data migration with AWS DataSync (where selected)

For file systems designated for AWS DataSync-based migration, the plan:

• Identifies all source–target EFS pairs using DataSync
• Confirms that both source and encrypted file systems have reachable mount targets for DataSync agents or service endpoints
• Helps you design a DataSync configuration per pair, including source and destination locations, filters, and metadata handling where applicable

You are then guided to:

• Provision and configure any required DataSync agents
• Create or confirm DataSync locations and tasks according to the plan
• Run DataSync tasks for initial bulk copy and any incremental syncs, and monitor progress

Migration status for each file system is tracked (e.g., not started, in progress, final sync complete), and you validate that data, structure, permissions, and metadata on the encrypted EFS meet expectations.

8. User-driven data migration with EC2 + rsync (where selected)

For file systems where you selected EC2-based tools, the plan:

• Identifies all source–target pairs using EC2+rsync (or similar)
• Confirms that migration instances can access both source and target EFS mount targets via appropriate VPCs, subnets, and security groups
• Validates and adjusts NFS-related security rules as necessary

It then helps you outline high-level migration parameters per file system:

• Directories to copy, exclusions, and overall strategy (initial bulk copy plus incremental syncs or single cutover)
• Expected cutover window and any special handling requirements

You are responsible for provisioning and configuring EC2 instances (or equivalent compute), mounting both EFS file systems, running rsync or similar tools, monitoring transfers, and handling errors. The plan provides a structure to record status (e.g., initial copy complete, final sync complete) and prompts you to validate data consistency and permissions on the encrypted targets.

9. Update AWS resources to use encrypted EFS

Once data is fully migrated and final syncs are complete, the plan turns to application cutover. Using the mapping of old to new EFS file systems and their access points, and taking into account migration status, it:

• Identifies AWS resources still referencing the old unencrypted file systems (such as EC2 mount configurations, ECS task definitions/services, Lambda function file system configs)
• Guides you in designing updated configurations so that all EFS references point to the new encrypted file systems or their access points

You then apply these changes:

• For EC2: update user data, configuration management, fstab entries, and any launch templates or Auto Scaling configurations that embed EFS details
• For ECS: register new task definitions and redeploy services using encrypted EFS references
• For Lambda: adjust function configurations to use new access points and redeploy as needed

If you require phased or blue/green cutover, the plan supports documenting and executing an incremental sequence of updates while monitoring application behavior. Completion is tracked per application or workload, and exceptions are documented with remediation plans.

10. Decommission and delete unencrypted EFS file systems

After confirming that workloads have fully transitioned, the plan leads you through safe decommissioning of the old unencrypted file systems:

• Verifies there are no remaining AWS resources depending on each unencrypted EFS instance
• Confirms that final data syncs are complete and that no new writes are occurring on the old file systems
• Ensures any mount targets or access points remaining exist only for residual migration tasks and that they are no longer needed

You are reminded that deletion is irreversible and must confirm data has been fully validated on the encrypted EFS. Approved unencrypted file systems are then cleaned up (removing access points and mount targets if required) and deleted. The plan verifies removal from inventory and produces a decommissioning log mapping each deleted unencrypted file system to its encrypted replacement and recording completion details.

Phase 3: Validation

11. Validate encryption status and KMS usage

To close the loop on the security objectives, the plan performs a final validation of EFS encryption across the in-scope environment:

• Retrieves the final list of EFS file systems in all covered accounts and regions
• Confirms that each in-scope file system is encrypted at rest
• Verifies that each encrypted file system created during the migration uses the expected KMS key (AWS-managed or customer-managed) as previously recorded

Any remaining unencrypted file systems in scope are flagged and documented as exceptions. The mapping from original unencrypted to encrypted replacements is reviewed for completeness, and basic health checks confirm the encrypted file systems are available and not reporting encryption or KMS-related issues. A validation report summarizes encryption status, KMS key usage, and whether project goals have been met.

12. User validation of applications on encrypted EFS

Finally, the plan emphasizes application-level validation:

• You review the applications and workloads that were moved to encrypted EFS
• For each, you run or coordinate functional tests to ensure expected behavior and confirm there are no regressions or performance issues that can be tied to the migration
• Any observed issues (functional or performance) are documented with affected components and EFS identifiers for follow-up

You also confirm that operational processes (backups, monitoring, maintenance tasks) continue to work correctly against the encrypted file systems. The phase concludes with your formal sign-off that applications are successfully running on encrypted EFS, or with a clearly documented list of outstanding concerns requiring further work.