2020-04-20

AWSをやっていく

ここんところ個人開発ではFirebaseを使ってサーバーレス構成にすることが多いけど、やはりAWSをはじめとするクラウドサービスを使えると構築できる幅が広がるので、AWSもガチっていきたい
そんなわけで最近AWSを一から学習している
この記事はそのメモです

AWSについて

  • Amazonが所有する「オンプレミスサーバー」(物理サーバー)の一部を借り、EC2と呼ばれるサーバーの役割を持つ仮想領域を使うことができる

    • ストレージやDBも同じように借りて使うことが可能
    • 要はインフラやアプリ開発に必要な機能が、オンデマンド(インターネット上から即時に使える)のパーツサービスとして提供されている
    • 各機能をパーツのようにオンライン上に組み合わせて、自分に必要な構成を実現することができる
    • (サーバーを購入し、サーバーを構築することを「オンプレミス」と呼ぶ(クラウドの対義語))
  • サービスには「マネージド型」「アンマネージド型」の二種類存在する

    • マネージド型

      • スケーリング、障害耐性、可用性がサービスに組み込まれていて、AWS側で管理されている

        • 管理が楽だが、設定が限定的であるという特徴がある
      • 代表的なサービス:Route53
    • アンマネージド型

      • スケーリング、障害耐性、可用性を利用者側で設定、管理する必要がある

        • 柔軟に設定を行えるが、管理が面倒である
      • 代表的なサービス:EC2
  • AWSは各国や地域にデータセンターを設け、インフラを提供する場所を「リージョン(世界22箇所)」単位で区切り提供している(物理的に隔離されたAWSの拠点)

    • リージョン

      • 日本には東京と大阪リージョンがある

        • 基本的にリージョンはそれぞれ物理的に隔離されているが、リージョン間は専用のネットワークで接続されているので、連携は十分可能
      • リージョンによっては、AWSの最新の機能がリリース後即使えないことがある

        • アメリカにあるリージョンが最速で、東京リージョンなどはリリースにタイムラグがある
      • 海外のリージョンを使うことは可能だが、そのリージョンの国の法律に影響される可能性も考慮する必要がある

        • 例:中国は政府の要請に従い、データを提供する義務が生じる(中国内のデータの持ち出し制限が存在するなど)
    • AZ(アベイラビリティーゾーン)

      • 1つのリージョンの中に、複数の独立したインフラの拠点が存在し、それをAZと呼ぶ

        • 東京リージョンには4〜5くらい存在している模様
        • 1つのリージョンには2つ以上のAZがある
      • 同リージョン内のAZ同士は低レイテンシーのリンクで接続されている
      • 1つのAZが物理的なデータセンターとなっている(数千のサーバーを収容)

        • AZにある物理インフラを仮想化してユーザーにインフラの機能を提供している(すなわちAWSの実態はこれ)
        • 1つのAZでサービスを利用していると、データセンター停止によるサービス停止の可能性があるので注意
        • 従って複数のAZで分けて信頼性の高いシステム構成にするのが基本的なAWSアーキテクチャ設計方針となる

          • しかし、同一AZ内でしか共有されない設定なども多いので、システム間の連携や共有は一部制限されてしまう
          • どのサービスがAZを跨げるのかなどを把握することが重要
    • エッジロケーション(150以上)

      • アベイラビリティゾーンの中にさらにエッジロケーションというより細かい拠点がある
      • キャッシュなどを利用する際のさらに小さなエンドポイント

        • CloudFrontやLambdaなど

AWSアカウントを作成したあと、すぐにやるべきこと

基本的にはIAMページへ移動し、IAMのダッシュボードにある「セキュリティステータス」を指示に従い完了していくことになる

1

+αでいくつかやっておくといいことがある。
具体的に以下の対応を行う

  1. ルートアカウントの停止と、IAMユーザーの作成

    • 最初emailで登録したアカウントのこと(emailとパスワードでログインするユーザー)
    • ルートアカウントは所謂管理者権限を持つアカウントなので、なんでもできてしまう
    • 日常的に使うことはまずない(使う時は契約情報の変更とか、クレカ情報の変更とか、根本的な部分の変更時に使うだけ)
    • ルートではないIAMユーザーを必要な分だけ作成し、基本はそちらを使ってもらう

      • 1つのルートAWSアカウントの中に、複数のIAMユーザーを作ることができる
      • 権限はアカウントを使う人の権限に応じた権限をつける

        • 権限はグループに付与したり、ユーザーに直接付与したりできる
        • AWSの管理責任者には、AdministratorAccessポリシーを付与したグループに所属させるとよい(直接でもよい)
      • アクセスの種類は、そのアカウントの使われ方からプログラム/コンソールを適宜選択する
      • IAMユーザーには追加の情報を付与できるタグ機能がある

        • 例えば role: Admin というタグをとあるユーザーに付与し、管理者であることがわかるようにしたりできる
  2. 多要素認証を有効にする

    • Google Authenticatorとか使うよくあるアレ
    • 物理デバイス用意するのは怠いので、仮想MFAデバイスでやればよさそう
  3. AWS Cloud Trailを有効にする

    • アクセスログなどを取れる仕組み
    • セキュリティ的に使うようにする
    • デフォルトで有効化されているが、データ操作などのログは有効化されていないので、必要に応じて有効化を行う
    • 左メニューの「証跡の作成」から作成を行う

      • AWS Organizationsを有効化し、複数のAWSアカウントを統合している場合には、「組織に証跡を適用」することができる
      • AWS KMSとは、暗号化キーのマネージドサービスで、そこで発生したイベントも記録することができる(使ってなきゃ記録しなくてもよい)
      • データイベントでは、取得したログをS3に保存したり、Lambdaで整形したりすることができる(一般的にS3への保存がよく使われるらしい)
      • 証跡にもタグをつけることができる
    • S3バケットにログを保存するようにした場合、放置すると大量のログが保存されお金がかかるので、証跡を削除するか、S3バケットを削除すること
  4. 請求レポートを有効にする

    • ある請求金額を超えた場合にアラート(メールなど)を出して教えてくれる仕組み
    • 爆請求で死なないようにやっておくのが吉
    • 請求情報の操作はデフォルトではルートアカウントでしかできない

      • 責任者のIAMユーザーに権限を付与して操作できるようにしておくとよい
      • ルートユーザーでログイン後、右上のメニューから「マイアカウント」へ移動し、「IAM ユーザー/ロールによる請求情報へのアクセス」を編集し、「IAMアクセスのアクティブ化」にチェックを入れ更新すると、IAMユーザーによる操作が可能になる
    • まず右上のメニューの「マイ請求ダッシュボード」 => 「Billingの設定」から、アラートを受け取るemailアドレスを登録しておく
    • 価格の監視は「Cloud watch」という監視サービスを使って行う

      • Cloud Watchでは全ての請求データとアラートをUS East(バージニア北部)のリージョンで操作する必要があるので、東京リージョンなど別のリージョンにいる場合は移動する
      • 左メニューの「請求」からアラームの作成ができる

あと地味にやっておくとよいのは、IAMダッシュボード上段にある「IAM ユーザーのサインインリンク」をカスタマイズし、アカウントエイリアスを設定すること
そしてそのサインインリンクをIAMユーザーのアカウントを持つ人に教えてログインしてもらうことになる
(このエイリアスはAWS全体で一意でなければならないので注意)