This document outlines the process to migrate an AWS account from one organization to another.
The EOS Network Foundation (ENF) Automation team had the foresight to create all cloud infrastructure in granular Amazon Web Services (AWS) accounts, one for each system or environment, making this process as straightforward as possible!
Contents
|
The existing ENF AWS account architecture looks like this.
---
title: AWS Account Architecture
---
flowchart LR
subgraph enf["`☁️ **ENF AWS**`"]
subgraph mgmt["`🏛️ **Management Account**`"]
direction LR
reports["📊 Cost Reports"]
billing["💲 Consolidated Billing"]
policy["📜 Organization Policy"]
org["🏢 Organization"]
billing -.-> reports
billing -.- org
org -.- policy
end
chickens["🐓 chickens-prod Account<br/><br/>Replay Testing"]
devhub["📚 devhub Account<br/><br/>Learn Portal"]
docs["📑 docs-prod Account<br/><br/>Docs Portal"]
mainnet["⛓️ evm-mainnet Account<br/><br/>EVM Mainnet Endpoints"]
testnet["🛠️ evm-testnet Account<br/><br/>EVM Testnet Endpoints"]
end
org ===> chickens
org ===> devhub
org ===> docs
org ===> mainnet
org ===> testnet
Each child account is a "member" of the management account's "organization". The organization policy in the management account enforces consolidated billing, and prevents child accounts from leaving the organization.
Each EVM account looks like this.
---
title: EVM Account Architecture
---
flowchart TB
subgraph evm["`🛠️ **evm Account**`"]
direction TB
subgraph policy["`📜 **Policy**`"]
direction TB
security["🔒 Security"]
iam["📋 IAM"]
groups["👥 Groups"]
users["👤 Users"]
security -.- iam
iam ---> groups
users ---> groups
end
subgraph resources["`🏗️ **Resources**`"]
direction LR
dns["📑 DNS"]
cdn["🌐 CDN"]
waf["🔥 WAF"]
lb["🔀 Load Balancers"]
vm["🖥️ VMs"]
db["🛢️ Databases"]
metrics["📈 Metrics"]
notifications["📲 Notifications"]
dns -.-> cdn
cdn <--> waf
waf <--> lb
lb <--> vm
vm <--> db
dns -.-> metrics
cdn -.-> metrics
waf -.-> metrics
lb -.-> metrics
vm -.-> metrics
metrics ---> notifications
end
groups ---> resources
end
internet((🌐))
subgraph org["`**ENF Management Account**`"]
enf((🏛️))
end
internet -.-> dns
internet <==> cdn
internet ~~~ evm
internet ~~~ iam
notifications ---> internet
enf -.-> |DNS| internet
resources ---> |💲 Billing| enf
enf ===x |Ownership| evm
You can see each account is isolated with its own security policy, IAM, users, groups, and resources. DNS is delegated using public DNS infrastructure, not Route53 IAM, so DNS will continue to work during and after a migration.
There are a few prerequisites to consider before migrating an AWS account.
The EOS Network Foundation (ENF) will need to do the following.
- Determine who will perform the migration, presumably the Automation team.
- Grant that user permissions to remove accounts from the organization.
- Remove email and SMS subscribers from the notification system in the accounts to be migrated, to protect their personal information.
The counterparty will need to do the following.
- Create an AWS account to serve as the management account, if they do not already have one.
- Setup billing.
- Create an AWS organization in that account.
- Ensure consolidated billing is on.
- Create an organization policy that prevents child accounts from leaving the organization (optional).
- Obtain a credit card to attach to the child accounts during the migration.
Important
AWS requires a credit card to be attached to an account to remove it from an organization.
Once the prerequisites are met, the migration process will look like this.
sequenceDiagram
actor enf as ENF
participant enfAWS as ENF<br/>Management<br/>Account
participant acct as AWS<br/>Child<br/>Account
participant labsAWS as Counterparty<br/>Management<br/>Account
actor labs as Counterparty
labs -->> enf: Provide Credit Card Info
rect rgb(62, 101, 194)
enf ->> acct: Add Credit Card to Billing Info
acct ->> enfAWS: Remove Account from Organization
end
note over acct: Orphaned<br/>Account
enf -->> labs: Transfer Root User Access
rect rgb(253, 1, 193)
labsAWS ->> acct: Invite Account to Organization
acct ->> labsAWS: Accept Invitation
end
This process must be repeated for each account to be migrated.
The accounts will be migrated in this order:
- Migrate a test account (optional).
- Migrate
evm-testnet
. - Migrate
evm-mainnet
.
Once all accounts have been migrated, stakeholders may wish to do the following.
- Remove the credit card used for the migration from child account billing information.
- Audit the IAM users with access to the child accounts.
- Migrate DNS from
*.evm.eosnetwork.com
to*.evm.example.com
. - Add new email and SMS notification subscribers to the child accounts.
- Create a new Telegram bot controlled by the counterparty, and remove the old one controlled by the ENF.
Internal resources.
- ./Development Process ⤴
- ../Engineering ⤴⤴
- engineering issue 84 - Organizational Migration of EVM Infrastructure
- EOS-EVM Documentation
- Cloud Architecture
- eos-evm-internal - internal-facing documentation of a sensitive nature.
- Runbooks
- Notification System
External resources.
- AWS Documentation
- AWS re:Post guide - How do I move an account from an existing AWS Organization to another AWS Organization?
- Blog - AWS Organizations, moving an organization member account to another organization: Part 1
- Blog - Migrating accounts between AWS Organizations with consolidated billing to all features
- Docs - Migrate an AWS member account from AWS Organizations to AWS Control Tower
- GitHub aws-account-migration-example
- Medium
Legal Notice
This document was created in collaboration with a large language model, machine learning algorithm, or weak artificial intelligence (AI). This notice is required in some countries.