AWSアカウント間でのインフラリソース移行ガイド：知っておくべき基礎知識と便利なTips

お知らせ
Table of Contents

背景

2024年10月1日より、PLT Placeの運営会社が株式会社HashPortに変更されました。
Xでのお知らせ

ユーザ視点では大きな変更はなく、親会社変更に伴う利用規約が改めて表示されるという軽微なものに見えていますが、
裏ではPLT Placeを構成する全てのリソースの別のawsアカウントへの引越しがおこなわれております。

今回はその移行内容の中でも特に注意が必要な点や具体的な確認ポイントを抽象化したPLT Placeの構成とともにご紹介できればと思います。
awsリソースの別アカウント移行を検討される方々の助けになれば幸いです。

前提

下記を前提とします。

  • リソースはaws上で構成されていること
  • リソースはすべてIaC化されていること
  • ドメイン、証明書はaws上で取得し、所有権を持っていること
  • 移行前/後のawsアカウント両方にadminアクセス可能な権限を持っていること
  • プロダクト特性としてダウンタイムを許容できること

構成

下記はざっくりとしたPLT Placeの構成です。

※本来DNS(route53)に来たアクセスは一度クライアントに返され、DNSから返されたCloudfrontやALBのCNAMEの値へ直接クライアントからアクセスが発生しますが簡易化するためにRoute53から矢印を引いています。

  • pltplace.ioに対してcloudfront+s3で静的リソースを返却
  • フロントエンドから呼び出されるapi.pltplace.ioはALBにルーティングされ、配下のECS内でアプリケーションが動作
  • データストアにはメインでAuroraを利用
  • batchがいてデータをゴニョゴニョ

小〜中規模webサービスとしてオーソドックスな構成だと思います。
今回は別アカウントにこれと同じものを構築し、そちらにアクセスを全て切り替えるということを行いました。

移行時特に注意すべきAWSサービス

移行の基本方針としてはIaCされたリソースを別アカウントに向けて実行することで全く同じ構成を実現し、そちらにリクエストがくるように仕向けるだけです。
しかしそれだけではうまくいかない厄介なサービスがいくつかあるので紹介します。

Route53

今回の要件としてpltplace.ioというドメインを変更しないというものがありました。Route53ではpltplace.ioというホストゾーンを管理しています。

Route53では別のawsアカウントであっても同名(pltplace.io)のホストゾーンを作成することは可能です。しかし作成しただけでは新規作成した方を向いてくれません。
これはpltplace.ioというドメインで問い合わせが来たらこのホストゾーンを見てねという設定があり、参照変更にはその変更が必要になるからです。
具体的には「.io」のDNSに登録するNSレコードを移行前のホストゾーンのNSレコードから移行後ホストゾーンのNSレコードに変更します。DNSの階層問い合わせについては割愛しますが、下記のようなイメージです。
file
※NSレコードは実際のものと異なります。
変更することで移行後アカウントのpltplace.ioのホストゾーンを参照するようになります。

手順

手順はIaCではできませんので手動で行う必要があります。
ドメインの移管は二つ意味があります。
・NSレコード変更による、参照ホストゾーンの変更
・ドメインの管理アカウントの変更

NSレコード変更による、参照ホストゾーンの変更

file
Route53のコンソールから登録済みドメイン>対象のドメインをクリックするとネームサーバというところにNSレコードの記載があります。
これが移行前のホストゾーンのNSレコードになっていることを確認します。
この値をアクション>ネームサーバの編集から移行後のホストゾーンのNSレコードに変更します。
これでDNS情報が順次更新され、移行後ホストゾーンを参照するようになります。

ドメインの管理アカウントの変更

上記で実質的な移行は完了しますが、ドメインの管理権限はまだ移行前アカウントに存在します。
file
別のAWSアカウントに移管からガイダンスに従って移行を行うと、移行後アカウントにドメインの管理自体もおこなえます。
移行完了後は移行後アカウントのRoute53コンソールの登録済みドメインから当該ドメインを参照することができます。

注意点

DNSの伝播に最大48時間かかります。
上記の手順で設定変更をした際に世界中にある.ioのDNSキャッシュにその情報が浸透するまで最大48時間かかります。
このレコードのTTLは短縮することができません。検証した結果ローカルリージョンからのアクセスは数分で反映されましたが世界各国からのアクセスに関しては古いDNSのレコードを参照してしまう可能性がありますのでこの時間を見越したメンテナンスやサービス停止を計画する必要があります。

Cloudfront

cloudfront+s3の構成では、SSL通信のためにdistributionに代替ドメインとカスタムSSL証明書を設定する必要があります。
この代替ドメイン名が全リージョン、全awsアカウントでユニークでないとダメで、pltplace.ioという代替ドメイン名を持つディストリビューションはこの世に2つ存在できません。
なので、

  1. 移行前アカウントのcloudfront distributionの代替ドメインと証明書を削除

  2. distributionのdeploy(1を行うと自動でdeploy開始)

  3. 移行後アカウントのcloudfront distributionの代替ドメインと証明書を追加

  4. distributionのdeploy(３を行うと自動でdeploy開始)

