AWS 割とちゃんとサービスをリリースする時にやらないといけないことメモ


概要

  • 下記の構成でAWSでサービスをリリースするためにやらないといけないことをメモ的にまとめる。
    • HTTPSでALBにアクセスされる事を想定している。

構成

  • 構成図

    • そこまで大規模サービスではない想定で、EC2インスタンスの中にMySQLを立てることにする。(RDS連携は記載しない)
    • ソースコードはGithubからcloneで取ってくるようにする。

  • 利用するAWSのサービス一覧

    • VPC
      • VPC
      • サブネット
      • ルートテーブル
      • インターネットゲートウェイ
    • S3
      • バケット
    • IAM
      • ユーザー
      • ロール
    • Route53
      • ホストゾーン
      • ドメインとIP(ALB)の紐付け
    • ACM
      • ssl証明書の取得
    • EC2
      • インスタンス
      • Elastic IP
      • セキュリティグループ
      • ロードバランサー
      • ターゲットグループ
  • 利用するAWS以外のサービス一覧

    • お名前ドットコム
      • ドメインの購入
      • ネームサーバーの切り替え

ざっくりとした作業順

VPC

  1. VPCの作成
    1. 任意の名前、任意のリージョン、IPアドレスの範囲を指定してVPCを作成する。
    2. 参考リンク → AWS VPCの作成
  2. サブネットの作成
    1. 任意の名前、IPアドレスの範囲、リンクさせるVPCを選び、2個のサブネットを作成する。
      • IPアドレスの範囲はVPCのIPアドレスの範囲内になっている必要があるはず。(多分)
    2. 2個のサブネットはそれぞれ別々のアベイラビリティゾーンに設置する。
    3. EC2インスタンスは片方のサブネットにしか設置しないが、ALB設置のために2個のサブネットを作成する。
      • ALBは2個以上のパブリックサブネットが無いと設置できない。
      • パブリックサブネットは複数のアベイラビリティゾーンにまたがっている必要がある。
    4. 参考リンク → AWS VPCの中にサブネットを作成する
      • こちらの記事では2個作成するサブネットのうち一つはプライベートサブネットになっているので注意
  3. インターネットゲートウェイの作成
    1. 任意の名前で作成し、すでに作成しているVPCと紐付ける。(アタッチする。)
    2. 参考リンク → AWS インターネットゲートウェイの作成
  4. ルートテーブルの作成
    1. 任意の名前で作成する。
    2. 作成したルートテーブルと、サブネット2個を関連付けする。
    3. ルートを追加して0.0.0.0/0の時ターゲットを作成したインターネットゲートウェイに向ける。
      • サブネット内部からインターネットに向けてアクセスする場合のルートを作ってあげる。
    4. 参考リンク → AWS ルートテーブルの作成とルートの追加

S3

  1. バケットの作成
    1. 一意のバケット名を付けてバケットを作成、アクセス権限のブロックはオフに設定する。

    2. バケット内にアップロードされたコンテンツを外部に公開したい場合、バケットポリシーに下記を記載する。

      {
          "Version": "2012-10-17",
          "Statement": [
              {
                  "Sid": "PublicReadGetObject",
                  "Effect": "Allow",
                  "Principal": "*",
                  "Action": "s3:GetObject",
                  "Resource": "arn:aws:s3:::バケット名/*"
              }
          ]
      }
      
    3. 参考リンク → AWS S3バケットの作成

IAM

  1. EC2 → S3接続用IAMロールの作成
    1. 任意の名前でEC2に割り当てるIAMロールを作成する。
    2. 参考リンク → AWS IAM ロールの作成
  2. EC2 → S3接続用IAMユーザーの作成
    1. 任意の名前でEC2に割り当てるIAMユーザーを作成する。
    2. ユーザー作成時にダウンロードできるCSVはしっかりダウンロードして保存しておく
    3. 参考リンク → AWS EC2 → S3接続用のIAMユーザーの作成

