# Cloud Interconnect

> Source: Courseiva IT Certification Glossary — https://courseiva.com/glossary/cloud-interconnect

## Quick definition

Cloud Interconnect is like having a private, dedicated highway directly from your office to the cloud data center, instead of sharing the public internet with everyone else. This private connection makes data transfer faster, more secure, and more reliable, which is critical for businesses that run important applications in the cloud. It helps avoid problems like slow speeds or internet outages that can happen with a regular internet connection.

## Simple meaning

Think of the public internet as a crowded public city street. Many people and cars (data packets) are trying to get around, and there are traffic jams, red lights, and potholes. Your data might get stuck in traffic, take a long detour, or even be at risk of someone peeking into your car. Now, imagine you own a large warehouse (your on-premises data center) and a big store (the cloud) on opposite sides of town. You need to move heavy boxes of inventory between them every day, reliably and quickly. Using the public street is possible, but it's slow, unpredictable, and not very secure.

Cloud Interconnect is like building a private, underground tunnel or a dedicated, multi-lane highway that connects your warehouse directly to your store. This tunnel is for your use only. No one else uses it, so you don't get stuck in traffic. The journey is much faster because there are no speed bumps or traffic lights. It's also much more secure because no one else can enter the tunnel and mess with your boxes. The cloud provider (like Google Cloud, Amazon Web Services, or Microsoft Azure) partners with a telecommunications company to set up this private physical cable connection from your location to one of their nearby facilities, called a colocation center. Once it's set up, your office computers and servers can talk to the cloud resources as if they were in the same room, even though they are physically miles apart.

This is a big deal for companies that have moved their critical business applications, like customer databases or financial systems, to the cloud. They need constant, high-speed access to this data without any hiccups. Cloud Interconnect guarantees a certain speed (bandwidth) and reliability (uptime), which the public internet simply cannot guarantee. It makes hybrid cloud setups, where some things are on your own servers and some are in the cloud, work smoothly and seamlessly.

## Technical definition

Cloud Interconnect is a suite of managed services offered by major cloud providers (Google Cloud Interconnect, AWS Direct Connect, Azure ExpressRoute) that establishes a direct, private, and highly available network connection between an organization's on-premises network and the cloud provider's virtual private cloud (VPC) or virtual network. It fundamentally bypasses the public internet, providing a more consistent, lower-latency, and higher-bandwidth network experience. The service is built on a partnership between the cloud provider and a network service provider (NSP) or colocation provider.

At its core, Cloud Interconnect relies on physical, cross-connected fiber-optic cables. The process begins with an organization selecting a cloud provider's supported partner location, which is typically a colocation facility (e.g., Equinix, Digital Realty) that is already connected to the cloud provider's backbone network. The organization must have a presence in that same facility or arrange for the partner to extend connectivity from the organization's on-premises location to that facility. Once both the organization and the cloud provider have network equipment within the same facility, a physical cross-connect is established between the organization's router and the cloud provider's edge router.

This physical connection implements the standardized IEEE 802.1Q VLAN trunking protocol to create multiple logical, isolated sub-interfaces or Virtual LANs (VLANs). This allows a single physical connection to carry traffic for multiple separate virtual networks, a feature known as Virtual Interfaces (VIFs) in AWS, or VLAN attachments in Google Cloud. Each VLAN attachment is configured with a specific Border Gateway Protocol (BGP) session. BGP is the routing protocol of the internet, and here it is used to dynamically exchange routing information between the on-premises network and the cloud VPC. The organization uses BGP to advertise its on-premises IP address ranges (CIDR blocks), and the cloud provider advertises the IP ranges of the VPC. This ensures that traffic takes the private path.

To achieve high availability and redundancy, which is a crucial aspect of IT implementations, cloud providers mandate that connections must be set up in pairs. A typical setup involves two distinct physical connections, often terminating on different routers in different availability zones (or in separate metro locations) to protect against a single point of failure. AWS refers to this as a Link Aggregation Group (LAG). BGP configurations on both ends use local preference and AS path prepending to control traffic flow, enabling active/active or active/passive failover scenarios. Service Level Agreements (SLAs) for Cloud Interconnect typically offer 99.9% to 99.99% uptime, a stark contrast to a standard internet connection without an SLA.

From a security perspective, traffic traversing a Cloud Interconnect connection is private and does not traverse the public internet. However, it is still important to encrypt sensitive data in transit using protocols like TLS or IPsec, especially if compliance standards like PCI-DSS or HIPAA demand it. The connection itself provides a layer of physical security and network isolation, but it is not a substitute for end-to-end encryption. The cloud provider's edge routers are managed devices that implement various security policies and access control lists (ACLs) to filter traffic. Organizations can further control routing by implementing network firewall appliances on their on-premises side or within the cloud VPC.

The technical implementation involves careful planning of bandwidth capacity, which can range from 50 Mbps to 10 Gbps or higher per connection. For very high throughput, users can bond multiple connections. Latency is significantly lower than over the internet because the traffic takes a direct, optimized path through the provider's backbone network. The setup also simplifies network management by removing the need for VPN termination, as the private connection is always on and provides a stable, predictable network link. In practice, Cloud Interconnect is the preferred solution for large-scale data migration (e.g., petabytes of data), real-time data replication, live video processing, and any workload where network jitter or packet loss is unacceptable.

## Real-life example

Imagine you own a very popular bakery in a busy city. Your main shop is downtown (your on-premises data center), but you also have a huge, secret kitchen in a nearby industrial district where you bake all your bread and pastries (the cloud). Every morning, you need to get fresh croissants and baguettes from the kitchen to the shop to sell. You have two options.

