ここまで請求書の読み方を続けて書いてきました。SPとRIを請求書だけで見分ける方法、リセラー割引が掛かる分母、そしてRI/SPの割引共有をマルチアカウントで確認する7項目。

最後の記事と本記事は同じ「移管」を扱いますが、層が違います。 あちらは請求の層で、請求のまとまりを変えると割引の効き方がどう変わるかという話でした。本記事は移行の層で、アカウントそのものを作り直すとき、発注の前に誰が何を決めるのかという話です。

なぜ先に書くのか

移行は、契約してから相談する項目ではありません。決めるべきことの多くが発注前にしか決められないからです。

後から出てくると困る、という理由もあります。「請求だけ切り替わる」と思って進めた話が、途中で「アカウントを作り直す」に変わると、検討自体がやり直しになります。だから最初に開示します。

前提: 既存アカウントのIDは、後から付け替えられない

AWSのアカウントIDは、アカウントを一意に識別する12桁の識別子です。AWSの公式ドキュメントは、アカウントの識別子としてこれを定義していますが、既存アカウントのIDを変更する手段は記載されていません2。

ここから重要な帰結が出ます。

「IDが変わる」＝「新しいアカウントを作る」＝「ワークロードを移行する」

この3つは選択肢ではなく、同じ一つの事実の言い換えです。順番に起きるのでもありません。新しいアカウントを作った結果としてIDが変わり、新しいアカウントには中身が無いので移行が要る、というだけです。

販売事業者が「IDが変わる方式」と呼んでいるのは、この「新しいアカウントを作る」ことです。既存のアカウントのIDが、別の値に書き換わるという意味ではありません。

したがって、「作り直しは不要だが、IDは変わる」という説明は成立しません。 もしそう説明されたら、どちらが本当なのかを確認してください。

移行は「オプション」ではなく導入条件

私たちがAWSでご提供しているのは、新しいアカウントを作る方式のみです。

つまり移行は、選べるオプションではありません。導入の条件です。 「移行なしで割引だけ適用する」形はお出ししていません。ここを曖昧にしたまま見積の話に進むと、後段で必ず戻ることになります。

Google Cloudは仕組みが別系統です。ここは正確に書きます。プロジェクトの請求先アカウントを変更する操作そのものは、Google Cloudに公式に用意されています（変更元と変更先の両方の請求先アカウントに対する権限が必要です）。つまり「請求先だけを差し替える」形が、プラットフォームとして存在しないわけではありません。

そのうえで、私たちがお出しする形では、既存の請求先に紐づいていたプロジェクトはそのままではお引き受けできず、新しいプロジェクトの作成とデータ移行が必要になります。 これはGoogle Cloudの仕様ではなく、販売事業者側の受け入れ要件によるものです。**「技術的に不可能だから」ではなく「私たちの提供形態がそうだから」**であり、混同しないようご案内しています。

クラウドによって事情は違うものの、私たちがお出しする形に「請求だけが切り替わって環境は一切動かない」ものは無いという点は共通しています。

何が「作り直し」の範囲に入るのか

対象になるのは、アカウントIDを参照しているものと、アカウント単位で発行・蓄積されるものです。性質ごとに分けると、棚卸しの担当を割り振りやすくなります。

性質何が該当するか誰が把握しているか
IDを名指ししているIAMロールの信頼関係、リソースベースのポリシー（バケットポリシー、キーポリシーなど）インフラ担当。外部に渡した設定は社外にしか無いことがある
アカウント単位で発行されるサービス上限の緩和申請、Marketplaceのサブスクリプション、サポートプランの契約申請した人。担当者が異動していると辿れないことがある
アカウントをまたいで移せないKMSのカスタマー管理キー（鍵ARNにアカウントIDが含まれ、鍵を別アカウントへ移す操作は無い。鍵ポリシーで使わせることはできる）セキュリティ担当。再暗号化の要否は設計次第
譲渡の仕組みが無いコミットReserved Instances、Savings Plans購入した部門。満了日が移行時期を決める

