AWSの基本的な使い方

AWSの基本的な使い方
M3 社内研修用
エンジニアリンググループ園田

View Slide

はじめに
スライドに利用しているマネジメントコンソールのスクリーンショットは2018/06時点のも
のとなります。
AWSの情報探索時の心構えとして、マネジメントコンソールは頻繁にUIが変わるので、
スクリーンショットをあてにしないようにしましょう。（リソースのモデルを把握しましょうw）
今回のスライドはかなり初心者向けの内容となっているため、ざっと資料を先読みして
自分にとって不要だなと判断したら時間がもったいないので読み飛ばしていただいて結
構です。

View Slide

はじめに
アンケートなどでM3でのユースケースがあるとわかりやすいという意見がありますが
（実際私もその方がわかりやすいと思いますが）、M3のユースケースを私自身すべては
把握しておらず、また使い方も千差万別のため「コレ」というものがありません。
前回講義でも触れましたが、AWSは非常に膨大な機能仕様があり、それらの組み合わ
せはほぼ無限に存在するため、この短い時間では代表的なユースケースですら解説す
るのは困難です。使い方の説明をメインにしているため、料金体系などの説明もあまり
出てきません。
今回の講義はどんなユースケースにおいても必要になるサービスや概念の説明がメイ
ンとなっています。

View Slide

アジェンダ
● 第1章 VPC
○ サブネット
○ NATゲートウェイ
● 第2章 EC2 / EBS
○ EBS
○ インスタンスプロファイル (IAMロール)
○ UserData
○ セキュリティグループ
● 第3章 AutoScaling / ELB
○ AMI
○ Launch Template
○ AutoScalingGroup
○ ELB

View Slide

一般的なWebシステムにおけるAWS環境の構築手順
通常のWebシステムの場合、構築手順はおおまかに以下のような流れになります。
1. ネットワークリソースの構築（VPC, サブネットなど）
2. サーバリソースの構築（EC2、RDS、セキュリティグループなど）
3. 負荷分散環境の構築（ELB、AutoScalingGroupなど）
4. BCP(国外リージョンによるDR)環境の構築（今回は触れません）
以降のスライドでは、それぞれの構築フェーズで行う作業と、考慮すべきポイントを解説
します。

View Slide

構築環境のイメージ
時間の都合上、今回はRDS構築の説
明はしません。

View Slide

第1章
VPC

View Slide

ネットワークリソースの構築
VPCによるネットワークリソースの構築を行います。VPCはほとんどのユースケースで
必要になる可能性が高いです。AWS利用の前提知識といえます。
VPCを構築する上で考慮しなければならない事項は以下の通りです。
● 他のVPCや別アカウントのVPCと接続する必要があるかどうか。
● 必要なIPアドレスの個数。（1VPCあたり上限65,536 - α）
● IPv6でのアクセスが必要かどうか。（通常は不要）
● VPC内のインスタンスからインターネットを参照可能とするかどうか。（通常は必要）
特に上２つは後からの変更が非常に困難なため、初期構築時に必ず検討する必要があ
ります。

View Slide

ネットワークリソースの構築（注意事項）
他のVPCや別アカウントのVPCと接続する必要があるかどうか。
VPCは構築時にCIDRを指定しますが、後から変更はできません。
他のVPCや別アカウントのVPCとVPCピアリング（VPC間接続）する際に、プライベート
ネットワークのアドレスが被っていた場合、接続できません。
そのため、接続先のVPCとネットワークアドレスが被らないようにCIDRを指定する必要
があります。
VPCエンドポイント + NLBという手段で接続できなくもないですが、構成が複雑になるた
めオススメしません。これは最終手段です。
https://dev.classmethod.jp/cloud/aws/try-aws-privatelink_1/

View Slide

必要なIPアドレスの個数。（1VPCあたり上限65,536 - α）
VPCのIPレンジ（ネットマスク）は最小で16ビットです。65536個のIPアドレスを発行可能
ですが、AWSの内部リソースに消費される予約分や、ELBなど動的に増減するIPアドレ
スを考慮に含めてIPアドレスの個数を検討します。
通常のWebシステムでIPアドレスが枯渇することはまずありませんが、VPC内で
Lambdaを大量に実行する場合や、EMRなどで大量のスポットインスタンスを立ち上げ
る場合はIPアドレスの枯渇を意識する必要があります。
もし60000を超えそうな場合はVPCを分割しても問題ないアーキテクチャで実装する必
要があります。

View Slide

VPC内のインスタンスからインターネットを参照可能とするかどうか
VPC内のインスタンスは踏み台インスタンスを除き、インターネットから接続不可能なプ
ライベートサブネットに構築するのが一般的です。ただし、インターネットへのアクセスは
必要になるケースは多いです。
● bundle installなど、パッケージのダウンロード
● sentryやdockerhubなど外部サイトへのアクセス
最初からこれらを考慮したクラウドネイティブなシステムを除き、ほとんどのケースでは
外部サイトへのアクセスが必要となります。
インターネットへのアクセスが必要な場合、通常はNATゲートウェイをVPCに構築しま
す。(NATインスタンスやForward Proxyという手段もあります )

View Slide

ネットワークリソースの構築（詳細手順）
新規ネットワークを構築するには以下の手順で行います。
1. VPCの作成
2. インターネットゲートウェイの作成
3. パブリック用のサブネットの作成
4. パブリックサブネットの設定
5. プライベート用のサブネットの作成
6. NATゲートウェイの作成
7. VPCエンドポイントの作成（作成は任意、今回は割愛）
8. プライベートサブネットの設定
この順序は、マネジメントコンソールでの作業順序となります。ややこしいのですが、マネジメントコン
ソールで作成する場合と、Terraformなどで作成する場合で作業順序が異なることが多々あります。

View Slide

