Spot’s onboarding process is simple: once you have a new AWS account, you are only a few clicks away from creating a Spot account and associating the two together.
But for bigger organizations that are provisioning AWS accounts regularly, this repetitive process becomes a bit laborious. There’s also another quibble with manual onboarding: suppose you want to grant Spot new permissions for a new product you’d like to use in all of your AWS accounts. If you had manually onboarded them, you’ll probably need to update Spot’s trusted role in each of those accounts. This can be mitigated with scripts and such, but that still is not automatic.
We’re happy to announce a faster and seamless way to automatically enroll newly created AWS accounts into Spot and manage them in a centralized fashion. A step-by-step guide is included towards the end of this post.
Spot’s Onboarding StackSet doesn’t only auto-create a new Spot account for AWS organizations under the AWS management account (main-payer), it’ll also update all Stacks when the StackSet itself is updated. This means:
- Spot accounts for newly created AWS accounts are created and managed by the Stack.
- The connection between the Spot and the AWS account is established automatically.
- Updates made to the Spot role are reflected automatically in all AWS accounts when the StackSet is updated.
- If the Stack in one of the AWS accounts is deleted, so is the Spot account, alongside all resources created by the Stack.
To use the Spot Onboarding StackSet, you’ll need to:
- Acquire a Spot API token with admin access. (docs)
- Enable Trusted Access with AWS Organizations. (docs)
- Verify that your Spot organization is permitted to enroll additional accounts. Contact our support team if you’re unsure about this permission.
The StackSet template explained
Stack Instances of this StackSet will be automatically created in newly provisioned AWS accounts, this is the nature of AWS StackSets.
The StackSet template is available here.
The only required parameter for this template is a Spot API token with administrator privileges. Each Stack Instance creates 6 resources in the target AWS account:
SpotManagedPolicy: The policy that grants Spot access to certain services in the AWS account. Will be attached to
SpotAccount: A lambda-backed resource. This one will potentially create a new Spot account that will be later linked to the AWS account. The name of the Spot account initially is the AWS account’s ID. If there already is a Spot connected to the current AWS account, it will retrieve its ID.
SpotExternalId: The external ID used by Spot when it needs to
SpotRole: Spot’s role, which allows it to manage AWS resources according to
SpotLinkedCredentials: This resource creates the actual link between the AWS account and the Spot account.
RenamedSpotAccountByAlias: This lambda-backed resource will rename the newly associated Spot account to the current AWS account’s alias (AKA billing name). This resource is optional: if you don’t want the accounts renamed, simply omit it.
Please note: While there are 4 lambda-backed “resources” here, the lambdas themselves are not provisioned in any of your AWS accounts.
If the AWS account the Stack is being created in is not already connected to a Spot account: a new Spot account will be created. The Spot account name is initially the AWS account ID.
If the AWS account the Stack is being created in is already connected to a Spot account: the Stack will “adopt” it — it will create a new Policy and Role, and apply them to this account. It will also rename the Spot account if the
RenamedSpotAccountByAlias resource is included. If the Stack is later deleted, it will delete this Spot account (even though the account wasn’t originally created by the Stack).
If the AWS account the Stack is being created in is connected to more than Spot account, Stack creation will fail.
Step-by-step: provisioning Stacks with Spot’s StackSet
In this demonstration I have two AWS accounts:
- A main-payer account – we’ll call it the “main account”
- An AWS organization account nested under an organizational unit – we’ll call it the “secondary account”
I want to enroll my secondary AWS account as a new account in Spot. I also want to make sure that any new AWS accounts I enroll under my main-payer get their own Spot account, connected to a Spot account.
The first step is to make sure your various accounts meet the prerequisites listed earlier in this post.
We’ll start by creating the StackSet in the AWS main-payer/management account.
- Go to CloudFormation → StackSets → Create StackSet
- Under the “Choose a template” screen, upload the template file for the StackSet. Click “Next”.
- Under “Specify StackSet details”, give your StackSet a name, description, and provide it with a Spot API token with administrative privileges. That is the only parameter this template requires. Click “Next”.
- Under “Configure StackSet options”, optionally tag the StackSet and configure other options as required.
- The “Set deployment options” screen is an important one because it determines how Stacks of the StackSet are going to be deployed
- In this example, we’re going to specify a single OU (Organizational Unit) where Stacks are going to be created.
- We’re also going to select a single region, because we don’t want to create a Spot account for every region, only for every new AWS account.
- And we want Stack Instances of the StackSet to be auto-deployed to AWS accounts under the main-payer.
- Click “Submit”
And that’s it! A new Spot account will be created shortly for our secondary AWS account, the two will be connected, and the Spot account will be renamed to match the AWS billing alias:
First, the account is created with the AWS account ID:
Then the account is connected to Spot:
Lastly, the account is renamed to the AWS account alias:
With this StackSet setup, various aspects of managing the AWS resources with Spot are seamlessly taken care of. Please reach out and contact support if you have any questions. We are happy to provide assistance in getting this configured.