この表で一番厄介なのは、右列が社外を指す行です。 監視SaaS、CI/CD、取引先との連携などに自社のアカウントIDを登録している場合、その一覧は自社の構成管理には載っていないことがあります。ここは技術の問題ではなく、誰が把握しているかの問題です。

「同じ名前で作り直せば戻る」ではありません

表の1行目（IDを名指ししているもの）について、実務でよく誤解される点をひとつ補足します。IAMロールの信頼ポリシーにロールやユーザーのARNを書くと、保存時にAWS側でそれがユニークなプリンシパルIDに変換されます。 元のロールやユーザーを削除すると、同じ名前で作り直してもIDが一致しないため、信頼関係は復活しません。公式ドキュメントは「ポリシーはもう適用されない」と明記し、ポリシー側を書き直す必要があるとしています。

つまり「同じ名前で同じ設計を組み直せば元に戻る」という前提は成り立ちません。そして相手側の設定が社外にあるなら、書き直しは社外にお願いすることになります。 2番目の決定事項で「誰が洗い出すか」を先に決めるのは、このためです。

RI/SPは「満了まで残る」前提で時期を組む

RI/SPについては前回の記事で詳しく書きました。移行の観点では次の3点です。

別のアカウントへ譲渡する仕組みは、公式に用意されていません。 割引の共有はAWS Organizationsの同じ組織の中で成立するもので、移管で請求のまとまりが変わると、旧アカウントのコミットが新アカウントの利用をカバーする形にはなりません。

Savings Plansは期間中に解約できません。 公式ドキュメントに明記されています。

Reserved Instancesの「売却」には道がありますが、条件は重いです。 「コミットは動かせない」と単純化されがちな部分なので、正確に書きます。EC2のStandard RI（リージョン／ゾーン）に限り、Reserved Instance Marketplaceで売却できます。ただし売り手登録はルートユーザーしか行えず、受け取りには米国所在の銀行口座が必要です。残存1ヶ月以上・保有30日以上といった条件もあります。Convertible RIは売却できず（交換は可能）、RDSやElastiCacheなど他サービスのRIも対象外です。日本の事業会社が移行の都合でこの経路を使えるとは限らないので、計画に織り込むなら先に可否を確かめてください。

結果として実務では、満了まで残る前提で時期を組むことになります。ここが移行時期を決める最大の要因です。

継続できるもの

作り直しの話ばかり書きましたが、変わらないものもあります。

  • SSO（AWS IAM Identity Center）は継続してご利用いただけます。 移行の作業にあわせて、新しいアカウントで引き続き使えるよう設定の引き継ぎを行います。ただし「どの方式で引き継ぐか」は環境ごとに変わります（次項）
  • 最上位権限（root）はお客様に帰属します。 移行後も変わりません
  • データの所在（利用しているリージョン）は変わりません
  • 設計・構成は踏襲して再構築します。 作り直すのは器であって、設計そのものではありません

ひとつ補足します。「踏襲して再構築する」は「そのまま持っていける」ではありません。データやリソースには移行の作業が要ります。 同じ設計を新しいアカウントの上に組み直す、という意味です。

SSOについて、公式仕様として押さえておくべきこと

「継続して使える」と「今と同じ形で使える」は別です。IAM Identity Centerには組織インスタンスとアカウントインスタンスの2種類があり、公式ドキュメントは次のように区別しています。

  • 組織インスタンスは、AWS Organizationsの管理アカウントで有効化するものです。IAM Identity Centerのすべての機能が使えます
  • アカウントインスタンスは、有効化した単一のAWSアカウントに紐づきます。 メンバーアカウントでも有効化できますが、公式の機能比較表では**複数アカウントの権限管理・AWSアカウントへのアクセスポータル・SAML 2.0の顧客管理アプリケーション・委任管理者による管理・追加リージョンへの複製が、いずれも「いいえ」**になっています

したがって、現在どちらの形でお使いかによって、引き継ぎの設計はまったく違うものになります。特に複数のAWSアカウントを1つのIdentity Centerでまとめて管理している場合は、その形をどう再現するかが個別の設計事項です。「使えます」の一言で片付く話ではないため、発注前の確認項目に入れてください。

