Open4

[TIL] 6. AWS EC2

wakakawakaka

EC2 Launch w/ SysprepによるAdminパスワード変更

EC2 Launch w/ Sysprepで初期化される主要な設定値は以下に示す通り。

  • マシンSID
  • ホスト名
  • Administratorユーザのパスワード

実際に以下の図に従ってEC2 Launchを実行した結果を示す。

  1. EC2 Launch w/ sysprep 前
    • SID:S-1-5-21-2664791155-3644586663-611401752-500
    • HOSTNAME:EC2AMAZ-7N7A18J
    • Admin password:v6SJRb3velkbQ=8eZsRmz2K983)9%)CP

  2. EC2 Launch w/ sysprep 後
    • SID:S-1-5-21-3472494662-2007414125-432707687-500
    • HOSTNAME:EC2AMAZ-73HRH61
    • Admin password:yud9yRo6Bkra3oP?bnZ&V4IqfAdGw8)z

  3. AMI作成 → EC2作成 → EC2 Launch w/o sysprep 後
    • SID:S-1-5-21-3472494662-2007414125-432707687-500
    • HOSTNAME:EC2AMAZ-73HRH61
    • Admin password:cRjE7L=P&JSP6XWb;w)IBIw4$HD7ObQ=

Administratorのパスワードが変わるということに注意が必要。EC2 Launch w/ sysprep 後のサーバにおいては、「Windowsパスワードの取得」機能により、キーペアを用いてAdministratorのパスワードを入手できる。しかし、「EC2 Launch w/ sysprep→AMI作成→AMIからサーバ作成」という手順により作成したサーバの場合には「Windowsパスワードの取得」機能を利用できない

Windows EC2インスタンスの初期パスワード設定はEC2の初期化処理の中でEC2Config/EC2Launchの機能として行われています。バックアップ用として取得されるAMIイメージではすでに初期化処理は実施済みであり、このイメージを元に新しいインスタンスを作成しても初期化処理が行われないため、AWSの基盤がWindowsのパスワードを知る方法も無く、この機能は利用できません。

この手順を踏んだ場合には、AMIから作成したサーバにキーペアでログインした後に、EC2 Launch w/o sysprepを用いてパスワードを再度生成する。これにより「Windowsパスワードの取得」機能を利用できるようになり、AMIから起動したEC2のパスワードを取得できる。

https://dev.classmethod.jp/articles/about-custom-ami-windows-password/

https://repost.aws/ja/knowledge-center/ec2-windows-password-not-available-error

wakakawakaka

EBSスナップショットは最新版のみで復元可能

EBSスナップショットは増分バックアップで行われる。一般的に増分バックアップは、最初にフルバックアップを取得し、その後増分のデータだけをバックアップしていくので、最初のフルバックアップが失われると復元することができない。

しかし、AWSの増分バックアップの場合には概念が異なり、最初のフルバックアップを削除しても、次に古いバックアップがフルバックアップを保持していくような設計となっている。

https://aws.amazon.com/jp/blogs/news/webinar-bb-amazon-ebs-2019/

https://aws.typepad.com/sajp/2014/04/trainingfaqbest10.html

wakakawakaka

EC2詳細モニタリングの勘違い

詳細モニタリングとは、詳細モニタリングを有効にしている期間のデータポイントのみ、1分間隔で表示することを許可する機能

基本モニタリングでも詳細モニタリングでもデータポイントは1分間隔に送信されているが、基本モニタリングの場合には期間を1分間隔で表示することはできず、最小でも5分単位で丸められる。

https://dev.classmethod.jp/articles/amazon-ec2-instance-basic-monitoring-data-point-per-minute/

wakakawakaka

Reserved Instances と Savings Plans

"Regional Reserved Instances" vs "Zonal Reserved Instances"

  1. Zonal RIと比較して、Regional RIではAZを変更することができる。つまり、Regional RIでは対象サーバのAZを変更した場合にも継続してRIが適用される。
  2. Regional RIにはインスタンスサイズの柔軟性がある。仮にインスタンスサイズを変更したとしてもリージョン/OS/インスタンスファミリーに変更がなければ、正規化係数に従い、自動でRIが適用される(Zonal RIの場合にも「RIの変更」※をすることでインスタンスサイズの変更は可能)。

※ プラットフォームがLinux/UNIXであり、現旧でRIのフットプリントが同じ場合に変更可能。
  正規化係数2のt2.medium*2 → 正規化係数4のt2.large*1に「結合」可能(FPは4で同等)
  正規化係数8のt2.xlarge*1 → 正規化係数4のt2.large*2に「分割」可能(FPは4で同等)

"Standard Reserved Instances" vs "Convertible Reserved Instances"

  1. Convertible RIはStandard RIと比較して、割引率が低い。
  2. Convertible RIでは「RIの交換」※が可能であり、「RIの変更」では変更できない属性に関しても対応可能である。

※ 差額を支払い、同等以上のRIにする必要がある。

"EC2 Instance Savings Plans" vs "Compute Savings Plans"

  1. EC2 Instance SPはConpute SPと比較して、割引率が高い。
  2. EC2 Instance SPでは、インスタンスファミリ―とリージョンを指定することで、台数/インスタンスサイズ/OS/テナンシーに関係なく、Saving Plansによる割引が適用される。
    ex) リージョンをus-east-1、コミット額を10USD/h、インスタンスファミリ―をm5と設定した場合には、us-east-1内の全てのm5インスタンスに対して10USD/hまで割引料金が適用される。
  3. Compute Savings Plansは最も柔軟性の高いモデルであり、インスタンスファミリ―やリージョン、OSなどを変更したとしても、Saving Plansによる割引が適用される。

https://dev.classmethod.jp/articles/ec2-reserved-instances-savings-plans-comparison
https://qiita.com/nasuvitz/items/1317495450e91c987cba#ec2-instance-savings-plans