IaC ジェネレーターを利用してAWSアカウントを引っ越し（AWSリソース移行）した話

こんにちは。ドコモ・テクノロジサービスインテグレーション事業部の伊藤です。

私はCCoE（Cloud Center of Excellence）という役割として、ドコモグループのクラウド活用を推進する業務を行なっています。そのひとつとして、グループのシステム開発・運用効率向上を目的とする様々なツールを提供しています。

ツールにはAWS上で構築・運用しているものもあり、今回あるツールのAWSアカウントの引っ越し（リソースの移行）を行ったため、その経験をもとに内容を共有したいと思います。また引っ越しを行う中で、AWS CloudFormationのIaC ジェネレーターという機能がとても便利でしたので、その点についても解説します。

※AWSアカウントの引っ越しというと、アカウントそのものを移行（AWS Organizaitions間の移行など）とも取れますが、本記事ではアカウント内のAWSリソースを別アカウントに移行することを指しますので、あらかじめご了承ください。

背景
引っ越しの全容
まとめ

背景

前提として、AWSアカウントはシステムや環境（開発・本番など）ごとにアカウントを分けることが推奨されています。アカウントを分けることで仮に侵害された際のリスクを小さくしたり、監査の効率化やコスト管理も容易になります。

今回移行するツールでは、こういった習わしが根付いてない頃からAWSを使っており、1つのAWSアカウントに他のツールと共存させる形で運用していました。また、ツールのコンプライアンス要件を満たす必要があり、今回の対応に至りました。

新規システムをAWSで導入する場合は、新しいAWSアカウントを用意して行いましょう。

引っ越しの全容

ここからは、AWSアカウント引っ越しの全容をお伝えします。実際に引っ越しする際には、以下のAWS規範ガイダンスを確認しておくと良いです。

docs.aws.amazon.com

AWS アーキテクチャ図

以下、移行対象であるツールのアーキテクチャ図です。

ツールのAWS アーキテクチャ図

引っ越しの流れ

移行の流れは以下の通りです。

1. AWSアカウントの用意
2. AWS CloudFormation テンプレートの用意
3. 移行日の調整・アナウンス
4. 移行手順の作成
5. AWSリソース及びツールの移行
6. 移行元リソースの削除

AWSアカウントの用意

AWSアカウントは、検証、本番それぞれ用意しました。 AWS Organizationsを利用している場合、環境に差が出ないように同一のOUに所属させるようにしましょう。

AWS CloudFormation テンプレートの用意

AWS CloudFormationは、テンプレートを元にAWSリソースを構築・管理できるサービスです。手動での構築に比べ学習コストがかかりますが、同じリソースを何度でも複製でき、運用効率が向上します。

今回のような構築済みのリソースを複製または移行する場合、IaC ジェネレーター (Infrastructure as Code ジェネレーター) の利用がおすすめです。

docs.aws.amazon.com

こちらはCloudFormationの管理対象になっていない既存のリソースをテンプレートに変換してくれるツールです。一からテンプレートを作成する場合に比べて、時間と手間を大幅に削減でき、リソースの移行漏れリスクも低下します。

IaC ジェネレーターの利用

IaC ジェネレータの使い方を簡単に紹介します。

マネジメントコンソールからCloudFormationを開き、「IaC ジェネレーター」を選択。「新しいスキャンを開始」すると、テンプレート作成に必要なアカウント内のリソースをスキャンします。

IaC ジェネレーター - トップ画面

スキャン完了後、「テンプレートを作成」を選択。削除ポリシーはCloudFormationの DeletionPolicy 属性、置換ポリシーは UpdateReplacePolicy 属性を指していて、 保持(Retain) or 削除(Delete) を選択できます。

保持(Retain)の場合
- CloudFormationのスタックを削除／置換してもリソースが保持されます。ログ保管用のS3バケットやデータを保持したいEC2、RDSで指定するケースがあります。
削除(Delete)の場合
- CloudFormationのスタック削除／置換時にリソースも削除されます。属性を明示的に指定しない場合は、削除(Delete)扱いとなります。

筆者のおすすめとしては、この時点では保持(Retain)としておき、後のテンプレート修正時に保持しないリソースの DeletionPolicy 、 UpdateReplacePolicy を属性ごと削除すると良いと思います。

IaC ジェネレーター - テンプレートの詳細を指定

次にテンプレートに追加するリソースを選択します。リソースタイプやタグ、リソース識別子等で絞り込みが可能です。

注意点として、すでにCloudFormationによってスタック管理されているリソースは追加できません。そういったリソースはすでにテンプレート化されているはずですので、そちらのテンプレートと併せて利用するとよいです。

IaC ジェネレーター - スキャンしたリソースを追加

次に前画面で選択したリソースの関連リソースを選択します（自動的にピックアップしてくれます）

IaC ジェネレーター - 関連リソースを追加