発注前に決める6項目

手順ではなく、決定事項として並べます。順番にも意味があります。1が決まらないと他が動きません。

1. 移行の時期を、コミットの満了日から決める RI/SPの満了日がいつかを先に確認します。満了前に動かすなら、対象を旧アカウントに残す段階移行しか成立しません。切り出せる系統があるかは構成によります。決めるのは財務とインフラの両方です。

ここで見落とされやすい仕様がひとつあります。公式ドキュメントに 「Savings Plansを保有するアカウントが組織を離脱すると、そのSavings Plansは一括請求に適用されなくなる」 と明記されています。段階移行でSPを買ったアカウントのほうを先に動かすと、旧側に残したアカウントがSPの恩恵を失います。加えて共有は購入側と受け取り側の両方で有効になっている必要があるため、「どのアカウントがコミットを持っているか」を満了日と一緒に洗い出してください。動かす順序が費用に直結します。

なお、アカウントを組織から外すと、在籍期間のコスト・使用状況データをそのアカウントからは参照できなくなります（組織の管理アカウント側では引き続き参照できます）。過去分析を自社で持ち続けたい場合は、移行前に手元へ書き出しておく判断が要ります。

2. IDを参照している箇所を、誰が洗い出すか 上の表の右列を埋める作業です。社外に渡した分を誰が追うかをここで決めておかないと、切替の直前に出てきます。

3. ID基盤をどう引き継ぐか 現在SSOで統合しているのか、アカウントごとに個別のIAMユーザーなのかで、引き継ぎの設計が変わります。IAM Identity Centerをお使いなら、それが組織インスタンスかアカウントインスタンスかまで確認してください。上に書いたとおり、両者でできることが違います。複数の事業部が同じIDでログインしている場合は、影響範囲の確認が先に要ります。

4. 権限設計を誰が作り直すか 設計は踏襲できますが、組み直す人は要ります。 自社で持つのか、移行支援に含めるのかを決めます。

5. アカウント単位の再取得を誰が担当するか 上限緩和、Marketplace、サポートプラン。それぞれ申請元が違うことが多く、担当が決まっていないと最後まで残ります。

6. 切替時の停止をどこまで許容し、誰が承認するか 許容できる停止時間は、事業側が決める話です。技術的にどこまで短くできるかは構成によって変わるので、先に許容ラインを持っておくほうが検討が早く進みます。

決めたあとは、どう進むのか

ここまでは決定事項の話でした。決めたあとに実際どう動くのかも、一般的な流れとして書いておきます。所要期間も作業量も構成によって大きく変わるので、ここでは順序と、どこで詰まりやすいかだけです。

1. 移行先のアカウントを用意する 新しい組織の下に新しいアカウントを発行します。ネットワークと権限の器を先に作り、そこへ載せていく形になります。

2. 移すものを2つに仕分ける 実務ではまずここで分かれます。

種別該当するもの移し方の性質
ステートレスコンテナ、関数、状態を持たないサーバー作り直して再デプロイする。 IaCやCIが整っていれば、パイプラインの向き先を変える作業に近くなります
ステートフルデータベース、キャッシュ、検索、オブジェクトストレージデータそのものを運ぶ。 所要時間はデータ量と、許容できる停止の幅で決まります

「移行にどれくらいかかるか」は、ほぼ後者の量で決まります。

3. データを渡す仕組みは、公式に用意されている アカウントをまたいでデータを渡す経路は、主要なサービスには公式にあります。ゼロから吸い出して入れ直すわけではありません。

  • RDS — 手動スナップショットを他のAWSアカウントに共有できます。共有先はそこからコピーでき、暗号化していないものは直接リストアもできます（暗号化済みのものは共有された状態から直接リストアできず、コピーを作ってからになります）。共有先は最大20アカウントです
  • S3 — レプリケーションの複製先バケットは、同じアカウントでも別アカウントでも構いません。別アカウントの場合、複製先のバケットポリシーで複製元に複製の許可を出す必要があります
  • EC2 — AMIを特定のAWSアカウントに共有できます。AMIはリージョン単位の資源なので、別リージョンで使うにはコピーしてから共有します

