fix: EFS tagging issue with resource-type-aware tagging

[jrzesz33]

• Problem: EFS resources failed with 'extraneous key [Tags] is not permitted' because add_default_tags() always used 'Tags' property, but EFS requires 'FileSystemTags' instead.

• Solution: Add resource-type-aware tagging system that maps AWS resource types to their correct tag property names.

Changes:

• Add RESOURCE_TAG_PROPERTY_MAP for resource-specific tag properties
• Update add_default_tags() to accept resource_type parameter and use correct property name (FileSystemTags for EFS, Tags for others)
• Update infrastructure_generator.py to pass resource_type to add_default_tags()
• Add helper functions get_resource_tag_property() and add_resource_to_tag_map()
• Add comprehensive unit tests for new functionality
• Maintain backward compatibility for existing callers

Benefits:

• Fixes EFS resource creation (was completely broken)
• Maintains backward compatibility for all existing resources
• Easy to extend for other non-standard AWS resource types
• Well-tested with comprehensive test coverage

Fixes: AWS API Error (ValidationException): Model validation failed
(#: extraneous key [Tags] is not permitted) for EFS resources

Summary

The AWS Cloud Control MCP Server has a bug where it always adds default tags using the Tags property, but some AWS resources use different tag property names. For example:

• EFS (AWS::EFS::FileSystem) uses FileSystemTags instead of Tags
• RDS (AWS::RDS::DBInstance) uses Tags
• S3 (AWS::S3::Bucket) uses Tags

This causes validation errors when creating EFS resources:
AWS API Error (ValidationException): Model validation failed (#: extraneous key [Tags] is not permitted)

Changes

1. src/ccapi-mcp-server/awslabs/ccapi_mcp_server/cloud_control_utils.py

   • Add RESOURCE_TAG_PROPERTY_MAP constant
   • Update add_default_tags() function

2. Find and update all callers of add_default_tags() - likely in:

   • Resource creation handlers
   • Infrastructure generation code
   • Any file that imports from cloud_control_utils

3. tests/ directory

   • Add unit tests for the new tagging logic
   • Test multiple resource types (EFS, S3, RDS, etc.)

User experience

1. Fixes EFS Resources: EFS file systems can now be created successfully
2. Future-Proof: Easy to add more resource types with non-standard tag properties
3. Backwards Compatible: Existing resources using Tags continue to work
4. Maintainable: Centralized mapping makes it easy to add new resource types

Checklist

If your change doesn't seem to apply, please leave them unchecked.

• [X ] I have reviewed the contributing guidelines
• I have performed a self-review of this change
• Changes have been tested
• Changes are documented

Is this a breaking change? (Y/N)

RFC issue number:1267

Checklist:

• Migration process documented
• Implement warnings (if it can live side by side)

Acknowledgment

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of the project license.

[github-actions]

This pull request is now marked as stale because it hasn't seen activity for a while. Add a comment or it will be closed soon. If you wish to exclude this issue from being marked as stale, add the "backlog" label.

[github-actions]

Closing this pull request as it hasn't seen activity for a while. Please add a comment @mentioning a maintainer to reopen. If you wish to exclude this issue from being marked as stale, add the "backlog" label.

[novekm]

Hi @jrzesz33,

Thanks for the PR and for identifying this EFS tagging issue. You're correct that EFS uses FileSystemTags instead of Tags, which breaks the current implementation.

We've actually already addressed this problem (see #1643), but using a different approach. Instead of hardcoding resource-specific tag properties, we check the CloudFormation schema for each resource type. If a resource doesn't have a standard Tags property (like EFS), we skip adding our default tags entirely. This prevents the validation error while automatically handling any AWS resource with non-standard tagging patterns.

The main advantage is that we don't need to maintain a mapping of every AWS resource type and their specific tag property names - the schema tells us what's supported. It also handles future AWS services automatically.

Your PR helped confirm that our current approach is working correctly for these edge cases. The EFS issue should already be resolved in #1643 which should release soon (likely within a few days or so).

Thanks for taking the time to dig into this and create such a detailed solution!