VPCの作成
VPCの作成に必要なパラメータは名前とCIDRの2つです。
VPCの名前です。Nameタグに設定されます。他の人が見てもわかり
やすい名前をつけましょう。my-vpcとかは言語道断。
VPCのIPアドレス範囲です。他のVPCと同じでもエラーになりません
が、VPC間でのネットワーク接続が必要な場合は考慮が必要です。特
に理由がない限り16ビットで切るのが一般的です。
これらのパラメータは通常のケースではデフォルトで問題ないです。
IPv6でのアクセスが絶対に必要な場合はまずないでしょう。

View Slide

VPCの作成
VPCを作成すると、以下のリソースがデフォルト生成されます。
● デフォルトのセキュリティグループ
● デフォルトのルートテーブル（メインルートテーブル）
これらのデフォルトで生成されたリソースは、VPCが存在する限り破棄できないため、
TerraformなどInfrastructure as Codeで管理する場合は基本的に利用しないほうがい
いです。
VPCに限らず、デフォルト生成されたリソースは基本的に無視したほうがTerraformなど
で管理しやすいです。自動生成されるリソースは、他にはDHCPオプションやRDSパラ
メータグループなどがあります。

View Slide

インターネットゲートウェイの作成
VPCとインターネットを接続するための仮想ルータである、インターネットゲートウェイ
(IGW)を作成します。
インターネットからの接続が不要でも、NATゲートウェイ経由でインターネットへ接続する
際に必要になるため、作成するケースがほとんどです。踏み台インスタンスにも必須で
す。

View Slide

インターネットゲートウェイの作成
作成したIGWをVPCにアタッチします。IGWをアタッチしない限り、VPCとインターネット
は相互通信不能です。(セキュリティインシデント発生時など、IGWをデタッチすることが
あります)

View Slide

パブリック用のサブネットの作成
AWSにおいてAZで分割された仮想ネットワークをサブネットと呼びます。
インターネットから直接通信可能なサブネットをAWS用語でパブリックサブネットといい
ます。パブリックサブネットを構築するためには、まずパブリックサブネット用のサブネット
を作成します。
ややこしいのですが、パブリックサブネットというリソースは存在しません。作成されたサ
ブネットに対してIGWをルーティングすることで、そのサブネットはパブリックサブネットと
なります。
パブリックサブネットには、踏み台インスタンス、および外部からHTTP(S)でアクセスする
ためのELBを含めることになります。ELBをマルチAZで構築するためには、パブリックサ
ブネットを複数のAZに作成する必要があります。

View Slide

パブリック用のサブネットの作成
サブネットの名前です。Nameタグに設定されます。SuffixにAZをつけ
るのが慣例です。
AZを選択します。マルチAZにする場合はサブネットを複数作成しま
す。サブネットのAZを後から変更することはできません。
サブネットのIPレンジをCIDRで指定します。通常、プライベートサブ
ネットよりもIPアドレスの個数は少なくすみますが、わかりやすくするた
め/24にすることが多いです。

View Slide

パブリックサブネットの設定
パブリックサブネット用に作成したサブネットに割り当てるルートテーブルを作成します。

View Slide

作成したルートテーブルに 0.0.0.0/0 宛（ローカルネットワーク以外のすべての通信）の
パケットをVPCにアタッチしたIGWにルーティングさせるように設定します。（ルートテー
ブルは上から評価されます）
VPC内のIPアドレスはすべてローカルネットワーク内の通信として扱われ、変更はでき
ません。そのため、他のVPCと通信する場合はIPアドレスの範囲がかぶらないようにし
なければなりません。

View Slide

この設定が完了した時点で、関連づけたサブネットは便宜上、パブリックサブネットと呼
ばれるようになります。
作成したルートテーブルとパブリックサブネット用に作成したサブネットを関連付けます。
ELBなどをマルチAZ構成にする場合はAZの異なる複数のサブネットを関連付けます。
明示的に関連付けを行う前は、VPC作成時に自動生成されたデフォルトのルー
トテーブル（メインルートテーブル）と関連付けられています。

View Slide

プライベート用のサブネットの作成
パブリック用のサブネットを作成した際と同様に、プライベート用のサブネットを作成しま
す。マルチAZが必須なケースがほとんどなので、複数AZで作成します。VPC内で大量
のリソースを作成する場合はCIDRを大きめに切ります。
当然ですが、パブリックサブネットと同じAZを選択したほうが通信のレイテ
ンシが少ないため、特に理由がない限りパブリックサブネットと同じAZを選
択します。

View Slide

NATゲートウェイの作成
プライベートサブネット内のインスタンスがインターネットに接続可能なようにNATゲート
ウェイを作成します。
NATゲートウェイと関連付けるサブネットを選択します。ここで選択する
サブネットはIGWと通信可能でなくてはなりません。つまり、先に作成し
たパブリックサブネットを選択する必要があります。

View Slide

プライベートサブネットの設定
プライベートサブネット用のルートテーブルを作成します。

View Slide

作成したルートテーブルに、インターネット向けパケットをNATゲートウェイに送信するよ
うにルーティング設定を行います。

View Slide

プライベートサブネット用に作成したサブネットを、ルートテーブルに関連付けます。これ
で、プライベートサブネット内に構築されるインスタンスがインターネットに対してパケット
を送信可能になります。
このキャプチャは保存前の状態です。

View Slide

補足: NATゲートウェイの冗長化
ここまでの手順で、以下のリソースが作成されています。
● VPC
● インターネットゲートウェイ
● パブリックサブネット * AZ
● プライベートサブネット * AZ
● NATゲートウェイ
● ルートテーブル * 2 (パブリック用、プライベート用)
このままでもシステム運用可能ですが、NATゲートウェイがシングルAZになっているた
め、インターネット通信を頻繁に行うシステム（電子決済や外部認証など）では可用性が
問題になります。

View Slide

補足: NATゲートウェイの冗長化
NATゲートウェイを冗長化するためには、各AZのパブリックサブネットと関連付けた
NATゲートウェイを複数作成し、プライベートサブネット用のルートテーブルをそれら
NATゲートウェイの数だけ作成する必要があります。
1. NATゲートウェイを各AZに作成する。
2. ルートテーブルを各AZ用に作成してNATゲートウェイにルーティング。
3. 各AZごとのサブネットに個別にルートテーブルを関連付ける。
3.1. ルートテーブル:プライベートサブネットが 1:1になる。
NATゲートウェイの冗長化はそれなりに費用がかかります。デプロイのタイミングでしか
インターネット通信が不要な場合や、ミッションクリティカルでないシステムではNATゲー
トウェイの冗長化が本当に必要か検討しましょう。
AZあたりのNATゲートウェイ料金 => $0.062/時 => $45.26/月

