継続は力なり

タイトル通り定期的な更新を心掛けるブログです。

AWS アカウントを跨いだプライベートホストゾーンの設定方法

タダです.

業務で Route53 プライベートホストゾーンを別アカウントの VPC でも使うことができるよう設定を行ったのでどのように設定するかを整理しておきます.

本記事で紹介する設定の概要

まず,Route53 プライベートホストゾーンは VPC に閉じたプライベートネットワーク内の DNS ドメインレコードを管理するためのコンテナになります.プライベートなのでインターネットにリソースを公開せずに名前解決が可能になるのが特徴で,関連づける VPC は複数サポートされています.

docs.aws.amazon.com

下の構成図のようにメインアカウントの Route53 プライベートホストゾーンとサブアカウントVPC を関連付ける方法をこの記事で紹介します.

f:id:sadayoshi_tada:20191116183151p:plain

同一アカウントでのプライベートホストゾーンの VPC 関連付けは Route53 の管理画面から VPC ID を参照できますが,別アカウントの VPC は下記の引用文にあるように参照できません.そのため,別のアプローチが必要になるのですが,今回は AWS CLI を使った設定方法を紹介します.

次の点に注意してください。

・あるアカウントで作成した複数の VPC と別のアカウントで作成したホストゾーンを関連付ける場合は、VPC ごとに認証リクエストを送信する必要があります。

・関連付けを許可する際、ホストゾーン ID を指定する必要があるため、プライベートホストゾーンが存在している必要があります。

VPC とプライベートホストゾーンの関連付けを許可する場合や、関連付けを行う場合はいずれも、Route 53 コンソールを使用することはできません。

参考ドキュメント

docs.aws.amazon.com

予め準備しておくこと

予め準備しておくこととして,別アカウントの VPC では DNS ホストゾーンの設定を有効化してください.プライベートホストゾーンの設定に必要な要素となります.

Amazon VPC 設定

プライベートホストゾーンを使用するには、次の Amazon VPC 設定を true に設定する必要があります。

・enableDnsHostnames

・enableDnsSupport

下記の画像のようにDNS hostnames Enabled になっていればOKです.

f:id:sadayoshi_tada:20191116180637p:plain

参考ドキュメント

docs.aws.amazon.com

また,AWS CLI の実行環境とプライベートホストゾーンの管理アカウントと関連づける VPC のアカウントそれぞれのアクセスキーとシークレットアクセスキーが必要です.Route53 の強い権限 AmazonRoute53FullAccess 等を付与ください.今回は,AdministratorAccess を付与して確認しています.

実際の設定作業

それでは,実設定を行います.

1 予めプライベートホストゾーンを管理するアカウントで別アカウントの VPC を関連づける前のホストゾーンの設定状況を確認します.

$ aws route53 get-hosted-zone --id  <プライベートホストゾーンのID>

[実行結果]

