Isn't using Terraform/IaC enough to avoid vendor lock-in?

It's a critical first step for infrastructure portability, but it doesn't solve the whole problem. IaC abstracts away VM or Kubernetes cluster definitions, but it cannot abstract proprietary managed service APIs like DynamoDB vs. CosmosDB, or AWS Lambda vs. Azure Functions. Furthermore, it does nothing to mitigate data gravity—the significant egress costs associated with moving terabytes of data out of a provider's ecosystem.

At what point does a manual lock-in assessment become unfeasible?

The tipping point is usually when a team operates across more than one cloud provider or manages over 200-300 resources. At that scale, the complexity of tracking disparate billing APIs, identifying equivalent services, and modeling data transfer costs grows exponentially. Manual spreadsheets become error-prone and are often outdated the moment they're completed.

How deep does Thalaxo's lock-in assessment go?

Thalaxo automates the foundational step: creating a detailed, unified inventory of all resources and their associated costs across supported providers. This provides the raw, normalized data required for a TCO analysis. It identifies which services are being used (e.g., Lambda, RDS, S3), allowing you to quantify your dependency on them. The subsequent architectural analysis of how to migrate those specific services remains a human-led, strategic task.

How Locked-In Is Your Cloud Infrastructure, Really?

Table of Contents

Your Cloud Bill is the First Sign of Vendor Lock-in

If you cannot accurately price a project running on AWS, you cannot accurately price its migration to Azure. This inability to model costs is the first gate in a real cloud vendor lock-in assessment. It’s less about dramatic platform failures and more about the slow, creeping inability to make strategic choices because the financial implications are opaque. The problem often starts with something as mundane as resource tagging. Without a rigorous cost allocation strategy, you are effectively locked-in by ignorance, unable to build a business case for alternatives because the baseline is a mystery.

Step 1: Quantify Proprietary Service Dependencies

Vendor lock-in isn’t just about VMs. The real glue is managed services with proprietary APIs. Think AWS Lambda vs. Azure Functions, or Amazon DynamoDB vs. Google Cloud Bigtable. While functionally similar, their APIs, integration patterns, and performance characteristics are distinct. Migrating requires code changes, not just a different Terraform provider. Your first step is to build a complete inventory of these services.

A simple inventory can begin with the CLI. I run this command to get a quick overview of our serverless footprint on AWS; it immediately tells me which runtimes we’re using, which is a key factor in estimating the complexity of a potential migration to another provider’s serverless platform.

# List all Lambda functions and their runtimes to assess migration complexity
aws lambda list-functions --query 'Functions[*].[FunctionName,Runtime]' --output text

Each proprietary service represents a migration work package. A high dependency on services like AWS Step Functions, Amazon SQS, or GCP’s Spanner indicates a higher degree of lock-in that requires significant re-architecture, not just a lift-and-shift operation. Tools like Terraform can abstract infrastructure, but they cannot rewrite your application code’s interaction with these platform-specific APIs. For a deeper look at challenges in cross-platform accounting, see our guide on why multi-cloud reconciliation takes days.

Step 2: Model the Data Gravity and Egress Costs

Data has gravity. The cost and effort of moving large datasets out of a cloud provider is one of the most significant and frequently underestimated barriers to migration. Cloud providers make it cheap and easy to ingest data but charge significant fees for data transfer out to the internet (egress). A few terabytes of logs, backups, or user data can quickly translate into a multi-thousand-dollar line item on your migration budget.

Before any serious migration discussion, you must calculate the total volume of data stored in services like Amazon S3, Azure Blob Storage, or Google Cloud Storage. The following AWS CLI command provides a human-readable summary of a single S3 bucket’s size, which is the starting point for estimating egress fees.

# Calculate the total size of a specific S3 bucket
# This is a critical input for estimating data egress costs
aws s3 ls --summarize --human-readable --recursive s3://your-production-datastore-bucket

Once you have the total size in TB or PB, you can model the cost using the provider’s public pricing. For example, AWS charges on a tiered basis for data transfer out. You can find the details on their official S3 pricing page. This calculation must include not just primary datastores but also backups, archives in colder storage tiers, and container registries.

A Practical Cloud Vendor Lock-In Assessment Framework

A structured assessment moves beyond fear and into data-driven decision-making. It combines the technical inventory with financial modeling to produce a clear picture of your real-world portability.

The 4-Point Assessment Checklist:

Service Inventory: Catalog all services in use. Classify each as either commodity (VMs, block storage) or proprietary (managed databases, serverless platforms, AI/ML APIs). This identifies the scope of required re-architecture.
Data Egress Modeling: Quantify all stored data. Use the provider’s pricing calculator to model the one-time cost of extracting that data. Remember to factor in the network bandwidth and time required for the transfer itself.
Operational Tooling Analysis: Evaluate your CI/CD pipelines, monitoring, and security tools. Are they cloud-agnostic (e.g., GitLab, Datadog, Terraform) or tightly coupled to native services (e.g., AWS CodePipeline, CloudWatch, IAM)? The more portable your tooling, the lower your operational lock-in. Running a simple command like `terraform state list` can give you an instant inventory of what’s already managed in a portable way.

# List all resources currently managed by Terraform in the current state file
# This helps identify infrastructure that is already abstracted from the cloud provider
terraform state list

Total Cost of Ownership (TCO) Comparison: A true TCO model includes the cost of migration (engineering hours, egress fees) and the target platform’s operational costs. Don’t just compare VM prices; compare the costs of the equivalent managed services you identified in step one.

Conclusion: From Assessment to Action

A cloud vendor lock-in assessment is not a one-time project but a continuous practice of architectural and financial awareness. The goal isn’t necessarily to be 100% portable—that’s often impractical—but to understand the real cost of your dependencies so you can make strategic decisions with open eyes. The average waste detected in cloud accounts is 32%, according to the FinOps Foundation State of FinOps 2024 report, and much of this stems from the same lack of visibility that enables lock-in.

Automating the inventory and cost analysis is the foundation of this practice. Thalaxo provides a unified view across multiple clouds, automating the resource discovery and cost allocation needed to feed a TCO model. It gives you the raw data to quantify your dependencies without spending weeks manually parsing bills. While Thalaxo is a newer platform with its SOC 2 Type II audit currently in progress, it’s built to provide the cross-platform clarity that native tools inherently lack. You can explore our supported integrations and see our pricing to understand how it fits into your FinOps toolkit.