Cloud Connect
This document is an informative description of the standard Inter.link Cloud Connect service. The applicable service order, Service Level Agreement (SLA), and Master Services Agreement (MSA) prevail in the event of any conflict.
Service overview
Section titled “Service overview”Inter.link Cloud Connect provides private Layer 2 connectivity between an eligible Inter.link port and a supported cloud-provider connection point. The customer establishes and operates any required BGP session directly with the cloud provider. Inter.link does not provide addressing, routing policy, NAT, DNS, an IP gateway, or Internet access as part of the service.
The customer-facing service is available at every Inter.link point of presence (PoP). Cloud provider, handoff location, and bandwidth availability is separate and is confirmed during ordering. The service order records the Inter.link port, cloud provider and account, handoff location, VLAN, bandwidth, term, and charges.
Private transport avoids ordinary public Internet forwarding but is not inherently encrypted. Inter.link does not provide data-plane encryption; any required encryption is selected and managed by the customer.
The standard customer-side service boundary extends to the Inter.link patch panel in the building meet-me room (MMR). Customer equipment, cabling, power, and any extension beyond that demarcation remain the customer’s responsibility. A data-centre cross-connect may be ordered directly by the customer or supplied by Inter.link as a separately quoted item.
Provider and region availability
Section titled “Provider and region availability”| Cloud provider | Current availability |
|---|---|
| AWS | Available |
| Azure | Coming shortly |
| GCP | Planned |
| Other providers | May be added on request, subject to feasibility and quotation |
The standard AWS regions are eu-west-1, eu-west-2, eu-central-1, and
eu-north-1. Other AWS regions may be requested, and supported regions can be
reached from any Inter.link PoP. The customer selects the handoff location for
the cloud connection when ordering; the available locations are shown in the
portal. The AWS hosted connection is created in the AWS region associated with
the selected handoff location, and VPCs in other AWS regions are reached
through the customer’s own Direct Connect Gateway.
AWS connections are delivered as an AWS Direct Connect hosted connection allocated into the customer’s own AWS account. Inter.link has the hosted connection allocated; the customer accepts it in the AWS console, then creates the virtual interface on it and establishes the BGP session. The virtual interface type (private, public, or transit) is the customer’s choice, and a hosted connection carries one virtual interface. Inter.link is not involved in the virtual interface or BGP configuration.
AWS bills the customer’s AWS account directly for the hosted connection (port-hours, from acceptance) and for data transfer out, in addition to the Inter.link charges. The cloud provider’s account, quota, and charging terms apply independently.
Physical and logical handoff
Section titled “Physical and logical handoff”The service may use a dedicated port or share an eligible physical port or Link Aggregation Group (LAG) with other Inter.link logical services. All physical interfaces operate in full-duplex mode. Auto-negotiation is not supported. Inter.link supplies and maintains the transceiver installed in Inter.link equipment; the customer supplies and maintains the transceiver in the customer equipment.
Supported transceivers
Section titled “Supported transceivers”| Interface | Standard transceiver | FEC behaviour |
|---|---|---|
| 1G | 1G-LX | — |
| 10G | 10G-LR | — |
| 25G | 25G-LR | RS-FEC by default; FC-FEC is available |
| 100G | 100G-LR or 100G-LR4 | RS-FEC where required by the optic |
| 400G | 400G-LR4 | — |
All listed optics use single-mode fibre. Connector type, reach, wavelength, and optical operating limits follow the selected transceiver. Other optical options may be quoted separately. Current port speeds and bandwidth options must be confirmed in the customer portal or with Sales.
Ethernet presentation
Section titled “Ethernet presentation”The customer-facing handoff is a tagged VLAN on the customer’s Inter.link port; an untagged handoff is not offered. The customer selects the VLAN ID on their own port. Inter.link translates the customer-facing VLAN to the VLAN required for the cloud connection, so those VLAN IDs do not need to match. The cloud-side VLAN is assigned by Inter.link and is the VLAN shown on the hosted connection in the customer’s AWS console; the virtual interface must use it.
| Attribute | Standard behaviour |
|---|---|
| Tagged service | Outer TPID 0x8100; the outer VLAN ID must exactly match the service configuration |
| VLAN range | VLAN IDs 2–4094 per port or LAG, subject to availability on the port |
| Additional tags | Tags below the outermost service tag are carried by Inter.link, but the cloud-side virtual interface terminates a single tag; only single-tagged frames are meaningful end to end |
| PCP and DEI | Preserved but not interpreted or honoured for traffic priority |
| Ethernet MRU | 9,100 bytes for the complete frame as received, including Ethernet headers, VLAN tags, payload, and FCS |
| End-to-end frame size | May be lower where required by the cloud provider or attachment and is confirmed for the ordered connection |
Cloud Connect uses dynamic source-MAC learning with a limit of 1,000 learned MAC addresses per service and an aging timer of 300 seconds of inactivity. ARP and IPv6 Neighbor Discovery are transported without Inter.link proxying.
Link aggregation
Section titled “Link aggregation”LACP is supported with one or multiple members. All members must have identical speeds and terminate on the same Inter.link router. Fast LACP timers are used, and no minimum members are configured. If a member fails, flows are redistributed across the remaining active members while the LAG remains operational.
Bandwidth and traffic treatment
Section titled “Bandwidth and traffic treatment”Cloud Connect bandwidth is symmetric and does not burst above the ordered rate. Traffic entering the Inter.link service is hard-policed at both the customer-facing and cloud-facing endpoints, and the cloud provider polices the hosted connection at the ordered rate.
The policer measures the complete Ethernet frame, including headers, VLAN tags, payload, and FCS. There is no product-defined packet-per-second or frames-per-second limit. The ordered bandwidth is dedicated to the service and is not shared with other customers.
Resilience and diversity
Section titled “Resilience and diversity”Cloud Connect may be ordered with varying levels of diversity. Sales can confirm which diversity levels are available.
The customer’s direct routing relationship with the cloud provider controls path selection and failure handling across services. Loss of a cloud-side or Inter.link path is not propagated by taking down the customer-facing Ethernet interface; the customer must detect failures through its cloud routing or BGP.
Ordering and management
Section titled “Ordering and management”New Cloud Connect services may be ordered through the customer portal or API. Support in the Inter.link Terraform provider will be available shortly after the official product launch. The portal shows the service status, and traffic graphs, port errors, and optical values for the customer’s Inter.link port.
Activation of an AWS service follows these steps:
- The order is placed with the Inter.link port and VLAN, the handoff location, the bandwidth, the term, and the 12-digit AWS account ID.
- Inter.link provisions the service. A hosted connection appears under Direct Connect connections in the customer’s AWS account, in the AWS region associated with the selected handoff location, pending acceptance. It carries the cloud-side VLAN assigned by Inter.link.
- The customer accepts the hosted connection, creates a virtual interface on it using that VLAN, and establishes the BGP session. The virtual interface shows as down until BGP is established.
- The service is active once the hosted connection and the BGP session are up.
Cloud Connect is sold on a fixed contract term. Cancellation of, and changes to, an existing service are handled through Inter.link support; a change is delivered as a new order replacing the existing service.
Responsibilities
Section titled “Responsibilities”| Activity | Inter.link | Customer or cloud provider |
|---|---|---|
| Layer 2 transport | Operates the customer-facing handoff, provider network, VLAN translation, and cloud interconnect within the ordered boundary | Cloud provider operates its cloud-facing edge and attachment |
| Service configuration | Provisions the ordered Cloud Connect service and has the hosted connection allocated into the customer’s cloud account | Supplies complete order data, accepts the hosted connection, and creates the virtual interface and BGP session in the cloud-provider console |
| Transceivers and customer equipment | Supplies and maintains the Inter.link-side transceiver | Customer supplies and maintains its transceiver, router, cabling, power, and configuration |
| Cross-connect | May supply it when separately quoted | Customer orders and maintains it unless included in the Inter.link quote |
| Routing and encryption | Provides Layer 2 transport only | Customer establishes routing directly with the cloud provider and manages any encryption |
| Capacity | Delivers the ordered bandwidth | Customer selects adequate capacity and manages cloud-provider quotas and charges |
| Redundancy | Delivers each ordered service independently | Customer designs redundancy across services and controls traffic selection through its cloud routing design |
| Fault isolation | Tests the Inter.link service to its demarcations and manages the support ticket | Customer and cloud provider test and support their respective service boundaries |
Service levels and support
Section titled “Service levels and support”Availability and performance commitments, incident priorities, response and restoration targets, maintenance rules, exclusions, remedies, and service credits are defined exclusively in the applicable SLA. Nothing in this informative specification changes those terms. Cloud-provider terms apply independently to the cloud-side portion of the connection.