{
    "VPCs": [
        {
            "VPCId": "vpc-xxxxxxxxxxxxxxxx",
            "VPCRegion": "ap-northeast-1"
        }
    ],
    "HostedZone": {
        "ResourceRecordSetCount": 2,
        "CallerReference": "xxxx",
        "Config": {
            "Comment": "for test",
            "PrivateZone": true
        },
        "Id": "/hostedzone/<プライベートホストゾーンのID>",
        "Name": "private.hoge.com."
    }

2 以下の AWS CLI コマンドをプライベートホストゾーンを管理するアカウントで実行して,対象のVPCを紐づけます.

$ aws route53 create-vpc-association-authorization \
--hosted-zone-id <プライベートホストゾーンのID> \
--vpc VPCRegion=ap-northeast-1,VPCId=<別アカウントの VPC ID>

[実行結果]

{
    "HostedZoneId": "<プライベートホストゾーンのID>",
    "VPC": {
        "VPCId": "<別アカウントの VPC ID>",
        "VPCRegion": "ap-northeast-1"
    }
}

3 サブアカウントの権限でプライベートホストゾーン管理アカウントに認証リクエストを送ります.

$ aws route53 associate-vpc-with-hosted-zone \
--hosted-zone-id <プライベートホストゾーンのID> \
--vpc VPCRegion=ap-northeast-1,VPCId=<別アカウントの VPC ID>

[実行結果]

{
    "ChangeInfo": {
        "Status": "PENDING",
        "Comment": "",
        "SubmittedAt": "2019-11-16T08:41:16.398Z",
        "Id": "/change/C1I9D47KD29FOR"
    }
}

4 再度プライベートホストゾーンを管理するアカウントでホストゾーンの設定状況を確認します.

$ aws route53 get-hosted-zone --id  <プライベートホストゾーンのID>

[実行結果]

{
    "VPCs": [
        {
            "VPCId": "vpc-xxxxxxxxxxxxxxxx",
            "VPCRegion": "ap-northeast-1"
        },
        {
            "VPCId": "<別のアカウントの VPC ID>", <= 別アカウント VPC ID が追加されています
            "VPCRegion": "ap-northeast-1"
        }
    ],
    "HostedZone": {
        "ResourceRecordSetCount": 2,
        "CallerReference": "xxxx",
        "Config": {
            "Comment": "for test",
            "PrivateZone": true
        },
        "Id": "/hostedzone/<プライベートホストゾーンのID>",
        "Name": "private.hoge.com."
    }
}

管理画面上でも関連づけられていることを確認できました.

f:id:sadayoshi_tada:20191116181804p:plain

まとめ

アカウントが分かれているVPC を Route53 プライベートホストゾーンに関連づける方法で必要な設定をさらいました.なかなかない機会でしたので記事化しましたが,同じ状況の方の参考になれば幸いです.

AWS サービス制限の管理に役立つ『AWS Limit Monitor』の紹介

タダです.

AWS にはサービスごとに制限が設けられています.EC2 でもオンデマンドインスタンスの制限として vCPU 制限が設けられたのは記憶に新しいです.

AWS サービスの制限 docs.aws.amazon.com

EC2 の起動制限がサーバー台数から vCPU での制限へ変更のアップデート情報を整理する sadayoshi-tada.hatenablog.com

サービス制限の管理には Trusted Advisor や Service Quotas 等のサービスを使って管理することも可能ですが,今回は AWS ソリューションにある「AWS Limit Monitor」というソリューションを紹介します.

aws.amazon.com

AWS Limit Monitor とは

AWS Limit Monitor」は AWS リソースの利用上限に達しそうになった時に Eメール または Slack に通知を飛ばすことで,利用上限に達する前に制限値を緩和のリクエストをあげる時に役立ちます.

ソリューションのアーキテクチャイメージは以下の通りです.

ソリューション概要AWS ソリューションの概要ページより引用 f:id:sadayoshi_tada:20191110194823p:plain

当該ソリューションの仕組みは, Trusted Advisor がチェックしている対象のサービス情報を使って利用上限をチェックします.追加でチェックするサービスを増やしたい場合は次のように CloudFormation テンプレート内で設定も可能です.

EventsMap:
   Checks:
     Services:
         '"AutoScaling","CloudFormation","DynamoDB","EBS","EC2","ELB","IAM","Kinesis","RDS","Route53","SES","VPC"'

docs.aws.amazon.com

関連情報

ソリューション概要

aws.amazon.com

ドキュメント

docs.aws.amazon.com

GItHub

github.com

利用方法

利用にあたっては,利用上限をチェックしたいアカウントで CloudFormation テンプレートを実行します.なお,当該ソリューションの CloudFormation テンプレートは バージニアリージョンで展開する必要があるのが注意点です.

CloudFormation テンプレートをデプロイするためには対象のAWSアカウント, Eメールアドレスが必要になるので準備しておいてください. Slack の incoming-webhook の URL と 通知チャンネル名 はオプション設定となるので必要であれば準備ください.

f:id:sadayoshi_tada:20191110201349p:plain

追加のアカウントもあれば別のテンプレートを利用します.このテンプレートをデプロイするためにはメインアカウントのIDが必要なので入力できるようにしておきましょう.

f:id:sadayoshi_tada:20191110205142p:plain

デプロイ後の通知テスト

当該ソリューションのデプロイ後に意図的にサービス上限値に近くなった時の通知テストをしてみました.試しに VPC の作成上限,1アカウントあたり5つまで VPC 作成可能な上限に触れるように VPC を増やしてみたところ Eメール通知がきました.Slack への通知が飛んでいない状況だったので Systems Manager Parameter Store の設定に問題がありそうなため設定を確認してアップデートします...

f:id:sadayoshi_tada:20191110205559p:plain

利用料

当該ソリューションを使うためのコストの参考例があります.1か月あたり約9.50ドル、セカンダリアカウントあたり1か月あたり8.03ドルとなると記載されていたので利用時の参考にしてください.

If you use this solution to monitor vCPU limits, the cost for running this solution in your primary account in US East (N. Virginia) is approximately $9.50 per month, and $8.03 per month per secondary account as of the date of publication.

docs.aws.amazon.com

まとめ

サービス上限の管理ソリューションである「AWS Limit Monitor」を紹介しました.AWS の運用において上限値と付き合って行く必要があります.通常のサービスだけでなく AWS ソリューションを使って素早く実現したいオペレーションの状態にするために利用検討してみてよいかと! Slack インテグレーション部分は確認出来次第アップデートします 🙇🏻‍♂️

EC2 の起動制限がサーバー台数から vCPU での制限へ変更のアップデート情報を整理する

タダです.

EC2 で 新しいオンデマンドインスタンスの制限が設けられ,vCPU ベース制限がアナウンスされました.これまでの考え方と異なるため,この記事では今回のアップデートについて利用者側でどんな対応が必要になるか,という観点で整理していきます.

今回のアップデート概要

これまでは EC2 オンデマンドインスタンスの起動できる制限がこれまではサーバーの台数によって決まっていましたが,今回のアップデートで vCPUでの制限に変わります.

公式ブログでのアナウンス記事 aws.amazon.com

なお,この変更に伴い現状のインスタンスは影響は受けないですし,同じ数のインスタンス数は作成できるようになっています.

Q: これにより実行中のインスタンスは影響を受けますか?

いいえ。vCPU ベース制限をオプトインしても実行中のインスタンスには影響ありません。

Q: 引き続き同じ数のインスタンスを作成できますか?

はい。vCPU ベースのインスタンス制限により、数量ベースのインスタンス制限として、少なくとも同じ数のインスタンスを作成できます

vCPU の制限の種類は次の5つがあります.これらの制限の管理は EC2 または Service Quotas で行うことができます.CloudWatch メトリクスと組み合わせることが可能なため,アラートと組み合わせて設定・管理すると良いでしょう.vCPU 数の制限はデフォルトの制限数に各インスタンスサイズ毎の vCPU 制限が加えられて表示されます.

Q: vCPU ベースの制限とはどのようなものですか?

AWS アカウントでの 1 つ以上のオンデマンドインスタンスの実行は制限されています。Amazon EC2 は、 AWS アカウントで実行中のオンデマンドインスタンスに割り当てられた 総 vCPU (仮想中央演算処理装置) 数に基づき、各制限に対する使用量を測定します。次の表は、各インスタンスサイズの vCPU の数を示しています。インスタンスタイプにおける vCPU のマッピングは異なる可能性があります。詳細については、Amazon EC2インスタンスタイプを参照してください。

インスタンスサイズ毎の vCPU 制限数

インスタンスサイズ vCPU
nano 1
micro 1
small 1
medium 1
large 2
xlarge 4
2xlarge 8
3xlarge 12
4xlarge 16
8xlarge 32
9xlarge 36
10xlarge 40
12xlarge 48
16xlarge 64
18xlarge 72
24xlarge 96
32xlarge 128

Q: Amazon EC2 で実行できるオンデマンドインスタンスの数はどれくらいですか?

5 つの vCPU ベースのインスタンス制限があり、特定のインスタンスファミリーの使用できるキャパシティの量をそれぞれ定義します。ジェネレーション、サイズ、またはバリアント設定 (例: ディスク、プロセッサータイプ) に関係なく、特定のインスタンスファミリーの使用量はすべて、下記の表に記載されているファミリーの総 vCPU 上限に追加されます。新規の AWS アカウントでは、当初この上限よりも少ない数に制限されることがあります。

デフォルトの vCPU 制限数

制限対象 デフォルトの vCPU 制限
オンデマンド標準 (A, C, D, H, I, M, R, T, Z) インスタンス 1152 vCPU
オンデマンド F インスタンス 128 vCPU
オンデマンド G インスタンス 128 vCPU
オンデマンド P インスタンス 128 vCPU
オンデマンド X インスタンス 128 vCPU

よくある質問(vCPU 制限関連)

aws.amazon.com

今回のアップデートに伴なう利用者側で発生する対応

今回のアップデートで利用者側はどのような対応が必要になるのでしょうか.よくある質問に下記の記載があり,2019年10月24日以降に vCPU 制限に移行して2019年11月8日以降に台数制限は利用できなくなると記載があるので今のうちに適用して確認しておきましょう,というステータスですね.

Q: 何が変更されますか?

Amazon EC2 はオンデマンドインスタンス制限を、現在の数量ベースの制限から、新たに vCPU ベースの制限に移行し、AWS のお客様の制限管理エクスペリエンスを簡素化します。vCPU ベースの制限に対する使用量は、アプリケーションのニーズを満たすインスタンスタイプの任意の組み合わせを起動するためのAmazon EC2インスタンスタイプにおける vCPU (仮想中央演算処理装置) の数によって測定されます。2019 年 9 月 24 日から、vCPU ベースのインスタンス制限をオプトインできます。Amazon EC2は、2019 年 10 月 24 日からインスタンス制限を vCPU に移行し、2019 年 11 月 8 日以降、現在の数量ベースのインスタンス制限は利用できなくなるか、またはサポートされなくなります。

vCPU 制限によって起動するインスタンスが制限に引っかかっていないかの確認は下記の「vCPU 計算ツール」が役立ちます.

https://ap-northeast-1.console.aws.amazon.com/ec2/home?region=ap-northeast-1#LimitsCalculator:

例えば,EC2 のm5.large(vCPU 2コア) を5台起動する場合を計算すると以下のように算出してくれます.算出結果,10 vCPU 分サービスの上限緩和が必要になります.サーバーの起動計画時に使っていくと良いでしょう.

f:id:sadayoshi_tada:20191102173415p:plain

vCPU 制限のオプトインの実践

僕のアカウントはまだ vCPU 制限をオプトインしていなかったので適用してみます.EC2 の制限画面よりオプトイン可能です.

f:id:sadayoshi_tada:20191101084731p:plain

オプトインしてみたところ,vCPU 制限が有効化されるまで最大15分ほど要するようです. f:id:sadayoshi_tada:20191102171140p:plain f:id:sadayoshi_tada:20191102171145p:plain f:id:sadayoshi_tada:20191102171228p:plain

なお,有効化前なので台数ベースの起動制限が有効化になっていることを確認しておきます. f:id:sadayoshi_tada:20191102171448p:plain

オプトイン後の画面は以下の通りです.オプトインされたことと起動制限が vCPU ベースに切り替わっています. f:id:sadayoshi_tada:20191102171532p:plain f:id:sadayoshi_tada:20191102171543p:plain

Service Quotas 画面でも同様に切り替わっています. f:id:sadayoshi_tada:20191102171942p:plain

vCPU 制限のオプトアウトの実践

逆に,オプトアウトで台数制限に戻す場合もオプトイン同様に設定変更可能です.vCPU の検証中に切り戻したいときは下記の通り変更します.

f:id:sadayoshi_tada:20191102172425p:plain f:id:sadayoshi_tada:20191102172429p:plain f:id:sadayoshi_tada:20191102172437p:plain f:id:sadayoshi_tada:20191102172440p:plain

まとめ

EC2 の起動制限が vCPU ベースに変わるためアップデートされる利用者側の観点で情報を整理しました.vCPU の計算ツールは今後の運用を考えると頻繁に使う機会があると思うので慣れておきましょう.時間は少ないですが試されてない方々は vCPU ベースの制限をオプトインして11月8日以降のアップデートを迎える準備をしていくことをお勧めします.不明点や懸念がある場合,下記のブログもしくはAWS サポートを通じて詳細を確認していきましょう.

関連の公式解説記事 aws.amazon.com

組織内での AWS 利用のガバナンスとアジリティを向上させる『AWS Service Catalog』を使ってみる

タダです.

業務でマルチアカウントかつ多数の開発ベンダーの方々が利用する環境の運用において「AWS Service Catalog(以下,Service Catalog)」の利用場面があると思い,まずは「Service Catalog」の概要や利用方法を確認した後,マルチアカウントかつ多数の開発ベンダーの方々が利用する環境での「Service Catalog」を利用パターンを整理します.

はじめに

「Service Catalog」とは

Service Catalog」とは2つの特徴のあるサービスです.

  1. 組織内のインフラプロビジョニングをアジリティを効かせて対処ができるサービス
  2. ガバナンスを効かせながらチームやプロジェクトがセルフでプロビジョニングする仕組みを作ることが可能

以下が各種サービスに関する参考情報リソースです.

サービストップ aws.amazon.com

ドキュメント docs.aws.amazon.com

Black Belt Online Seminar

「Service Catalog」の利用メリット

Service Catalog」の利用メリットは,以下の通りです.

  • 組織内での AWS 利用を適切な権限を設定して環境をプロビジョニングが可能なことからより良い AWS 利用促進に寄与すること
    • 管理者視点では,利用者に適切な権限を設定してガバナンスを強化
    • 利用者視点では,適切な権限をもらった上で素早く自分たちで環境をプロビジョニングが可能

「Service Catalog」の用語

Service Catalog」の用語として以下のものがあります.

  • 製品 : CloudFormation テンプレートをパッケージ化したもの.
    • EC2 やストレージ,データベースなどの1つ以上の AWS リソースからなり,バージョン管理可能.
  • 制約 : 製品のデプロイ方法を制御.ポートフォリオごとに各製品に制約を追加.
    • テンプレート制約 : 製品を起動する時のユーザーが使用できるパラメータ(EC2 インスタンスタイプ等)を制限.
    • 起動制約 : 起動時にリソースをプロビジョニングするのに利用するロール.
    • 通知制約 : SNS トピックを使ってスタックのイベントに関する通知を受けることを可能にする.
  • ポートフォリオ: 製品の集合.ポートフォリオの単位でユーザーに製品の仕様を許可.
  • プロビジョニングされた製品 : 製品のインスタンス.

「Service Catalog」の利用可能なリージョン

2019年10月時点で「Service Catalog」の利用利用可能なリージョンは東京含め下記のリージョンで利用可能です.

「Service Catalog」の利用料金

Service Catalog」の利用料金はポートフォリオの数で決まります.1つのポートフォリオにつき1 か月あたり「$5」の固定料金です.

料金ページ aws.amazon.com

「Service Catalog」の利用

Service Catalog」の利用の仕方を下記のページを参考に進めていきます.

開始方法 docs.aws.amazon.com

1. 管理者および利用者への権限付与

まずは,「Service Catalog」の管理者と利用者への権限を設定します.管理者には,「AWSServiceCatalogAdminFullAccess」という管理ポリシーが用意されてますが,「AdministratorAccess」権限が付与されていれば追加の権限は不要です.もし,「AdministratorAccess」権限がなければ管理ポリシーに加え,下記のインラインポリシーも設定ください.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "ec2:CreateKeyPair",
                "iam:AddRoleToInstanceProfile",
                "iam:AddUserToGroup",
                "iam:AttachGroupPolicy",
                "iam:CreateAccessKey",
                "iam:CreateGroup",
                "iam:CreateInstanceProfile",
                "iam:CreateLoginProfile",
                "iam:CreateRole",
                "iam:CreateUser",
                "iam:Get*",
                "iam:List*",
                "iam:PutRolePolicy",
                "iam:UpdateAssumeRolePolicy"
            ],
            "Resource": [
                "*"
            ]
        }
    ]
}

