Outsourcing infrastructure changes who operates a component, but it does not remove dependency. A business may become more reliable overall while also becoming more concentrated on one provider, account or platform.
1) Types of vendor dependency
- A service depends on one provider being available
- Data is stored in a provider-specific format
- Operations require one management portal or account
- Specialist skills exist only with one supplier
- Licensing or contract terms limit alternatives
- Several vendors rely on the same upstream platform
2) Concentration is often hidden
Different applications may appear diversified because they have different names and suppliers, yet all run in the same cloud region, use the same identity provider or depend on the same telecommunications carrier.
A dependency map should identify upstream providers and shared control planes, not only direct contracts.
3) Provider resilience and customer resilience are different
A provider may operate highly resilient infrastructure while the customer deploys everything in one region, account or configuration. Conversely, a customer may design for multiple regions but still depend on one global control plane.
Responsibility must be separated between what the provider offers and what the customer has actually configured, tested and purchased.
4) Portability and exit planning
Portability is the practical ability to move data, workloads and operations. It depends on export formats, transfer time, application architecture, skills, licences, DNS, identity and the availability of a destination.
An exit plan should estimate time and cost rather than simply state that migration is possible.
5) Contractual protections
Service-level commitments, support terms, data-return clauses and notice periods can reduce uncertainty, but they do not create immediate technical failover.
Contract review and architecture review should inform each other. A recovery design may require features or support levels that are not included in the basic service.
6) Dependency review questions
- Which business services depend on this provider?
- What upstream platforms does the provider use?
- How long could the service be unavailable?
- Can data be exported and validated?
- What credentials are required to leave?
- Is there a tested fallback or only a contractual promise?
Operational review questions
Use these questions to connect the concept to a real service or environment:
- Which services and decisions depend on this provider or platform?
- What concentration is hidden behind direct suppliers?
- What contractual commitments differ from technical capability?
- How long would migration or exit actually take?
- Who owns the dependency and next review?
Related guides
Anycast Routing Explained — Why CDNs and DNS Work So Fast
A plain-language explanation of anycast routing and why it allows DNS providers, CDNs, and global platforms to deliver traffic from the nearest location.
Compute & StorageConsistency vs Availability Explained
A detailed, plain-language explanation of consistency vs availability in distributed systems, including trade-offs, real-world examples, and why systems cannot maximize both.
Cloud ArchitectureHow Cloud Regions and Availability Zones Actually Work
A clear, architecture-first explanation of how cloud regions and availability zones are designed, connected, and operated — and why they matter for resilience and latency.
Network & DeliveryHow Content Delivery Networks (CDNs) Actually Work
A plain-language explanation of how content delivery networks work, including edge caching, origin fetches, anycast routing, and why CDNs reduce latency.