非 Aurora な RDS から Aurora へ移行する時に考えること全部盛り
Japan AWS Jr. Champions Advent Calendar 23日目の投稿です！クリスマスイブイブですね。
今回は、Aurora でない RDS で稼働している DB を Aurora へ移行することを検討してみます。
現在の データベース
具体的な例があった方が分かりやすいので、移行対象の DB の情報を仮定しておきます。
- データベースの情報
- 利用状況
- CPU利用量：余裕あり
- ディスク利用量：余裕あり
- メモリ利用量：2GiB弱程度で安定推移
- システム稼働：時間帯や日による変化はなく、一定した稼働
RDS周りのサービス
具体的な話に入る前に、今日出てくるサービスの全体像を先にまとめておきます。
RDSには Aurora と 非Aurora の別があり、
さらに Aurora には、固定のスペックで稼働するプロビジョンドと、アプリケーションニーズに応じて動的にスペックが変わるサーバレスの別があり、
さらにプロビジョンドには、一般的な課金体系であるオンデマンドと、一定期間の利用を約束することで割引が受けられるリザーブドの別があり、
サーバレスには v1 と v2 の別があります。
この中から、今回のワークロードに適切なものを選択していきます。
Aurora と 非Aurora な RDS は何が違うの？
Aurora への移行の前段で、非 Aurora な RDS と Aurora はそもそも何が違うの？という方は、よくまとまっている記事があるので、こちらをご覧ください！ dev.classmethod.jp dev.classmethod.jp
Aurora の方が料金が高くなるケースもありますが、Aurora にしかない機能が多くあったり、パフォーマンスの優秀さから、Aurora への移行を検討するケースも多いのではないでしょうか。
Aurora を選択する場合の最初の分岐はプロビジョンド or サーバレスです。機能と料金の両面から比較していきます。
Aurora Provisioned vs Aurora Serverless
機能面
上に記載の通り、Auroraサーバレスには、v1 と v2 がありますが、公式docに以下の記載があるように、基本的には v2 はほとんど Aurora プロビジョンドと同等の機能を利用でき、v1 よりパワーアップしているので、v1 は検討の対象から除外します。
Greater feature parity with provisioned – You can use many Aurora features with Aurora Serverless v2 that aren't available for Aurora Serverless v1.
サーバレス v2 とプロビジョンドの機能の差を見ると、公式 doc に以下の記載があります。
Aurora プロビジョン済み DB インスタンスの以下の機能は、現在 Amazon Aurora Serverless v2 では使用できません。
・データベースアクティビティストリーム (DAS)。
・Aurora PostgreSQL のクラスターキャッシュ管理。apg_ccm_enabled 設定パラメータは Aurora Serverless v2 DB インスタンスには適用されません。
前者のデータベースアクティビティストリーム（DAS）は、DBネイティブの仕組みではなく、AWSの仕組みで監査ログを取得する機能です。（もっと深めたい方はこちら）
今回移行対象の DB は該当の要件はないのと、この機能が利用できるインスタンスタイプも限られているため（参考）、サーバレス利用にあたり問題はなさそうです。
後者のクラスターキャッシュ管理は、フェイルオーバーした際、旧ライターインスタンスが利用していたキャッシュを、昇格した新ライターインスタンスも継続利用できるようにすることで、フェイルオーバー時のパフォーマンス低下を防ぐ機能です。（もっと深めたい方はこちら）
こちらは PostgreSQL の機能なので、今回の検討では問題なさそうです。
サーバレス v2 を選択しても、機能面で致命的に不足している点はなさそうなので、次に料金面の比較をしてみます。
料金面
最適なスペックの選択
最初に、どのスペックで試算すべきかを考えます。
プロビジョンドの場合
前述の通り、現在は db.t3.medium で稼働していますが、その選択をしたのも数年前なので、プロビジョンドにおいても、あらためて最適なインスタンスタイプを考え直します。
おさらいですが、現在の DB は、CPU / ディスクは利用量に余裕あり、メモリ利用量が 2GiB 弱程度で安定して推移しているという前提でした。
メモリを基準に考えると、プロビジョンドのインスタンスタイプを選択する場合、以下あたりが候補になりそうです。（インスタンスタイプの一覧はこちら）
| インスタンスクラス | CPU(vCPU) | メモリ(GiB) |
|---|---|---|
| db.t2.small | 1 | 2 |
| db.t2.medium | 2 | 4 |
| db.t3.small | 2 | 2 |
| db.t3.medium | 2 | 4 |
| db.t4g.medium | 2 | 4 |
さすがにメモリが 2GiB のものをプロビジョンドで選択すると、すぐに拡張を考える必要がありそうなので、最低でも 4GiB はあった方が良さそうです。
t2 or t3 のような世代の選択については、以下の通り、できるだけ最新世代を選びます。
（出典：https://pages.awscloud.com/rs/112-TZM-766/images/C2-07.pdf）
※ T系を選択する場合は、世代によってバーストの仕様にも違いあるのでその点も注意が必要です。（詳細はこちら）
ここまで考慮すると、 db.t4g.medium が良さそうですね。
CPU が Graviton2 になる点がこれまでとは変わる点ですが、RDSの場合は、大きな影響はなさそうです。
（出典：https://pages.awscloud.com/rs/112-TZM-766/images/20210603-Instance_Choice_and_Graviton2.pdf）
サーバレスの場合
サーバレスには固定されたスペックがないため、ACU (Aurora Capacity Unit) という単位に対して課金されます。 1ACU = メモリ 2GiBで、設定可能な最小値は 0.5 ACU です。（ACU の詳細はこちら）
現状、メモリは 2GiB で安定推移しているので、今回は 1ACU で試算します。
プロビジョンドの場合は、拡張の負荷を考えて 4GiB としましたが、サーバレスの場合は勝手に拡張してくれるので、検討の負荷が減って良いですね。
試算
プロビジョンドとサーバレスv2のそれぞれの場合の1か月間の料金を試算してみます。
東京リージョンでの単価は以下のようになっています。前述の通り、プロビジョンドの単価は db.t4g.medium を前提にしています。
（Aurora の料金詳細はこちら）
ここでは基本項目だけ取り上げて試算しますが、その他にも金額に響く細かな要素はあるので、詳細は AWS Pricing Calucalator を利用して計算してみましょう。
- 試算前提
- プロビジョンド
- データベースインスタンス：USD 0.113 × 24時間 × 30日 = USD 81.36
- ストレージ：USD 0.12 × 50GB = USD 6.00
- IO：USD 0.24
- 合計：USD 87.60
- サーバレス v2
- データベースインスタンス：USD 0.2 × 24時間 × 30日 = USD 144.00
- ストレージ：同上
- IO：同上
- 合計：USD 150.24
サーバレス v2 の方が、データベースインスタンスの金額が2倍弱高いので、こう見るとやっぱり高いですね。。
サーバレスの良いところは、自動的に拡張するところなので、どのくらいキャパシティが必要か予測がつかないとか、管理対象が多く全てのキャパシティ管理は負荷が高いとか、そんなワークロードに向いていそうです。
Aurora をもっと安く使いたい
ここまでの検討で、Aurora プロビジョンドの db.t4g.medium を利用するのが濃厚です。
すると、次の検討観点はインスタンスをオンデマンドとするか、リザーブドとするかです。
観点は利用料金なので、Aurora をより安く使う方法を検討してみます。
リザーブドインスタンスを利用する
これは Aurora に限った話ではありませんが、一定期間の利用を確約する代わりに、インスタンスを安く利用できます。
移行先の db.t4g.medium のインスタンスについて、非 Aurora な RDS (オンデマンド)、Aurora (オンデマンド)、Aurora (リザーブド)で単価を比較してみます。リザーブドインスタンスの単価は、1年利用確約/前払い無しで算出しています。
データベースインスタンスの料金が、リザーブドではオンデマンドの85%程度なので、USD 75 / 月 程度まで削減できそうです。
前述の通り、現在は非 Aurora のオンデマンドインスタンスを利用していますが、それと比較しても少し安めに使えそうですね。
本当に MultiAZ が必要か検討する
前述の通り、現在の RDS は、MultiAZ 構成です。
上で算出した金額は、インスタンスが1つであることを前提としているため、実際は倍程度の金額がかかります。
RDS と Aurora は、アーキテクチャが大きく異なるため、それによって、SingleAZ構成としたときのリスクに多少の違いがあります。
（出典：https://aws.amazon.com/jp/blogs/news/webinar-bb-amazon-aurora-mysql-2019/]）
まず、RDS は公式に記載の通り、ストレージには EBS が利用されています。
Amazon RDS ストレージのハードウェア構成はどのようなものですか?
Amazon RDS は、データベースとログの格納に EBS ボリュームを使用します。
EBS は AZ に紐づいており、AZ 内の HW にレプリケートされています。
（出典：https://www.slideshare.net/AmazonWebServicesJapan/20190320-aws-black-belt-online-seminar-amazon-ebs]）
一方で Aurora は、インスタンス（コンピュートノード）とストレージは分離されており、インスタンスは 1AZ で構成されていても、データは 3AZ にまたがる 6つのノードに書き込まれます。
さらに、書き込みは 4/6、読み込みは 3/6 のノードが生き残っていれば、データベースとして問題なく稼働し、サービス影響が出ることはありません。
（出典：https://www.slideshare.net/AmazonWebServicesJapan/20190424-aws-black-belt-online-seminar-amazon-aurora-mysql）
つまり、RDS の場合は 1つの AZ のストレージに障害が起きたらサービス稼働に影響が出ますが、Auroraの場合は、残りの2つの AZ に存在するデータノードが無事ならサービス維持が可能です。
また、インスタンスに障害が起きた場合は、そのインスタンスが存在する同じ AZ に、10分未満で自動的に再作成されます。
DB クラスターに Aurora レプリカが含まれていない場合、障害イベントの発生時にプライマリインスタンスが同じ AZ に再作成されます。（中略）新しいプライマリインスタンスが再作成されると、サービスが回復します。これは、通常は 10 分未満で行われます。
しかし、1つの AZ 内の全てのストレージに障害が起きるケースは、大抵 AZ レベルでの障害なんじゃないかと思いますが、AZ レベルで障害が起きてしまった場合は結局手動で復旧するしかなく、サービス維持は不可能です。
プロビジョン済みまたは Aurora Serverless v2 クラスターに 1 つの DB インスタンスしか含まれていない場合、またはプライマリインスタンスとすべてのリーダーインスタンスが同じ AZ にある場合は、別の AZ に 1 つまたは複数の新しい DB インスタンスを手動で作成する必要があります。
というわけで、AZ 障害の場合も継続的にサービス提供可能とする場合は、Aurora であっても MultiAZ とするしかありませんが、可用性要件が比較的低いシステムの場合は、SingleAZ 構成とすることも検討してみてください。
最後に
RDS から Aurora への移行を検討する際の観点全部盛りでお届けしたつもりです。
結構な文字数になりましたがどなたかの参考になれば幸いです！
ALBへのクロスルート証明書インポートでインフラ基礎を学び直す
クロスルート証明書を扱う機会があり、仕組みを理解しようとインフラ基礎をお勉強し直したのでメモです。
全部盛りしたらえらい長さになりましたがご容赦ください。
TL;DR
ALBにクロスルート証明書をインポートするには、証明書チェーン欄に以下を設定してあげればいい。
—–BEGIN CERTIFICATE—– ・ 中間CA証明書の文字列 —–END CERTIFICATE—– —–BEGIN CERTIFICATE—– ・ クロスルート設定用証明書の文字列 —–END CERTIFICATE—–
こんな情報はググれば出てくるので、仕組みを理解します。
クロスルート証明書とは
クロスルート方式とは、従来の証明書階層で使用するルート証明書に加えて、クロスルート用の中間証明書を設定することにより、別のルート証明書にも接続可能とする仕組みです。
(引用元 : https://www.cybertrust.co.jp/sureserver/support/faq/442g976c4sgy.html )
この絵がとてもわかりやすいですね。(※図1)
証明書インポートのオーダー内容
「今回から認証局側で仕様が変わって、証明書がクロスルートになってます。証明書の更新作業お願いします。」という依頼とともに、計5種類のファイルを受領。
送られてきたファイルはこんな感じです。
証明書
|--{FQDN}.crt
|--クロスルート証明書
| |--CrossSignedRoot.crt
|--ルート証明書
| |--DigiCertGlobalRootCA.crt
| |--TrustedRoot.crt
|--中間証明書
| |--DigiCertCA.crt
図1に出てくる証明書の枚数と、 .crt ファイルの枚数は一致してるので必要なものは揃っていそうです。
分からないのは、ルート証明書が2枚あるので、2つある証明書チェーンのどちらのルート証明書であるか、という点です。
まずはこれを調べてみます。
証明書の階層関係を調べる
以下のコマンドで、手元にある証明書の情報を出力することが可能です。
openssl x509 -text -noout -in {CrtFileName}
色んな情報が表示されますが、注目するのは「Issuer」と「Subject」という項目です。
それぞれ「発行元」と「発行先」を示しており、誰が誰に対して発行した証明書なのかを確認することができます。
それぞれのファイルに対してコマンド実行し、該当の項目を抜粋した結果が以下です。
## {FQDN}.crt
Issuer: C = US, O = "DigiCert, Inc.", CN = DigiCert G5 TLS RSA4096 SHA384 2021 CA1 ★1
Subject: jurisdictionC = JP, businessCategory = Private Organization, serialNumber = xxxx-xx-xxxxxx, C = JP, ST = xxx, L = xxx, O = xxx, CN = abc.yyy.jp
## CrossSignedRoot.crt
Issuer: C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert Global Root CA ★2
Subject: C = US, O = "DigiCert, Inc.", CN = DigiCert TLS RSA4096 Root G5 ★3
## DigiCertGlobalRootCA.crt
Issuer: C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert Global Root CA ★2
Subject: C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert Global Root CA ★2
## TrustedRoot.crt
Issuer: C = US, O = "DigiCert, Inc.", CN = DigiCert TLS RSA4096 Root G5 ★3
Subject: C = US, O = "DigiCert, Inc.", CN = DigiCert TLS RSA4096 Root G5 ★3
## DigiCertCA.crt
Issuer: C = US, O = "DigiCert, Inc.", CN = DigiCert TLS RSA4096 Root G5 ★3
Subject: C = US, O = "DigiCert, Inc.", CN = DigiCert G5 TLS RSA4096 SHA384 2021 CA1 ★1
同じ文言には、★で同一の番号を振っています。
DigiCertGlobalRootCA.crt と TrustedRoot.crt は、発行元と発行先が同じなので、自己証明書 = ルート証明書であることが分かります。
(受領したファイルのディレクトリ構成通りですが。)
また、ある証明書の発行元が、ある証明書の発行先であったりすることがわかります。
例えば、
{FQDN}.crt の 発行元 が ★1 で、
DigiCertCA.crt 発行先 が★1 なので、
DigiCertCA.crt -> {FQDN}.crt の階層順になることが分かります。
この情報から階層関係を整理すると、以下の感じになります。
まずは、階層関係を読み解くことができました。
証明書チェーンに何を記載するか
AWSの場合、ACMというサービスを利用して証明書をインポートします。
画面はこんな感じになってます。
証明書本文である {FQDN}.crt を除いて残り4種の証明書があるわけですが、
前述の通り、ググると、中間証明書 -> クロスルート用証明書の形式でインポートすればよいと書いてあります。
とはいえ、「今回はルート証明書も連携されてきているけど、それはインポートしなくてもいいのか。。？」という一抹の不安が残るので、もう一段深めます。
証明書チェーンの仕組み
結論、ルート証明書はサーバ側に設定する必要はありません。
なぜかを説明するために、まずデジタル証明書の仕組みを軽くおさらいします。
(引用元：https://www.infraexpert.com/study/security6.html )
上記サイトから要約して抜粋。
Webサーバ側で公開鍵と秘密鍵を生成する。
公開鍵と各種証明書を認証局に渡し、デジタル証明書を発行依頼する。
クライアントPCからWebサーバに対して接続要求を行う。
クライアントPCに対して、Webサーバはデジタル証明書を送付する。
クライアントPCは、受信したデジタル証明書が正しいものかを確認するために、認証局の公開鍵を使用して、秘密鍵による署名部分の復号を行い、検証する。
※ 認証局の公開鍵を含んだデジタル証明書は、代表的な認証局のデジタル証明書の場合、クライアントPCのブラウザにインストールされている。インストールされていない場合、ブラウザで警告表示される。
上図は中間認証局が存在していないですが仕組みは同じです。
大事なのは最後の記載です。
※ 認証局の公開鍵を含んだデジタル証明書は、代表的な認証局のデジタル証明書の場合、クライアントPCのブラウザにインストールされている。インストールされていない場合、ブラウザで警告表示される。
デジタル証明書の正しさは中間認証局によって保証され、中間認証局の正しさはルート認証局によって保証され、ルート認証局の正しさはルート認証局自身によって保証されています。
そして、どのルート認証局を信頼するかは、あらかじめOSやブラウザにインストールされています。
OS/ブラウザへのプリインストール時点で不正が起きるのは考えづらいので、安心して利用ができます。
なお、信頼するルート認証局(=ルート証明書)を自分で追加することも可能です。
企業の場合、独自で認証局を立てるケースも多く、それはOSやブラウザに信頼の対象としてもともと入っているわけがないので、自分で追加する必要があります。(参考)
というわけで、ルート証明書はサーバ側にインストールしなくてもいいことがわかったので、ググった通りにインポートして作業完了です。
クライアントから証明書を確認してみる
インポートできたところで、クライアント側からコマンドで証明書を確認してみます。 サーバにインストール済の証明書を確認するコマンドは以下です。
openssl s_client -connect {FQDN}:443 -showcerts
出力される情報には証明書の階層情報が以下の番号で振られているので、
「0」：サーバー証明書
「1」：中間 CA 証明書
「2」：クロスルート用中間 CA 証明書
0,1,2の数字があれば、正しくクロスルート証明書をインポートできていることになります。(参考)
出力結果がこちら↓
[root@ip-172-16-0-51 ~]# openssl s_client -connect abc.yyy.jp:443 -showcerts ..... --- Certificate chain 0 s:/jurisdictionC=JP ... /CN=abc.yyy.jp ..... 1 s:/C=US ... /CN=abc.yyy.jp ..... 2 s:/jurisdictionC=JP ... /CN=abc.yyy.jp .....
バッチリですね〜！！
加えて、今回対象のシステムでは1つのALBに対して、異なるFQDNを持つ2つのアプリをぶら下げているので、もう1つのFQDNに対しても確認しておきます。
[root@ip-172-16-0-51 ~]# openssl s_client -connect def.yyy.jp:443 -showcerts ..... --- Certificate chain 0 s:/jurisdictionC=JP ... /CN=abc.yyy.jp ..... 1 s:/C=US ... /CN=abc.yyy.jp ..... 2 s:/jurisdictionC=JP ... /CN=abc.yyy.jp .....
お気づきでしょうか。
階層の数字は正しいのですが、紐づいている CN が、対象のFQDNと対応していません。
なぜ。。
答えは、SNI (Server Name Indicator) という仕組みの中にありました。 SNIとは、
一つのサーバーで複数のドメイン名を使用する場合に、複数のSSL証明書を運用できるようにするSSL/TLSの拡張仕様です。
(引用元 : https://www.stream.co.jp/blog/blogpost-38236/ )
まさしく今回のケースですね。
SSL/TLSの通信は以下のシーケンスで行われ、サーバからクライアントへ証明書が送られるのは「Certificate」メッセージの中ですが、この段階では、サーバは、クライアントがアクセスしたいドメインの情報が分からないため、適切な証明書を送付することができません。
(引用元 : https://milestone-of-se.nesuke.com/nw-basic/tls/https-structure/)
そこで生まれた仕組みがSNIで、前段階でアクセス先ドメインをサーバ側に伝えることによって、単一サーバで複数ドメインを設定できるようになりました。
というわけで、今回も単一のALBに複数のFQDNが紐づいており、単純にコマンドを打っても、ALB側からするとどのFQDNに対してアクセスされているのかが分からないため、明示してあげる必要があります。 servernameオプションで指定ができます。
結果が以下↓
[root@ip-172-16-0-51 ~]# openssl s_client -connect def.yyy.jp:443 -showcerts -servername def.yyy.jp ..... --- Certificate chain 0 s:/jurisdictionC=JP ... /CN=def.yyy.jp ..... 1 s:/C=US ... /CN=abc.yyy.jp ..... 2 s:/jurisdictionC=JP ... /CN=def.yyy.jp .....
ばっちりです✌️
なぜクロスルート証明書なのか
ちょっと話がそれますが、今回色々分からなくてたくさんググっていると、目につく関連キーワードが。。
最近の仕様変更でクロスルートになったという話だったのでトレンドなのかと思いきや非推奨だなんて。
もう少し深めてみると、そもそもクロスルート証明書が生まれた理由は暗号鍵の鍵長にあるようです。
コンピュータの計算能力が増すにつれて、解読を防ぐため鍵長はどんどん長くなっていきましたが、クライアント側がそれに追いつけず、最高強度の 2048bit が扱えないケースが生まれました。
そのため、2048bit が扱えるクライアントでは、セキュリティ強度の高い 2048bitで、そうでないクライアントは 1024bit で、と使い分けられるよう、クロスルート証明書が生まれたとのこと。
それも2010年には完全に 2048bit に移行しており、クロスルートを残しておく = 脆弱なルートが残っているということになるため、非推奨ということみたいです。(参考)
ではなぜ DigiCert はこのタイミングでクロスルート証明書に変えたのかという疑問が残りますが、ちゃんとアナウンスがありました。
2023年3月9日（木）、日本時間午前2時より、TLS/SSL証明書を第五世代ルート(G5ルート)および中間CA証明書階層への移行を開始します。(中略) 新しいG5ルートが旧来のデジサートルート証明書同様に普及するまでの間、(中略) デジサートが提供のクロスルート証明書をインストールいただくことを推奨いたします。
新たなG5ルートという証明書チェーンへの移行期間ということでした。謎が解けました。
実機を確認してみる
証明書チェーンの移行期間ということですが、OS/ブラウザにプリインストールされているルート証明書はどうなっているのでしょうか。
「証明書チェーンの仕組み」の項でも記載した通り、信頼するルート認証局の情報はあらかじめインストールされているはずですが、
2023/3月から適用される新しい証明書階層となると、現状の実機がどうなっているか気になります。
配置されている場所はOSによって異なるようですが、今回ログイン対象は AmazonLinux2 です。
[root@ip-172-16-0-51 ~]# cat /etc/pki/tls/certs/ca-bundle.crt | grep Digi # DigiCert Assured ID Root CA # DigiCert Assured ID Root G2 # DigiCert Assured ID Root G3 # DigiCert Global Root G2 # DigiCert Global Root G3 # DigiCert High Assurance EV Root CA # DigiCert Trusted Root G4
「証明書の階層関係を調べる」の項で出力した、2つのルート証明書情報を再度おさらい。
# DigiCertGlobalRootCA.crt Issuer: C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert Global Root CA Subject: C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert Global Root CA # TrustedRoot.crt Issuer: C = US, O = "DigiCert, Inc.", CN = DigiCert TLS RSA4096 Root G5 Subject: C = US, O = "DigiCert, Inc.", CN = DigiCert TLS RSA4096 Root G5
DigiCertGlobalRootCA.crt の CN に記載の「DigiCert Global Root CA」が、実機の確認結果の中にもありますね！
しかし、もう1つの TrustedRoot.crt の CN に記載の 「DigiCert TLS RSA4096 Root G5 」は実機にはありません。
後者はこれから移行していくG5ルートのルート証明書であり、既存のサーバにはまだ情報がないってことですね。
クロスルートの場合、どちらか一方のルートが確認できれば正常にアクセスできるため、片方が成り立ってなくても問題はありません。
まとめ
クロスルート証明書のインポートをテーマに、インフラ基礎を深掘ってみました。
最後に、思っていることを小声で書きます。
デジタル証明書の目的は大きく2つです。
- 通信データの暗号化
- 運営者の実在性の確認
証明書にはEV, OV, DVと3種類あります。
(引用元 : https://www.cybertrust.co.jp/blog/ssl/knowledge/certificates-types.html )
違いは、認証方法にあります。EVが最も多くの認証を必要とするので、認証レベルは高いです。
しかし、これら3種の証明書のセキュリティ強度には、違いはありません。
DV証明書利用の場合、「2. 運営者の実在性の確認」の観点では、相対的に認証レベルが低くなります。 が、EV証明書利用の場合、かつてはアドレスバーの鍵マークが緑色になっていたり、組織名が表示されたり、利用者にとって分かりやすい表示になっていましたが、今はそれもなくなっているケースが多いです。(参考)
ユーザーは、わざわざ鍵マークをクリックしないと違いは分かりません。
かつ、EV証明書の発行には十数万かかり、これが毎年発生します。
さらに、AWS であれば、AWS 発行の証明書 (DV) を利用することができ、これを使えば証明書はAWSが勝手に更新してくれます。
兼ね合いではありますが、できるだけマネージドにした方が楽だなあと思います。
とはいえ、今回はインポート作業を経て、個人的にはとても勉強になりました。
日々のタスクをこなすことも大事ですが、分かるまで深めてみる時間もまた良いです。
丁寧に教えてくださったプロジェクトの皆様に大感謝でした！
