はじめに

昨日aws sysops合格しました。
勉強方法は先人の記事が色々あるし、私もそれを参考にしただけなのでそれ以外で記事を書きたいと思って、今回はこの試験勉強で「タメになった」、「こんなのあったんだ」みたいに思ったものを記載していこうと思います。

sysopsって日々の業務に活かせるのかとか、そういう参考にしてもらえればと思います。
ちなみに私はAWSを使って運用業務を主にやってますが、ちょいちょい役に立ってます。

書き方について

私基準でサービスで分けれるものはサービス、セキュリティなど試験項目のようにまとめた方がわかりやすそうなのは試験項目のような感じで分けようと思います。もっとこうした方が良いとかあれば指摘ください。

注意

2021年11月時の知識なので今後変わってくる可能性があるので注意してください。

勉強してタメになったと思ったもの列挙

この記事読んでsysopsについて興味が持てたら資格取得を目指すのおすすめです。
勉強して仕入れた知識で、実際に触ったことがないものについては「らしい」とか少しボカした記載してます。あしからず。

CloudWatch

EC2インスタンスに対してCloudWatch エージェントをインストールすると、オペレーティングシステムレベルのメトリクスを収集することができる
アプリケーションのログからキーワードの文字が出力されたらEC2を自動再起動することがCloudWatchのアラームを使えば出来るらしい
CloudWatchのクロスアカウントクロスリージョンダッシュボードを使えば、違うアカウントのものもまとめて見れるようになるっぽい

移行

VMware vCenter Serverでホストされる仮想マシンのホストもAWS Server Migration Serviceを使えば移行可能

データベース

Amazon Aurora は、標準的な MySQL データベースと比べて最大で 5 倍、標準的な PostgreSQL データベースと比べて最大で 3 倍高速らしい。だからAuroraは他のRDSより値段が高い
RDSのイベントサブスクリプションって機能でSNSと組み合わせて特定の操作に対する通知設定が可能。セキュリティグループの変更も通知出来る

ネットワーク

3つ以上のVPCで相互に接続出来るようにするには、それぞれでピアリング接続設定をする必要がある（別のVPC経由でまた別のVPCには移動出来ない）
VPCピアリングは異なるリージョン、アカウント同士でも接続出来る
Cloudfrontのビューワーレポート機能でどの端末（スマホ、パソコン）、どのブラウザ（chrome、firefox）、OS、国からのアクセスがあるかそれぞれ確認出来るみたい

CloudFormation

CloudFormationは実行に失敗した場合、それまでの処理をロールバックする。
- 補足：terraformには無い
CloudFormationのAutoScalingGroup配下のインスタンス入れ替えで、AutoScalingRollingUpdate というポリシーを使えば最低1台は稼働させ、1台ずつ入れ替えるらしい。

セキュリティ

特定のIPからのアクセスを拒否するにはネットワークACLを使う（セキュリティグループで拒否設定は出来ない）
AWS Configを使用すれば、設定したポリシー違反のものがあれば通知出来る仕組みがあるみたい。SSHポートが開放されてる場合に通知を送るみたいなことも出来る
Trusted Advisorの機能はサポートプランによってチェックしてくれる項目数が異なる（ビジネス以上でフルセット）
EBS、RDS、EFS、S3などのストレージタイプの中で一番セキュリティが強固なのはS3

S3

S3は保存オブジェクトを複製して耐障害性を上げている。リージョン内の複数のデータセンタに複製する
S3のバケットバージョニングが設定されたバケットは中身を空にしただけでは削除出来ない
バケットが空でもバージョニングが有効になっている場合、削除マーカーというのを削除しないとバケットを削除出来ない

EC2、EBS

EC2インスタンスを起動させた際にボリュームのステータスチェックで「データ不足」と出た場合、実際のデータ不足以外にもボリュームチェック中の時も出力される可能性があるらしい
- 時間経過で正常になる可能性がある
リージョン間でキーペアは共有されていない
- インポートキーペアを利用すると、別リージョンにキーペアの複製をすることが可能
EC2立ち上げ時に容量が無いと「InsufficientInstanceCapacity」エラーメッセージが出るらしい
EBSのデータ量を表すステータスで、EBSWriteOpsは書き込み完了数、EBSWriteBytesは書き込まれたバイト数を表してる。総数とバイト数の違い
EC2フリート(fleet)っていう複数のインスタンスを制御する機能がある
- 制御されてるEC2インスタンス群を一括起動、一括削除ってことが出来るみたい
- fleetの意味は艦隊
インスタンスを再起動すると同じホストで起動される。停止→起動をすると別のホストで立ち上がる。
- EC2のステータスチェックが失敗した時に再起動だと問題解決せず、停止→起動で解決するのはこの動きの違いが起因してる
EBSスナップショットの保存上限は100,000
立ち上げてるEC2が廃棄予定のホスト上にあると、AWSからメールで連絡が来る。記載の時間帯に強制的に停止されてしまうみたい。回避方法はその時間までに停止、起動を行う
EC2のスナップショットは増分バックアップで、手動と自動何回取ってもデータ量に変化が無ければ費用に変わりはない

ELB

ALBのみURLの文字列から処理を割り振るサーバを指定出来る（コンテントベースルーティング）
NLBはALBとCLBの既知の制約を解決するためにリリースされた負荷分散サービス
突発的な負荷が予想される、ELBのIPが変動してほしくない→NLB
リクエストごとに処理を振り分けるサーバを変えたい、証明書は自動更新したい→ALB
急激なアクセス増が予想される時用にELBの暖機運転（pre-warming）申請をすることで事前にELBをスケールアップさせられるらしいけど、NLBではこの申請は無い
- NLBは元々大規模アクセス用に作られている為、申請せずとも対応してくれる

Auto Scaling

Auto Scalingで可用性を高めることが可能。
- 例えば踏み台サーバにAuto Scalingの設定をして台数を1にしておけば、何らかの事情で踏み台サーバが落ちたら自動的に1台作成される
Auto Scalingには3種類の方法がある
- 簡易スケーリング：1つのメトリクスに対して1種類のスケーリング調整値を指定する
  - 例：CPU50%になったら一台追加する（現在は非推奨）
- ステップスケーリング：1つのメトリクスに対して複数種類のスケーリング調整値を指定する
  - 例：CPU60%なら1台追加、70%なら2台追加、80%なら3台追加といった設定が出来る
  - 簡易よりはステップスケーリングを使った方が良いみたい
- ターゲット追跡スケーリング
  - 目標値のみ設定
  - 例：CPU40%を維持するように記載するだけ。目標値を満たすように自動的にスケーリングされる
Auto Scalingのスケジュール設定で重複した設定を入れると競合を知らせるエラーメッセージが出力される
Auto Scalingインスタンスのモニタリング設定で、コンソールから設定するとデフォルトが基本モニタリング（5分間隔）、CLIで設定すると詳細モニタリング（1分間隔）になる
- GUIで設定するかCUIで設定するかでデフォルト設定されるモニタリングが異なる

費用

EFSではライフサイクル管理により選択したライフサイクルポリシーにもとづいて、保存データを自動的に低価格なEFS IA ストレージクラスに移動させることが出来る
Cost Exprolerの機能で今後3ヶ月間の予想費用を出すことが出来る

その他

SQSは受け取ったメッセージをデフォルトで4日間保存する。送り先に数日送れなくても受信可能後に送ってくれる。
AWS Chatbotを使えばslackにAWS障害情報を連携出来るらしい