First, you could hire a regular delivery driver to use the public city streets (the internet). The driver has to deal with traffic jams, construction zones, red lights, and unpredictable road closures. Sometimes the delivery takes 10 minutes, sometimes 45. The bread might get jostled around, and there's a small chance someone could open the delivery box and take a bun. This works for a few croissants, but for hundreds of orders, it's unreliable and slow. You can't promise customers that the pastries will be fresh and on time.

Second, you could invest in a dedicated underground conveyor belt system (Cloud Interconnect) that goes directly from your industrial kitchen's loading dock to your shop's basement. This conveyor belt is privately owned and maintained. It runs at a constant speed, 24/7. No traffic, no red lights, no potholes. You can send hundreds of boxes of croissants every minute, and you know exactly when they will arrive. You can also lock your boxes securely before they go on the belt, so no one can tamper with them. This is a significant investment to set up, but now you can guarantee that your customers will always get their fresh-baked goods on time, every time. Your business can scale up because the conveyor belt can handle a much larger volume. You can even run your daily operations knowing that the supply chain is rock solid.

In the IT world, the public city streets are the public internet traffic. The dedicated conveyor belt is Cloud Interconnect. The 'boxes of croissants' are your critical business data and application traffic. The 'bakery shop' is your office or data center, and the 'industrial kitchen' is the cloud region. The initial cost of building the conveyor belt is like the setup fee and monthly charges for the physical cable and cross-connect. The benefit is a reliable, fast, secure, and scalable connection that makes your hybrid business model work flawlessly.

## Why it matters

For many modern businesses, the cloud is not just a place to host a simple website. It is the core platform for running enterprise resource planning (ERP) systems, customer relationship management (CRM) databases, data warehousing, and real-time analytics. These applications are sensitive to network latency, jitter, and packet loss, which are common on public internet connections. If a financial analyst cannot access the cloud-based trading platform because the internet is slow, the business loses money. If a globally distributed team cannot collaborate on a shared database because of intermittent connectivity, productivity plummets.

Cloud Interconnect solves these critical business continuity and performance challenges. It provides a consistent, predictable network path with a guaranteed Service Level Agreement (SLA) for uptime and performance. This allows IT teams to design hybrid architectures where workloads can be migrated, replicated, or scaled between on-premises and cloud environments. For example, a company might run its legacy database on-premises for security reasons but use cloud-based machine learning services to analyze that data. Without a private, high-bandwidth connection, the data transfer would be too slow and unreliable to be practical.

Cloud Interconnect helps organizations meet strict regulatory and compliance requirements. Many industries, such as finance, healthcare, and government, have regulations that prohibit sensitive data from traveling over the public internet. By using a private, dedicated connection, organizations can audit and control the entire data path, satisfying auditors and reducing security risks. It also saves money in the long run for high-volume data users, as egress data transfer costs (data moving out of the cloud) over Cloud Interconnect are often significantly lower than over the public internet. In short, Cloud Interconnect transforms the cloud from a remote, best-effort utility into a reliable, high-performance extension of a company's own data center.

## Why it matters in exams

Cloud Interconnect is a high-value, frequently tested topic across AWS, Azure, and Google Cloud certification exams, especially at the associate and professional levels. For the AWS Certified Solutions Architect – Associate (SAA-C03), it is critical. Exam objectives explicitly cover designing a hybrid architecture, and AWS Direct Connect is the primary solution for this. You might encounter a scenario where a company needs a dedicated, low-latency connection to its VPC that is not subject to internet latency. The key differentiator to remember is that Direct Connect uses a dedicated line, while Site-to-Site VPN goes over the internet. Another common scenario is a large data migration (e.g., 50 TB) that would take weeks over the internet; here, the answer is often AWS Direct Connect or AWS Snowball, but the question will specify 'dedicated network connection' leading you to Direct Connect.

For the Azure Administrator (AZ-104) and Azure Fundamentals (AZ-900) exams, the equivalent service is Azure ExpressRoute. Expect questions about creating a private connection between an on-premises network and Azure. You will need to know the differences between ExpressRoute and a Site-to-Site VPN. A classic trap is a scenario about a connection that must be 'private' as opposed to 'encrypted.' ExpressRoute is private but does not encrypt traffic by default (it is private, but you can add encryption). A VPN is encrypted but goes over the public internet. The exam will test your understanding of this trade-off.

For Google Cloud exams like the Associate Cloud Engineer (ACE) and Professional Cloud Architect (PCA), Google Cloud Interconnect is a core concept. Questions often revolve around choosing between Partner Interconnect (using a supported service provider) and Dedicated Interconnect (direct physical cross-connect). A common scenario involves a company needing 10 Gbps of bandwidth. Dedicated Interconnect offers 10 Gbps, while Partner Interconnect starts at 50 Mbps. The exam might also test the requirement for redundancy: you must have two separate connections for a robust setup. Questions about VLAN attachments and BGP sessions are common at the professional level. For the Cloud Digital Leader exam, understanding the business value of low latency and security (compliance) for hybrid workloads is sufficient.

## How it appears in exam questions

Exam questions about Cloud Interconnect typically fall into a few distinct patterns, focusing on scenario-based architecture decisions, configuration details, and troubleshooting. One common pattern is the 'Architecture Scenario' question. The question describes a company with a data center that already has a Site-to-Site VPN to the cloud, but they are experiencing intermittent connectivity and high latency for a latency-sensitive application like VoIP or real-time data replication. The correct answer is to implement a dedicated private connection (Direct Connect, ExpressRoute, or Cloud Interconnect) to provide a consistent, low-latency path.

