How to Delete AWS Accounts (via API)

Two ways to delete AWS accounts

In this article, we will explain how to delete AWS Accounts.

There are 2 convenient ways:

1. Using the new Organizations model, which was introduced at the end of March 2022.
   This way of deleting AWS accounts is great, since you can manage all closures of accounts directly from the AWS root account. You are not required to log into each individual member account.
2. Automating the AWS account deletion. This is possible both via the REST API and via the AWS CLI.

1. Delete AWS accounts via the user interface

To be able to close an AWS account, you will need administrator access to the so-called root account. This account hosts all of the individual member accounts (of which you will delete one).

• Go to the AWS organizations page where you can see a hierarchy of all AWS accounts in your organization. Find the AWS account that you want to delete and open it.

• In the detailed view of the AWS Account, you will find a “Close” button on the top right. Click on it.

• This will open up a form that verifies whether you really want to close the AWS account. It will also make you aware of some of the conditions that apply (more on that below)

2. Delete AWS accounts via API or CLI

For those that love automation out there, we are lucky: AWS this time also developed API and CLI methods to close accounts! Read here how this works.

CLI

The process for the AWS CLI is quite trivial. Grab the 12-numbered AWS Account ID and execute the following command:

# How to use
aws organizations close-account --account-id <value>

# Example
aws organizations close-account --account-id 123456789012

Learn more about this CLI command in the AWS CLI documentation.

API

Using the AWS API is also an option. AWS introduced a new CloseAccount action that can be executed. You will only need the AccountId to be able to execute this quite trivial operation. Read more in their API documentation on how to use the operation exactly.

Limitations of AWS account deletion

There are some limitations to deleting AWS accounts. We will list them here for you:

• Closing an AWS account does not mean it gets deleted immediately. There is a 90 day grace period in which you have the chance to reopen it again by contacting AWS support. (AWS calls this the “Post-Closure Period”)
• After the post-closure period passes, all content in the account is automatically deleted.
• An organization can in a given month only delete 10% of all of its member accounts. If your organization e.g. has 300 accounts, this means you can close only up to 30 accounts per month. Keep this in mind when designing your cloud tenant deprovisioning process.

by Jelle den Burger

Cloud Tenant Management: What You Need to Know in 2021

This post gives an overview over important cloud tenant management concepts.

If you work as a CIO, as a Cloud Architect, in DevOps or you are just interested in the cloud tenant lifecycle and its implications, this post is for you.

We'll look at the cloud tenant, or cloud account, lifecycle from fundamental considerations, to provisioning, running workloads, and de-provisioning.

In this new guide you will learn:

• What cloud tenant management is
• Why cloud tenant management is at the core of good cloud governance
• How cloud tenant management ties in with billing, IAM and cloud security
• Best practices in structuring cloud accounts
• The resource hierarchies of AWS, Azure and GCP
• Why tagging and labeling is an essential part of cloud tenant management

Let's get started with the basics:

What is Cloud Tenant Management?

Cloud tenant management is the coordination and administration of a cloud tenant throughout its entire lifecycle to provide developers with a secure, efficient, and fitting working basis in the cloud.

We refer to a cloud tenant as an account with a cloud provider. In the case of AWS, it would be an account, Azure calls it a subscription and Google coined it GCP project. Other providers may have come up with other names but they all describe what we call a cloud tenant. Others just go with cloud account - this post covers the management of such tenants or accounts.

How Cloud Tenant Management Ties in with Cloud Governance

Thorough cloud governance is essential for enterprises and it gets more complex with the number of clouds in use and the number of projects running.

Cloud tenant or cloud account management is an integral part of cloud governance: It's important to effectively manage many cloud accounts over numerous cloud platforms.

Take Care of Cloud Tenant Management Early

Losing track of cloud accounts costs money and risks security: Enterprises embarking on their cloud journey may start with a small number of projects and accounts. But putting thought into proper cloud tenant management can save a great deal of effort in later stages when things grow and get more complex.

The Cloud Tenant Lifecycle

The lifecycle of a cloud tenant is closely related to the cloud project lifecycle, in which a tenant is configured, users are invited, resources are provisioned and at last, everything is de-provisioned again. The cloud project lifecycle is a subset of the cloud tenant lifecycle so to speak.

Resource Hierarchies for AWS, Azure and GCP

In this section, we'll describe the resource hierarchies of AWS, Azure, and GCP on a very high level. The resource hierarchy refers to the organization of resources inside a cloud platform account. The three big providers offer several levels, some of which are optional:

AWS and GCP allow for the cloud tenant (account or project) to be the highest up in the resource hierarchy. Azure requires you to have a root management group for all tenants, that can't be moved or deleted.

Azure also requires you to have at least one resource group - a level that the other two providers do not have at all.

The levels determine the inheritability of policies, how access is managed, and so on. These levels are your building blocks to map your organization to the cloud.

Best Practices for Organizational Structure in the Cloud

Mapping your organization to the cloud is a major and fundamental part of the cloud journey. In this section, we'll cover best practices to provide some guidance along the way.

Planning a consistent scheme ahead of time is important to avoid structures that occlude what is actually going on further down the road.

A best practice we see in the industry and with our customers is creating cloud accounts according to the environments an application should run in. Commonly that means three cloud accounts for one application: One for development, one for staging/QA, and one cloud account for the production environment.

Keep in mind, that for every new cloud account this can mean management overhead piling up - depending on the maturity of your cloud governance capabilities. We'll get to that later.

Flat hierarchies reduce complexity and avoid vendor lock-in to a single cloud service provider.

From our as well as from a best practice point of view your organizational structure should be modeled after your use cases or IT products instead of aligning it to your departments or organizational hierarchy.

