MTU and Jumbo Frames on AWS

You choose the MTU when you create the Virtual Interface in your AWS console, and it cannot be changed afterwards. The AWS-side ceiling is set by the VIF type – Private VIF up to 9001 bytes, Transit VIF up to 8500 bytes, Public VIF 1500 only. The Tata Communications side carries jumbo below 9000 bytes by default, so a 9001-byte Private VIF is effectively capped just under 9000 end to end.

What MTU support depends on

On AWS Direct Connect, the maximum frame size depends on the VIF type created in your AWS account:

VIF type	AWS-side maximum MTU
Private VIF	9001 bytes
Transit VIF	8500 bytes
Public VIF	1500 bytes only

What Tata Communications delivers

Both the Tata Communications-managed direct interconnect and the partner-routed path support jumbo frames, sized below 9000 bytes on the Tata Communications side. The Tata Communications MPLS backbone carries jumbo on customer Cloud VCs by default; no customer action is required to enable it. Where a Private VIF is set to 9001, the usable end-to-end size across the Tata Communications side is just under 9000; a Transit VIF at 8500 is unaffected because it already sits below that ceiling.

What to set, and where

The AWS-side ceiling is fixed by the VIF type you choose at VIF creation: 9001 bytes on a Private VIF, 8500 on a Transit VIF, 1500 on a Public VIF. The Tata Communications side carries jumbo below 9000 bytes, so a 9001-byte Private VIF is effectively capped just under 9000 end to end; a Transit VIF at 8500 is unaffected. Set your CPE to match the end-to-end ceiling. Apply the value on your router or firewall per your vendor's configuration guidance.

VIF MTU is set at creation

The MTU on an AWS VIF is chosen when the VIF is created and cannot be changed afterwards. To move a VIF from 1500 to jumbo (or back), delete and recreate it – see Configuring Virtual Interfaces (VIFs) for AWS.

Path MTU and the network in between

Setting the right MTU at both ends is necessary but not sufficient – the whole path must be jumbo-clean. Common causes of trouble:

Tata Communications MPLS tail-circuit at 1500 – large packets dropped at the edge. Confirm the Tata Communications MPLS service MTU with your account team.
PMTUD blackholing at the customer firewall – a firewall dropping ICMP unreachable breaks Path MTU Discovery.
Inner-MTU reduction through an IPsec overlay – ESP overhead (~50–60 bytes) lowers the effective MTU on encrypted traffic.
AWS-side endpoint below the VIF MTU – some AWS endpoints terminate at 1500 regardless of the VIF setting.

Verifying end-to-end MTU

A do-not-fragment ping from the CPE confirms whether jumbo is working before applications go live. Size the payload below the effective ceiling (account for IP/ICMP overhead). If it succeeds, the path is jumbo-clean at the tested size; if it fails with “fragmentation needed”, the path MTU is lower somewhere and needs investigation. The exact flags are host-dependent.

When to use jumbo

Jumbo helps measurably for bulk transfer over a Private VIF (backup, replication, large objects), storage protocols (NFS, iSCSI, SMB) aligned to 8–9 KB frames, and workloads where per-packet processing is the bottleneck. It does little for small-payload transactional traffic (API calls, DNS, monitoring); for mixed traffic, leaving MTU at 1500 is often simpler.

If MTU isn’t working as expected

If the values are set per the handoff and symptoms persist, raise a service request on the TC^x Portal, or see AWS Troubleshooting.