Cloud integrations (AWS)
Release integrates with your favorite cloud provider(s)! This is the first step in building out a self-hosted cluster in the cloud provider account of your choice.
Last updated
Release integrates with your favorite cloud provider(s)! This is the first step in building out a self-hosted cluster in the cloud provider account of your choice.
Last updated
To set up a Kubernetes (EKS) cluster in your AWS account using Release, you first need to create an integration between Release and your AWS account.
Navigate to Configuration. Select the Cloud Integrations button and click the Create Cloud Integration button.
Select "Amazon" under "Cloud Integration Provider".
Choose a name for your integration (something like "Production" or "Preproduction", depending on what you are going to run in this cloud account).
Press Create Cloud Integration.
This will create a new integration under your Cloud Integrations tab. Note that this is just a placeholder integration when you first create it as you haven't yet authenticated with AWS.
Once you've created the integration, you can authenticate your AWS account by navigating to the integration and pressing the Launch Stack button. This will create the required IAM role in your AWS account to allow Release to carry out actions on your behalf in AWS. Note that this is just an integration stack and it will not yet create a cluster or set up any compute resources in your AWS account.
In a new window, you'll be prompted to sign into your AWS account to complete the integration. You should use an account with sufficient privileges to create new IAM roles, create and destroy Route 53 records, create and destroy EKS clusters and associated resources, and manage any other AWS services you wish to use with Release.
We recommend you use AWS Organizations to create a sub-account to deploy your AWS resources into. This ensures a safe boundary between Release clusters and infrastructure and any other application infrastructure you may be testing or using, especially in development or test environments. This may align with your company policies on auditing, billing, and business units. Using an isolated sub account can also prevent any unintended consequences in your production or mission-critical accounts. Feel free to ask us any questions or concerns you may have about account permissions and boundaries.
Many customers deploy Release clusters into their production accounts to run their production workloads. The above recommendation for using an isolated sub account still applies if this is your first time integrating with Release. We recommend a "crawl-walk-run" iterative approach when approaching large problems.
Please make sure you use the correct account where Release will deploy your cluster (for example, preproduction clusters should be created in your "development" or "staging" AWS account, not in your "production" account).
Most users will not change or alter the parameters. In particular, the AccountID, ExternalID, and Integration URL are set by Release and should not be edited. The Permissions Boundary ARN is explained in AWS Permissions Boundaries. You should not add a Permissions Boundary unless you have talked with Release first to verify the permissions restrictions will not break anything. If this is your first time running the AWS integration, you should not add a permissions boundary until after your cluster(s) have been created.
Within 2-3 minutes, the stack should appear in the integration page. You can use the refresh button on the right to view the status of each component of the integration stack, and the refresh button on the left to view the overall status of the stack.
Once the stack status is "Complete", you can navigate back to your Release account.
Under "Cloud Provider Integration Info" on the Cloud Integrations tab, you should now see your AWS account ID, as in the image below. This indicates that Release has successfully pulled information from your AWS account and the integration is up and running.
