第131回 雲勉【オンライン】 AWSを9年触ってきて経験した 落とし⽳、ハマったポイント

０．⾃⼰紹介 2 n アイレット株式会社 クラウドインテグレーション事業部 池⽥ 雅彦( @kiwi_clp ) • ユーザ系SIerで11年オンプレミスを中⼼としたインフラエンジニアとして活動 • アイレット歴3年 VMware Cloud on AWSやNutanix Clusters on AWSなどマイグレーション案件などを担当 • 好きなAWSサービス[VMware Cloud on AWS/Direct Connect/Application Migration Service] • Japan AWS Top Engineers Network 2023

1．EC2の誤った削除 3 ・停⽌と終了のオプションがあるが終了=停⽌と勘違いして終了を選択してしまう。 ・AWS初⼼者にありがちなミス。 「インスタンスを終了」を選択してEC2を削除してしまう ■対策 ・EC2のオプションで「終了保護」を有効にしておく。 ・IAMユーザの権限で削除が出来ないように権限を絞っておく。 https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/terminate-instances-considerations.html#Using_ChangingDisableAPITermination AWS公式ドキュメント 終了に関する考慮事項

2．リージョン選択のミス 4 ・本来デプロイしたいリージョンではなく意図しないオレゴンリージョンなどにデプロイしてしまう。 ・初級者じゃなくてもありがちなミス。 デフォルトで選択されるオレゴンリージョンにEC2などをデプロイしてしまう ■対策 ・右上のリージョン設定を都度⾒るようにする。 ・デフォルトのリージョンを設定しておく。 [⻭⾞マーク]→[その他のユーザ設定]→[デフォルトのリージョン] https://docs.aws.amazon.com/ja_jp/awsconsolehelpdocs/latest/gsg/select-region.html AWS公式ドキュメントϦʔδϣϯΛબ୒͢Δ

3．EC2、Lambdaからメール送信が出来ない 5 ・EC2、LambdaからTCP25でメール送信する場合は制限される。 ・Spamリレーを防ぐ対策でありユーザ保護のため必要な制限。 TCP25経由ではスパム防⽌対策でメールが送信出来ない ■対策 ・TCP25経由でメール送付する場合は「Eメール送信制限解除申請フォーム」でリクエストする。 ・TCP587(サブミッションポート)を使ってメール送信を⾏う。 ・SESを使ってメール送信をする。 https://repost.aws/ja/knowledge-center/ec2-port-25-throttle AWS re:Post Amazon EC2 Πϯελϯε·ͨ͸ AWS Lambda ؔ਺ͷϙʔτ 25 ͷ੍ݶΛղআ͢Δʹ͸Ͳ͏͢Ε͹Α͍Ͱ͔͢? Point ・リージョン毎に送信制限解除申請が必要 ・制限解除が出来て送信出来ても受信者側で迷惑メール認定がされる可能性が⾼い。

4．EC2のIPアドレスを固定すると接続出来なくなる 6 ・OS上のネットワーク設定でIPアドレスを静的設定するのはサポート外。 ・OS側のネットワーク設定とENIの設定に不整合が⽣じて通信が取れなくなる。 ・OS側はDHCP設定が必須。 ・復旧する場合はセカンダリENIをアタッチしてセカンダリENI経由で接続してDHCP設定に戻す。 OS設定でIPアドレスを静的設定すると通信がすべて出来なくなる ■対策 ・IPアドレスを指定したアドレスを割り当てたい場合はEC2の⽴ち上げ時にENIの詳細設定で固定したい IPアドレスを設定する。 ・外部アドレスの場合はElastic IPをアタッチする。 https://repost.aws/ja/knowledge-center/static-private-ip-windows AWS re:Post Amazon EC2 Windows Πϯελϯεʹ੩త IP ΞυϨεΛׂΓ౰ͯΔʹ͸Ͳ͏͢Ε͹Α͍Ͱ͔͢?

5．EC2をリストアするとIPアドレスが変わってしまう 7 ・IPアドレス、MACアドレスがアプリケーション側要件で固定化が必要な場合、アタッチされたENI が削除されて新しいENIが割り当てられるとIPアドレス、MACアドレスが変わってしまい アプリケーション側に影響が⽣じてしまう。 EC2削除時はデフォルトでアタッチされたENIが削除されてしまう ■対策 ・ENI(ネットワークインターフェイス)の設定から「終了時の動作を変更」から削除設定を無効化する。 ・リストア時に使っていたENIを指定してEC2を起動する。 https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/using-instance-addressing.html AWS公式ドキュメント Amazon EC2 Πϯελϯεͷ IP ΞυϨεࢦఆ