Another frequent pattern involves 'Cost Optimization and Data Transfer.' A scenario may describe a company that transfers petabytes of data monthly between its on-premises environment and the cloud. The exam will ask for the most cost-effective and performant method. The trap answer is often 'Use a Site-to-Site VPN because it's cheaper.' While a VPN can be set up for free with a virtual gateway, the data egress costs over the internet are high. The correct answer is to set up a private connection with lower data transfer rates and higher speed.

A third pattern is the 'High Availability and Redundancy' question. The question outlines a scenario where a single private connection is in place, and it fails. The answer will involve the concept of a redundant connection to a different location or device. Often, the question will explicitly state 'achieve 99.99% uptime,' which is a direct hint to set up a connection with a failover, often to a second Direct Connect location or a backup VPN.

Configuration-level questions are more common on professional-level exams. For example, a question might show a diagram of two VPCs and ask what is required to route traffic from an on-premises network to the cloud over a private connection. The answer will involve configuring BGP sessions to route the appropriate CIDR blocks. In Azure, a common question is about 'ExpressRoute circuits' and 'private peerings' versus 'Microsoft peerings.' A troubleshooting question might ask: 'Your on-premises network cannot reach a resource in the cloud over your private connection. You have verified that the connection is up. What is the most likely issue?' The answer would be a misconfigured BGP session, incorrect route propagation, or a firewall ACL blocking the traffic.

## Example scenario

Your company, 'FinFlow Analytics', has its main headquarters in Chicago, where it runs a legacy database (Oracle) that handles all financial transactions. The company also uses Google Cloud for its advanced machine learning platform to analyze those transactions for fraud detection. The database is 5 TB in size and needs to be queried in real-time by the cloud ML application. The current connection is a VPN over the public internet, but it suffers from high latency (150 ms) and occasional packet loss, which causes the ML models to time out and give inaccurate results.

You, as the cloud architect, propose using Google Cloud Partner Interconnect. You contact a supported partner (like Equinix) that has a presence in a Chicago colocation facility. You arrange for a 1 Gbps dedicated fiber connection from your office to that colo facility. Inside the facility, the partner establishes a physical cross-connect from your router to a Google Cloud edge router. You then configure two VLAN attachments, each with a BGP session. One VLAN attachment is for production traffic, and the other is for management and data synchronization. You also set up a second connection to a different Google Cloud edge router in the same facility for redundancy, creating a Link Aggregation Group (LAG).

After the setup, the latency drops to 2 ms, and the data transfer is stable. The ML models now work perfectly, and the company saves money on egress fees because the dedicated connection has a lower data transfer cost. The hybrid architecture is now robust, meeting the SLA requirements of the financial services compliance team. This scenario shows how Cloud Interconnect solves the real-world challenge of performance, reliability, and cost in a hybrid cloud environment.

## Cloud Interconnect: Direct Connectivity to Google Cloud

Cloud Interconnect is a Google Cloud service that provides direct, private, and high-bandwidth connections between an organization’s on-premises network and Google Cloud’s network. Unlike connecting over the public internet, which introduces variability in latency, bandwidth, and security, Cloud Interconnect offers a dedicated link that bypasses internet congestion. This is particularly important for enterprises with hybrid cloud architectures, real-time applications, or data residency requirements.

The primary use cases for Cloud Interconnect include migrating large datasets to Google Cloud, maintaining consistent performance for latency-sensitive workloads (such as video streaming or financial trading), and ensuring regulatory compliance where data must traverse a private path. There are two main types: Dedicated Interconnect, which provides a direct physical connection between your router and Google’s edge router at a colocation facility, and Partner Interconnect, which leverages a supported service provider to establish connectivity when a direct physical link is not feasible. Both options offer 99.9% or 99.99% uptime SLAs, depending on configuration.

Cloud Interconnect does not include data transfer charges for ingress, but egress data is billed at a lower rate compared to internet egress. This makes it cost-effective for heavy egress workloads like content delivery or disaster recovery. Understanding when to use Cloud Interconnect versus VPN or Carrier Peering is a common exam topic. VPN is cheaper but limited by bandwidth and latency, while Carrier Peering offers no SLA and is less reliable. Cloud Interconnect is the premium option for predictable performance.

From a networking perspective, Cloud Interconnect supports both VLAN attachments (using IEEE 802.1Q) and Layer 2 or Layer 3 connectivity. You can use it to connect to multiple VPC networks, enabling segmentation at the infrastructure level. Cloud Router is key to dynamic routing via BGP, which automatically advertises and learns routes, making failover seamless. The service integrates with Cloud Armor for DDoS protection and Cloud VPN for backup connections. Mastering these subtleties is critical for Google Cloud architect exams, where scenario-based questions often ask whether to use Interconnect, VPN, or Carrier Peering based on bandwidth, cost, and uptime requirements.

## Dedicated vs. Partner Interconnect: Choosing the Right Type

Google Cloud Interconnect is divided into two primary types: Dedicated Interconnect and Partner Interconnect. Dedicated Interconnect provides a direct physical connection between your own equipment in a colocation facility and Google’s network. This is ideal for organizations with high bandwidth demands (10 Gbps or more per circuit) and full control over the physical layer. You must provision a circuit through a colocation provider and bring your own router. The connection supports multiple VLAN attachments, each of which can map to a different VPC network. The SLA for Dedicated Interconnect is 99.99% uptime when configured with two redundant connections (diverse paths).

Partner Interconnect, on the other hand, allows you to connect through a supported service provider (such as Equinix, CenturyLink, or Megaport). This is suitable for lower bandwidth needs (from 50 Mbps to 10 Gbps) and when you cannot or do not want to manage a physical cross-connect. The provider handles the last mile, and you configure a VLAN attachment on the Google side. Partner Interconnect offers a 99.9% uptime SLA with redundant connections. One key advantage is that you can scale bandwidth up or down more flexibly without changing physical infrastructure.