利用者には「ServiceCatalogEndUserAccess」をアタッチします.利用者の権限には,インラインポリシーとしてProvisionProductアクションを付与する必要があります.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "servicecatalog:ProvisionProduct"
            ],
            "Resource": "*"
        }
    ]
}

ドキュメントリンク

管理者へのアクセス権限の付与 docs.aws.amazon.com

利用者へのアクセス権限の付与 docs.aws.amazon.com

2. ポートフォリオの作成

ポートフォリオを作っていきます.ポートフォリオの作成はサービストップ画面の「今すぐ始める」からスタートします. f:id:sadayoshi_tada:20191022100700p:plain f:id:sadayoshi_tada:20191022100715p:plain

ポートフォリオの作成が完了すると,以下の様な状態になります. f:id:sadayoshi_tada:20191022100647p:plain

3. 製品を作成する

ポートフォリオを作れば製品を追加する準備が整うので,Amazon Linux の開発環境を作るための「Linux Desktop」という製品を作ります.ドキュメントの指示に従って設定を入力します. f:id:sadayoshi_tada:20191022131108p:plain f:id:sadayoshi_tada:20191022131132p:plain f:id:sadayoshi_tada:20191022131152p:plain f:id:sadayoshi_tada:20191022131200p:plain

4. テンプレートに制約を追加

