RFC: Extend aws-network-mcp-server with Load Balancer, Route 53, and VPC Endpoint tools

[ravikulk1]

RFC: Extend aws-network-mcp-server with Load Balancer, Route 53, VPC Endpoint, and Profiles tools

Summary

This RFC proposes adding 11 new read-only tools to the existing aws-network-mcp-server, organized into 4 phases:

• Phase 1 — Load Balancer (3 tools)
• Phase 2 — Route 53 / DNS (5 tools, including DNS Firewall)
• Phase 3 — VPC Endpoints / PrivateLink (2 tools)
• Phase 4 — Route 53 Profiles (1 tool)

All tools follow the server's existing patterns: plain async def functions registered via mcp.tool(func) in server.py, boto3 clients via the get_aws_client() helper, structured return dicts, and ToolError from fastmcp.exceptions for error handling. All operations are strictly read-only (Describe/Get/List).

Excluded: Route 53 Global Resolver (GA March 2026) — the boto3 client (route53globalresolver) does not exist yet in the SDK. Will add once available.

Motivation

"I can't connect to my instance/service" is the #1 AWS support request. The most common root causes — unhealthy LB targets, DNS misconfigurations, DNS Firewall blocking, and broken PrivateLink connectivity — have zero MCP tool coverage today:

1. Load Balancer gap: The server's IAM policy already includes elasticloadbalancing:DescribeLoadBalancers, but no tools use it.
2. DNS gap: Across all 67+ AWS MCP servers, there is zero Route 53 / DNS coverage.
3. DNS Firewall gap: DNS Firewall rule groups block/allow DNS queries per VPC — critical for "my DNS is being blocked" troubleshooting. Uses the same route53resolver client.
4. VPC Endpoint gap: The server has ec2:DescribeVpcEndpoints in its IAM policy but no dedicated endpoint diagnostic tools.
5. Profiles gap: Enterprise customers managing DNS across hundreds of VPCs use Route 53 Profiles — no visibility exists.

Proposed Tools

Phase 1 — Load Balancer (3 tools)

Tool	Description	AWS APIs
list_load_balancers	List all ALBs/NLBs/GLBs with optional type filtering	elbv2:DescribeLoadBalancers
get_lb_details	Detailed LB config: listeners, target groups, security groups, AZ mapping	elbv2:DescribeLoadBalancers, DescribeListeners, DescribeTargetGroups
get_lb_target_health	Per-target health status with failure reasons	elbv2:DescribeTargetGroups, DescribeTargetHealth

Phase 2 — Route 53 / DNS (5 tools)

Tool	Description	AWS APIs
list_hosted_zones	List hosted zones with type (public/private) and VPC associations	route53:ListHostedZones, GetHostedZone
query_dns_records	Search DNS records by type or name prefix within a hosted zone	route53:ListResourceRecordSets
check_health_checks	Health check statuses with per-region checker details	route53:ListHealthChecks, GetHealthCheckStatus, cloudwatch:GetMetricStatistics
list_resolver_rules	Resolver endpoints and forwarding rules across VPCs	route53resolver:ListResolverRules, ListResolverRuleAssociations, ListResolverEndpoints, ListResolverEndpointIpAddresses
list_dns_firewall_rules	DNS Firewall rule groups with VPC associations and individual rules	route53resolver:ListFirewallRuleGroups, ListFirewallRuleGroupAssociations, ListFirewallRules

Phase 3 — VPC Endpoints / PrivateLink (2 tools)

Tool	Description	AWS APIs
list_vpc_endpoints_detailed	Detailed inventory of interface/gateway endpoints with DNS entries and SG associations	ec2:DescribeVpcEndpoints
check_endpoint_connectivity	Verify DNS resolution, SG rules, and ENI details for a PrivateLink endpoint	ec2:DescribeVpcEndpoints, DescribeSecurityGroups, DescribeNetworkInterfaces

Phase 4 — Route 53 Profiles (1 tool)

Tool	Description	AWS APIs
list_route53_profiles	List Profiles with VPC associations and attached resources (PHZs, resolver rules, DNS Firewall rule groups)	route53profiles:ListProfiles, ListProfileAssociations, ListProfileResourceAssociations

New IAM Permissions Required

Phase 1 — Load Balancer

• elasticloadbalancing:DescribeLoadBalancers — already in IAM policy
• elasticloadbalancing:DescribeListeners — NEW
• elasticloadbalancing:DescribeTargetGroups — NEW
• elasticloadbalancing:DescribeTargetHealth — NEW

Phase 2 — Route 53 / DNS

• route53:ListHostedZones, GetHostedZone, ListResourceRecordSets, ListHealthChecks, GetHealthCheckStatus — NEW
• route53resolver:ListResolverRules, ListResolverEndpoints, ListResolverRuleAssociations, ListResolverEndpointIpAddresses — NEW
• route53resolver:ListFirewallRuleGroups, ListFirewallRuleGroupAssociations, ListFirewallRules — NEW
• cloudwatch:GetMetricStatistics — NEW (calculated health check status, must use us-east-1)

Phase 3 — VPC Endpoints

• All permissions already exist in the IAM policy. Zero new permissions.