Configuration for both types involves creating a VLAN attachment (a Cloud Interconnect attachment) in the Google Cloud Console, specifying the region, and assigning a Cloud Router to handle BGP sessions. For Dedicated Interconnect, you also need to create a connection resource that represents the physical link. The router must be configured with the correct BGP parameters, including ASN, peer IP, and enable BGP. It is common practice to configure two separate attachments for high availability, each on a different physical link and region. Redundancy is a major exam focus: understand that a single Interconnect connection provides no redundancy, and two connections must be placed in different edge availability domains within a metro to achieve true HA.

A typical setup for Dedicated Interconnect involves ordering the interconnection through the Google Cloud console, coordinating with the colocation provider to patch the fiber, and then verifying the link status. For Partner Interconnect, you simply authorize the partner to create a connection, and they handle the physical aspect. The Cloud Interconnect dashboard shows statuses like "active," "waiting for partner," or "down." Monitoring these statuses and troubleshooting BGP session drops is a common exam scenario. For example, if a VLAN attachment is stuck in "pending partner" state, the issue is typically that the partner has not yet completed their provisioning. Understanding these distinctions helps in selecting the correct interconnect type for given bandwidth, cost, and resilience requirements in architecting hybrid networks.

## Cloud Interconnect Pricing and Service Level Agreements

Cloud Interconnect pricing is a critical factor in network design and a frequent topic in certification exams. Pricing is based on three main components: the connection fee (for Dedicated Interconnect), the VLAN attachment fee (hourly per attachment), and data transfer (egress) fees. The connection fee for Dedicated Interconnect is a one-time charge per physical circuit (e.g., 10 Gbps or 100 Gbps). After that, you pay an hourly rate per VLAN attachment, which increases with capacity (e.g., 200 Mbps, 1 Gbps, 10 Gbps). For Partner Interconnect, the pricing model is similar but the partner may add their own markups. Data transfer egress is billed at a reduced rate compared to standard internet egress, typically around 20-40% less, depending on destination region and volume.

Ingress data (data flowing into Google Cloud) is free for Cloud Interconnect, which is beneficial for data uploads. This means moving large amounts of data from on-premises to Google Cloud incurs no upload costs. However, egress (data leaving Google Cloud to on-premises) is what incurs cost. The egress tiered pricing model (e.g., first 10 TB at one rate, then lower rates for higher volumes) can lead to significant savings for continuous large-volume data flows. Exams often test whether Cloud Interconnect is cheaper than internet for egress in the long run, considering the upfront connection cost. The answer is typically yes for predictable, high-volume traffic, but not for small, sporadic transfers.

Service Level Agreements (SLAs) for Cloud Interconnect depend on the type and redundancy configuration. Dedicated Interconnect with two redundant connections configured in different edge availability domains offers a 99.99% uptime SLA. A single connection offers only 99.9% uptime for Google’s network, but the physical link itself is subject to colocation provider SLAs. Partner Interconnect offers a 99.9% uptime SLA for the Google portion when using two attachments. Exam questions often ask how to achieve the highest SLA: answer is to use two Dedicated Interconnect connections in different metros or edge availability zones, with dual VLAN attachments, and use Cloud Router for BGP failover. Not understanding that a single connection does not provide HA is a common mistake.

there are monthly commitments that can lower hourly rates for both Dedicated and Partner Interconnect. If you commit to a certain amount of capacity (e.g., 10 Gbps for 1 year), you get a discounted hourly rate. However, if you do not meet the committed usage, you still pay for the commitment. This trade-off is tested in cost optimization scenarios. Other costs include cross-connects from colocation providers (ranging from $200-$2000 per month depending on location) and partner fees for Partner Interconnect. Knowing these details helps in designing cost-effective hybrid networks that meet performance requirements while staying within budget. For exams, pay attention to scenarios where Cloud Interconnect is recommended for consistent performance, while Carrier Peering is used for lower cost but no SLA.

## Security, Redundancy, and Best Practices for Cloud Interconnect

Security for Cloud Interconnect is a multi-layered topic that involves network segmentation, encryption, and access control. By default, Cloud Interconnect traffic does not encrypt the payload; it relies on the physical security of the fiber and colocation facility. For sensitive data, it is recommended to add an overlay encryption layer such as IPsec VPN on top of the Interconnect connection. This is often done by configuring a Cloud VPN tunnel that uses the Interconnect link as the underlay. This hybrid approach offers both the performance of a dedicated connection and the encryption of VPN. In exams, this scenario is common: a question describes a need for both low latency and encryption, and the answer is to use Cloud Interconnect with an IPsec tunnel over it.

Another best practice is to implement redundancy at every level. This means using two separate physical Interconnect connections from different colocation facilities (or different edge availability zones within a metro). Each connection should have its own VLAN attachment and Cloud Router. BGP can be configured with multiple sessions, and Cloud Router can be set up with active/active or active/passive routing. In the active/passive model, you set lower local preference on the backup path to avoid asymmetric routing. For true high availability, use two Interconnect connections from distinct locations (e.g., region A and region B) to protect against regional outages. This is known as multi-region redundancy.

Network segmentation is another important best practice. Each VLAN attachment can be associated with a specific VPC network, and you can use separate attachments for production vs. development traffic. This prevents accidental cross-contamination and simplifies troubleshooting. Use Cloud Armor with Interconnect for DDoS protection, as the dedicated connection can be a target for volumetric attacks. Cloud Armor rules can filter traffic before it reaches your on-premises resources.

