aws-cloudformation / aws-cloudformation/cloudformation-coverage-roadmap
[AWS::EFS::MountTarget] - [Enhancement] - Propagate tags to service-managed ENIs / Network interfaces
- 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
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