CloudFormation テンプレートに利用者の制約を追加していきます.以下のルールでLinux サーバーを起動する時にt2.microt2.smallインスタンスしか選択できない様制約を設定します.

{
  "Rules": {
    "Rule1": {
      "Assertions": [
        {
          "Assert" : {"Fn::Contains": [["t2.micro", "t2.small"], {"Ref": "InstanceType"}]},
          "AssertDescription": "Instance type should be t2.micro or t2.small"
        }
      ]
    }
  }
}

5. 起動制約を追加する

起動制約は利用者が製品を起動するときに IAM が引き受ける Service Catalog ロールを指定します.利用者が CloudFormation を使える様に テンプレート起動制約を追加します.以下の IAM ポリシーを設定し,IAMロールとして Service Catalogを選択して設定します.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "cloudformation:CreateStack",
                "cloudformation:DeleteStack",
                "cloudformation:DescribeStackEvents",
                "cloudformation:DescribeStacks",
                "cloudformation:GetTemplateSummary",
                "cloudformation:SetStackPolicy",
                "cloudformation:ValidateTemplate",
                "cloudformation:UpdateStack",
                "ec2:*",
                "s3:GetObject",
                "servicecatalog:*",
                "sns:*"
            ],
            "Resource": "*"
        }
    ]
}