View Slide

補足: NATゲートウェイが不要なケース
以下に該当する場合はNATゲートウェイが不要な可能性があります。
● インターネット通信量や通信頻度が少ない場合
○ NATゲートウェイではなく、 NATインスタンスを構築する。
○ インターネット通信が必要な場合（デプロイ時や AMI作成時など）のみNATゲートウェイを構築して
ルーティングする。（この操作は Lambdaなどで実装する）
● 出口対策などでフォワードプロキシを構築する（もしくは構築済みの）場合
○ インターネット向けの通信をプロキシサーバを経由するようにルーティングする。
● 通信対象がAWSのサービスのみの場合
○ S3やCloudWatch LogsなどVPCエンドポイントがサポートされているサービスでは VPCエンドポイ
ントを利用する。
○ Amazon LinuxのyumリポジトリはS3なので、標準リポジトリのみ利用の場合は VPCエンドポイント
で代替可能。
● 接続先サイトに対してIPv6で接続可能な場合
○ Egress Only Internet Gatewayの利用を検討する。（自分は使ったことないのであまり良く知りません・・・）

View Slide

以上でネットワーク構築は完了です。

View Slide

お気づきになりましたか？
ここまでで、セキュリティグループについて触れていません。
AWS初心者にありがちなのが、ネットワーク通信制御とセキュリティグループとを混同す
ることです（少なくとも私は最初混乱しました。インフラの人から見たらハナから別物なのかなあ・・・）。
セキュリティグループで通信を許可しても、VPCでルーティングされていなければ通信は
不可能です。また、セキュリティグループは文字通り、リソースを通信単位でグルーピン
グするためのものです。ネットワーク設定とは厳密に異なります。AZやサブネットの概念
がありません。セキュリティグループはリソースありきとなるため、次の章から説明しま
す。
とはいえあまり複雑に捉えず、セキュリティグループはネットワーク設定の上にあるレイヤと思っておけば問題な
いです。

View Slide

第2章
EC2 / EBS

View Slide

サーバリソースの構築
EC2は仮想マシンを時間課金で起動するタイプの、いわゆるIaaSという概念に該当する
ものです。つい最近、ベアメタルインスタンス（物理マシン）のサポートも開始されました。
ELB、ECS、Elastic Beanstalk、EMR など数多くのサービスがEC2をラップしたサービ
スなので、EC2の概要を知ることはAWS利用の上で必須といえます。
実際に踏み台用のEC2インスタンスを作成する手順に沿って、EC2構築における概念
や考慮事項を説明していきます。

View Slide

サーバリソースの構築
EC2を構築するうえで考慮しなければならないのは以下の事項です。
● OSとバージョン
● インスタンスタイプ（CPU、メモリ、ネットワーク帯域）
● ストレージの種類とサイズ、IOPS性能
● サーバの初期化処理（UserData =>プロビジョニングスクリプト）
● インスタンスプロファイル（IAMロール）
● Windowsの場合はドメイン、ライセンスなど考慮事項多数

View Slide

OSとバージョン選定
EC2の作成では、まずOSとバージョンを選択します。

View Slide

EC2では以下のOS(ディストリビューション)が利用可能です。
● Amazon Linux
● Amazon Linux 2 (LTS候補版)
● Ubuntu Server
● RedHat Enterprise Linux
● SUSE Linux Enterprise Server
● Windows Server 各種
● コミュニティAMIには多種多様なディストリが存在する
○ CentOS、FreeBSD、openSUSE、Debian、Gentoo、Fedoraなど

View Slide

どのOSのどのバージョンを利用するかは、目的によって異なると思いますが、特に理由
がない限りAmazon Linuxの利用をオススメします。
● AWS利用における情報量の多さ、AWSのサポート
● AWSが独自にパッチを当てたXenやKVMとの親和性
● パッケージリポジトリがS3に存在するため超高速インストール
● 通常のRHELやCentOSよりもパッケージが少し新しめ
● aws-ssm-agentなどAWSツールが標準リポジトリからインストール可能
なお、公式のAMIではカーネルパラメータやカーネルモジュールなどは汎用的な用途に
マッチするように初期設定されています。これらはgrubやmodproveの設定を変更した
状態でAMIを作成することにより、ユーザによってチューニング可能です。

View Slide

RHEL や SUSE 、Windows など有料のOSのライセンスは従量課金の利用料金に含
まれています。
すでにライセンスを購入済みの場合は購入済みライセンスを適用することで従量課金額
を安くすることができます。(BYOL: Bring Your Own License)
Windows Server のライセンス形態は複雑すぎてよくわからないので、不安な場合はソ
リューションアーキテクトの方に相談してください。
※ただでさえ複雑なWindowsライセンスがAWSの独自エディションでわけわからなくなっています。
Windowsに限らず、BYOL利用の場合はソリューションアーキテクトへの相談は必要に
なるでしょう。

View Slide

OSとバージョン選定まとめ
● OS選定で最も重要なのは、インストールするパッケージのサポート。
● 次に重要なのは運用チームの習熟度。
● 特に理由がない限り、Amazon Linuxを選んでおけばOK。
● systemdを利用したい場合は RHEL7 か Amazon Linux 2。
● Windows向けの製品を利用したい場合。Windows向けだけではないけど、
Windowsに最適化された製品も多数存在する。(日立のCosminexusとか)
マネジメントコンソールでの作業だとわかりづらいですが、OS選択画面では、裏側で当
該OSがプリインストールされたAMIのIDが選択されています。AMIについては後述しま
す。

View Slide

インスタンスタイプ選定
OSを選択したら、次にインスタンスタイプを選択します。