Looking at you cloud organization from three different angles:

• How you want your teams to work?
• How you want your IT products managed?
• and from the life cycle perspective

This clearly shows why modeling your organizational structure after IT products or use cases is meaningful:

1. Start with how you want your team to work on IT products or use cases. "The right person for the right job" describes pretty nicely what you want, and to gather a team of specialists you may need employees from the different departments as most goals can be only achieved if various departments work cooperatively.
2. How do you want IT products to be managed? Avoiding bottlenecks and enable teams to self-organize and drive innovation! This means you want to have a self-service approach for each IT product so that the team can be self-sovereign to some degree i.e. having their own DevOps team, rights and role structure, chargeback, and metadata.
3. Everything changes and the organizational structure model should be robust against these changes. Responsibilities of departments for IT products change overtime or IT products move between departments, or maybe the departments themselves will be reorganized. These events would require major remodeling for the organizational structure in your multi-cloud modeled after your departments.

The Importance of a Multi-Cloud-Account Strategy in the Cloud

Most enterprises need a multi-cloud strategy and within these clouds a multi-cloud-account strategy.

Having only one cloud account - or cloud-tenant - for each cloud in use brings major drawbacks that have caused serious trouble: Hackers used the chaos created by running all applications on one cloud tenant to mine cryptocurrency in Teslas AWS account.

Here are 4 risks and limitations caused by running both production and non-production services in one cloud tenant:

1. Concentration risk

2. Service limits

3. Permissions and transparency (think of the Tesla case)

4. Cost allocation (also think of Tesla)

Multi-Tenant Approach for better Security, Agility, and Transparency

The solution to avoid these unnecessary and dangerous downsides of running everything in one cloud tenant is - of course - having a cloud tenant for every production and non-production stage of your applications.

It's also a prerequisite for enabling teams to create their own cloud tenants in self-service - we'll get to that later. This approach is great for tenant isolation, innovation, and enablement. But it definitely needs a good grasp on proper cloud tenant management to keep track of every cloud tenant's lifecycle.

Cloud Account Meta Data

When creating a cloud account - a cloud tenant - metadata is required to manage the specific new cloud account and the overall number of accounts in the organization. here are some common examples of cloud tenant metadata:

• Budget
• The responsible developer
• Type of environment: development, staging or production?

Many companies gather this data over a form or a survey prior to the provisioning of the cloud account from the requesting team. Some store this important metadata in a database, an excel sheet, or simply a PowerPoint presentation.

This manual process is slow, prone to errors and manipulation. Over time the reality of a specific cloud account or all cloud tenants in the organization will differ dramatically from the static metadata: A single source of truth is missing.

Cloud Tagging needs to be consistent. Establishing authoritative sources for each tag and clarifying responsibilities for keeping the tag value up to date is essential.

Metadata to cloud tenants needs to be integrated - meshStack serves as a metadata layer for many of our customers.

Tagging and Labeling Your Cloud Accounts

One way of integrating metadata to a cloud tenant is using tags (Azure and AWS) and labels (GCP). Tagging or labeling cloud tenants increases transparency within the organization:

One central advantage of using the cloud is rapid scalability. And with this comes the necessity to keep track of what is going on in your cloud infrastructure while it is constantly growing and changing. That's where tags come in: You will need a consistent set of tags to apply globally across all of your resources following a consistent set of rules. Tagging is the cornerstone to effective cloud governance: Cost allocation, reporting, chargeback and showback, cost optimization, compliance, and security - all these aspects can only be managed with proper tagging in place.

Everything can be put into this mnemonic: Tag early, tag often.

We've been talking about how tagging is essential and coming up with a cloud tagging strategy should be an early stage step in setting up your cloud governance.

Here are the most common use cases to show you why:

1. Cloud Cost Management
Gain transparency when it comes to cloud usage and costs: Tagging cost centers, business units, and specific purposes help you keep track.

2. Cloud Access Management
Proper tagging enables administrators to control the access of users or user groups to resources or services.

3. Cloud Security Management
Tags are essential to identify sensitive cloud tenants and keeping them secure. Cloud tenant tagging is a matter of compliance and should be treated as such by the central cloud team (the Cloud Foundation Team).

4. Automation
The added metadata of tags enable a whole new level of automation: Many different automation tools can read these tags and utilize them to make your life easier in almost every regard concerning the previously mentioned use cases.

Self-Service Cloud Tenant Creation

We talked about the advantages that draw enterprises to the cloud in the first place: To leverage these advantages you will need a self-service cloud tenant creation for your DevOps teams.

A DevOps team lead should be able to provision a cloud tenant and deploy applications without the interference of some kind of central IT. Offering a self-service cloud account creation requires a high degree of automation. This reduces manual workload and with that reduces the "time-to-cloud" for the developers.

The user interface for that has to be easy to use to enable as many users as possible to provision their own cloud tenants.

Automate Tenant Configuration

Automating the cloud tenant creation and enabling users to do so in self-service can only be the first step. Automating the tenant configuration has to follow to keep a consistent level of cloud security, compliance, and transparency throughout all company cloud accounts and across cloud providers.

Depending on if the newly created cloud account is for development, QA or production - as an example - different configurations and policies should automatically apply. An Azure subscription for production gets a different set of tags and a specific blueprint than let's say an AWS account that's used for staging and is automatically configured with the according landing zone.

The cloud service provider offers their own tooling and support for third-party tools to automate the cloud tenant configuration. AWS has its AWS Vending Machine and GCP provides the Google Project Factory to work with terraform configuration files. The same is possible with Microsoft Azure.

To learn more about the meshcloud platform, please get in touch with our sales team or book a demo with one of our product experts. We're looking forward to get in touch with you.

by Wulf Schiemann