Monitoring the health of Interconnect connections is crucial. Use Cloud Monitoring (formerly Stackdriver) to set up alerts for BGP session drops, latency spikes, or bandwidth usage. The Cloud Interconnect dashboard provides metrics like bytes sent/received, packet drops, and round-trip time. For global connectivity, consider using Cloud CDN or HTTP Load Balancers behind the Interconnect for content delivery. Another best practice is to enable VPC Flow Logs on the subnets that use the Interconnect to capture traffic metadata for security audits and troubleshooting. Exams test knowledge of when to use which security feature: for example, if a company requires encryption on-premises to cloud, the correct choice is to use Cloud Interconnect with IPsec VPN, not just Interconnect alone. Understanding these best practices is essential for both the Google ACE and PCA exams, as well as for real-world architecture.

## Common mistakes

- **Mistake:** Thinking Cloud Interconnect and a Site-to-Site VPN are functionally the same and interchangeable for all uses.
  - Why it is wrong: Cloud Interconnect provides a dedicated, private, physical connection that bypasses the public internet, offering consistent latency, higher bandwidth, and a service-level agreement (SLA). A Site-to-Site VPN uses the public internet and is subject to its variability, congestion, and potential security risks, though it does encrypt traffic.
  - Fix: Use a VPN for lower-cost, encrypted connectivity when consistent latency and high bandwidth are not critical. Use Cloud Interconnect for mission-critical workloads requiring high performance, reliability, and a private network path.
- **Mistake:** Believing that a single Cloud Interconnect connection provides sufficient high availability.
  - Why it is wrong: A single connection creates a single point of failure. If the physical cable is cut, the router fails, or the colocation facility has an outage, the entire connection is lost. Cloud providers mandate at least two connections for a highly available setup.
  - Fix: Always provision at least two separate physical connections, ideally to different provider edge routers and, if possible, in different colocation facilities or availability zones, to achieve resilience.
- **Mistake:** Assuming Cloud Interconnect automatically encrypts all data in transit.
  - Why it is wrong: By default, traffic over a private connection is physically isolated but not encrypted. It is transmitted in cleartext within the cloud provider's network. For compliance with standards like HIPAA or PCI-DSS, data still needs to be encrypted using TLS or IPsec.
  - Fix: Implement end-to-end encryption (e.g., TLS for application traffic, or an IPsec VPN tunnel over the private link) to ensure data confidentiality and meet security compliance requirements.
- **Mistake:** Confusing the bandwidth of Cloud Interconnect with the speed of data transfer for a single TCP stream.
  - Why it is wrong: A 10 Gbps connection might not give you a 10 Gbps file transfer speed for a single file using a single thread. TCP window size, network congestion on the application layer, and the processing power of the servers can limit throughput.
  - Fix: Use multiple parallel TCP streams or increase TCP window sizes on both ends to fully use the available bandwidth of the private connection.
- **Mistake:** Forgetting that route advertisement (BGP) must be configured correctly for traffic to flow over the private link.
  - Why it is wrong: Simply establishing the physical link and VLAN is not enough. The on-premises router must advertise its IP subnet (CIDR) to the cloud, and the cloud must advertise the VPC subnet. If the BGP session is down or routes are not propagated, traffic will not use the private path.
  - Fix: Verify that BGP sessions are established and that the correct routes are being advertised and accepted. Check route tables in both the cloud console and on-premises router.
- **Mistake:** Choosing a location for the physical cross-connect without considering proximity to cloud provider edge routers.
  - Why it is wrong: The physical cable from your office to the colocation facility must be short enough to avoid signal loss and high latency. If the facility is far away, the benefit of low latency is lost.
  - Fix: Select a colocation facility that is geographically close to your on-premises location and is a direct partner of your cloud provider to minimize physical cable distance and latency.

## Exam trap

{"trap":"In an AWS exam scenario, they ask for the most secure way to connect an on-premises network to a VPC. The options include a VPN with encryption and AWS Direct Connect. The trap is to choose the VPN because it has encryption.","why_learners_learners_choose_it":"Learners often associate 'private' with 'encrypted.' They see 'Direct Connect' as a private connection but forget that 'private' in this context means network isolation, not data-level encryption. The VPN explicitly provides encryption, so they choose it without considering the overall security architecture.","how_to_avoid_it":"Understand the difference between network-layer privacy (isolation from the public internet) and data-layer encryption (scrambling the data). A Direct Connect connection is private but does not encrypt traffic by default. However, you can easily run a VPN over a Direct Connect to get both privacy and encryption. The most secure option is often a combination: a Direct Connect connection with a VPN tunnel running over it, or simply a private connection with application-layer TLS encryption."}

## Commonly confused with

