Copyable resource
Multi-cloud portability worksheet
A worksheet for deciding which parts of an app can stay portable across AWS, GCP, Azure, Kubernetes, and VM targets.
Multi-cloud portability worksheet
Use this before you build a "simple" AWS/GCP/Azure abstraction. The goal is to count the work before it turns into an unplanned platform team.
Product feature:
Customer / segment:
Supported targets:
- AWS
- GCP
- Azure
- Kubernetes
- Single VM
- Air-gapped / offline
Accepted install paths:
- CloudFormation
- Terraform
- Helm
- Branded CLI
- Offline package
- Other:
1. Resources
List every resource the feature needs.
| Resource | Purpose | Holds customer data? | Frozen or live? | Delete behavior |
|---|---|---|---|---|
| Worker / compute | ||||
| Storage | ||||
| Queue | ||||
| KV / database | ||||
| Vault / secrets | ||||
| Other |
2. Runtime API
For each resource, write the application API you want and the cloud-native calls behind it.
| Resource | Portable API | AWS | GCP | Azure | Kubernetes / VM |
|---|---|---|---|---|---|
| Storage | |||||
| Queue | |||||
| KV | |||||
| Vault | |||||
| Worker trigger |
Questions:
- What operation exists in one provider but not another?
- What limits differ across providers?
- What errors and retry rules differ?
- What behavior must be documented as "not portable"?
3. Provisioning
Write the resources that must be created or discovered for each target.
| Resource | AWS | GCP | Azure | Kubernetes / VM |
|---|---|---|---|---|
| Compute runtime | ||||
| Storage | ||||
| Queue / trigger | ||||
| Secret store | ||||
| Identity | ||||
| Network attachment | ||||
| Logs / metrics |
Questions:
- Which resources are created once and then frozen?
- Which resources are updated on every release?
- Which customer-owned resources must be discovered instead of created?
- What happens if setup fails halfway through?
- What happens if the customer manually changes the resource later?
4. Permissions
Write the exact identity and permission set for setup, management, and runtime.
| Layer | AWS | GCP | Azure | Kubernetes / VM |
|---|---|---|---|---|
| Provisioning identity | ||||
| Ongoing management identity | ||||
| Runtime identity | ||||
| Trust relationship | ||||
| Revocation path |
Reviewer checks:
- Provisioning permissions are not reused for ongoing management.
- Runtime permissions are scoped per worker.
- Management permissions do not include sensitive data reads unless explicitly approved.
- The customer can revoke access without deleting customer data.
- The generated policy can be reviewed as raw IAM / RBAC / YAML.
5. Install Artifacts
For each accepted install path, list the generated artifact and who owns it after install.
| Install path | Artifact | Generated from | Customer can edit? | Support risk if edited |
|---|---|---|---|---|
| CloudFormation | ||||
| Terraform | ||||
| Helm | ||||
| CLI | ||||
| Offline package |
Questions:
- How do you prove all install paths represent the same deployment?
- How do you detect if the customer changed the generated artifact?
- How do you upgrade the install artifact later?
- How do you keep support from debugging four different deployment products?
6. Existing Customer Retrofit
Most teams do not get to restart from a clean install path. Write down how the new model handles deployments that already exist.
| Question | Answer |
|---|---|
| Which customers are already installed? | |
| Which install path did each one use? | |
| Which generated values, Helm values, Terraform variables, or cloud resources must be imported? | |
| Which resources are customer-owned and must not be recreated? | |
| How do we start receiving telemetry without forcing a reinstall? | |
| How do we preserve staging / production / POC environment boundaries? |
Pass condition:
- Existing customers can be imported one deployment at a time.
- Customer-owned resources are discovered, not recreated.
- The retrofit path does not require a big-bang migration across every customer.
7. Release and Rollback
Write the operational path after the first install.
| Question | Answer |
|---|---|
| How do we ship a code update? | |
| How do we update a permission policy? | |
| How do we add a new resource? | |
| How do we roll back one customer? | |
| How do we pause updates for one customer with an approval gate? | |
| How do we know which customers are on which version? | |
| What happens when the customer has no internet egress? |
8. Support and Observability
| Signal | Where it lives | Who can read it | Customer-data risk | Retention |
|---|---|---|---|---|
| Health | ||||
| Logs | ||||
| Metrics | ||||
| Failed deployment step | ||||
| Version / release state |
Questions:
- Can support see enough to diagnose failure without SSH?
- What can be shared with the vendor without exposing sensitive payloads?
- What is the customer asked to do during an incident?
- What provider-specific failure modes need runbooks?
9. Final Cost Check
Count the work before building.
| Count | Value |
|---|---|
| Resources in this feature | |
| Cloud targets | |
| Install paths | |
| Runtime adapters | |
| Provisioning artifacts | |
| Permission sets | |
| Release paths | |
| Support runbooks |
Decision:
- Build this abstraction ourselves.
- Keep the feature single-cloud for now.
- Use native cloud APIs behind a managed deployment platform.
- Re-scope the customer promise.