BYO AWS Account¶
Frame provides Customer and Organization admins with the option to “Bring Your Own” (BYO) Amazon Web Services (AWS) account. Each Frame Platform installation has a default AWS account associated with it. This default AWS account is used for provisioning infrastructure like EC2 instances, EBS volumes, etc. The default account is also used for storing Gold Master Images, known as Amazon Machine Images (AMIs). With the BYO AWS Account option, these components are instead provisioned in your AWS account, rather than in the default AWS account.
Common reasons you may want to go with the BYO option include:
- You wish to take advantage of your existing billing arrangements with AWS for convenience and/or pricing. For example, your organization may already have certain AWS consumption commitments or pre-payments – and you can use Frame to consume those resources on your own AWS account.
- You would prefer to “own” your Frame workloads and therefore have full administrative access.
- You want to configure other network integrations (VPN gateway) on your own within your AWS account.
We allow any new Frame account to be created under a non-default AWS account to leverage “Bring Your Own AWS Account” feature.
- In order to use an AWS account with Frame, you will need to ensure that you have an IAM user with at minimum the following permissions:
- AWS Console login
You will need your Account ID number, which can be found by going to your “My Account” page in your AWS console. Click on the drop down menu next to your account name in the upper right corner of your AWS Console to access this page. See below for all the steps required to add your BYO AWS account.
Some costs may begin to accrue immediately after completing the CloudFormation Stack creation.
You will need to be logged in to the AWS console with your IAM user in a separate tab or window in order to complete the CloudFormation Stack creation. Nutanix Xi Frame does not have access to your AWS credentials.
Due to the way that CloudFormation Stacks operate, the continuing orchestration of Frame resources on your AWS subscription is not tied to any particular account. The Frame platform does not rely on the IAM user that was used to associate your AWS subscription to the Frame platform, and that IAM user can be deleted or disabled at any time without disabling your integration with Frame. If you do wish to disable your integration with Frame manually, please delete the nutanix-common and nutanix-frame CloudFormation stacks, as well as the FrameGatewayWorkload and FrameWorkload IAM roles.
Add Frame BYO AWS Cloud Account Credentials¶
BYO cloud accounts can be created within one of two different contexts of Frame’s logical hierarchy (the “customer” or the “organization” tier). More information about Frame’s hierarchy concepts can be referenced here.
A BYO cloud account created at the “customer” (highest) tier will be accessible to all hierarchical children (“organizations” and their accounts). If you choose to add the BYO cloud account at the “organization” tier, the BYO cloud account will only be available to the chosen organization and any accounts underneath it.
A particular AWS subscription can only be associated with a single entity on the Frame platform. If you associate your AWS subscription to one Organization, it cannot be associated with another Organization or Customer. If your use case requires that multiple Organizations will have access to your AWS subscription, you must associate the cloud account to your Customer entity.
Once the BYO account is created and accessible, any accounts created from that point forward will have the new BYO account available as an option for the platform. “Organization” admins are authorized to create a new organization with BYO AWS credentials or add BYO credentials to an existing organization. “Customer” admins have the same authorizations as “organization” admins, as well as the authorization to add BYO credentials to existing customers.
Go to the Frame Admin view.
Navigate to the “Organizations” or “Customers” section (depending on where you wish to add the cloud account).
Click on the ellipsis listed next to the organization or customer you wish to add your cloud account to, click “Cloud Accounts.”
Click the “Add Cloud Account” button on the top-right:
A new window will appear prompting you for the following information:
- Cloud provider: Select the AWS icon.
- Cloud account ID: Enter your AWS Account ID (without dashes) in this field.
- Name: Enter the desired name of your cloud service.
Once you have entered the information, click the “Prepare the account with Common AWS CloudFormation” button.
- At this point, your browser will be redirected to the AWS console in a new tab. If you are not logged in to AWS with the desired BYO AWS account, you will be prompted for credentials.
- Make sure you are logged in with the correct AWS account you wish to use (if you have multiple AWS accounts).
- The first page you will be taken to is the CloudFormation Stack Quick Stack Creation page. All information should be automatically filled out for you. Simply scroll to the bottom and check the box to allow CloudFormation to create IAM resources for you, then click “Create stack”
The AWS CloudFormation template will create an IAM role that allows Frame to securely orchestrate workloads in your AWS account.
- Once the above process is complete, you will be directed to a page which lists the events for this CloudFormation Stack. The creation process will proceed automatically. You may need to refresh the page to see new events. Once an event appears named “nutanix-common” and is marked as status “CREATE_COMPLETE”, the stack creation has completed. This typically takes less than two minutes.
- Once the stack has been created, navigate back to your Frame tab and select “Verify Cloud account Setup.”
- You should be informed that the cloud account setup has been verified. There will be a small text response below the “Verify Cloud Account Setup” stating “Cloud account setup is verified”. This will indicate everything is working properly.
- Next, toggle the “Frame” slider under “Configure cloud account types” in the “Add new cloud account” dialog. Another button to prepare the account with Frame AWS CloudFormation will appear. Click it and repeat the above steps.
- Once the Frame CloudFormation Stack has been created, select the datacenters that you wish to configure for use with Frame and check the box at the bottom informing you of possible resource usage on your AWS cloud infrastructure. CLick “Create.”
If you create non-Frame related virtual machines in your AWS VPC or Azure VNET that is being managed by Frame, those virtual machines may be identified as potentially orphaned resources by Frame and deleted. We do not support the use of non-Frame resources in a Frame-managed VPC/VNET.
Support for Pre-configured VPCs¶
The Frame Platform allows the addition of workload instances to your existing AWS VPCs when adding a new Frame account. This supports organizations with stricter security policies that prevent Frame from creating VPCs automatically and who wish to have more granular control over the life cycle of their AWS VPCs.
Adding workload instances to an existing VPC is simple. When you are creating a new account as an Organization or Customer admin, you will see a checkbox entitled “Customize VPC settings” at the bottom of the account configuration page. Click the checkbox, select the blue “Enter Private VPC ID” link, and enter the VPC ID of your existing VPC.
This is an Early Access Feature.
AWS Service Limits¶
By default, a newly created AWS account will impose certain service limits on available resources. Depending on the size of the Frame workload required, you will likely need to adjust the default limits imposed on the AWS account. If these limits are set to values that are lower than what is required by the Frame platform, you can expect certain functions to either fail, or be substantially delayed. The requirements by Frame for these service limits depends on the desired workload and required resources. The recommended service limit increases include the following:
To modify service limits on your AWS account, you will need to click on the “Limits” link in the navigation panel on the left of the AWS console (pictured below):
Service Limits Tips¶
- If possible, group your service limit increases by geographic region. Each geographic region has its own approval team. A limit increase across multiple regions can take 6-8 weeks.
- Approval time can vary by the size of the request. For instance, two or three small service limit increase requests are generally approved more quickly than one large request.
- Since capacity is limited, increasing service limits on GPU-backed instances generally takes longer than general purpose limit increases.
- T2 instance limit increase requests are usually approved and implemented within 24 hours of the request. G2/G3 instance limit increases take longer (especially for larger quantities).
More information about AWS service limits can be found in their official documentation.
AWS Instance Types¶
Each IaaS provider has a unique naming scheme for their instance types. AWS categorizes their “Elastic Cloud Compute instances” (a.k.a. “EC2 instances”) based on performance optimization. More information about Amazon EC2 instances can be found in their official AWS documentation. The table below shows available instance types on Xi Frame and their specifications.
What Resources are Created by Xi Frame during BYO AWS Setup?¶
The Xi Frame platform will immediately provision a VPC with an Internet Gateway and a default 10.0.0.0/16 CIDR block (this can be changed by the administrator with VPC CIDR feature). Multiple subnets are then created within the VPC that utilize the usable availability zones. Xi Frame will also create AWS security groups for the workloads that allow the Frame Gateway servers to connect into the workloads. S3 buckets will be created for workloads to store various assets and user settings. EBS snapshots are created in each selected datacenter as a part of the publishing process and Lambda services are used to consume event-based triggers.