お名前ドットコム-1

  1. ドメインの購入
    1. 任意のドメインを購入しておく、勉強用なら1円のドメインを1年だけ購入するとかで良いと思う。

Route53

  1. ホストゾーンの作成
    1. 購入したドメインを登録して「パブリックホストゾーン」を選択して作成する。
    2. 参考リンク → AWS Route53 ホストゾーンの作成

お名前ドットコム-2

  1. ネームサーバーの変更
    1. 作成したホストゾーンのNSレコードのルーティング先に記載されている4個のルーティング先をお名前ドットコムに設定する。(ルーティング先の最後の.は不要なので注意)
    2. 参考リンク → お名前.com ネームサーバーをAWS Route53に変更する

EC2

  1. セキュリティグループの作成
    1. 任意の名前で作成、インバウンドルールに下記アクセスを許可するルール定義(メールサーバーとのやり取りとかがある場合、任意でルール追加)
      • タイプ:SSH(22ポート) ソース:0.0.0.0/0
      • タイプ:HTTP(80ポート) ソース:0.0.0.0/0
      • タイプ:HTTPS(443ポート) ソース:0.0.0.0/0
    2. 参考リンク → AWS Webサーバー用のセキュリティグループを作成
  2. インスタンスの作成
    1. 作成したVPC、パブリックサブネット、セキュリティグループを当ててEC2インスタンスを設置する。
    2. 参考リンク → AWS EC2 AmazonLinux2にApacheを入れる
  3. インスタンスへのIAMユーザー割り当て
    1. インスタンスへssh接続し、作成したIAMユーザーのアクセスキーとシークレットアクセスキーを$ aws configureコマンドを使って登録する。
    2. 参考リンク → AWS EC2 AmazonLinux2インスタンスにIAMの情報を登録する
  4. インスタンスへのIAMロール割り当て
    1. 作成したIAMロールをEC2に割り当てる。
    2. 参考リンク → AWS EC2へIAMロールを紐付け
  5. Elastic IPアドレスの作成
    1. Elastic IPを用いてグローバルIPアドレスを固定する。
    2. 固定したグローバールIPアドレスをEC2インスタンスに紐付ける。
    3. 参考リンク → AWS Elastic IP 固定化したグローバルIPアドレスを取得してEC2インスタンスに割り当てる
  6. ターゲットグループの作成とEC2の割り当て
    1. 任意の名前で下記に記載する情報で作成
      • Basic configuration
        • ターゲット:インスタンス
        • Protocol:HTTP
        • Port:80
        • VPC:作成したPVC
        • Protocol version:HTTP1
      • Health checks
        • Health ckeck protocol:HTTP
        • Health ckeck path:/
    2. インスタンスを設定
      1. 次の画面でインスタンス一覧が出る。
      2. ターゲットに指定したいEC2インスタンス(作成したもの)を選択して「Include as pending below」をクリックする。
      3. 選択したEC2がReview targetsのリストに移動するので「Create target group」ををクリックしてターゲットグループを作成する。
  7. ロードバランサーの作成
    1. 任意の名前で下記に記載する情報で作成(特筆してないものはデフォルト)
      • Basic configuration
        • Scheme:Internet-facing
        • IP address type:IPv4
      • Network mapping
        • VPC:作成したVPC
        • Mappings:作成したサブネット(別のアベイラビリティゾーンのものを2個以上選択)
      • Security groups
        • Security groups:デフォルトのものが設定されているので削除 → 作成したEC2用セキュリティグループを設定
      • Listeners and routing
        • デフォルトのHTTP:80のを変更する。
          • Protocol:HTTPS
          • Port:443
          • Default action:作成したターゲットグループを選択
      • Secure listener settings
        • Security policy:ELBSecurityPolicy-2016-08
        • Default SSL certificate:From ACMを選択 → ACMで取得したsslを選択

ACM(Certificate Manager)

  1. ssl証明書の発行
    1. 購入したドメインを使ってパブリック証明書をDNS検証でリクエストする。
    2. 発行されたら先に作成したRoute53のホストゾーンにAレコードを追加してドメインを登録する。ルーティング先は作成したALBを設定する。)
    3. 参考リンク → AWS Certificate Managerでssl証明書を取得する

