AWSまとめ

はじめに

今回の記事は、復習も兼ねたアウトプット記事です。
Drow.ioで構成図も書いてみました。よかったらみてみてください。

概要：
このサイトでは、リロードを繰り返すと ALB がリクエストを振り分け、マルチ AZ に配置したサーバー A / C のどちらかに振り分けれらるようになっています。
構成図の画像は CloudFront を経由し、OAC（Origin Access Control）を使って CloudFront からしか読めない Private な S3 に置いています。
また検証用として、CloudFront の Requests メトリクスを CloudWatch Alarm で監視し、1 分以内に 30 リクエストを超えた時点で SNS を経由して Lambda が起動するようにしています。
Lambda は incident.json というS3のバケット上に置いてあるファイルを更新し、通常ページの初回表示時にその状態ファイルを確認して、incident の場合は sorry ページへ切り替わる構成にしています。

---

記事の最後に、敢えてAWSで一からインフラを構築せずに別のサービスを使ってホスティングしたサイトも用意しました。
是非ご覧ください。

インプットしたAWSサービス一覧 🧠

• VPC
  AWSのネットワークを考えるときの土台。まずここを理解しないと全体像が見えにくいと感じた。家を建てるための土地のようなもので、CIDR(サイダー)でIPの範囲を定義する。VPCの場合、5つほど強制的に予約されSubnetの場合は、ネットワークアドレスやブロードキャストアドレス用などにIPを先に予約されたりする。
  計算方法としては、そもそもIP自体が32ビットで表現されており/24とすると32ビット中24ビットをネットワークで占有するという意味で自由に使えるのが32-24で８ビット分になり2の8乗で256パターン使用できるがそのうち前述した通りVPCだと5つ予約されているので-5で251個、Subnetだと2つ予約されてるので254個のIPを自由に使用できるという計算になる。特に、CIDRは、AWSでサービスを構築する際に頻繁に出てきたので押さえておきたい。

例）

VPC（-5予約済み）
  /16 → 自由なビットが16個 → 約65,531個
  /24 → 自由なビットが 8個 → 251個
  /32 → 自由なビットが 0個 → 1台だけ指定

Subnet（-2予約済み）
  /16 → 自由なビットが16個 → 約65,534個
  /24 → 自由なビットが 8個 → 254個
  /32 → 自由なビットが 0個 → 1台だけ指定

• Subnet
  VPCという土地を用途ごとに区画整理したものがサブネットで、その土地に建てるWebサーバーなどは、基本的にPrivate Subnet に置いて、必要な通信だけ通す構成にしたかったりするが個人開発だと NAT Gateway のコストが高い印象、別の選択肢としてNATインスタンス（EC2でNATを自前で立てる）というやり方もあるが管理コストなども考慮しないといけなかったりする。

  • NAT(Network Address Translation) IPアドレスを変換する仕組みでPrivate Subnet内でEC2インスタンスをたてるなどしたらPrivateなIPを振り分けられるので外部ネットワークと通信する際などにPublicなIPに変換して通信する必要がありその際に必要。
    NAT Gatewayは、AWSのマネージドサービス。

• Internet Gateway (IGW)
  VPC をインターネットにつなぐための出入り口。Public Subnet にEC2を置くだけでは、通信はできない。
  このIGWを設けてRouteTableを設定することで外部ネットからsshでの接続やHTTPでの接続ができるようになったりする。

• NAT Gateway
  便利だけど高い。個人用途だと、NAT インスタンスを立てたほうが安く済む可能性はある。ただし、そのぶん管理の手間は増える。

• Route Table
  どこ向きの通信をどこへ流すかを決める設定。
  例えば、0.0.0.0/0 → IGWで外部向け通信をインターネットに流す、10.0.0.0/16 → localでVPC内通信はそのまま内部で完結させるといった設定などをする。

• Security Group
  なぜか、接続できないなと思ったらここのインバウンドルールの設定ミスなことが多い。
  ここでもまたCIDRが出てくる。

• EC2
  t2.micro（無料枠あり） や t3.micro は個人検証で使いやすい。インスタンス本体だけでなく EBS（Elastic Block Store）付属のストレージの料金は、別途発生するので注意。

