# 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.