CloudFormationで管理されたAuroraを後から暗号化しました

こんにちは。アルダグラムでエンジニアをしている okenak です。

弊社のサービスのKANNAではデータベースにAWS Auroraを利用していますが、大手企業からのセキュリティ要件としてDBの暗号化が求められるようになってきたため、先日メンテナンス作業を実施してAuroraの暗号化を実施しました。

今回は本番稼働中のDBに対してどのような手順で反映を行ったかについて記載します。

（ついでにAWSより利用中のAurora MySQL 2.09のバージョンが廃止される通知がきていたため、
Aurora MySQL 2.11.1へのマイナーバージョンアップも合わせて行っています）

後からAuroraの暗号化についての課題点

まず、暗号化されてないAuroraクラスターは後から暗号化することはできない仕様でした。
Amazon Aurora の暗号化された DB クラスターの制限事項

そのため、手順としてはスナップショットから暗号化されたAuroraクラスターの新規構築が必要になるようです。本番稼働中のDBに対して実施する場合は、スナップショットからの構築中にデータの差分が発生しないようサービスをメンテナンスモードにしてから作業が必要でした。

当日行った作業の流れ

作業のステップとしては以下のような流れでメンテナンス作業は2時間程度で完了しました。

1. サービスをメンテナンスモードにしてDBのデータが更新されない状態にする
2. AWSダッシュボード上からAuroraのスナップショットを作成する（数分程度で完了）
3. CFnで暗号化済みのAuroraクラスターを新規スタックで作成（1時間程度かかる）
4. サービス側のデプロイを行い接続先を新規DBに切り替える
5. 旧Auroraクラスターを一時停止状態にする（完全停止まで数十分かかる）
6. サービスが問題なく動作することを確認する
7. メンテナンスモードを解除
8. 不要になった旧Auroraクラスターを削除する（しばらく落ち着いた後に対応）

※もしメンテナンス中に何か問題が発生した場合は旧Auroraクラスターに切り戻すことで対応

暗号化のためのCFnテンプレート修正箇所

修正箇所は以下の通りです

Type: 'AWS::RDS::DBCluster'
  Properties:

  ~省略~

    StorageEncrypted: true # データ暗号化を有効にする設定
    KmsKeyId: alias/aws/rds # KMSのKeyIDを指定（今回はAWSが提供するマネージドキーを使用）
    SnapshotIdentifier: "arn:aws:rds:XXX" # 事前に作成したスナップショットのARNを指定する

SnapshotIdentifierについては、今後運用で変更が発生してしまうとクラスターの再構築が発生するため、初回設定以降は値を変更しない運用になりそうでした。
AWS Documentation AWS CloudFormation User Guide

また、リカバリ用に旧Auroraクラスターを残しておきたかったためCFnでは新しいテンプレートを用意して新規スタックとして作成することで暗号化済みのAuroraの構築を行いました。

DBのエンドポイントの指定をCNAMEにする改善も実施

KANNAの従来の設定ではDBのエンドポイントをコンテナ側に直接渡していたため、DBの向き先切り替えのためにAPIやWokerのコンテナのデプロイが必要でした。

これでは向き先切り替えの度にデプロイが必要となり利便性が悪いため、Route53にライターとリーダー用のCNAMEを登録してコンテナ側の宛先もCNAME経由にすることで、Route53側で切り替え作業が完結できて運用が楽になるよう改善も行いました。

上記はANDPADさんの記事を参考にさせていただきました

まとめ

今回行った作業は本番稼働中のサービスに対しての実施で失敗は許されないため、事前に開発環境を使って検証やリハーサルを何回か実施しました。

おかげで、本番メンテナンス作業はスムーズに進行ができ何事もなく無事サービスが再開されましたのでほっと一安心と言ったところです。

この記事がどなたかの参考になれば幸いです！