Each Rackspace account can house one or more AWS accounts. By default, you can create up to five new AWS accounts through the Rackspace Technology Customer Portal. If you need more than five accounts, open a ticket to request a limit increase. In addition to creating new AWS accounts, you can also transfer existing AWS accounts to Rackspace for management.
Each AWS account provides a top-level administrative control boundary for the resources that it contains. While you can leverage Amazon’s Identity and Access Management (IAM) platform to isolate certain resource access, we typically recommend provisioning an AWS account per application deployment phase (such as development, staging, and production). This provisioning allows you to assign different users in your organization access to one or more accounts without complex IAM policies. In this example, you could grant developers access to provision EC2 instances, RDS databases, and so on in your development and staging accounts and restrict them to read access for the resources in your production account.
In addition to being a strong permission boundary, AWS accounts also provide a convenient construct for tracking expenses because, by default, the system groups both AWS and Rackspace charges by AWS account and can span multiple accounts. For example, if you use four separate AWS accounts (app1-dev, app1-prod, app2-dev, and app2-prod), you can easily see how much you are spending on each application environment. We highly encourage you to use tagging for more fine-grained expense tracking within accounts. However, tagging is more complicated. You might miss tagging certain resources resulting in unallocated cost, and not all AWS resource types support tagging. AWS accounts provide a great default cost allocation construct.
Lastly, by using separate AWS accounts for each environment, you have the flexibility to select different Rackspace features for each environment because Rackspace applies service levels at the AWS account level.
As we describe later in this document, several FAWS features (such as Rackspace Logbook) are available in both cross-account and account-specific views, enabling unified visibility across multiple AWS accounts.
Based on services that you are subscribed to, we automatically apply some account defaults on AWS accounts registered with Rackspace Technology, whether created through the Rackspace Technology Customer Portal or created directly with AWS and registered with Rackspace. These account defaults, detailed below, serve multiple purposes: requirements for us to provide services to you, systematic requirements for our tooling, AWS partner requirements, as well as security best practices. Some account defaults are required, while some may be optional (but recommended).
- Set up an IAM role named Rackspace for ongoing access to the account. See AWS Identity and Access Management (IAM) for additional details.
- Set the IAM account password policy for all passwords. Passwords have the following requirements:
- Are at least 12 characters in length.
- Contain at least one uppercase character.
- Contain at least one lowercase character.
- Contain at least one number.
- Contain at least one symbol.
- Are not one of the previous 24 passwords used.
- Create an IAM role named CloudHealth-Role to enable us to provide you with CloudHealth.
- Tampering or removing this role could cause overbilling.
- Create a bucket named <account_uuid>-logs in the US West 2 (Oregon) region with the following settings:
- Enable versioning and apply an S3 bucket lifecycle policy to the <account_uuid>-logs bucket that expires files after 365 days and permanently removes deleted files after 90 days.
- Set an S3 bucket policy on the <account_uuid>-logs bucket to allow write access from CloudTrail.
- Create a bucket named rackspace-<account_uuid> in the US West 2 (Oregon) region with the following settings:
- Enable versioning and apply an S3 bucket lifecycle policy to the rackspace-<account_uuid> bucket that expires files after 365 days and permanently removes deleted files after 90 days.
- Configure AWS CloudTrail in each AWS region to log to the S3 bucket named <account_uuid>-logs.
- Configure an SNS topic named rackspace-cloudtrail in each region and subscribe it to a region-specific Shared Management Services SQS queue for use by the Rackspace Logbook service.
- Note: Our account provisioning automation does not create a new trail if one already exists or if the AWS account is managed by Control Tower.
- Create an IAM role named AWSConfig for the AWS Config service to use.
- Configure AWS Config in each AWS region to log to the S3 bucket named “<account_uuid>-logs”.
- Configure an SNS topic named “rackspace-awsconfig” in each region and subscribe it to a region-specific Shared Management Services SQS queue for use by Rackspace tooling.
- Note: Our account provisioning automation skips AWS Config deployment if a Config recorder already exists in the AWS region or if the AWS account is managed by Control Tower.
- Create SNS topics named rackspace-support, rackspace-support-standard, rackspace-support-urgent, rackspace-support-emergency in each region and subscribe it to a region-specific Shared Management Services SQS queue for use by our Rackspace Watchman service.
- Create an IAM role named rackspace-dispatcher and an IAM policy with the same name to allow us to respond to AWS Health RISK events.
- Create an Amazon EventBridge Rule named rackspace-dispatcher with a corresponding target in the US East 1 (N. Virginia) region.
While the Rackspace Technology Customer Portal enables you to provision new AWS accounts easily, you might occasionally want to transfer an existing AWS account to Rackspace for management. We also support this, and after the transfer completes, it allows Rackspace management tooling and expertise to function with your existing AWS account.
This process involves formally assigning your AWS account to Rackspace for management, which you can initiate by submitting a request in the Rackspace Technology Customer Portal.
When submitting an AWS Master Payer, notify Rackspace to ensure a smooth transition of the AWS Master Payer and linked accounts before adding them to the portal.
Click Add AWS Account at the bottom of the AWS account list. For account source, select Use an existing AWS account not currently managed by Rackspace. Include the following required information:
- AWS Master Payer(s) or Account Number(s)
- Legal Company Name
- Legal Company Address
- Authorized Signatory Name (the individual who can legally give authorization to assign your AWS account to Rackspace)
- Authorized Signatory Email Address
After receiving your request, we create a ticket for you with instructions your team must carry out to prepare the AWS account for the transition to Rackspace support. After your tem completes the instructions, Rackspace sends a request to AWS to review and approve the account assumption request. AWS confirms whether any custom legal or pricing terms exist that should transfer to Rackspace. Then, AWS approves the account assumption.
After those steps finish, Rackspace automatically applies several default settings to the account based on best practices we have developed in cooperation with AWS. For details, refer to the Account Defaults section of this product guide.
This process typically takes two to four weeks from start to finish. This partly depends on you because certain steps of the process require action on your part. Monitor your email and the Support Tickets section of the Rackspace Technology Customer Portal for tickets that require your action.
Note: Transferring an existing AWS account to Rackspace does not count against the limit of new AWS accounts you can provision through the Rackspace Technology Customer Portal.
Note: The transition process might disrupt the Reserved Instance and Savings Plan sharing between AWS accounts. For details, consult your Rackspace Onboarding Manager or Customer Success Manager.
For you to transition an existing AWS account to Rackspace, it must meet our minimum account requirements, which include the following criteria:
- No access keys exist for the root user of the AWS account.
- The account is not consolidated under a payer account or serving as a payer account with linked child accounts.
- The account cannot be a part of an AWS Organization.
Make sure your account meets these mandatory requirements before you transition the account to Rackspace.
While we hope to serve you for life, should you ever decide that you no longer require Rackspace’s management of your AWS account we can work with you to transition your account to a direct relationship with AWS. You would retain access to all AWS resources, but would lose access to Rackspace tooling such as Logbook and CloudHealth as well as Rackspace’s AWS expertise and service. If you are considering making this change, please contact your Account Manager for further assistance.
During the offboarding process, all Rackspace SNS Topics and IAM Roles will be removed, with the exception of “RackspaceDefaultEC2Role” IAM Role. This role might be used by your EC2 instances. You can keep using this role or you can remove it if it’s not used by any instances.
Rackspace requires root access of the Program Management (Payer) Account as governed by AWS requirements. There are 2 account models: SPAM (Solution Provider Account Model) and ECAM (End Customer Account Model). As outlined here, if the accounts are under the SPAM model, Rackspace will need to own the root credentials of the member (linked) accounts as well. If the accounts are under the ECAM model, the customer will own root credentials of the member (linked) accounts.
Why must Rackspace hold root credentials for AWS accounts (Payer/SPAM accounts)?
Rackspace holds the root credentials to secure AWS accounts and prevent fraudulent usage because security compromise is critical to our management of AWS accounts. AWS specifies several Identity and Access Management best practices to minimize the risk of account compromise. These include locking away the AWS account root user access keys and enabling multifactor authentication (MFA). By holding the root permission and credentials, we can enforce these best practices on AWS accounts.
Amazon requires Rackspace to use these root credentials to communicate with Amazon’s billing department to address billing issues.
We set the root user’s email address to a unique Rackspace email account. Automation creates and updates tickets in the Rackspace ticketing systems based on emails sent to that email address. This lets Rackspace Fanatical Support for AWS (FAWS) share important account updates with you through tickets.
How are my team and I impacted by not holding our AWS account root user credentials?
You can manage all access as either:
- Users within the Rackspace Technology Customer Portal
- IAM Roles for AWS resources, such as EC2 instances (see AWS Identity and Access Management)
For the specific tasks that require AWS account root user permission, a small set of FAWS Rackers can carry out the tasks.
How does Rackspace secure and store root credentials?
We store Root credentials in a secure vault and limit access to a specific set of employees. We audit this access and constrain it to only the few situations in which we need the credentials. After we update the credentials for the root user of the AWS account to a Rackspace email address, we generate a new strong password and enable multifactor authentication for the AWS account. We encrypt the new password and vault it by using AWS Key Management Service (KMS).
Rackspace tools and employees accomplish most AWS account management by using IAM roles and users.
Rackspace transfers control of these credentials to your ownership if you end the partnership with Rackspace.
Why does Rackspace require root access key deletion?
You can use access keys (an access key ID and secret access key) to make programmatic requests to AWS. Rackspace requires that you delete root access keys because using root access keys violates AWS Identity and Access Management best practices and exposes the account to the risk of security compromise. Amazon encourages the use of IAM users, groups, and roles to manage access.
How does Rackspace release root credentials?
There are two relevant scenarios: the closure of an account and a reverse assumption (customers taking ownership of accounts). If you close an account, root credentials lead to a dead end so we don’t need to destroy them.
When customers terminate management services with Rackspace, we follow a reverse assumption process. This includes changing the root user credentials to those defined by the customer.
Before Closing an Account - Things to do and considerations
Please review the product terms within your Rackspace contract to understand what notice is required before we will close an AWS account on your behalf.
Back up any resources or data that you want to keep. Transfer data from Amazon Simple Storage Service (Amazon S3) or Amazon Elastic File System (Amazon EFS) using AWS Transfer Family. Find all your active resources and terminate to stop incurring billing for the AWS services. If you purchased subscriptions with ongoing payment commitments, then you’re charged for these subscriptions until the plan term ends even after you close your account. This applies to subscriptions such as Amazon Elastic Compute Cloud (Amazon EC2) Reserved Instances (RIs) and Savings Plans.
After Closing an Account
After 90 days, any content remaining in your account will be permanently deleted, and AWS services that aren’t already terminated also will be terminated. However, service attributes might be retained as long as necessary for billing and administration purposes. AWS retains your account information as described in the Privacy Notice. You can’t permanently delete your account before 90 days. You can’t reopen the account after 90 days.
You can’t create new AWS accounts using the email address that was associated with your account at the time of its closure.
“DDI Moves” refers to the process of moving a Customer’s AWS Account, associated with a specific Rackspace Customer account number, to another Rackspace Customer account number.
Customer requests for DDI moves must be submitted at least 14 business days in advance of the designated DDI Move date. DDI Moves are performed ONLY on a quarterly basis and ONLY during designated periods to minimize impact on billing. (i.e., starting on or about the 15th of the month and ending on or about the 25th of the month). Subject to Rackspace discretion, DDI Moves requested outside the designated DDI Move window will be subject to additional Fees. DDI Moves are subject to additional terms and conditions as may be communicated to Customer via Services ticket.
If you are considering making this change, please contact your Account Manager for further assistance.
Updated 26 days ago