Documentation
System StatusPortal Login

AWS accounts

Suggest Edits

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.

Account Defaults

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).

AWS Identity and Access Management (IAM):

  • 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.

AWS Simple Storage Service (S3):

  • 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.

AWS CloudTrail:

  • 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.

AWS Config:

  • 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.

AWS Simple Notification Service (SNS):

  • 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.

RISK Events:

  • 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.

Transferring existing AWS Master Payers and linked accounts to Rackspace

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.

📘

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.

📘

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.

Minimum account requirements

For you to transition an existing AWS account to Rackspace, it must meet our minimum account requirements, which include the following criteria:

Make sure your account meets these mandatory requirements before you transition the account to Rackspace.

Offboarding

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.

This section provides a high-level overview of the process that the Rackspace Process Engineering team follows when offboarding an AWS account from Rackspace. Rackspace employees refer to this as our Reverse Assumption process. This process is subject to change without notice, but you can always ask your Rackspace Account Manager to provide you with the most recent process guide at any time during your agreement with Rackspace.

📘
  • Account Reverse Assumptions time to process is dependent upon the required termination notice from Customers contract.

  • Customer must be current with account balance before we transfer ownership.
  • For dedicated master payer account transfers, the master payer account CANNOT be handed over until after the 15th of the month. This is a hard requirement, and no exceptions can be made since it is for the finalization of billing services.
  • There is no downtime for the customer during the Reverse Assumption Process.

Reverse Assumption Steps

  1. Customer initiates request in Customer Portal, which triggers a support ticket that all internal and external communication pertaining to the reverse assumption will reside in.
  2. Rackspace CSM will update ticket with requisite information needed from the customer in order to transfer their accounts, i.e., new roots emails, authorized signatory, etc.
  3. Rackspace CSM informs our process engineers who then work to schedule a date or dates (Monday – Friday during business hours) for transferring the accounts based on their availability nearest the date of the customer’s contractual termination obligation to Rackspace. Date subject to schedule availability of resources and volume of accounts being transferred.
  4. A Consent to Assignment (CTA) will be generated ONLY if the account is Public Sector or if the account is operating under the Amazon Web Services India Private Limited ("AWS India") (formerly known as Amazon Internet Services Private Limited). A Consent to Assignment will require signatures from both Rackspace and the customer. AWS must generate the CTA for Public Sector Accounts. The Rackspace CSM will generate a CTA for any accounts operating under the Amazon Web Services India Private Limited.
  5. Prior to the Reverse Assumption date, the Process Engineers will amend customer’s billing permissions to be able to enter a credit card, Process Engineers to confirm completion. The payment method can be changed following transfer of ownership. This process is handled differently and at the end if the customer has a dedicated master payer.
  6. Day/Days of the reverse assumption, Rackspace Process Engineers will confirm before proceeding that the customer is current on all account balances with Rackspace. Customer must be current before we transfer ownership. Rackspace Process Engineers will perform all necessary tasks to delink the customer accounts from Rackspace and will notify AWS via APN case of ownership transfer. Instructions will be provided to the customer on how they can access their AWS accounts.
  7. Final Rackspace bill for infrastructure and support for time in the month accounts were under Rackspace ownership will be sent to customer on their standard billing date the month or second month, depending on invoice cycle, following the account transfer. Customer may also get a bill from AWS for that same month but only relative to the time accounts were not under Rackspace ownership.

AWS Account Changes Rackspace Makes When Transferring Accounts

  • Update account contact information.
  • Update payment method information.
  • Downgrade Enterprise Support
  • Disable MFA
  • Remove Rackspace Roles (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.)
  • Remove SNS topics.
  • Leave Organization (not applicable when keeping the organization intact)

Reverse Assumption Summary

The initial driving factor in this process is the termination language in the customer’s Rackspace agreement, followed by the responsiveness of the customer in providing needed information and taking the required actions to complete this process.

Like other support teams, these requests are then action first come, first served and if there are competing customers with a high volume of accounts seeking transfer the same day, we will schedule the nearest date we can in conjunction with the availability of our Process Engineers to accommodate our customers.

AWS root credentials and account access

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:

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.

Closing AWS Accounts

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.

Moving AWS Accounts from one Rackspace Account (DDI) to another Rackspace Account

“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 about 1 year ago