Platform dependencies per cloud platform
Modern applications are built from ready-made building blocks of a cloud platform. Every building block is a dependency. Some are easy to replace with an alternative outside the platform. Others are so proprietary that transferring them amounts to rebuilding.
This page is a reference for the inventory behind an exit strategy: which platform-specific services does a solution use, and which of those have a realistic alternative? The tables are not an argument against platform services; they make dependencies visible, so that choosing them is a conscious choice. The assessment per component is indicative. The deeper a component is woven into the architecture, the greater the actual dependency. The tables are a snapshot (July 2026); cloud services change.
Microsoft Azure
| Component | Role in the application | Layer | Alternative outside Azure? |
|---|---|---|---|
| Azure App Service | runs the web application | PaaS | yes, reasonably (container or VM) |
| Azure Functions | loose, event-driven code | PaaS | limited (bindings are proprietary) |
| Azure SQL Database | relational database | PaaS | yes (T-SQL is portable) |
| Cosmos DB | NoSQL database | PaaS | limited (only via compatibility APIs) |
| Azure Blob Storage | file storage | PaaS | yes (S3-like alternatives) |
| Azure Service Bus | message queue | PaaS | limited |
| Azure Event Grid / Event Hubs | event distribution and streaming | PaaS | limited |
| Logic Apps | no-code workflows | PaaS | no |
| API Management | API gateway, throttling, keys | PaaS | yes (Kong, NGINX) |
| Azure Key Vault | secrets and certificates | PaaS | yes (Vault) |
| Microsoft Entra ID | authentication and authorisation | PaaS | yes, but invasive |
| Azure Virtual Network | network topology | IaaS | yes |
| Application Gateway / Front Door | load balancing, WAF, TLS | IaaS | yes |
| Azure Firewall / NSGs | network filtering | IaaS | yes |
| Azure Monitor / Application Insights | logging and telemetry | PaaS | yes |
| Bicep / ARM templates | infrastructure definition | — | no, Azure-specific |
The heaviest dependencies typically sit with Cosmos DB, Logic Apps, Entra ID and Bicep/ARM.
Amazon Web Services (AWS)
| Component | Role in the application | Layer | Alternative outside AWS? |
|---|---|---|---|
| Elastic Beanstalk / App Runner | runs the web application | PaaS | yes, reasonably (container or VM) |
| AWS Lambda | loose, event-driven code | PaaS | limited (triggers and integrations are proprietary) |
| Amazon RDS / Aurora | relational database | PaaS | yes (RDS: standard engines; Aurora more limited) |
| DynamoDB | NoSQL database | PaaS | no practical equivalent |
| Amazon S3 | file storage | PaaS | yes (the S3 API is the de facto standard) |
| SQS / SNS | message queue and pub/sub | PaaS | limited |
| EventBridge / Kinesis | event distribution and streaming | PaaS | limited (Kafka is an alternative to Kinesis) |
| Step Functions | workflows | PaaS | no |
| API Gateway | API gateway, throttling, keys | PaaS | yes (Kong, NGINX) |
| Secrets Manager / KMS | secrets and keys | PaaS | yes (Vault) |
| IAM / Cognito | authentication and authorisation | PaaS | yes, but invasive |
| Amazon VPC | network topology | IaaS | yes |
| ALB / CloudFront | load balancing, CDN, TLS | IaaS | yes |
| Security Groups / AWS WAF | network filtering | IaaS | yes |
| CloudWatch | logging and telemetry | PaaS | yes |
| CloudFormation / CDK | infrastructure definition | — | no, AWS-specific |
The heaviest dependencies typically sit with DynamoDB, Step Functions, the Lambda integrations and CloudFormation/CDK.
Google Cloud
| Component | Role in the application | Layer | Alternative outside Google Cloud? |
|---|---|---|---|
| Cloud Run / App Engine | runs the web application | PaaS | Cloud Run: yes (containers); App Engine: limited |
| Cloud Functions | loose, event-driven code | PaaS | limited (triggers are proprietary) |
| Cloud SQL | relational database | PaaS | yes (standard engines) |
| Firestore / Bigtable / Spanner | NoSQL and distributed databases | PaaS | no practical equivalent |
| Cloud Storage | file storage | PaaS | yes (S3-compatible API) |
| Pub/Sub | messages and events | PaaS | limited (Kafka as an alternative) |
| Workflows | workflows | PaaS | no |
| Apigee / API Gateway | API gateway | PaaS | yes (Kong, NGINX) |
| Secret Manager / Cloud KMS | secrets and keys | PaaS | yes (Vault) |
| Cloud IAM / Identity Platform | authentication and authorisation | PaaS | yes, but invasive |
| VPC | network topology | IaaS | yes |
| Cloud Load Balancing / Cloud CDN | load balancing, CDN, TLS | IaaS | yes |
| Cloud Armor / firewall rules | network filtering | IaaS | yes |
| Cloud Monitoring / Cloud Logging | logging and telemetry | PaaS | yes |
| Deployment Manager | infrastructure definition | — | no, Google Cloud-specific |
The heaviest dependencies typically sit with Firestore/Spanner, Workflows and Deployment Manager.
How to use these tables
- For the inventory behind an exit strategy: which components are in use and which of those have no realistic alternative? That determines what is needed to continue the service elsewhere.
- As a design choice: those who deliberately select components with an alternative, within a single platform, build the exit strategy into the architecture. A platform-independent infrastructure definition (for example Terraform) reduces the dependency on platform-specific templates. The underlying services remain platform-bound.
- When setting up a deposit: a deposit is only complete when, alongside the source code, the infrastructure definitions, the configuration and a description of the platform services used are recorded as well. For solutions with heavy platform bindings, CloudSecure® arranges the continuity of the entire running cloud service.
Exit strategy and digital sovereignty → Cloud escrow or CloudSecure? →