使ったAWSサービスの簡単なメモ

VPC系

VPC
  • AWSの中で仮想のネットワークをつくれるやつ
サブネット
  • VPCの中に作れる更に小さいネットワーク
  • アプリケーションのサブネットとDBのサブネットは本来分けるべき
  • 更にアプリケーションのサブネットはパブリックからアクセスできる、DBのサブネットはアプリケーションのサブネットからじゃないとアクセスできないようにすることが望ましいっぽい
ルートテーブル
  • サブネット内部殻のネットワークトラフィック経路を導くためのもの
インターネットゲートウェイ
  • VPCをインターネットとつなぐもの

S3

バケット
  • データ保管しておくところ、外付けHDDとかSSDみたいな感じ
  • 別にEC2の中にデータ保管しておいてもいいけど、外付け状態だと管理が楽だったり、EC2がスケールして複数台合った時とかもEC2の中にだけデータ合っても困るから

IAM系

IAMユーザー
  • 我々がAWSにログインするときに使っているものがIAMユーザーの認証情報
  • 人間がブラウザからAWSにログインする時以外にもシステムがAWSにログインするときにも使う
  • でも人間がブラウザからログインする時のIAMユーザーとシステムがAWSにログインする時のIAMユーザーはユーザー作成の段階で若干違う
  • 人間がブラウザからログインできるからって同じアカウントでシステムがログインできるとは限らない、逆にシステムがAWSログインに使っているアカウントで人間がブラウザうからログインでできるとは限らない。
    • IAMユーザー作成時にブラウザからのログイン許可、システムのログイン許可をチェックマークで選ぶところがあるのでそれ次第
IAMロール
  • IAMユーザーやEC2に割り当てられる権限のグループのこと
  • 権限はその名の通り、「あなたは管理者なのでこのページ見れますよ」「あなたは一般ユーザーなので請求周りのページは見れませんよ」とかの機能制限のやつ
  • AWSはAWSがプリセットで登録してくれている権限だけでもかなりの数が存在する。
  • それを「Aさんは請求、EC2、S3だけ見れるように」「BさんはEC2、S3だけ見れる様に」「CさんはEC2、S3、Route53だけ見れるように」みたいに一個一個のIAMに割り当てていったら管理大変
  • そこで「EC2閲覧可能、S3閲覧可能」(これを仮称「メンバーロール」とする)というIAMロールを作ることで、「Aさんは請求とメンバーロール」「Bさんはメンバーロール」「CさんはメンバーロールとRoute53」というふうにまとめられる。

Route53

  • どのドメインがどのリソース(IPやALB)に紐付いているかのルールを記載しておくもの

ACM

  • ssl証明書の発行をしてくれる

EC2系

インスタンス
  • 仮想のWebサーバー
  • 今回はVPCの中のサブネットの中に構築したけど、別にそんな事しなくてもEC2だけで構築できる
Elastic IP
  • パブリックIPの固定をする事ができる
セキュリティグループ
  • EC2にアクセスするルールのグループ
ロードバランサー
  • ユーザーアクセスのトラフィックを振り分けたりしてくれるやつ
  • ユーザーアクセスを後述するターゲットグループに紐づくリソースに渡す
  • ターゲットグループのリソースが健康かどうか確認もしてくれる。不健康なリソースにはアクセスさせないとかを設定によっては勝手にやってくれる(ヘルスチェック)
  • 別に振り分けを絶対させないと行けないわけではない。
  • ただ、ユーザーからきたアクセスをロードバランサーを通すことでロードバランサーでsslの検証とかしてくれる。
  • 分かってしまえばそんなに難しいものではないので一回分かっちゃえば全然大丈夫、恐れなくていい
ターゲットグループ
  • ロードバランサーにアクセス来た時にどこに渡せばいいかの設定が書いてあるもの
  • 昔はロードバランサーに直接EC2とかのターゲットを指定してたらしい

参考文献