Subaccounts
Subaccounts let you give a customer a single-tenant deployment in its own cloud account with a few clicks. Alien creates an AWS account, a Google Cloud project, or an Azure resource group in your cloud, requests the quotas it needs, and deploys your stack into it.
Architecture diagram. Left: Your side containing Alien manager. Right: Your AWS organization containing Alien subaccounts containing customer-1 containing us-east-1; eu-west-1; customer-2 containing us-east-1.
A separate account per customer is the strongest isolation a cloud offers: separate permissions, quotas, and bills. Without subaccounts, you create each account by hand and run initial setup in it. See Single-tenant in your cloud.
Deploy a customer
Once you've connected your cloud, a new customer takes one form:
- Open Deployments, choose Deploy release, then Deploy to your environment.
- Enter the Environment name, for example
customer-1. - Under Where, choose New AWS subaccount, New Google Cloud subaccount, or New Azure subaccount.
- Check the Subaccount name and pick the Region, then choose Deploy.
The deployment moves through Creating, Waiting for quota if a quota is too low, and Deploying. A new account is ready in a few minutes, or at once when a warm pool has one ready.
No one runs CloudFormation or Terraform. Alien sets up the account itself and keeps it current on every release, like any other deployment.
One account, many deployments
A subaccount can hold several deployments, in any region. How you group them is up to you:
- One subaccount per customer, for isolation.
- One per customer, several regions: pick the customer's existing subaccount under Where and another Region.
- One shared subaccount for customers who don't need their own.
An existing subaccount shows under Where with its number of deployments. Deploying into it needs no initial setup, so the deployment starts right away.
Your own cloud account is still under Where, for an account you created yourself. It uses the usual initial setup with CloudFormation or Terraform.
Close a subaccount
Deleting a deployment never closes its subaccount on its own. When you delete the last deployment in a subaccount, the dialog asks whether to close the subaccount as well.
To close one later, open it under Subaccounts and choose Close subaccount:
- AWS suspends the account. It still counts toward your organization's account limit for 90 days.
- Google Cloud shuts down the project. You can restore it for 30 days, and its project ID can't be reused.
- Azure deletes the resource group and everything in it.
From your backend
To create the customer's environment when they sign up, call the API with the same choice. dedicatedAccount creates a new subaccount first; cloudAccountId deploys into an existing one:
{
"name": "customer-1",
"project": "acme",
"platform": "aws",
"region": "eu-west-1",
"dedicatedAccount": {
"requestId": "8f0c4a52-1d6e-4b0e-9a57-3a1f2c7d9e10",
"connectionId": "2b7d1c90-6a4e-4f3b-8c21-5e9f0a3d7b64",
"name": "customer-1"
}
}connectionId is the connected cloud. Reuse the same requestId when you retry, so a retry never creates a second subaccount.
Next
- Connect a cloud: give Alien access to create subaccounts.
- Warm pools: keep accounts ready so new customers start at once.
- Quotas: account limits and the quotas inside each account.