Phase 4 — Route 53 Profiles

• route53profiles:ListProfiles — NEW
• route53profiles:ListProfileAssociations — NEW
• route53profiles:ListProfileResourceAssociations — NEW

Phased PR Approach

4 separate PRs, one per phase:

1. PR 1 — Load Balancer (3 tools) + tests + IAM updates
2. PR 2 — Route 53 / DNS (5 tools including DNS Firewall) + tests + IAM updates
3. PR 3 — VPC Endpoints (2 tools) + tests + documentation
4. PR 4 — Route 53 Profiles (1 tool) + tests + IAM updates

Potential Overlaps

1. list_vpc_endpoints_detailed vs get_vpc_network: Existing tool returns basic endpoint info for a single VPC, skips Gateway endpoints. Our tool adds cross-VPC listing, service name filtering, Gateway support, and detailed fields (DNS entries, private DNS, SG IDs, ENI IDs). Fallback: rename to get_vpc_endpoint_details with specific endpoint ID.

2. check_endpoint_connectivity vs get_eni_details: Different entry point (VPC endpoint vs ENI), aggregates endpoint state + private DNS + SGs + ENIs into one diagnostic view.

Design Decisions

• Follow existing patterns exactly — plain async functions, ToolError, get_aws_client()
• Client-side filtering for Route 53 — ListResourceRecordSets uses pagination cursors, not filters
• CloudWatch fallback for calculated health checks — GetHealthCheckStatus doesn't work for calculated HCs; CloudWatch metrics only in us-east-1
• Graceful partial results — get_lb_details and check_endpoint_connectivity return what succeeded + error indicators for failed sub-calls
• Rate-limit awareness — GetHealthCheckStatus only called when specific HC requested or count ≤ 20
• Single-pass association lookups — resolver rules, DNS Firewall, and Profiles all fetch associations once and build lookup dicts instead of N+1 queries
• Separate module for Profiles — uses different boto3 service (route53profiles) so gets its own tools/route53_profiles/ module

Questions for Maintainers

1. Should Phase 3 VPC Endpoint tools be renamed to avoid overlap with get_vpc_network?
2. Is the phased PR approach acceptable, or would you prefer fewer PRs?
3. Any concerns about Route 53 tools being in the network server vs a dedicated Route 53 server?
4. Should list_dns_firewall_rules be a separate tool or merged into list_resolver_rules?
5. Should Route 53 Profiles go in tools/route53/ or separate tools/route53_profiles/?

All code is implemented and tested — 326 tests passing, 94% branch coverage, zero conflicts with existing 27 tools.

[ravikulk1]

Update: Expanded scope — 11 tools across 4 phases

After deeper review of the Route 53 API landscape, I'm expanding the proposal from 9 tools / 3 phases to 11 tools / 4 phases. Two additions:

Phase 2 addition: list_dns_firewall_rules

Tool	Description	AWS APIs
list_dns_firewall_rules	List DNS Firewall rule groups with VPC associations and individual rules	route53resolver:ListFirewallRuleGroups, ListFirewallRuleGroupAssociations, ListFirewallRules

Why: "My DNS queries are being blocked" is a top troubleshooting scenario. DNS Firewall is the first thing to check. This uses the same route53resolver boto3 client as list_resolver_rules — no new service dependency. Adds 3 new IAM permissions.

Phase 4 (new): list_route53_profiles

Tool	Description	AWS APIs
list_route53_profiles	List Route 53 Profiles with VPC associations and attached resources (PHZs, resolver rules, DNS Firewall rule groups)	route53profiles:ListProfiles, ListProfileAssociations, ListProfileResourceAssociations

Why: Enterprise customers managing DNS across hundreds of VPCs and accounts use Profiles as the management layer above individual resolver rules and firewall groups. This uses a separate route53profiles boto3 service. Adds 3 new IAM permissions.

Excluded: Route 53 Global Resolver

Route 53 Global Resolver went GA in March 2026, but the boto3 client (route53globalresolver) does not exist yet in the SDK. I verified this by checking boto3.Session().get_available_services(). Will add this in a future PR once the SDK ships the client.

Updated phase summary

Phase	Tools	New IAM Permissions
Phase 1 — Load Balancer	3 tools (unchanged)	3 new
Phase 2 — Route 53 / DNS	5 tools (was 4, added DNS Firewall)	13 new (was 10, added 3 DNS Firewall)
Phase 3 — VPC Endpoints	2 tools (unchanged)	0 new
Phase 4 — Route 53 Profiles	1 tool (new phase)	3 new

Updated PR approach

4 separate PRs instead of 3:

1. PR 1 — Load Balancer (3 tools)
2. PR 2 — Route 53 / DNS including DNS Firewall (5 tools)
3. PR 3 — VPC Endpoints (2 tools)
4. PR 4 — Route 53 Profiles (1 tool)

Updated questions

Adding to the original questions:
4. Should list_dns_firewall_rules be a separate tool or merged into list_resolver_rules?
5. Should Route 53 Profiles go in the tools/route53/ module or a separate tools/route53_profiles/ module? (I chose separate since it's a different boto3 service.)

All code is implemented and tested locally — 326 tests passing, 94% branch coverage.