最終確認後にテンプレートが生成され、「ダウンロード」からテンプレートを取得できます。

IaC ジェネレーター - 生成されたテンプレートの画面

以下、ダウンロードしたテンプレートの一部（CloudWatch アラームの設定値）です。インスタンスIDやarn（AWS Resource Name）を直接指定しているため、他のAWSアカウントのCloudFormationでそのままデプロイするとエラーになります。修正が必要ですがベースはできているため、テンプレートを一から作るよりも時間と手間を省けます。

ダウンロードしたテンプレートの一部

IaC ジェネレーターはこのように簡単に使えますので、気軽に試してみてください。

移行日の調整・アナウンス

ツールの移行にはダウンタイムを伴うため、移行日の調整に加えユーザーへの事前アナウンスを行いました。また今回の移行により、NLB（Network Load Balancer）とNAT gatewayに紐づけているElastic IPが変更となる関係で、利用者側に変更後のIPのアクセス許可を依頼する必要がありました。

利用者によっては、ベンダーの都合や作業自粛などによる都合も発生しうるため、移行前のアナウンスは余裕をもって行いましょう。またメンテナンスの時間は、アクシデントによる切り戻し等も考慮して余裕を持って確保しましょう。

移行手順の作成

AWSリソースの移行には、CloudFormation テンプレートだけではまかなえない部分もあります。例えば今回の場合、以下のような手動作業が必要でした。

Amazon EC2
- AMIの取得 → 新規アカウントにAMIを共有 → AMI IDをテンプレートで指定して起動
Amazon EBS
- Data Lifecycle ManagerでEBS スナップショットの自動バックアップ設定
Amazon RDS
- スナップショットの取得 → 新規アカウントにスナップショットを共有 → スナップショットIDをテンプレートで指定して起動
Amazon Route 53
- ドメイン移行元NLBとのレコード解除 → 新規NLBに紐付け
Amazon SES
- IDの登録と検証
- SMTP 認証ユーザーの作成

その他、AWS サービスクォータの制限解除／ACM証明書の発行／ログの設定（Amazon CloudWatch, AWS CloudTrail）に加え、ツール本体の設定も必要でした。移行手順には修正後のテンプレートのデプロイ作業と上記のような手動作業を手順にまとめました。

検証ではうまくいっても本番では思わぬアクシデントが発生することもよくありますので、確実に作業できるように移行手順は極力詳細に作成しましょう。 AWSリソースの構築前に正しいリージョン先となっていることを手順に含めておく事をお勧めします。

また想定通りの環境が立ち上がるか検証し、検証でつまづいたポイントも手順に残すようにしましょう。移行日当日に万が一の事があった場合に備えて、切り戻しができるように手順を整えておきましょう。

AWSリソース及びツールの移行

作成した手順をもとに、AWSリソース及びツールの移行を行いました。本番環境の移行は以下のポイントを意識すると良いです。

休暇前日、大型連休前は避ける
- 変更直後は不具合発生の可能性が高く、休日中のトラブルリスクを下げられます
作業前後など、関係者への周知を忘れずに行う
- 作業中の進捗共有もチームメンバーに行いましょう。問題発生時にも内容をすぐに共有できるようにしましょう
移行後、ツールが問題なく動作しているか念入りに確認する
- ただ起動しているかだけでなく、アラートが発生していないか、各機能が正常に使えるか確認しましょう
  - チェックリストを移行手順に事前にまとめておくと当日もスムーズに確認できます

また、どんなプレッシャーも冷静さがものを言います。万が一アクシデントが発生しても、心を落ち着かせて慎重に行いましょう。（コーヒーには、鎮静作用（眠気覚まし）と集中力向上が期待できます。）

移行元リソースの削除

本番環境で問題なく動作し、切り戻しの可能性がないことを確認したら、移行元アカウントのAWSリソースを削除します。コスト面やセキュリティ面からも、旧リソースの削除は早めに行いましょう。

つまづいたポイント

無事に稼働していることを確認し、めでたしめでたしと思った矢先、「Couldn't connect to host, port: xxxxxx.xxxxxxxxxx.amazonaws.com, 25; timeout 30000エラーが発生しておりメールの送信に失敗している」と利用者から報告がありました。想定外の報告にヒヤリとさせられ、調査を進めているうちに以下のページにたどり着きました。

repost.aws

EC2 ポート25（SMTP）のアウトバウンド通信はスパム防止としてデフォルトで閉じられており、こちらの制限を解除する必要がありました。解除するにはAWSへの申請が必要であり、申請から数時間後に解除され、エラーも解消されました。
「移行手順の作成」のところで、CloudFormation テンプレートだけではまかなえない部分について記載しましたが、ポート制限の解除というポイントもありました。

※こちらの事象は移行対象のツールからのメール配信が必要であるために発生しました。メール配信を行わない（ポート25のアウトバウンド通信が発生しない）場合は対象外となります