6. 利用者での動作確認

利用者の IAM ユーザーでログインし,「Service Catalog」でテンプレートを起動できるかを確認します. f:id:sadayoshi_tada:20191022133743p:plain

利用者の画面から作成した「Linux Desktop」が確認できます.起動するとインスタンスタイプはt2.microt2.smallしか選べない様になっており制約も効いています. f:id:sadayoshi_tada:20191022133748p:plain f:id:sadayoshi_tada:20191022133751p:plain f:id:sadayoshi_tada:20191022133756p:plain f:id:sadayoshi_tada:20191022133759p:plain f:id:sadayoshi_tada:20191022133802p:plain f:id:sadayoshi_tada:20191022133806p:plain

利用者の CloudFormation テンプレート起動が成功しました. f:id:sadayoshi_tada:20191022133810p:plain f:id:sadayoshi_tada:20191022133813p:plain

マルチアカウントでの「Service Catalog」の利用シーン

マルチアカウントでの「Service Catalog」の利用シーンについて下記の資料のアーキテクチャパターンを整理したいと思います.

Case1. Hub-Spoke パターン(マスターアカウントから各アカウントへのポートフォリオの共有)

マスターアカウントで製品を一元管理し,各アカウントにポートフォリオをコピーする利用です.一番ベーシックなパターンかと思います.CloudFormation テンプレートの制約はマスターアカウントでの設定が引き継がれ,各アカウントのポートフォリオに追加のテンプレート制約も設定可能です.

