Cloud Scoping
How the isolated area is defined within each cloud provider.
Your application lives in a small, isolated area within the customer's cloud account. This page explains what that area looks like on each provider, and how the boundary is drawn.
The requirements are the same everywhere: lightweight to set up, fine-grained enough that your application can't touch anything outside its boundary, and easy for the customer's security team to review.
Azure — Resource Group
A resource group is a container that holds related resources. It's the clearest model — the boundary is explicit and visible in the Azure portal.
The customer creates a resource group for your deployment. All of your application's resources live inside it. Permissions are scoped to the group — Alien can't see or manage anything in other resource groups.
╔═ Customer's Azure Subscription ════════════════════════════╗
║ ║░
║ ┌─ rg-acme-myapp ───────────────────────────────────┐ ║░
║ │ │ ║░
║ │ Container App · Blob Storage · Service Bus │ ║░
║ │ Key Vault · Managed Identity │ ║░
║ │ │ ║░
║ └───────────────────────────────────────────────────┘ ║░
║ ║░
║ Other resource groups — untouched. ║░
╚════════════════════════════════════════════════════════════╝░
░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░GCP — Project
A GCP project is a natural isolation boundary. Each project has its own resources, permissions, and billing.
The customer creates a project for your deployment. Alien's permissions are scoped to that project via custom roles. Other projects in the customer's organization are invisible.
╔═ Customer's GCP Organization ══════════════════════════════╗
║ ║░
║ ┌─ Project: acme-myapp ────────────────────────────┐ ║░
║ │ │ ║░
║ │ Cloud Run · Cloud Storage · Pub/Sub │ ║░
║ │ Secret Manager · Service Account │ ║░
║ │ │ ║░
║ └──────────────────────────────────────────────────┘ ║░
║ ║░
║ Other projects — untouched. ║░
╚════════════════════════════════════════════════════════════╝░
░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░AWS — Resource Prefix
AWS doesn't have a built-in container like a resource group or project. Instead, the boundary is defined through a naming prefix — a short, unique string that all of your deployment's resources share.
Alien generates an 8-character prefix for each deployment (e.g. k44e9b72). Every resource is named with this prefix: k44e9b72-worker (Lambda), k44e9b72-data (S3 bucket), k44e9b72-tasks (SQS queue). IAM policies then restrict access to resources matching that prefix — every ARN is scoped to k44e9b72-*.
╔═ Customer's AWS Account ═══════════════════════════════════╗
║ ║░
║ Resources matching prefix "k44e9b72-*": ║░
║ ┌─────────────────────────────────────────────────────┐ ║░
║ │ │ ║░
║ │ k44e9b72-worker (Lambda) │ ║░
║ │ k44e9b72-data (S3 bucket) │ ║░
║ │ k44e9b72-tasks (SQS queue) │ ║░
║ │ k44e9b72-secrets (Secrets Manager) │ ║░
║ │ │ ║░
║ └─────────────────────────────────────────────────────┘ ║░
║ ║░
║ Other resources — denied by IAM policy. ║░
╚════════════════════════════════════════════════════════════╝░
░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░Why a prefix instead of tags or a dedicated account? A few reasons:
- Works everywhere. S3 bucket names, Lambda function names, SQS queue names, Secrets Manager names — all support prefix-based scoping in IAM policies. Not all AWS services support tag-based access control.
- Lightweight. No need to create a separate AWS account or organization unit per customer. Hundreds of deployments can coexist in the same account, each isolated by prefix.
- Reviewable. The customer can look at the IAM policy and see exactly which resources the role can touch — every ARN ends with the prefix pattern.
The prefix is generated automatically by Alien. You don't choose it or manage it.
What all three share
The mechanism differs, but the result is the same:
- Clear boundary — your application's resources are isolated from everything else in the account.
- Revocable — the customer can remove access at any time by deleting the resource group, project, or IAM role.
- Reviewable — the customer's security team can inspect exactly what permissions exist before approving.
Alien derives the scoping automatically from your stack definition. You define the resources; Alien generates the correct naming, policies, and role bindings for each cloud.