View Slide

EC2には用途に応じてインスタンスタイプという区分が存在します。インスタンスタイプに
よって搭載される仮想CPUコア数、メモリ量や、ネットワーク帯域、ローカルストレージ容
量が変わります。
インスタンスタイプは用途を表すアルファベット1文字と世代を表す数字1文字、グレード
で表されます。用途と世代を合わせた2文字をインスタンスファミリーと呼称します。イン
スタンスファミリーは2文字以上のものも存在します。
例: m5.4xlarge の場合
● m => 汎用インスタンスを表す。
● 5 => 第５世代のインスタンスを表す。
● 4xlarge => インスタンスファミリーにおけるグレード。
○ 大きいほど高価で高性能。 4xlargeはxlargeの4倍という意味。

View Slide

現行世代には以下のインスタンスファミリーがあります。
● m4, m5 => 汎用インスタンス
● t2 => CPU利用制限がある廉価な汎用インスタンス
● c4, c5, c5d => CPUコア数が多いコンピューティング最適化インスタンス
● p2, p3, g3 => GPU搭載量が多いGPU最適化インスタンス
● h1, i3, d2 => ストレージ容量が多いストレージ最適化インスタンス
● i3.metal => ベアメタルインスタンス
● f1 => FPGAによる拡張が可能な特殊インスタンス
通常のWebシステムでは m5 か t2 を選ぶことになります。価格も m と t 以外は低価格
帯での提供タイプがないものが多いです。

View Slide

t2インスタンスは、普段はCPUが従来の20%しか利用できない代わりに時間単価がか
なり安いインスタンスタイプです。
時間経過とともにクレジット（単位は時間）が溜まっていき、このクレジットを消費すること
でクレジット分の時間だけバースト（CPU性能を100%利用可能な状態）することができ
ます。
また、Unlimitedオプションを有効にすると、クレジットが枯渇しても追加料金を支払うこと
でバースト時間を増やすことができます。
現行世代では低パフォーマンス帯のインスタンスタイプはt2でしか提供されていないの
で、今後利用する際にはt2ファミリーの利用が増えると思います。

View Slide

インスタンスタイプごとに設定されているvCPU数やメモリ容量は理論値です。
実際にまったく同じインスタンスタイプのEC2インスタンスでも、パフォーマンスに大きく
差が出ることがよくあります。
これは、DCに設置されているKVMホストマシンもしくは接続機器の故障や老朽化によっ
て仮想マシンにパフォーマンス劣化の影響が出ているためです。
EC2インスタンスのパフォーマンスにバラツキがあるため、このような事象をEC2ガチャ
と呼んだりします。
なので、低パフォーマンスのEC2を引いたときでも即廃棄できるようにイミュータブルな
システムを構築することはクラウドにおいて必須と言えます。

View Slide

一部のインスタンスタイプでは、EC2インスタンスの仮想マシンに物理接続されている
ローカルストレージであるインスタンスストア（エフェメラルディスク）が付いてきます。
このインスタンスストアはEC2終了時にデータが消去されますが、ネットワーク接続され
ているEBSと比べてI/Oが圧倒的に高速というメリットがあります。
なので、ログや中間ファイルなどをインスタンスストアに入出力することでシステム全体
のパフォーマンス向上に寄与します。
ただし、インスタンスストアは現行世代のインスタンスにはほとんど搭載されていませ
ん。つい最近まで m3.medium ですらあったのに、なんで！？

View Slide

インスタンスタイプ選定まとめ
● とにかく低コストにしたいのであれば t2
● AutoScaling前提のWebシステムであれば汎用の t2 か旧世代の m3
● 平常時のアクセス量が多い中規模以上のWebシステムであれば m5
● DBなどディスクI/O性能を求めるならストレージ最適化
● RedisやMemcachedなどオンメモリDBを利用するならメモリ最適化
● 機械学習など計算量が多いシステムならGPU最適化
● VMware on AWS など Hypervisor を利用したい場合は i3.metal
● エムスリーなので m3

View Slide

ネットワークの設定
EC2インスタンスの詳細設定画面です。量が多いのでセクションごとに説明します。まず
はネットワーク周りです。VPCとサブネットを選択します。
EC2インスタンスは必ずVPC内のサブネットに属します。（昔はVPC外
に作成することができました。）
後からVPCやサブネットを変更することはできません。変更したい場合
はスナップショットを作成して起動しなおします。
踏み台インスタンスでは、EIPをアサインしてIPを固定にするた
め自動割り当てのパブリックIPは利用しません。

View Slide

スポットインスタンス
スポットインスタンスは、入札により課金額が決定するインスタンスです。
通常のオンデマンドインスタンスより最大9割くらい安く稼働させることができますが、入
札額が相場を下回ると自動的に停止します。
ステートレスな処理を大量に行うバッチ処理などで有効です。Webシステムではスパイ
クアクセスなどによりトラフィックが急増した際に利用したりします。
また、AWS BatchやEMRなど一部のサービスではスポットインスタンスを利用する機能
が備わっているものもあります。

View Slide

プレイスメントグループ
AZ内のEC2インスタンス間通信は十分に高速ですが、プレイスメントグループを作成す
るとさらに高速な通信が可能になります。
プレイスメントグループは、ネットワーク的に近いHW上にインスタンスを構築すること
で、通信のレイテンシを最小限におさえることが可能です。
ただし、「ネットワーク的に近い = 物理的な距離が近い」なので、災害などによりまとめて
死ぬことがありえます。
一般的なWebシステムでは、インスタンス間の通信は不要なことが多いため、プレイスメ
ントグループを利用することは少ないと思います。分散バッチなどでの利用がメインとな
るでしょう。他には、インスタンス間通信を前提としたErlang/OTPや、トライアド構成のシ
ステムなどでも有用かもしれません。

View Slide

ネットワーク以外の設定です。IAMロールは後述します。モニタリングやテナンシーは今
回は割愛します。
その他の設定
EC2インスタンスに紐付けるIAMロールを選択します。IAMロールはイン
スタンスプロファイルを持っている必要があります。