• ALB
  サービス全体の名前としては ELB があり、その中の1つとして ALB を選ぶイメージ。L7 （アプリケーション層）での振り分けやヘルスチェックを考えると、かなり便利。
  あと、コンソール上でリソースマップという欄を見るとALBがどのターゲットグループ（EC2やECSタスク）に振り分けているかが視覚的にわかりやすい。

• Auto Scaling Group
  オートスケーリングにもいくつか考え方があると知れた。
  今回のASGは、スケールアウト（（水平）インスタンスを増やす）/ スケールインを自動化するサービスで
  基本手動とのことだが、スケールアップ / ダウン（垂直）インスタンスのスペックを上げ下げなど
  その他にもタスク（コンテナの塊）単位でスケールイン/アウトするECSサービスもある。

• IAM
  サーバーや Lambda に権限を持たせたり（IAM ロール）、メンバーごとの権限を管理したり（IAM User）と、
  地味だけどかなり重要と感じた。
  毎回この権限の設定をするのが面倒だったが細かく設定しないとセキュリティーに関わるので注意。

• RDS
  高い。とにかく高い。一時停止できても7日で自動再起動するというトラップ付き。使わないときは完全に削除かスナップショットだけ残してRDSを削除した方がいい。Auroraを触ってクラスターを組んでみようかと思ったが通常のmysqlより高そうだったので今回はmysqlをたてるに止まった。
  EC2をmysql化するよりこのマネージドサービスを使った方がバックアップやフェイルオーバーなどの管理がしやすすく必要なメトリクスもデフォルトでとってくれてたりするので自分で設定しなくていいのもありがたい。

• S3
  S3は、ただのファイル置き場ではなく、ログ保存・静的サイトホスティング・Lambda のトリガー元など幅広く使えて、OAC（Origin Access Control）で CloudFront 経由のアクセスのみに制限する方法や、バケットポリシーまで理解しておくと自由度がかなり上がるなと感じた。今回は Lambda のトリガー元や CloudTrail のログの保存先として使用してみたりしたが他のAWSサービスとの連携がスムーズで触っていて一番楽しかった。

• SDK
  boto3 など。Lambda から AWS リソースを触るときに、必要になる。

• AWS CLI
  S3 バケットまわりなどを操作する際には、個人的にはだが GUI のほうが安心だと感じた。
  ただ、繰り返し作業やスクリプト化したい作業がある場合などには、CLIの方が圧倒的に速いので、慣れてきたらCLIに移行するのが良さそう。

• CloudFront
  CDN として便利なのはもちろん、今回のようにパスごとに origin を分ける入口としてもかなり便利だった。

• Route 53
  DNS 管理のサービで、レコード単位で様々な設定ができたりする。
  主にAレコードなどでEC2のサーバーのipにドメイン名を紐付けたり、www.example.comをCNAMEレコードを使ってexample.comで表示できるようにしたりなど突き詰めるとかなり奥が深そうだなと感じた。

• Lambda
  小さな処理をイベント駆動でつなぐときに便利で、SNS や CloudWatch などと組み合わせたりコンソール上でテストを作成して実行したりそのテスト自体を保存していつでも再実行できたりするので使いこなすとアイデアの幅が広がりそうだと感じた。

• CloudWatch
  最初は無料寄りの監視サービスだと思っていたが、使い方によっては普通に有料になるので注意が必要だった。
  あと、アラートが思ってたより簡単に作れることを知れた。

• SNS
  マネージドサービスの便利さを感じやすいサービス。通知用途だけでなく、サービス間の中継としても使いやすい。

• SQS
  今回は深く触れていないが、非同期処理やバッファとして重要なサービスだと感じた。

• CodePipeline
  　CI/CDの流れをまとめて自動化するサービスで、GitHubなどのコード取得 → Build（CodeBuild）→ Deploy（CodeDeploy）の流れを簡単に作れて、コードをpushするだけでデプロイまで自動で流れる状態にできる。

• CodeBuild
  ビルドして、そのアーティファクト（成果物）を S3 に置いてくれるサービス。主にCode DeployがそのS3に置いた成果物を取ってきてサーバーにばら撒くというのが主な流れ。
  buildspec.yamlでビルド方法などを設定する。