- **Cloud Interconnect vs Site-to-Site VPN:** A Site-to-Site VPN uses the public internet to create an encrypted tunnel between networks. Cloud Interconnect uses a private, dedicated physical cable that does not touch the public internet. Cloud Interconnect offers lower latency, higher bandwidth, and an SLA, while a VPN is cheaper and provides encryption by default but with variable performance. (Example: Think of a VPN as a secure, armored car driving on a busy, shared highway (internet). Cloud Interconnect is a private, underground tunnel directly connecting your office to the cloud.)
- **Cloud Interconnect vs Cloud VPN (or Virtual Private Cloud):** VPC is a logically isolated section of the cloud network where you launch resources. It is a virtual container for your cloud environment. Cloud Interconnect is a physical or virtual connection that links your on-premises network to that VPC. You need a VPC first before you can use Cloud Interconnect to connect to it. (Example: A VPC is your own private room in a large office building (the cloud region). Cloud Interconnect is a private hallway from your home (on-premises) directly to your private room.)
- **Cloud Interconnect vs Cloud CDN (Content Delivery Network):** Cloud CDN caches static content (like images, videos) at edge locations around the world to serve users faster. Cloud Interconnect does not cache anything; it is a high-speed, low-latency connection between two specific points: your on-premises network and a specific cloud region. CDN is about distributing content globally; Interconnect is about connecting two locations privately. (Example: CDN is like having multiple mini-shops (edge locations) around the city so customers can get products quickly. Cloud Interconnect is a dedicated highway between your factory and your main warehouse.)
- **Cloud Interconnect vs Cloud Peering (Google Cloud):** Cloud Peering (Direct Peering) is a free connection between your on-premises network and Google's network, but it does not provide guaranteed SLAs and is not managed by Google. Cloud Interconnect is a managed service with SLAs, and it connects to a specific VPC network, not to the entire Google network. Cloud Peering is less reliable and typically used for traffic that can tolerate some loss. (Example: Direct Peering is like having a handshake agreement with a courier to drop off packages at a shared dock. Interconnect is a formal contract with dedicated staff and a guaranteed delivery time.)
- **Cloud Interconnect vs AWS Direct Connect Gateway:** A Direct Connect Gateway is a component that allows a single AWS Direct Connect connection to connect to multiple VPCs in different AWS regions. The Direct Connect connection itself is the physical link. The gateway is a logical routing object that enables multi-region connectivity. (Example: The Direct Connect connection is the main water pipe from your house. The Direct Connect Gateway is a valve that can split that water flow to different rooms (different VPCs) in different parts of the house (different regions).)

## Step-by-step breakdown

1. **Assess Requirements and Choose a Provider** — The first step is to determine your bandwidth needs (e.g., 1 Gbps, 10 Gbps), desired latency, and budget. Then, choose between a dedicated connection (e.g., AWS Direct Connect, Google Cloud Dedicated Interconnect) for high bandwidth, or a partner connection (e.g., Partner Interconnect, Azure ExpressRoute via a provider) for lower bandwidth. Check the cloud provider's list of supported network partners and colocation facilities.
2. **Select a Colocation Facility** — You must have a presence in a colocation facility that is a partner of your cloud provider. If you don't already have equipment in such a facility, you must rent space. This facility is where your on-premises router and the cloud provider's edge router will be physically cross-connected. Choose a facility geographically close to your office to minimize fiber run latency.
3. **Order the Physical Circuit** — Work with a telecommunications provider or the partner to provision a physical fiber circuit from your on-premises location to the colocation facility. This circuit will carry your data. The circuit's bandwidth must match your requirements. This step involves a contract and can take several weeks to set up.
4. **Create a Virtual Interface (VIF) / VLAN Attachment** — In the cloud console (e.g., AWS, Azure, GCP), you create a virtual interface or VLAN attachment. This step associates the physical connection with a specific VPC or virtual network. You assign a VLAN ID (from 1-4094) to create a logical sub-interface on the physical link. This allows you to have multiple isolated connections over the same physical cable.
5. **Configure BGP Sessions** — Configure Border Gateway Protocol (BGP) on both the on-premises router and the cloud provider's edge router. You need to exchange routing information. For example, on your on-premises router, you configure a BGP session with the cloud router's IP address (provided by the cloud), and you advertise your on-premises IP subnet (e.g., 10.0.0.0/16). The cloud router will advertise the VPC subnet (e.g., 172.16.0.0/16).
6. **Configure On-Premises Routing** — Update your on-premises router's routing table to prefer the Cloud Interconnect path for traffic destined to the cloud VPC. This might involve adjusting BGP local preference or route metrics to ensure data uses the private path instead of the internet route, if one exists. This step ensures traffic does not accidentally exit through the much slower VPN or internet connection.
7. **Set Up Redundancy** — Provision a second physical connection (or a second VLAN attachment) to a different cloud provider edge router, ideally in a different availability zone or colocation facility. Configure BGP on both connections, with thoughtful AS path prepending to ensure traffic fails over to the backup if the primary fails. This is essential for achieving the SLA guarantee of 99.9% or higher.
8. **Test and Validate** — Test the connection by pinging cloud resources from on-premises and vice versa. Verify the latency is low and consistent. Use tools like traceroute to ensure the traffic is taking the private path (you should not see any public internet hops). Test the failover by manually disconnecting the primary link and ensuring traffic switches to the backup without major data loss.
9. **Monitor and Optimize** — Continuously monitor the connection's health, bandwidth utilization, and BGP session status using cloud provider monitoring tools (e.g., CloudWatch, Cloud Monitoring). Set up alerts for drops in throughput or BGP session downtime. Periodically review if you need to increase bandwidth or add more VLAN attachments for new services.
10. **Compliance and Security Hardening** — If required, implement additional encryption over the private link, such as an IPsec VPN tunnel or TLS for applications. Document the connection for compliance audits. Ensure firewalls on both sides of the connection are configured with the correct rules to allow and protect the specific data flows.

## Practical mini-lesson

Setting up Cloud Interconnect is a significant project that involves coordination between your organization, a network service provider (NSP), and the cloud provider. A professional architect needs to understand the nuances to avoid costly delays and misconfigurations.

First, always start with a clear understanding of the 'why.' Is it for latency-sensitive applications, large-scale data migration, or compliance? This will dictate the connection type. For example, if you need less than 1 Gbps, using a partner provider like Megaport or Equinix Fabric is faster and more flexible than getting a dedicated 10 Gbps line. Partner connections can be provisioned in days, while dedicated connections can take weeks.