View Slide

IAMロール (インスタンスプロファイル)
EC2にはIAMロールを紐付けることができます。
IAMロールがアタッチされたEC2インスタンスからは、各AWSサービスに対してアクセス
キーなしでAPI実行が可能なため、セキュアにAWSのAPIを利用可能です。
EC2からAWSのサービスを利用する場合は、必ずIAMロールを設定するようにしてくだ
さい。
間違ってもIAMユーザーを作成して、アクセスキーをEC2上に格納しないように気をつけ
てください。

View Slide

UserData (プロビジョニングスクリプト)
EC2では初回起動時に行うプロビジョニングの処理を設定することができます。これを
UserDataと言います。
Linuxであればshebangで実装言語を指定可能です。#cloud-config をshebangに指定
した場合は、YAMLで記述可能なCloud-Initの仕様を利用可能です。

View Slide

BashでUserDataを記載する例を見てみます。
以下の例では、sshdのListenポートを変更しています。
※前職でよく使っていました。その時は443に変更してました。

View Slide

Cloud-InitはクラウドサーバをプロビジョニングするためのDSL仕様で、ansibleみたいに
宣言的にサーバの状態を記述できるため非常に便利です。
以下のリンクに様々なユースケースでのサンプルコードが載っています。
http://cloudinit.readthedocs.io/en/latest/
初回起動時以外のイベント処理も記載可能で、冪等性も担保されます。
なお、ECSではクラスタインスタンスの利用でUserDataを必ず利用します。Elastic
BeanstalkではUserDataの代わりにインスタンスを初期化する手段があります。

View Slide

EC2のストレージ (EBS)

View Slide

EBSは仮想ブロックストレージです。仮想ハードディスクと思っておけば大体あってま
す。EC2のOSイメージや、アプリケーションバイナリ、ログファイルなどのファイルを格納
するための永続化ストレージです。
EC2そのものは永続ストレージを持っていません。EC2起動時にOS起動イメージが格
納されたEBSが複製・アタッチされ、アタッチされたEBSがマウントされた状態で起動し
ます。ファイルシステムはAmazon LinuxデフォルトだとXFSです。
また、EBSはEC2上で動作する他のサービスでも利用されます。代表的なもので、RDS
やElasticsearchがあります。これらのサービスはEBS上にデータを永続化しています。
ちなみに、API上ではEBSはVolumeというエンティティ名です。忘れやすいので注意。

View Slide

EBSは最低で100 IOPSのベースライン性能が出ます(gp2の場合)。また、IOクレジット
があり、クレジットが枯渇しない限り最大3000 IOPSまでバースト可能です。
プロビジョンドIOPSストレージ(io1)の場合、IOPSを最大で60000まで指定することが可
能です。
EBSには gp2, st1, sc1 など種別があり、ランダムアクセスが得意、シーケンシャルアク
セスが得意、スループットが安定しているなどの特性があります。
通常のWeb利用ではストレージ速度を気にすることはあまりないので、汎用ボリューム
のgp2を選択することが多いです。

View Slide

EBSはスナップショット機能があります。オンラインで取得可能なのでデータの信頼性が
重要なシステムでは重宝します。
ただ、リストアにそれなりに時間がかかるので、RTT（目標復旧時間）の指標が厳しい
ミッションクリティカルなシステムではEBSのスナップショットとは別に、OS内でファイル
システムのスナップショット(LVMスナップショットやxfs_dumpなど)を取得することもよく
あります。前職では2台のEC2でDRBDを組んだりしてました。
RDSの自動バックアップ機能はEBSのスナップショットにより実現されています。スナッ
プショットされたイメージはS3に格納されます。なお、S3のコンソールからスナップショッ
トを確認することはできません。

View Slide

タグの設定
EC2においてタグは比較的重要です。Systems Managerによるパッチ適用やパッケー
ジインストールなどを行うにあたり、タグを利用するためです。サーバーロールや環境
名、サービス名などを入れておきましょう。

View Slide

セキュリティグループの設定
セキュリティグループについては後述します。ここでは社内からのSSHを許可していま
す。

View Slide

キーペアの選択

View Slide

以上で踏み台インスタンスの構築は完了です。

View Slide

セキュリティグループ
セキュリティグループは文字通り、通信を許可するリソースをグルーピングするための機
能です。通信の受信（Ingress）と送信（Egress）を、ホワイトリストとブラックリストにより
認可します。
設定可能な代表的なパターンは以下の通りです。
● 特定のセキュリティグループからのアクセスに対する認可
● セキュリティグループ内のアクセスに対する認可
● 特定のIPアドレス(CIDR)からのアクセスに対する認可
● 特定のIPアドレス(CIDR)へのアクセスに対する認可
● VPCエンドポイントへのアクセスに対する認可（今回は割愛）

View Slide

特定のセキュリティグループからのアクセスに対する認可
VPC内のリソースからのアクセスを制御するパターンで、頻出パターンです。EC2に対
するELBからのアクセス、RDSに対するEC2のアクセスなど、AWSリソース間でのアク
セス制御に利用します。非常にシンプルですが、設計を誤ると相互参照が発生します。
相互参照は作成する分にはエラーにはなりませんが、削除しようとするとエラーになるた
め、terraformなどで厄介です。

View Slide

セキュリティグループ内のアクセスに対する認可
同一セキュリティグループ内の通信を許可するパターンです。RDSやElastiCacheのセ
キュリティグループとして利用することが多いです。複数のセキュリティグループをオー
バーラップさせる前提となります。相互参照しづらくなるためterraformなどとの相性がい
いですが、人間にはわかりづらいというデメリットがあります。

View Slide

特定のIPアドレス(CIDR)からのアクセスに対する認可
踏み台インスタンスへのSSH接続、テスト環境へのWebアクセスなど、VPCの外にある
拠点からのアクセスを制限する場合に利用します。これには、VPN接続で接続されてい
る別のVPCや、Direct Connect経由で接続されているオンプレからのアクセスも含まれ
ます。

View Slide