そして3つとも、同じところで引っかかります。暗号化です。

  • RDSは、AWSのデフォルトKMSキーで暗号化したスナップショットは共有できません
  • S3は、SSE-KMSで暗号化したオブジェクトを別アカウントへ複製する場合、鍵の所有者が複製元に鍵の使用を許可する必要があります
  • EC2も、デフォルトのAWSマネージドキーで暗号化されたスナップショットに紐づくAMIは共有できません。カスタマー管理キーであれば、その鍵の使用を相手に許可したうえで共有します

前の表で「アカウントをまたいで移せないもの」としてKMSのカスタマー管理キーを挙げました。ここに繋がります。鍵そのものは移せませんが、鍵で守られたデータを渡す経路はあり、そのために鍵の使用許可を出す作業が要る、という関係です。既定の暗号化設定のまま運用してきた場合、この段になって初めてカスタマー管理キーへの切り替えが要ると分かることがあります。 棚卸しの段階で暗号化の方式まで見ておくと、ここで止まりません。

4. 新旧が並走する期間がある 切替の当日まで、旧環境は動いたままです。その間は両方に課金されます。 期間の長さは移行の設計によりますが、費用として見込んでおく項目です。

5. 切り替える DNSやエンドポイントの向き先を新環境へ変えます。ここが、6番目の決定事項で決めた停止の枠に当たります。

6. 旧環境を閉じる 旧アカウントを組織から外す、または閉じる作業です。ひとつ順序があります。前述のとおり、アカウントを組織から外すと、在籍期間のコスト・使用状況データをそのアカウントからは参照できなくなります。 過去の分析を自社で持ち続けたい場合は、閉じる前に書き出します。

公式に確認できたこと／明記が見つからなかったこと

前回と同じく、この2つを分けて書きます。初稿で「確認できていない」としていた項目のうち2件は、公式ドキュメントに記述がありました。

確認できたこと

  • Marketplaceのサブスクリプションは、同じ組織の中でなら共有できます。 AWS License Managerのグラント経由で、組織・OU・個別アカウントに使用権を配れます。ただし共有できるのはAMI・コンテナ・機械学習・データ製品・Oracle Database@AWSの各サブスクリプションに限られ、受け取った側（Entitlementレベル）はさらに他へ配れません。 そして組織の外のアカウントへ譲渡する仕組みはありません。 移行先が別の組織になるなら、原則として再購入の検討が要ります
  • 技術サポートの起票先は、公式に区分があります。 AWSのドキュメントは Resold Support（販売事業者経由のサポート）について「請求に関する問題はAWSパートナーに直接連絡してください。AWS Supportは Resold Support の請求やアカウント管理といった技術以外の問題には対応できません」としています。私たちがお引き受けするのは請求・契約・移行に関する日本語サポートの窓口で、技術サポートそのものはAWSのサポートプランとして提供されるものです。この分担は当社独自の運用ではなく、公式に線が引かれています
  • サポートプランはアカウント単位です。 組織全体をまとめて購読することもできますが、その場合でも組織を離脱したアカウントはBasicに落ちます。移行後に同じ内容が要るなら、新しいアカウントで取り直す前提で見てください

明記が見つからなかったこと

  • サポートケースの履歴が新しいアカウントに引き継がれない点について、明示的な公式記述は確認できていません。サポートプランとケース作成がアカウント単位であることからの推定です
  • SaaS型など、上に挙げた5種類以外のMarketplace製品の扱いは、共有可能な製品タイプの一覧に挙がっていないというだけで、「できない」と明記されているわけではありません。個別にご確認ください
  • IAM Identity Centerを具体的にどう引き継ぐかは、環境ごとの個別設計です。インスタンス種別ごとの機能差は上に書いたとおり公式に確認できていますが、お客様の構成に対する最適な引き継ぎ方は、現状を見てからでないと決まりません