A common pitfall is underestimating the physical layer. The fiber circuit from your office to the colo facility must be tested before you attempt to set up the cloud side. If the light levels on the fiber are low (measured in dBm), your connection will be unstable. You must coordinate with the NSP to have a 'turn-up' call where they test the circuit. Once the circuit is verified, you can request the cloud provider to complete the cross-connect in the colo facility. You must provide the exact patch panel numbers (e.g., 'Equinix DC2, Field 3B, Port 47') to the cloud provider.

On the cloud side, you deploy a virtual private gateway (e.g., in AWS) or a cloud router (in Google Cloud). This virtual device handles the routing for the private connection. The most critical configuration part is the BGP session. You will be assigned a private ASN (Autonomous System Number) for your on-premises router, or you can use a public ASN. You must configure a minimum of two BGP sessions per VLAN attachment (for active/active traffic) or multiple sessions for redundancy. The BGP timers can be tuned (e.g., keepalive 10 seconds, hold time 30 seconds) for faster failover detection, but this must be coordinated with the cloud provider's edge router settings.

After setup, practical use involves managing costs. Cloud Interconnect has a monthly port fee (for the port on the cloud provider's router) and a data transfer fee for traffic going out of the cloud (egress). However, the egress price per GB is often significantly lower than standard internet egress. A professional should calculate the break-even point where the monthly port fee is offset by lower data transfer costs. You can use 'hairpinning' (traffic going from on-premises to cloud, then back) but this is not efficient. Route all necessary traffic through the private link.

In a real-world scenario, you may also need to integrate with other network services. For instance, you might have an IPsec VPN tunnel running over the private connection for encryption. This is done by terminating the IPsec tunnel on a virtual network appliance (e.g., a Cisco CSR 1000v) in the cloud, which then forwards traffic over the private connection. This creates a complex but highly secure hybrid network. What can go wrong? BGP flapping (routes going up and down) due to misconfigured timers, firewalls dropping BGP packets, or MTU (Maximum Transmission Unit) mismatches. The cloud provider typically supports an MTU of 1500 bytes, while on-premises networks might use jumbo frames (9000 bytes). If you do not set the MTU correctly on both ends, packets will be fragmented, causing performance degradation. Always verify the MTU settings.

Finally, remember that a single connection is not resilient. The exam and real-world best practice is to have two connections from different providers or different locations. For example, a primary connection via your main provider and a backup via a cellular-based VPN or a secondary circuit. The automatic failover is handled by BGP route selection. You must test this failover by actually taking the primary circuit down during a maintenance window.

## Commands

```
gcloud compute interconnects attachments create my-attachment --region us-central1 --interconnect my-dedicated-interconnect --vlan-tag 100 --capacity 10Gbps --type DEDICATED
```
Creates a VLAN attachment for a Dedicated Interconnect with a specified VLAN tag and capacity.

*Exam note: Tests understanding that Dedicated Interconnect requires creating a separate attachment resource with the correct type, capacity, and VLAN tag.*

```
gcloud compute interconnects attachments create partner-attachment --region us-east1 --partner-interconnect my-partner --vlan-tag 200 --capacity 1Gbps --type PARTNER
```
Creates a VLAN attachment for a Partner Interconnect using a partner resource.

*Exam note: Exams ask about creating Partner Interconnect attachments; note that you reference a partner resource, not a direct physical connect.*

```
gcloud compute interconnects create my-dedicated-conn --location 'LAX-SJ' --description 'Primary connection' --requested-link-count 2 --admin-enabled
```
Orders a Dedicated Interconnect physical connection at a specific colocation facility, requesting two links for redundancy.

*Exam note: Tests that Dedicated Interconnect uses the --location flag for colo facility, and requesting multiple links for high availability.*

```
gcloud compute interconnects attachments get-status my-attachment --region us-west1
```
Retrieves the operational status of a VLAN attachment, such as 'active' or 'down'.

*Exam note: Used to check BGP session health; exam scenarios often have a 'down' status due to BGP misconfiguration or physical link failure.*

```
gcloud compute routers create my-router --region us-central1 --network default --asn 65001
```
Creates a Cloud Router with a specified ASN for BGP peering over Interconnect.

*Exam note: Cloud Router is mandatory for dynamic routing; ASN must match on-premises peer ASN. Common exam question: 'What resource is required for BGP with Interconnect?'*

```
gcloud compute routers update-bgp-peer my-router --peer-name peer1 --interface if1 --peer-ip-address 169.254.1.1 --peer-asn 65001 --advertised-route-priority 100
```
Updates a BGP peer on a Cloud Router, setting a custom local preference for path selection.

*Exam note: Tests ability to configure BGP metrics for active/passive failover; exam questions present a scenario requiring traffic to flow over the primary link only when it's up.*

```
gcloud compute interconnects attachments describe my-attachment --region us-east1 --format='json' | jq '.privateIpAddress'
```
Describes the attachment and extracts the private IP address used for BGP peering.

*Exam note: The private IP on the Google side is allocated from the 169.254.0.0/16 range; this is tested in troubleshooting BGP neighbor mismatches.*

## Troubleshooting clues

- **VLAN Attachment Stuck in 'Waiting for Partner' State** — symptom: After creating a Partner Interconnect attachment, the console shows 'Waiting for partner' for an extended period.. This occurs when the service provider (partner) has not yet completed their side of the provisioning. The attachment remains in a pending state until the partner activates the connection. (Exam clue: In exams, a question presents a scenario where an attachment is stuck in 'Waiting for partner', and the correct answer is to check with the partner provider or wait for their provisioning to complete, not to delete and recreate.)
- **BGP Session Not Establishing** — symptom: The BGP session stays 'Idle' or 'Active' and never reaches 'Established'.. This is usually due to incorrect BGP configuration: mismatched ASN, wrong peer IP address, or firewall blocking TCP port 179. Verify that the on-premises router's peer IP matches the attachment's private IP (169.254.x.x) and that both sides have the same ASN. (Exam clue: Exams test that BGP uses TCP 179 and that the private IP range is 169.254.0.0/16. A question might describe a new BGP session not coming up after adding an Interconnect, and the answer is to check the BGP configuration on the on-premises router.)
- **Intermittent Packet Loss or Latency Spikes** — symptom: Traffic over the Interconnect experiences random packet drops or increased latency during peak hours.. This may indicate a capacity bottleneck on the VLAN attachment or the physical link. Check bandwidth utilization metrics in Cloud Monitoring. If utilization exceeds 70% consistently, consider upgrading capacity or adding an additional connection. (Exam clue: Exam questions often present a scenario of intermittent drops and ask for the likely cause: answer is 'insufficient bandwidth' and the fix is to increase attachment capacity or add another Interconnect circuit.)
- **VLAN Attachment State 'Down' After Local Maintenance** — symptom: After a planned maintenance on the on-premises router, the Interconnect attachment shows as 'Down'.. The BGP session may have timed out due to configuration changes or rebooting of the on-premises router. The interface may also be admin down. Verify the on-premises router interface status and restart BGP sessions on both sides. (Exam clue: In exams, a scenario describes an admin performing maintenance and then losing connectivity; the correct step is to check the BGP session on the Cloud Router and restart if needed, ensuring the interface is not disabled.)
- **Egress Traffic Going Over Internet Instead of Interconnect** — symptom: Data from Google Cloud to on-premises is using public internet route, causing higher latency and costs.. This happens when the on-premises network does not advertise the correct routes via BGP, or the routes are not being accepted by the VPC. Ensure that the Cloud Router is importing the custom advertised routes from the on-premises side. Also, check that the on-premises router is advertising specific prefixes. (Exam clue: Exams test that dynamic routing via Cloud Router is needed for traffic to use Interconnect; otherwise, destinations fall back to the default internet route. A question with 'on-premises traffic still going to internet' points to missing BGP route advertisement.)
- **Cannot Create a Second VLAN Attachment on the Same Interconnect** — symptom: When attempting to add a second VLAN attachment to an existing Dedicated Interconnect, the console shows an error about exceeding VLAN limits.. A single Dedicated Interconnect (10 Gbps or 100 Gbps) supports a maximum number of VLAN attachments (typically 8 per 10 Gbps circuit). You have reached the limit. Either reduce the number of attachments, or order an additional Interconnect circuit. (Exam clue: This tests understanding of the maximum VLAN attachments per Interconnect. An exam question might ask 'why can’t I add a 9th VLAN attachment on my 10G Interconnect?' and the answer is the VLAN attachment limit.)
- **Dedicated Interconnect Link Status 'No Light'** — symptom: The physical link on the colocation router shows 'No Light' or 'Link Down'.. This indicates a physical issue with the fiber optic cable: it may be unplugged, damaged, or not properly patched at the colocation facility. Check physical connections and contact the colocation provider for assistance. (Exam clue: In troubleshooting scenarios, an admin sees 'link down' on a Dedicated Interconnect; the first step is to verify physical connectivity at the colo, not just the software configuration. This is tested in practical troubleshooting questions.)

## Memory tip

Remember 'CUPS' for Cloud Interconnect: Consistent latency, Unmatched bandwidth, Private path, SLA guarantee. It is a 'Private Highway', not a 'Public Tunnel' (VPN).

## FAQ

**Is Cloud Interconnect the same as the internet?**

No. The internet is a public network of networks. Cloud Interconnect is a private, dedicated connection that bypasses the public internet. It is like using a private road instead of a public highway.

**Can I use Cloud Interconnect for a small business?**

It is generally not cost-effective for small businesses with low bandwidth needs. The monthly port fees and contract terms are designed for medium-to-large enterprises that need consistent performance for critical workloads.

**Does Cloud Interconnect encrypt my data?**

By default, no. The traffic is private because it is on a dedicated path, but it is not encrypted. You need to add encryption (e.g., TLS or IPsec) on top to secure the data content, especially for compliance reasons.

**How long does it take to set up Cloud Interconnect?**

It varies. A dedicated physical connection can take several weeks due to fiber cabling and facility access. A partner-based connection (e.g., through Megaport) can be provisioned in a few days because the partner already has connections in place.

**What happens if the Cloud Interconnect cable breaks?**

If you have only one connection, your connectivity to the cloud will be lost. Best practice is to have a redundant, second connection set up. If you have two connections and one breaks, BGP routing will automatically fail over traffic to the working connection, often within 60 seconds.

**Can I connect to multiple VPCs with one Cloud Interconnect connection?**

Yes, but it requires additional configuration. For example, in AWS you use a Direct Connect Gateway to connect to multiple VPCs in different regions over a single connection. In Google Cloud, you can use multiple VLAN attachments to connect to different VPCs.

**Is Cloud Interconnect more expensive than a VPN?**

Yes, the initial setup and monthly port fees are higher. However, for large data volumes, the lower egress costs of Cloud Interconnect can make it cheaper overall than a VPN with high data transfer fees.

**Do I need Cloud Interconnect to use cloud services?**

No. You can access all cloud services over the public internet via a web browser or a VPN. Cloud Interconnect is only necessary when you require a guaranteed high-performance, low-latency, and private connection for critical workloads.

---

Practice questions and the full interactive page: https://courseiva.com/glossary/cloud-interconnect