aws-cloudformation / aws-cloudformation/cloudformation-coverage-roadmap

[AWS::EFS::MountTarget] - [Enhancement] - Propagate tags to service-managed ENIs / Network interfaces

Open
#2,478 0 comments 5 reactions 0 assignees View on GitHub
enhancement
Dominant language
No language data
Stars
1.1k
Forks
62
PR merge metrics
No merged PRs in 30d

Description

### Name of the resource

AWS::EFS::MountTarget

### Resource name

_No response_

### Description

When an `AWS::EFS::MountTarget` is created, the EFS service provisions an ENI in the specified subnet. For Regional file systems, one mount target (and thus one ENI) can be created per Availability Zone. For One Zone file systems, a single mount target is created in the file system's AZ. These service-managed ENIs do not inherit tags from the mount target or the parent file system.

### Problem

- Each mount target creates exactly one ENI in the specified subnet. The ENI's `NetworkInterfaceId` is returned in the mount target description, but the ENI itself carries no tags.
- Mount targets can be deleted and recreated (e.g., when changing the VPC or subnet), resulting in new untagged ENIs.
- There is no mechanism -via CloudFormation, the EFS API, or `TagSpecifications`- to control tags on these ENIs at creation time.

### Impact

Organizations enforcing mandatory tagging policies (via AWS Config, SCPs, or compliance tools) face:
- **Cost allocation gaps**: Untagged ENIs cannot be attributed to a project or team.
- **Compliance violations**: AWS Config rules like `required-tags` flag these ENIs as non-compliant despite being fully AWS-managed.
- **Operational overhead**: Workarounds require event-driven Lambda functions (CloudTrail + EventBridge) to retroactively tag ENIs after creation.

### Expected Behavior

Tags defined on `AWS::EFS::MountTarget` (or inherited from `AWS::EFS::FileSystem`) should be automatically propagated to the ENI created by the mount target. When mount targets are recreated, new ENIs should receive the current tags.

Alternatively, a property like `NetworkInterfaceTagSpecifications` on `AWS::EFS::MountTarget` could allow explicit control.

### Other Details

The ENI description format set by EFS is not publicly documented in a standardized way. The mount target's `NetworkInterfaceId` field references the ENI, but the ENI has no back-reference via tags to the file system or mount target.

### Reproduction

1. Create an EFS file system and mount target with tags via CloudFormation:
```yaml
MyFileSystem:
Type: AWS::EFS::FileSystem
Properties:
FileSystemTags:
- Key: Environment
Value: production

MyMountTarget:
Type: AWS::EFS::MountTarget
Properties:
FileSystemId: !Ref MyFileSystem
SubnetId: subnet-aaa
SecurityGroups:
- sg-xxx
```
2. Describe the mount target to get the ENI ID:
```
aws efs describe-mount-targets --file-system-id fs-xxxxxxxx \
--query "MountTargets[].NetworkInterfaceId"
```
3. Check the ENI tags:
```
aws ec2 describe-network-interfaces \
--network-interface-ids eni-xxxxxxxx \
--query "NetworkInterfaces[].{ID:NetworkInterfaceId,Tags:TagSet}"
```
4. Observe: `TagSet` is empty.

Contributor guide

Open the contributing guide

Research direction

Start with the AWS CLI reproduction using `describe-mount-targets` and `describe-network-interfaces` for an `AWS::EFS::MountTarget`. Review the requested tag propagation or explicit network-interface tag control, including behavior when mount targets are recreated. Done means newly created service-managed ENIs receive the applicable tags.

Written by the indexing model from the issue text.

Assessment

Tech stack
aws
Domain
cloud, infrastructure
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.