6．EBSのディスクタイプは最適なタイプを選択する 8 ・IOPS/スループット要件が低くgp3/gp2などのSSDが不要であれば安価なHDDタイプを選択する。 ・スループットが必要な場合、gp2よりスループット最適化ボリュームのst1が適切となる。 要件によっては標準のgp3またはgp2のタイプだとオーバスペックになる https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/ebs-volume-types.html AWS公式ドキュメント Amazon EBS ϘϦϡʔϜͷछྨ ボリュームタイプ 価格/1GB IOPS スループット 汎⽤SSD gp3 $0.096/GB 1IOPS $0.006 1MBスループット $0.048 標準3,000IOPS 追加料⾦で最⼤16,000IOPS 標準125MB/s 追加料⾦で最⼤1,000MB 汎⽤SSD gp2 $0.142/GB 100IOPS〜16,000IOPS 33.33GiB以上は1GBあたり3IOPSが 割り当て 128MiB/s〜250MiB/s 170GiB以上の割り当てで250MiB/s ま でバースト 334GiB以上で250MiB/s スループット最適化HDD St1 $0.054/GB 最⼤500IOPS ※容量で変動 最⼤500MiB/s ※容量で変動 Cold HDD Sc1 $0.018/GB 最⼤250IOPS ※容量で変動 最⼤250MiB/s ※容量で変動

7．EBSの変更後の再変更が時間がかかる 9 ・初回のボリューム変更の適⽤は最⻑で24時間かかる場合がある。 多くの変更は数分で変更が⾏われる。 ・ボリュームのサイズ縮⼩は出来ない。IOPS、スループットは減少可能。 ・ボリュームの変更のキャンセルは出来ない。 ボリューム変更後は少なくとも6時間再変更が出来ない https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/requesting-ebs-volume-modifications.html AWS公式ドキュメント EBS ϘϦϡʔϜ΁ͷมߋͷϦΫΤετ 通常時ボリュームステータス 変更中ボリュームステータス

8．暗号化したEBSのAMIを他アカウントで共有出来ない 10 ・デフォルトのAWS管理キー(マネージドキー)で暗号化されたスナップショットで バックアップされたAMIを共有することは出来ない。 ・共有する場合はCMK(カスタマーキー)で暗号化してカスタマーキーの利⽤権限を共有先の アカウントで許可する。 別アカウントは暗号化キー(KMS)のアクセス権がないためEBSの復号が出来ない https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/WindowsGuide/sharingamis-explicit.html AWS公式ドキュメントಛఆͷ AWS ΞΧ΢ϯτͱͷ AMI ͷڞ༗

9．KMSで暗号化したEBSがアタッチしたEC2をLambdaなどで起動出来ない 11 ・EBSが暗号化されているEC2を起動した際に起動エラーが発⽣した場合はKMSへの許可が ない場合がある。 ・デフォルトではルートアカウントにのみKMSキーのアクセス権限が付与される。 LambdaがKMSの権限にアクセス出来ずEC2の起動が出来ない https://repost.aws/ja/knowledge-center/encrypted-volumes-stops-immediately AWS re:Post҉߸Խ͞ΕͨϘϦϡʔϜ͕ఴ෇͞Εͨঢ়ଶͰΠϯελϯεΛελʔτ͢ΔͱɺΠϯελϯε͸͙͢ʹʮىಈ࣌ͷΫϥΠΞϯτΤϥʔʯͱ͍͏ΤϥʔͰఀࢭ͠·͢ɻ ■対策 ・Lambdaなどで利⽤するIAMロールにKMSのアクセス権限を許可する。

10．MGNでオンプレミスの仮想マシンを移⾏するにはEBS暗号化が必須 12 ・EBS暗号化は必須であり暗号化なしでEC2へのデプロイは出来ない。 ・別アカウントにAMIを共有しない場合は問題ないが予定がある場合はCMKをMGNのオプションで 指定することで別アカウントにAMIを共有できる。 ・復号化する場合はレスキューインスタンスを⽤意してddコマンドなどでディスクを複製する。 MGNで移⾏したEC2のEBSはデフォルトのAWS管理キーで暗号化される https://aws.amazon.com/jp/application-migration-service/faqs/ AWS Application Migration Service のよくある質問