特定のIPアドレス(CIDR)へのアクセスに対する認可
特定のIPアドレスへの通信のみを許可し、外部へのアクセスを制限するパターンです。
マルウェアや内部犯行対策として設定することがほとんどです。

View Slide

ネットワークACL
IPアドレスに対する制限は（説明していませんが）ネットワークレイヤであるサブネットの
ACLでも可能です。
より堅牢にするのであれば、サブネットのACLとセキュリティグループを併用して同じ制
限をかけます。こうすることによって、誤ってどちらかの制限を解除してしまった場合でも
救済することができます。
当然、管理は煩雑になるのでterraformなどで管理したほうがいいでしょう。

View Slide

第3章
AutoScaling / ELB

View Slide

AutoScaling
AutoScalingは、最小インスタンス数と最大インスタンス数を指定して、スケーリングポリ
シーに応じてスケールアウト・スケールインを行う仕組みの総称です。AWSに限った用
語ではありません。
AWSでは、ロードバランサーから接続するWebサーバを負荷分散するために利用する
のが主な用途です。
なお、ロードバランサーは必須ではなく、バッチ処理を複数サーバで分散処理する場合
にも利用されます。
AutoScalingの機能自体はロードバランサーに依存していないため、多くのユースケー
スで利用が可能です。

View Slide

Amazon Machine Image (AMI)
AutoScalingを説明する上で、AMIの説明は避けて通れないのでAMIを紹介します。
AMIとは、EC2起動前のVMイメージです。より具体的にはEC2のメタデータ（OSやデバ
イスマッピング情報など）と、OS起動イメージやファイルなどが格納されているEBSを圧
縮したアーカイブファイルです。
AWSから提供されているAMIでEC2を起動し、起動したEC2にミドルウェアやアプリケー
ションをインストールして、AMIを作成することができます。
EC2は必ずこのAMIから起動されます（起動時にAMIのIDを指定します）。

View Slide

AutoScalingでは、スケールアウトさせる際に、どのAMIを利用してEC2を起動するかを
予め定義しておく必要があります。
AWS提供のデフォルトAMIから起動してUserDataでもろもろ初期化してもAutoScaling
は可能ですが、パッケージインストールしてアプリケーションを展開して設定ファイルを生
成してなどをUserDataで行うと、スケールアウトまでの時間が非常に長くなってしまいま
す。
そのため、通常はアプリケーションなどをインストール済みの状態でAMIを作成してお
き、AutoScalingの起動設定でそのAMIを指定することで起動時間を短縮することがで
きます。

View Slide

起動設定に利用するAMIの戦略として、代表的なパターンとして以下があります。
● 必要なミドルウェアのみインストールされた状態のAMI
● アプリケーションまでインストールされた状態のAMI
● アプリケーションの設定や環境変数まで格納されたAMI
下に行くほど起動は高速になりますが、設定や環境変数まで格納したAMIを作成する
と、開発環境用AMI、本番用AMIなど非常に多くのAMIがバージョンごとに存在すること
になり、コストも増大します。
そのため、よく利用されるパターンとしては２番めの戦略となります。その場合、アプリ
ケーションの設定や環境変数は起動スクリプトなどで取得します。

View Slide