の手順が必要になり、シームレスな移行ができません。
この1~4が完了するまでの間にアクセスすると、当該ドメインでは証明書のエラーが発生します。
色々調べた結果これは回避できそうになく、どうしてもダウンタイムとして発生してしまいます。
各distributionのdeployは15分程度は見ておいた方がいいです。

S3

上記Cloudfrontと同じくバケット名が全リージョン、全awsアカウントでユニークである必要があります。
IaCで単純に実行してしまうとバケット名称の重複エラーが発生するのでバケット名の変更が必要です。
s3のエンドポイントをそのまま利用している場合は参照先の変更が必要になるのでその辺りも注意が必要です。

S3のデータ移行として一番おすすめなのは、バケットのクロスアカウントレプリケーションです。
移行前：bucket-1
移行後：bucket-2
として、
bucket-1 →　bucket-2のクロスアカウントレプリケーションを設定すると、移行メンテナンス期間中もニアリアルタイムでデータがbucket-2にコピーされデータの欠損、移行漏れなくバケット内のデータを新環境にレプリケーションできます。
問題ないことを確認したらレプリケーションの設定を解除するだけでOKです。

Certificate Manager

証明書が有効になるためには二つの方法があります。
・DNS認証
・メール認証
証明書の発行までIaCされている場合はDNS認証を選択されている方が多いと思います。公式でもDNS認証が推奨されています。
しかしDNSが新環境のものを参照する前では、移行後DNSでは移行後アカウントで発行された証明書は認証されません。
これを回避するために、あらかじめ下記のようにしてDNS認証を完了させ、有効になった証明書を用意すると時間短縮になって良いと思います。
file
先述の通り、Cloudfrontには代替ドメインとそのドメインをカバーするカスタムSSL証明書の設定が必要なので有効な証明書を用意しておけば待ち時間なしでCloudfrontの移行に着手できます。

その他

正直使っているawsサービスによって移行の難易度は大きく異なりますし、ここでは紹介しきれないほど考慮する内容はたくさんあります。
例えばAWS KMSを利用していれば生成されるキーが変わりますので旧環境で復号して新環境の鍵で暗号化する必要があったり、VPCが変わるのでアプリケーションが外部にアクセスするための固定IP、NAT gatewayのIP等も変わります。大事なことは移行したいプロダクトが利用しているサービスをしっかりと把握し、それらの特性から移行時の挙動を推測、検証することです。

大まかな移行手順

上記pltplaceの構成をもとに実際に行った移行手順を紹介します。
事前作業が非常に大事です。

事前作業

  1. 移行用の新規awsアカウントを発行

  2. 新規awsアカウントにIaCを適応
    ここが大変
    エラーを解消しつつリソースを構築する
    上記の「移行時特に注意すべきAWSサービス」はエラー,もしくは要考慮事項になるのでぜひ参考に

  3. フロントエンドをdeploy
    よくあるモダンjsのbuild時にできる/dist,/build,/outとかの配下のリソースを作成されたs3にアップする

  4. バックエンドをdeploy
    ECS前提
    作成されたECRの対象リポジトリにイメージをpushする

  5. DBにDDLを実行しておく
    CREATE DATABASE, CREATE USER, GRANTなど
    当日dumpを入れられる準備

  6. この時点で仮ドメインで動作確認してみるのがおすすめ
    IaCも変える必要がある
    リリース前には必ず仮ドメインの設定を全て削除して再適応しておく

当日作業

最低限しか記載していませんが、大まかにはこんな流れです。

  1. メンテin

  2. batchやapiなどDBアクセスするアプリケーションを停止

  3. DBのdump取得

  4. 新環境DBへのdump restore

  5. ドメイン移管
    「移行時特に注意すべきAWSサービス」のRoute53参照
    これより新環境につながる可能性発生

  6. Cloudfront移管
    「移行時特に注意すべきAWSサービス」のCloudfront参照
    ダウンタイム発生
    新環境につながっていることを確認する

  7. 定時バッチ等のDBのリカバリ
    もし必要であれば

  8. 動作確認、メンテout

感想

正直IaCされていれば移行なんてチョロだと思ってました。実際別のドメイン使っていいという話であればチョロだったと思います。
ここまでの話は本番環境ですが、開発環境だけ先に移行した際に上記本番手順とDNS周りが違って工夫したり、仮ドメインでテストしたらフロントエンド・バックエンドで色々設定を変えなければならず動作確認のための動作確認をがっつり強いられたりと本当に移行日直前まで四苦八苦しました。インフラエンジニアとしてとても成長できる機会と、継続してご利用いただいているユーザの皆様に感謝し、これからも精進していきたいと思います！

タイトルとURLをコピーしました