Case2. CI/CD

事例のページに記載がありますが,CI/CDパターンが紹介されていました.マルチアカウントでのステージングを構成する場合のプロビジョニング構成方法として参考になります.

まとめ

Service Catalog」のサービス概要およびマルチアカウントでの利用シーンを整理しました.今やマルチアカウントでの運用も増え,「AWS Organaizations 」と組み合わせて管理者に依存しない環境のプロビジョニングが開発のアジリティを高めていくことはビジネス成長に寄与すると思います.利用シーンが合えばサービス利用を検討していきたいところです.また,下記のリポジトリには「Service Catalog」で使うテンプレートが入っているので参考にするのもの良いでしょう.

AWS Organizations で使用できる AWS のサービス docs.aws.amazon.com

awslabs/aws-service-catalog-products github.com

RDS と Aurora の SSL/TLS 証明書のメンテナンスアナウンスについて

タダです.

RDS 及び Aurora で使っている CA 証明書の入れ替えがアナウンスされています.今回はこのメンテナンスの情報をまとめ,対処や注意点に触れて関係する方の一助になればと思います.

2019/10/25 更新

AWS ドキュメントのアップデートがあり,デフォルト証明書適用開始日が11/1 から 2020年1月14日変更になった模様です.

Any new RDS DB instances created after January 14, 2020 will use the new certificates by default. If you want to temporarily modify new DB instances manually to use the old (rds-ca-2015) certificates, you can do so using the AWS Management Console or the AWS CLI. Any DB instances created prior to January 14, 2020 use the rds-ca-2015 certificates until you update them to the rds-ca-2019 certificates