アプリケーションまで含めたAMIはCI/CD対象です。
アプリケーションに変更を加え、Gitにプッシュしたら新しいバージョンのAMIを作成する
ためのジョブを起動し、最新のAMIが即時利用可能な状態にしておくのが望ましいで
す。（古いバージョンの削除も行います）
起動AMIをCI/CDするための仕組みはAWSでは多数用意されています。
● CodePipeline + CodeBuild + Packer
● Systems Manager の Automation
● Elastic Beanstalk の Custom Platform Builder
これらを説明している時間はないので、起動AMIは作成済みという前提で先に進みま
す。(※Nginxインストール済みAMIの作成は資料末尾のAppendix参照）

View Slide

AutoScalingの起動設定 (非推奨）
AutoScalingを設定するためには、スケールアウト時にどのAMIを起動するかを予め設
定しておく必要があります。この設定をLaunchConfiguration(起動設定)といいます。
LaunchConfigurationの内容は、EC2の起動で入力したパラメータとほぼ同じです。
なお、LaunchConfiguration は現在非推奨となっています。
起動テンプレートを利用することが推奨されているため、今回は起動設定の説明を割愛
します。
起動テンプレートはローンチされたばかりの新しい機能です。そのため、Webで検索す
るとほとんどは起動設定がヒットします。注意してください。

View Slide

Launch Template
LaunchConfigurationはAutoScalingでしか利用できませんが、Launch Templateは通
常のEC2起動に利用可能です。また、起動テンプレートはバージョン管理されます。以
下は起動テンプレート作成画面です。

View Slide

Launch Template
起動テンプレートで起動するAMIのIDとインスタンスタイプ、キーペア名を指定します。
ネットワークタイプは必ずVPCを選択してください。Classicを使うことは将来的に見ても
ありません。
AutoScalingに利用する場合は、アプリケーションなどがインストールされ
たAMIのIDを指定します。
起動したEC2にSSHログインする必要がない場合は空にします。
ssm-agentを利用する前提であればSSHログインは不要です。

View Slide

ネットワークインターフェイス、ストレージは空のままにします。
Launch Template
AutoScalingで利用する場合は、AutoScalingGroupの設定でネットワー
クを設定するため不要です。
ルートボリュームはAMIに含まれています。ルートボリューム以外をアタッ
チする必要がある場合のみ指定します。

View Slide

タグを指定します。このタグはAutoScalingで起動されたすべてのインスタンスに設定さ
れます。これらとは別に、AutoScalingGroupのIDなどメタ情報のタグも設定されます。
Launch Template

View Slide

セキュリティグループを指定します。起動されたすべてのEC2インスタンスがここで設定
したセキュリティグループに所属します。
Launch Template
まだELBを作成していないので、とりあえず同一セキュリティグループからのHTTPアク
セスを許可しておきます。

View Slide

その他の詳細設定です。EC2起動時に設定
した内容と似ていますが、ElasticGPUなど
の項目が追加されています。
特定のAMIでのみ有効な項目もあります。
RAMディスクIDとカーネルIDはほぼ利用す
ることはないでしょう。
重要なパラメータとしてモニタリングがありま
す。次のスライドで説明します。
Launch Template

View Slide

モニタリングは重要なポイントなので補足します。詳細モニタリングを有効にしなかった
場合、スケーリングの判断に必要なCloudWatchのメトリクスは最小でも5分間隔でしか
取得されません。
これはつまり、閾値を超えてスケールアウトが必要になるまでに最大で10分かかること
を意味します。そこからEC2が起動して準備完了になるまでさらに数分かかるため、ス
ケールアウトが完了するまでの時間は12〜15分くらいかかることになります。迅速なス
ケールアウトが必要なシステムでは必ず詳細モニタリングを有効にしてください。（ただ
し、詳細モニタリングはコストが上がります）
Launch Template

View Slide

AutoScalingGroupの作成
起動テンプレートができたら、AutoScalingGroupを作成します。
作成した起動テンプレートを選択します。起動テンプレート画面から
AutoScalingGroupの作成を実行した場合はこの画面はスキップされます。

View Slide

起動するテンプレートのバージョンとグループ名を指定します。
「バージョンID」もしくは「最新」を選択可能です。起動テンプレートもCI/CDを行うのであ
れば、「最新」を選択してはいけません。新しいインスタンスが勝手に最新バージョンの
AMIで起動されてしまいます。

View Slide

作成直後のインスタンス数と、起動対象となるVPCおよびサブネットを指定します。
複数のサブネットを指定することでMulti-AZ構成となります。ここではプライベートサブ
ネットのゾーンAとゾーンCで起動するように指定しています。

View Slide

なお、AutoScalingGroupの画面から直接ELBを指定することも可能ですが、今回は先
にAutoScalingGroupを作成するため、ここでは行いません。

View Slide

AutoScalingで最も重要なパラメータである、スケーリングポリシーを設定します。最小
サイズ、最大サイズ、メトリクス、閾値などを指定します。
ここではCPU利用率以外には、ネットワークOut、ネットワークIn、リクエスト数が選択可
能です。他のメトリクスを利用する場合はCLIなどから設定します。AutoScalingGroup
については、マネジメントコンソールで可能な操作が極端に制限されています。以前より
も設定項目が減っています。

View Slide

スケーリングポリシーに関しては、AWSのキモと言ってもいい設定です。そのため、設定
内容は非常に細かく、マネジメントコンソールで設定しようとするとUIが非常に煩雑にな
るため、あえてシンプルな設定しかできないようにデグレードしたものと思われます。
シンプルなスケーリングポリシーを利用する場合は問題ありませんが、カスタムメトリク
スの利用や、細かい制御を行いたい場合はCLIやterraformでの設定が必須となりま
す。
そもそもスケーリングポリシーに関しては運用中に頻繁に見直すべき内容ですので、最
初はシンプルなもので設定しておくというのは理にかなっているのかもしれません。

View Slide

ライフサイクルイベント発生時の通知先を指定可能です。画面ではメールアドレスを指
定していますが、SNSトピックであれば何でもいいので、ライフサイクルイベント発生時
にフック処理を行う場合はSNS経由でLambdaを呼び出します。

View Slide

最後にタグを設定して作成完了です。

View Slide

ELB(ロードバランサー)の作成
AWSのロードバランサーは以下の３種類が存在します。
● Application Load Balancer (ALB)
● Network Loadbalancer (NLB)
● Classic Load Balancer (CLB)
通常のWebシステムではALBを利用しますが、他の2つについても非常に重要なのでそ
れぞれの特徴について説明します。

View Slide

ELB (Elastic Load Balancer)
各ELBを説明する前に、ELB全体についての説明をします。
ELBは負荷量に応じて自動でスケールアウトするロードバランサーのEC2インスタンス
です。スケールアウトは全自動で行われ、利用者が制御することはほぼできないので、
いつの間にか台数が増えたり減ったりしています。
スケールアウトした場合は当然IPアドレスが消費されるので、ELBを使うサブネットでは
スケールアウト分のIPアドレス余剰がなければいけません。（IPアドレスが足りないとス
ケールアウトが失敗しますが、ELB自体が無効になったりはしません）
また、キャンペーンや〇〇砲など、負荷増大が事前にわかっている場合は、ウォーム
アップ申請を行ってスケールアウトを高速化することが可能です。

View Slide

ELB (Elastic Load Balancer)
ELBは通常のロードバランサーでよく見かける以下の機能があります。
● CookieによるSession Persistence
● ヘルスチェック（ロードバランサーだから当たり前）
● Connection Draining （切り離しても一定時間トラフィックを保持）
● X-Forwarded-XXX ヘッダ（リバースプロキシのためのヘッダ）
また、AWS特有の機能として以下があります。
● S3へのアクセスログ配信
● AWS WAF統合（ALBのみ）
● リクエスト追跡のためのヘッダ（X-AMZN-TRACE-ID）
これらの機能については今回は説明しません。

View Slide

Application Load Balancer
HTTPに特化したL7ロードバランサーです。ホスト名もしくはパスに応じて振り分け先の
インスタンス（またはAutoScalingGroup）を動的に決定します。
ALBでは、HTTPもしくはHTTPSプロトコルのリスナーを追加して、プロトコルを有効にし
ます。HTTPリスナーが追加されていればHTTPが、HTTPSリスナーが追加されていれ
ばHTTPSが有効になります。
HTTPリスナーでは受信ポートを指定できます。HTTPSリスナーでは受信ポートに加
え、TLSの証明書を指定できます。TLSの証明書はACM(Amazon Certificate
Manager)に登録されている必要があります。
通常のWebシステムであればこのALBを利用します。構築方法については後述します。

View Slide

Network Load Balancer
TCPのL4ロードバランサーです。ALBと違うのは、負荷分散対象がEC2インスタンス以
外に、静的なIPアドレスを対象にできるということです。
IPアドレスが疎通していればどんな対象にでもトラフィック可能なため、EC2インスタンス
に限らず、オンプレのサーバや他のAWSサービスに対しても負荷分散が可能です。
2018年6月現在ではTLS終端の機能は持っていないため、TLS終端処理はターゲット側
で行う必要があります。
主な用途としては、オンプレとの負荷分散、VPCエンドポイントの負荷分散、および
gRPCなどHTTP/2の負荷分散です。（ALBではHTTP/2の負荷分散はできません）

View Slide

Classic Load Balancer
TCPのL4ロードバランサーです。ALBと違い、ホスト名やパスでのルーティングはできま
せん。対象はEC2インスタンスもしくはAutoScalingGroupとなります。
NLBと違い、TLS終端機能を持ちます。そのため、現状ではインターネットからgRPCを
利用する場合はほぼCLB一択となります。(VPC内であればNLBでいいと思います。)
Classicと名前が付いていますが、NLBがTLS終端機能を持っていないため、HTTP以
外の負荷分散ではバリバリの現役選手です。
TLS終端で利用する証明書はACM(またはIAM Server Certification)に登録されている
必要があります。IAM Server CertificationはACMが出る前の旧機能。

View Slide

ALBの作成
作成済みのAutoScalingGroupに対して負荷分散を行うALBを構築します。

View Slide

ALBの作成
今回はHTTPSは使わずにHTTPのみです。

View Slide

ALBの作成
ELBのサブネットを指定します。インターネット向けのELBはパブリックサブネットに構築
しなければなりません。また、ELBは可用性のためMulti-AZで負荷分散することがほと
んどです。

View Slide

ALBの作成
セキュリティグループを設定します。インターネット向けなのでHTTPを全公開していま
す。
スクリーンショットのために 0.0.0.0/0 を指定していますが、評価目的などでは
オフィスのグローバルIPからのみアクセスを許可してください。

View Slide

ALBの作成
続いて、ALBの設定のキモであるターゲットグループを作成します。ここではデフォルト
（すべてのパス）のターゲットグループを作成します。
ターゲットへの通信はHTTP/1.1です。HTTP/2に対応していません。そのた
め、gRPCなどHTTP/2が必須の場合にALBが利用できません。

View Slide

ALBの作成
ターゲットグループごとにヘル
スチェックの指定ができます。
成功コードは複数指定やレン
ジ指定が可能です。

View Slide

ALBの作成
ターゲットのインスタンスを登録しますが、AutoScalingGroupを利用する場合はここでイ
ンスタンスを登録してはいけません。AutoScalingGroup側から追加します。ここで登録
してしまうとインスタンスが固定のためスケールアウトで追加されたインスタンスにトラ
フィックが到達しません。

View Slide

ALBの作成
ALBの作成が完了したら、ルールを確認します。

View Slide

ALBの作成
マネジメントコンソールから作成した場合、デフォルトのルールのみが存在します。これ
は、すべてのHTTPトラフィックをターゲットグループ edu-201806 にルーティングする
ルールを表しています。

View Slide

AutoScalingGroupをALBに登録
AutoScalingGroupをALBのターゲットグループとして登録します。先ほど作成した
AutoScalingGroupの設定画面で、ALBのターゲットグループを入力して設定を保存しま
す。

View Slide

AutoScalingGroupをALBに登録
すると、自動的にターゲットグループのターゲットにAutoScalingGroup配下のインスタン
スが登録されます。

View Slide

最初にAutoScalingGroupを作成してからALBを作成したため、ALBからEC2への通信
が許可されていません。そのためヘルスチェックに失敗します。
ALBからEC2への通信を許可するには2通りのやり方があります。
● ALBをEC2のセキュリティグループに参加させる。
● ALBのセキュリティグループからのアクセスをEC2のセキュリティグループで許可す
る。

View Slide

ALBをEC2のセキュリティグループに参加させる場合
ロードバランサーメニューで当該ALBを選択してセキュリティグループの編集
を行います。

View Slide

ALBからのアクセスをEC2のセキュリティグループで許可する場合
EC2の起動テンプレートで設定したセキュリティグループに対してALBのセキュリティグ
ループからのアクセスを許可します。

View Slide

どちらの手段で設定したとしても、ターゲットの状態がHealthyになりました。

View Slide

ブラウザでの確認
ALBのDNS名を確認して、ブラウザでアクセスします。

View Slide

ブラウザでの確認
起動テンプレートで指定したNginxインストール済みのEC2インスタンスに接続されるこ
とが確認できました。

View Slide

作成したリソースの削除
● NATゲートウェイの削除（時間がかかるので最初に行う）
● AutoScalingGroupの削除
○ これをやらないとインスタンス削除しても復活してしまう
● SNSトピックの削除 (AutoScalingGroup消しても消えない)
● ロードバランサーの削除
● ターゲットグループの削除（ALB消しても消えない）
● インスタンスの削除、AMIの削除
● ALBセキュリティグループの削除
● VPCの削除

View Slide

まとめ
今回説明した内容はAWSの基礎中の基礎となるサービスの、ごく一部の機能だけで
す。
膨大なスライドの量にもかかわらず、実際に作業してみると１時間もかかりません。
なので、取っ掛かりを得たら実際に手を動かして構築してみましょう。
ところどころ書きましたが、AWSをちゃんと使うためにはマネジメントコンソールでは限界
があります。
CLIやterraform、CloudFormationの使い方を理解してチャレンジしましょう。

View Slide

Appendix
Nginx入りのAMI作成手順は以下のとおりです。
1. パブリックサブネットにAmazon LinuxのEC2を作成。キーペアを指定。
2. EC2にEIPをアタッチしてSSHで対象EIP宛にec2-userでログイン。
3. yumでnginxをインストール。chkconfig nginx onしてSSHを終了。
4. 起動中のEC2からイメージを作成。イメージが作成できたらEC2を削除。

View Slide

AWSの基本的な使い方

AWSの基本的な使い方

Sonoda Ryohei

More Decks by Sonoda Ryohei

Other Decks in Technology

Featured

Transcript