• CodeDeploy
  EC2 に対して段階的に配る、一気に配る、などの制御ができる便利なサービス。デプロイ方法を細かく調整したいときに強いなと感じた。
  appspec.yamlでファイルの配置先やデプロイ時に実行するスクリプトを定義したりする。

• CloudFormation
  GUIでやるより圧倒的に速く、再現性も高い。YAMLで構成を書いてデプロイすると、関連リソースをまとめて管理できてその単位をスタックというみたいだ。今回触っていて一番感動したサービスのひとつではあったのだが、一気にリソースを削除できたり作成したりできる分まずはGUIでの操作に慣れてから使いたいと感じた。

豆知識 🫘

コンソールの内容を操作したり確認できるモバイルアプリがある。

• EC2やRDSのインスタンスを起動・停止できたりアラートの確認や操作ができかなり便利だと感じた。

Cloudfront

• CloudFront のメトリクスを使用したアラートをcloudwatchで作成しようとすると初見だと迷うことがある。
  というのもCloudFrontのアラートは、 バージニア北部 (us-east-1) で扱う 前提になることがあり、
  普段使用するであろう東京リージョンでCloudWatchを見てしまうとメトリクスを見失うという罠がある。

補足：
  オリジン = 「どこからコンテンツを取得するか」の設定。
  ビヘイビア = 「どのパスをどのオリジンに流すか」の設定。
  ディストリビューション = CloudFrontの設定全体をまとめる単位

次使ってみたいサービス

Cognito

• ユーザー認証・管理をAWSが肩代わりしてくれるサービスで
• 無料枠は月50,000ユーザーまである。

App Runner

コンテナやソースコードを渡すだけで、インフラを全部AWSが面倒を見てくれるサービス。
ECSだとVPC・サブネット・タスク定義・ALB・Auto Scalingなどを自分で設定する必要がるが、App Runnerはそれを全部省略できて手軽にデプロイできる。

感想 ☕️

初めは、Linuxのコマンドを学習しようと考え手を動かし始めたが、次第にMac OS上でコマンドを叩いても学習効率があまりよくないと感じ、実際にEC2インスタンスをたててその中でコマンドの学習をしたほうがいいのではと考え、AWSに触れてみたところ便利な機能が沢山あることを知れました。

AWSのIAMには、単に一つのAWSアカウントに複数人入れるようにするという機能だけでなくサーバー自体に権限をあたえたり外したりできたりルートユーザー以外のユーザーに細かい権限の設定ができたりなど、一つのサービスを取ってもかなり細かいところまでカスタマイズできる自由度の高いサービスが多いなという印象を持ちました。

ここまで、VPCからCFNまで横断的にAWSを学習してみて思ったがネットワーク関連の理解があるとさらに飲み込みが早かったかもと感じたので次回は、ネットワーク系の知識を理解した上で、AWSで何か本格的なサービスを構築してみようと思います。

おわりに 🚪

今回の学びを通してあえてAWS以外のサービスを使用して公開してみたサイトです。
よろしければ、アクセスしてみてください。
（サイト内の記事などは作成中で、現在表示しているのはダミーです）

今回は、NeonというDBを使用してvercelにホストしてみています。
同じドメインでもレジストラが違うだけで$7/年も違ったりしてたので
ちゃんとレジストラの比較は、したほうがいいなという教訓。

おまけ ☕️

よく使ったコマンド集

$ systemctl enable システム名　👈インスタンス起動時に指定したシステムを常に起動させるコマンド
$ systemctl start システム名　👈システムの開始。
$ systemctl stop システム名　👈稼働中のシステムを停止。
---
$ dnf update　
$ dnf install インストールしたいもの
$ dnf list
---
$ yes > /dev/null & 👈サーバーに負荷かけてテストしたい時に使用。
yes
「y」を無限に出力し続ける
> /dev/null
その出力を/dev/nullに捨てる。
---
dig example.com　👈ドメインがDNSに紐づくまで時間がかかっていた際に確認のため使用した。

参考になった記事一覧