11．EBS暗号化済みのスナップショットをリージョン間転送すると⾼い 13 ・利⽤状況によって変動するが暗号化なしのスナップショットを転送する場合圧縮が⾏われる。 ・EBS暗号化済みのスナップショットを転送する場合は圧縮が⾏われない。 ・リージョン間転送は1GBあたり$0.09と⾼い。 暗号化なしの場合はデータ転送量が圧縮されるが暗号化済みの場合は圧縮されない https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/ebs-copy-snapshot.html AWS公式ドキュメント Amazon EBS εφοϓγϣοτͷίϐʔ Ҿ༻ IUUQTEPDTBXTBNB[PODPNKB@KQ"84&$MBUFTU6TFS(VJEF&ODSZQUJPOIUNM

12．⼤きなインスタンスサイズのEC2が起動出来ない 14 ・「RunInstances オペレーションを呼び出すときにエラー (InsufficientInstanceCapacity) が発⽣し ました (最⼤リトライ回数: 4 に達しました)。現在、リクエストされたアベイラビリティーゾーンには ⼗分な容量がありません。」というエラーで起動が出来ない事象。 ・特殊なインスタンス、サイズのでかいインスタンスを使っている際に発⽣する問題。 起動を⾏うAZでキャパシティ不⾜でEC2を起動できない https://repost.aws/ja/knowledge-center/ec2-insufficient-capacity-errors AWSre:Post EC2 インスタンスの開始時または起動時の InsufficientInstanceCapacity エラーをトラブルシューティングする⽅法を教えてください ■対策 ・オンデマンドキャパシティ予約を作成しておく。 ・インスタンスタイプを変更して再度起動を⾏う。 ・ゾーンRIを事前に購⼊しておく。

13．T系のインスタンスを利⽤しているとCPUパフォーマンスが低下する 15 ・T系インスタンスはCPU利⽤率が⾼くなるとクレジットを消費してバーストを⾏う。 ・クレジットが無くなるとCPU制限がかかりパフォーマンス低下が⽣じる。 CPUクレジットが枯渇してCPU制限がかかった https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/burstable-performance-instances-unlimited-mode-concepts.html AWS公式ドキュメント Unlimited Ϟʔυͷ֓೦ ■対策 ・T系インスタンスを使わない。 ・Unlimitedを有効化して無限バーストさせる。 →Unlimitedを有効にした状態で恒久的にCPU利⽤率が⾼いとM系の⽅が安いケースがある。

14．AWSアカウント毎にAZ IDが変動する 16 ・AZ ID違いでVPC Peeringを接続するとAZ間通信料が発⽣する。 ・AZ障害が発⽣した際にap-northeast-1aだけど影響がない、影響があるアカウントに分かれる。 アカウント跨ぎで1a同⼠接続しても実はAZ IDが違うことがある https://docs.aws.amazon.com/ja_jp/ram/latest/userguide/working-with-az-ids.html AWS公式ドキュメント AWS ϦιʔεͷΞϕΠϥϏϦςΟʔκʔϯ ID ■対策 ・AWSアカウント開設時にAZ-IDがゾーンに割り当てられるため変更は不可 確認⽅法は[EC2]→[サービス状態]から確認が可能

15．Amazon Linux 2023にTera termからSSH接続出来ない 17 ・Tera Term4.0ではrsa-sha2-256、rsa-sha2-512が利⽤できないため。 Amazon Linux 2023はSSH-RSA署名が無効化されている https://docs.aws.amazon.com/ja_jp/linux/al2023/ug/ssh-host-keys-disabled.html AWS公式ドキュメントσϑΥϧτͷ SSH αʔόʔઃఆ ■対策 ・EC2側でSSH-RSA署名を有効化する。 →有効化は推奨されていない。 ・Tera Term5.0を利⽤する。 ・Tera Term 4.107以降のバージョンを利⽤する。

16．SQL Server on EC2はSQL ServerはCドライブにインストールされている 18 ・SQL Server on EC2のAMIから⽴ち上げるとCドライブにプログラムとデータベースが作成されている。 Dドライブなど別のドライブに変更する場合はサーバのCドライブに同封されているインストール ファイルからインストールし直しが可能。 格納場所は「C:¥SQLServerSetup」 ※以前はサポートにメディアの提供をリクエストする必要がありました。 ・⽇本語済みイメージは「Windows_Server-2019-Japanese-Full-SQL」などで検索 Dドライブに変更する場合は再インストールが必要 https://docs.aws.amazon.com/sql-server-ec2/latest/userguide/sql-server-on-ec2-amis.html AWS公式ドキュメントσϑΥϧτ 'JOEB42-4FSWFSMJDFOTFJODMVEFE".*

17．Windowsインプレースアップグレードを実⾏すると操作不能に 19 ・アップグレード時にエディションを変更してプロファイルが変更になる。 ・⽇本語OSに英語OSイメージでアップグレードするとプロファイル変更になる。 コンソール画⾯を確認するとプロファイルの変更画⾯で⽌まっていた https://repost.aws/ja/knowledge-center/ec2-windows-in-place-upgrade AWS re:Post EC2 Windows インスタンスのインプレースアップグレードを実⾏する⽅法を教えてください。 ■対策 ・Microsoft、AWSのドキュメントを確認してアップグレード要件を満たす。 ・アップグレード失敗に備えてAMIの取得を⾏っておく。 ・事前に複製したEC2でアップグレード検証を⾏う。

18．EC2をリストアするとEBSのパフォーマンスが低下する 20 ・スナップショットから作成されたボリュームは初回のブロックアクセス時にS3からブロックデータ をダウンロードする仕組みのためEBSのパフォーマンス低下が発⽣する。 ファーストタッチペナルティが発⽣して初回のブロックアクセスが遅い https://aws.amazon.com/jp/blogs/news/new-amazon-ebs-fast-snapshot-restore-fsr/ AWS公式ブログ 新機能 – Amazon EBS Fast Snapshot Restore (FSR) ■対策 ・事前に対象のスナップショットのFSR機能を有効にしておく。 ・リストア後、ddコマンドなどですべてのブロックにアクセスを⾏う。 Point ・FSRを有効にすると1時間毎に課⾦が発⽣する。 ・FSRを有効にできる数はクオータで制限されている。

19．FSRを有効にしてリストアをしたがパフォーマンス低下が発⽣する 21 ・FSRを有効化してリストア、その後に同じスナップショットを所有するAMIから2台⽬のサーバを 起動したがFSRのクレジットが溜まっておらずFSRが有効になった状態でリストア出来ていなかった。 FSRのクレジットが貯まる前にリストアしてしまった https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/ebs-fast-snapshot-restore.html AWS公式ドキュメント Amazon EBS ߴ଎εφοϓγϣοτ෮ݩ ■対策 ・CloudWatchのメトリクスで「FastSnapshotRestoreCreditsBalance」を確認したうえでリストア を⾏う。

20．NLBでエンドポイントのIPにアクセスすると1AZにしか振り分けられない 22 ・NLBはAZ毎にアクセスするエンドポイントが⽣成される。 特定のAZのエンドポイントにアクセスするとクロスゾーン負荷分散がオフの場合はエンドポイントが 所属するAZに属するターゲットグループにしかアクセスが通らない。 クロスゾーン負荷分散がオフになっていた https://docs.aws.amazon.com/ja_jp/elasticloadbalancing/latest/network/target-group-cross-zone.html AWS公式ドキュメントλʔήοτάϧʔϓʹର͢ΔΫϩεκʔϯෛՙ෼ࢄ ■対策 ・クロスゾーン負荷分散を有効化する。 ただし、正常なAZが異常が⽣じているAZの影響を受けないように明⽰的にオフにすることもある。 Point ・ENIの2IPをDNS登録してラウンドロビンアクセス をする構成であれば問題はない。

21.RDSのストレージの利⽤容量が急激に増えていく 23 ・⼤量のレコード登録、更新⼀括処理などが実施されており⼤量の監査ログが排出されていた。 ・ストレージの⾃動拡張を設定していたのでRDSの動作に影響はなく気づくのが遅れた。 データベースの監査ログを取得しておりログが肥⼤化していた https://repost.aws/ja/knowledge-center/rds-postgresql-pgaudit AWSre:Post PostgreSQL Λ࣮ߦ͍ͯ͠Δ Amazon RDS DB ΠϯελϯεΛ pgaudit ֦ுػೳΛ࢖༻ͯ͠؂ࠪ͢Δʹ͸Ͳ͏͢Ε͹Α͍Ͱ͔͢? ■対策 ・監査ログの取得は⾏わない。 ・アプリケーション側でログのチューニングを⾏う。

22.CloudWatch metrics/logsの料⾦が⾼い 24 ・CloudWatch logsへの取り込みは1GBあたり$0.76と⾼額。 ・メトリクス取得は1,000件ごとに$0.01だが監視SaaSサービスなどと連携すると費⽤がかさむ。 ログの取り込み容量が多くCloudWatch料⾦が⾼騰した https://repost.aws/ja/knowledge-center/cloudwatch-logs-bill-increase AWSre:Post CloudWatch Logs ͷ੥ٻֹ͕ٸʹ૿Ճ͍ͯ͠Δͷ͸ͲͷϩάάϧʔϓͰ͔͢? ■対策 ・排出するログを絞る。 ・低頻度アクセス($0.38/GB)に出⼒するように変更する。

23.オンプレミスから特定のEC2への通信が出来ない 25 ・オンプレミス→Direct Connect→Direct Connect Gateway→Trasnit Gateway→Trasnit Gatewayア タッチメントの通信でプライベートサブネットaz-aへのルーティングでもプライベートサブネットaz-cの Transit Gatewayアタッチメントを経由して通信して通信の制限がされていた。 ・どちらのTransit Gatewayアタッチメントを経由するかなどの通信ロジックは⾮公開。 ・同じサブネットでも通信できるEC2と出来ないEC2があり特定に時間がかかった。 ・169.254.xx.xxのDirect Connectルータ側のIPでtracerouteも⽌まっていて特定に時間がかかった。 NACLを有効にしていることでTGWの通信が⼀部ブロックされていた https://docs.aws.amazon.com/ja_jp/vpc/latest/tgw/tgw-best-design-practices.html AWS公式ドキュメント Transit Gateway ઃܭͷϕετϓϥΫςΟε ■対策 ・NACLを利⽤しない。 ・Transit Gatewayアタッチメント専⽤サブネットを作成(推奨)し、NACLは適⽤しない。

26 23.オンプレミスから特定のEC2への通信が出来ない

24.Windowsライセンスのアクティベーションがリストア後出来ない 27 ・スナップショットからAMIを作成して作成したAMIからEC2をリストアしたところLinux機として EC2が認識しており、Windowsライセンスで利⽤するKMSサーバに接続が出来なかった。 ・ストレージパフォーマンスも低下が確認出来た。 ・Windowsのライセンス課⾦もされないためライセンス違反の状態となった。 スナップショットからAMIを作成、リストアをするとLinux機として認識してしまった https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/WindowsGuide/Creating_EBSbacked_WinAMI.html AWS公式ドキュメントカスタム Windows AMI を作成する ■対策 ・Windows機はスナップショットからAMIを作成しない。 ・Linux機として認識している場合復旧は不可能。稼働しているEC2のAMIを取ってリストアしても Linux機として認識されるので詰む。 ・CドライブのEBS付替も⾮推奨なのでWindows機として認識していた状態のAMIからリストアをして Dドライブなどの付替をする。

28 ・コンソールの翻訳を信じない。 ・理論上問題ないと判断しても公式ドキュメントなどを確認して⾮推奨じゃないか確認。 ・オンプレミスで出来たこともAWSで出来るとは限らない。 ・時にはオンプレミスで経験した知識をクリアにしてクラウドネイティブ思考に。 ・コストカットの意識を常に持つ。 ・暗号化が本当に必要か考える。KMSは結構はまりがち。 ・NACLは極⼒使わない。制限したければSGやNetwork Firewallを使う。 ・ハマるのは仕⽅ない。ハマった後の⾏動を意識する。 ・ハマった時はナレッジを社内共有、社外に発信する。 25．まとめ

動画URL 29 n 動画タイトル 第131回 雲勉 AWSを9年触ってきて経験した落とし⽳、ハマったポイント n 動画URL https://youtu.be/meCGZ5MKmWI