更新されたドキュメントページ https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/UsingWithRDS.SSL-certificate-rotation.htmldocs.aws.amazon.com

2019/12/21 更新

AWS から RDS 及び Aurora の証明書更新に関してブログが更新されました.今回の記事でデータベースを再起動せずに証明書を入れ替えられる AWS CLImodify-db-instance--no-certificate-rotation-restart オプションが紹介されています.今回のメンテナンスは, SSL/TLS でのデータベース接続していないデータベースにも影響があります.本稼働中のデータベースでは再起動を入れづらいと思いますのでこれは利用者にとってとてもありがたいアップデートですね.

aws.amazon.com

注意点として,下記の引用にもある様に上記のコマンドで再起動を避けられるが,証明書の適用されるのは再起動が発生するタイミングとなります.

If you do not want to restart your database, you can use a new CLI option for the modify-db-instance CLI command (--no-certificate-rotation-restart) specifically to rotate and stage the new certificates on the database host to avoid a restart. However, new certificates will be picked up by the database only when a planned or unplanned database restart happens.

データベースを再起動したくない場合は、modify-db-instance CLIコマンドの新しいCLIオプション(--no-certificate-rotation-restart)を使用して、特にデータベースホストで新しい証明書をローテーションおよびステージングできます。再起動を避けます。ただし、データベースが新しい証明書を取得するのは、計画的または計画外のデータベースの再起動が発生した場合のみです。

AWS CLI ドキュメント

docs.aws.amazon.com

AWS からのメンテナンスアナウンス情報まとめ

概要

今回のメンテナンスの概要ですが,RDS 及び Aurora に接続する際に通信を暗号化で使う SSL/TLS 証明書のデフォルトがrds-ca-2015からrds-ca-2019に変更となります.それに伴い,証明書の入れ替えが RDS 及び Aurora で発生します.また,クライアント側でも利用しているルート証明書の入れ替えを行う必要があります.

メールでのアナウンス

AWS より発行されている本メンテナンスに関するメールの引用文です.

タイトル

Update Your Amazon RDS SSL/TLS Certificates by October 31, 2019

本文

Hello,

Please act before October 31, 2019 to address an upcoming interruption of your applications using RDS and Aurora database instances.

To protect your communications with RDS database instances, a Certificate Authority (CA) generates time-bound certificates that are checked by your database client software to authenticate any RDS database instance(s) before exchanging information. Following industry best practices, AWS renews the CA and creates new certificates on a routine basis to ensure RDS customer connections are properly protected for years to come. The current CA expires on March 5, 2020, requiring updates to existing RDS database instances with certificates referencing the current CA.

You are receiving this message because you have an Amazon RDS database instance(s) in the AP-NORTHEAST-1, AP-NORTHEAST-2, AP-SOUTHEAST-1, AP-SOUTHEAST-2 Region(s). If your applications connect to those instances using the Secure Sockets Layer (SSL) or Transport Layer Security (TLS) protocol please follow the detailed instructions in the link below to complete your update(s). If not completed, your applications will fail to connect to your DB instances using SSL/TLS after March 5, 2020.

