AWS Bandwidth Changes and Upgrades

AWS Hosted Connection bandwidth can be changed after provisioning, but the process depends on the delivery path. On the Tata Communications-managed direct interconnect, AWS supports a hot change. On the interconnect partner-routed path, the connection must be deleted and recreated.

Why bandwidth changes are not a single workflow

Hosted Connections look identical to the customer regardless of delivery path, but the underlying provisioning differs, and so does the change behaviour. Before raising a change, identify which path your connection is on – the TC^x Portal shows this.

Delivery path	Bandwidth change behaviour	Customer impact
Tata Communications-managed direct interconnect	Hot change, raised through AWS support on your behalf	No teardown; BGP, VIFs and routing stay up
Partner-routed path	Rebuild – current connection deleted, new one created	BGP goes down; VIFs must be recreated and re-accepted

Confirm the target bandwidth is supported

AWS does not over-provision Direct Connect interconnects. Before raising any change, Tata Communications confirms feasibility (free capacity on the interconnect at the target location). If the target exceeds what the current interconnect supports, it cannot be done as a simple adjustment – a new interconnect or a second Hosted Connection may be needed. The per-connection ceiling follows the AWS interconnect rule (5 Gbps on a 10 Gbps interconnect, 10 Gbps on 20 Gbps, 25 Gbps only at 100 Gbps locations).

Changing bandwidth on the direct interconnect (hot)

Raise the change request on the TC^x Portal (or via your account team).
Tata Communications validates feasibility – interconnect capacity at the target location.
Tata Communications raises the AWS support ticket on your behalf (AWS does not expose Hosted Connection bandwidth changes in the console).
AWS applies the change; BGP, VIFs and routing remain operational throughout.
Tata Communications confirms and closes; the new bandwidth reflects in your portal view.
Raise the change request on the TC^x Portal with the target bandwidth.
Tata Communications validates feasibility on the new slab.
Tata Communications schedules a maintenance window (your agreement is required, since this is disruptive).
The current Hosted Connection is deleted; BGP over it goes down.
A new Hosted Connection is created at the target bandwidth.
You recreate and re-accept VIFs – the new connection has a new identifier, so old VIFs do not carry over.
Routing converges and traffic resumes.

Typical lead time is 2–5 business days, depending on the AWS support queue. No CPE re-configuration is required as long as your access circuit supports the higher rate.

Changing bandwidth on the partner-routed path (rebuild)

Raise the change request on the TC^x Portal with the target bandwidth.
Tata Communications validates feasibility on the new slab.
Tata Communications schedules a maintenance window (your agreement is required, since this is disruptive).
The current Hosted Connection is deleted; BGP over it goes down.
A new Hosted Connection is created at the target bandwidth.
You recreate and re-accept VIFs – the new connection has a new identifier, so old VIFs do not carry over.
Routing converges and traffic resumes.

Typical maintenance window is 30–90 minutes including reconvergence. If you need continuous availability through the change, provision a second Hosted Connection at the target bandwidth, shift traffic with BGP, then retire the old one.

Upgrade vs. add capacity

Vertical upgrade - raise the bandwidth of the existing Hosted Connection. Simpler; no BGP topology change.
Horizontal expansion - add a second Hosted Connection at a second Direct Connect location and balance with BGP. Adds resilience as well as capacity.

For workloads above 5 Gbps with strong availability requirements, horizontal expansion is the recommended pattern even where a vertical upgrade is possible.

Downgrades and billing

Downgrades follow the same mechanics as upgrades – hot on the direct path, rebuild on the partner-routed path. Billing transitions to the new bandwidth from the change-completion date; it is not back-dated to the request date.