まとめ

  • AWSの既存アカウントのIDは、後から付け替えられない。だからこそ「IDが変わる」「新しいアカウントを作る」「ワークロードを移行する」は同じ事実の言い換えになり、切り離せない
  • したがって移行はオプションではなく導入条件。「作り直しは不要だがIDは変わる」という説明は成立しない
  • 作り直しの対象は、IDを名指ししているもの／アカウント単位で発行されるもの／アカウントをまたいで移せないもの／譲渡の仕組みが無いコミットの4種類
  • 一番追いにくいのは社外に登録したアカウントID。技術ではなく「誰が把握しているか」の問題
  • 同じ名前で作り直しても信頼関係は戻らない。 信頼ポリシーのARNはユニークなプリンシパルIDに変換されるため、削除するとポリシー側の書き直しが要る
  • RI/SPの満了日が移行時期を決める。 別アカウントへの譲渡の仕組みは無く、SPは期間中解約できない。EC2のStandard RIだけは売却の道があるが、ルートユーザーでの登録と米国所在の銀行口座が要る
  • SPを保有するアカウントが組織を離脱すると、一括請求へのSP適用が止まる。 段階移行では動かす順序が費用に直結する
  • SSOは継続してご利用いただける。 ただしIAM Identity Centerは組織インスタンスとアカウントインスタンスでできることが公式に違う。引き継ぎの構成は環境ごとの個別設計
  • 最上位権限はお客様に帰属し、データの所在も変わらない。 設計は踏襲するが、データには移行作業が要る
  • Google Cloudの「新しいプロジェクトが必要」は、プラットフォームの制約ではなく提供形態によるもの。 請求先アカウントの変更操作自体は公式に存在する
  • アカウントをまたいでデータを渡す経路は公式にある。詰まるのは暗号化。 RDS・EC2はAWSマネージドのデフォルトキーで暗号化していると共有そのものができず、S3はSSE-KMSの鍵所有者が使用を許可する必要がある
  • 新旧が並走する期間は両方に課金される。 移行の費用として見込んでおく

CloudCutの見方

私たちはAWS / Google Cloudの請求代行を通じた最大20%の削減1をご提供していますが、この記事は割引率の話ではありません。その前に決めておく必要があることの話です。

移行が導入条件である以上、率が合っていても時期が合わなければ進みません。そのためご相談をいただいた際は、率の試算より先にコミットの満了日とアカウントIDがどこまで外に出ているかを伺っています。この2つで、実際に動ける時期がほぼ決まります。

「今のところ切り替えるかは未定だが、動くとしたら何が作り直しになるのか把握しておきたい」というご相談だけでも承っています。お見積りとは切り離してお出しできます。

ご相談はこちらから。

出典（2026年8月13日確認）

本記事の仕様に関する記述は、次の公式ドキュメントで確認しています。**「決めたあとは、どう進むのか」で参照した3件のみ、2026年8月28日の確認です。**サービスの仕様・条件・サポートプランの区分は変わります。 実際に発注を判断される前には、確認日以降の更新をご自身でもご確認ください。

AWS — アカウントとIAM

AWS — コミットとサポート

AWS — Identity CenterとMarketplace

AWS — アカウントをまたぐデータの受け渡し（2026年8月28日確認）

  • Sharing a DB snapshot for Amazon RDS — 手動スナップショットを他のAWSアカウントへ共有できる旨、共有先は最大20アカウントである旨、共有かつ暗号化済みのスナップショットからは直接リストアできずコピーが要る旨、デフォルトのKMSキーで暗号化したスナップショットは共有できない旨
  • Configuring replication for buckets in different accounts — 複製先バケットが別アカウントでもよい旨、複製先のバケットポリシーで複製元に許可を出す必要がある旨、SSE-KMSの場合に鍵の所有者が複製元へ使用を許可する必要がある旨
  • Share an AMI with specific AWS accounts — 特定のAWSアカウントへAMIを共有できる旨、デフォルトのAWSマネージドキーで暗号化されたスナップショットに紐づくAMIは共有できない旨、暗号化済みの場合は鍵の使用許可が要る旨、AMIがリージョン単位の資源である旨

Google Cloud

なお cloud.google.com の各ページは docs.cloud.google.com へ転送されます。