We encourage you to test these steps within a development or staging environment before implementing them in your production environments. Beginning today, you can start testing and updating your existing RDS database instances. For detailed instructions, please visit: https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/UsingWithRDS.SSL-certificate-rotation.html

Any new RDS instances created after November 1, 2019 will default to using the new certificates. If you wish to temporarily modify new instances manually to use the old (rds-ca-2015) certificates, you can do so using the AWS console or the AWS CLI. Any instances created prior to November 1, 2019 will have the rds-ca-2015 certificates until you update them to the rds-ca-2019 version.

If you have questions or issues, please contact AWS Support at: https://aws.amazon.com/support

公式ブログでのアナウンス

公式ブログではよくある質問への回答まとめ記事がでていましたので関係しそうな方は要チェックです.

aws.amazon.com

利用者側での必要な対処について

利用者側で必要な対処は,2つあります.

参考ドキュメント

https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/UsingWithRDS.SSL-certificate-rotation.htmldocs.aws.amazon.com

https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/UsingWithRDS.SSL.htmldocs.aws.amazon.com

注意点

注意点として,ドキュメントにも記載がありますがインスタンスの再起動が発生します.本番のワークロードに乗っている場合は計画的に再起動を検討していきましょう.

また, RDS への SSL 接続していない場合でも来年の3月5日に強制アップデートがかかるため,rds-ca-2015を使っていれば再起動されていた、、、なんてことが発生しかねないため注意して再起動メンテナンスのタイミングを計画した方が良いでしょう.

2020 年 2 月 5 日以降、既存の DB インスタンスについて、2020 年 3 月 5 日の最終期限を迎える前に実施される強制アップデートのスケジュールの通知を送付させていただきます。もし、CA 証明書が 2020 年 3 月 5 日までにアップデートされなかった場合、お客様のアプリケーションからの SSL/TLS 接続は、CA 証明書が無効になっているため、失敗するようになります。この最終期限につきましては、CA 証明書が実際に無効になる日付であるため、延期することができません。

11月1日から起動したインスタンスにはデフォルト証明書がrds-ca-2019が適用されます.これは即ちポイントインタイムリカバリやスナップショットからの復元でも適用される点は注意です.

2019 年 11 月 1 日以降、お客様が新たに DB インスタンス (Amazon RDS DB インスタンス、Amazon Aurora DB クラスター、リードレプリカおよびスナップショットからのリストアを含む) を作成した場合、そのインスタンスはデフォルトで新しい CA 証明書 (rds-ca-2019) を使用いたします

なお,公式ブログにはデフォルト証明書の切り替えタイミングは変更の可能性が記されていますが,早急に対応すべきメンテナンスのため,11月1日目処に切り替えられるよう準備を進めることをお勧めします.

新規 DB インスタンスにおける CA 証明書のデフォルトの切り替え日 (2019 年 11 月 1 日) につきましては予定となっており、お客様からのフィードバックを元に延期する予定でございます。新しい切り替え日につきましては、追ってご連絡させていただきます。

今回のメンテナンスに関わるスケジュール

最後に,今回のメンテナンスに関するスケジュールを以下にまとめます.

Q: CA 証明書更新のタイムラインはどのようになっていますか?
2019 年 10 月 31 日: 当初 2019 年 11 月 1 日より新しい CA 証明書が新規 DB インスタンスで使用される予定だったため、CA 証明書アップデートの早期実施の推奨日
2019 年 11 月 1 日: 当初新しい CA 証明書が新規 DB インスタンスで使用開始される予定だった日
2020 年 2 月 5 日: 最終期限である 2020 年 3 月 5 日より数週間前に実施される強制アップデートについての通知が送付される予定の日付
2020 年 3 月 5 日: 古い CA 証明書が無効になり、強制アップデートが実行され、新しい CA 証明書を持っていないアプリケーションが SSL/TLS 接続性を失う日付

まとめ

RDS 及び Aurora の SSL/TLS 証明書 入れ替えに伴うメンテナンス概要,利用者側の対応及び注意点を整理しました.RDS や Aurora を利用されている方は多くいらっしゃるかと思いますので,再起動も発生しますし入念に準備を進めて行きましょう.