Slide 1
Slide 1 text
AWSの基本的な使い方
M3 社内研修用
エンジニアリンググループ 園田
Slide 2
Slide 2 text
はじめに
スライドに利用しているマネジメントコンソールのスクリーンショットは2018/06時点のも
のとなります。
AWSの情報探索時の心構えとして、マネジメントコンソールは頻繁にUIが変わるので、
スクリーンショットをあてにしないようにしましょう。（リソースのモデルを把握しましょうw）
今回のスライドはかなり初心者向けの内容となっているため、ざっと資料を先読みして
自分にとって不要だなと判断したら時間がもったいないので読み飛ばしていただいて結
構です。
Slide 3
Slide 3 text
はじめに
アンケートなどでM3でのユースケースがあるとわかりやすいという意見がありますが
（実際私もその方がわかりやすいと思いますが）、M3のユースケースを私自身すべては
把握しておらず、また使い方も千差万別のため「コレ」というものがありません。
前回講義でも触れましたが、AWSは非常に膨大な機能仕様があり、それらの組み合わ
せはほぼ無限に存在するため、この短い時間では代表的なユースケースですら解説す
るのは困難です。使い方の説明をメインにしているため、料金体系などの説明もあまり
出てきません。
今回の講義はどんなユースケースにおいても必要になるサービスや概念の説明がメイ
ンとなっています。
Slide 4
Slide 4 text
アジェンダ
● 第1章 VPC
○ サブネット
○ NATゲートウェイ
● 第2章 EC2 / EBS
○ EBS
○ インスタンスプロファイル (IAMロール)
○ UserData
○ セキュリティグループ
● 第3章 AutoScaling / ELB
○ AMI
○ Launch Template
○ AutoScalingGroup
○ ELB
Slide 5
Slide 5 text
一般的なWebシステムにおけるAWS環境の構築手順
通常のWebシステムの場合、構築手順はおおまかに以下のような流れになります。
1. ネットワークリソースの構築（VPC, サブネットなど）
2. サーバリソースの構築（EC2、RDS、セキュリティグループなど）
3. 負荷分散環境の構築（ELB、AutoScalingGroupなど）
4. BCP(国外リージョンによるDR)環境の構築（今回は触れません）
以降のスライドでは、それぞれの構築フェーズで行う作業と、考慮すべきポイントを解説
します。
Slide 6
Slide 6 text
構築環境のイメージ
時間の都合上、今回はRDS構築の説
明はしません。
Slide 7
Slide 7 text
第1章
VPC
Slide 8
Slide 8 text
ネットワークリソースの構築
VPCによるネットワークリソースの構築を行います。VPCはほとんどのユースケースで
必要になる可能性が高いです。AWS利用の前提知識といえます。
VPCを構築する上で考慮しなければならない事項は以下の通りです。
● 他のVPCや別アカウントのVPCと接続する必要があるかどうか。
● 必要なIPアドレスの個数。（1VPCあたり上限65,536 - α）
● IPv6でのアクセスが必要かどうか。（通常は不要）
● VPC内のインスタンスからインターネットを参照可能とするかどうか。（通常は必要）
特に上２つは後からの変更が非常に困難なため、初期構築時に必ず検討する必要があ
ります。
Slide 9
Slide 9 text
ネットワークリソースの構築（注意事項）
他のVPCや別アカウントのVPCと接続する必要があるかどうか。
VPCは構築時にCIDRを指定しますが、後から変更はできません。
他のVPCや別アカウントのVPCとVPCピアリング（VPC間接続）する際に、プライベート
ネットワークのアドレスが被っていた場合、接続できません。
そのため、接続先のVPCとネットワークアドレスが被らないようにCIDRを指定する必要
があります。
VPCエンドポイント + NLBという手段で接続できなくもないですが、構成が複雑になるた
めオススメしません。これは最終手段です。
https://dev.classmethod.jp/cloud/aws/try-aws-privatelink_1/
Slide 10
Slide 10 text
ネットワークリソースの構築（注意事項）
必要なIPアドレスの個数。（1VPCあたり上限65,536 - α）
VPCのIPレンジ（ネットマスク）は最小で16ビットです。65536個のIPアドレスを発行可能
ですが、AWSの内部リソースに消費される予約分や、ELBなど動的に増減するIPアドレ
スを考慮に含めてIPアドレスの個数を検討します。
通常のWebシステムでIPアドレスが枯渇することはまずありませんが、VPC内で
Lambdaを大量に実行する場合や、EMRなどで大量のスポットインスタンスを立ち上げ
る場合はIPアドレスの枯渇を意識する必要があります。
もし60000を超えそうな場合はVPCを分割しても問題ないアーキテクチャで実装する必
要があります。
Slide 11
Slide 11 text
ネットワークリソースの構築（注意事項）
VPC内のインスタンスからインターネットを参照可能とするかどうか
VPC内のインスタンスは踏み台インスタンスを除き、インターネットから接続不可能なプ
ライベートサブネットに構築するのが一般的です。ただし、インターネットへのアクセスは
必要になるケースは多いです。
● bundle installなど、パッケージのダウンロード
● sentryやdockerhubなど外部サイトへのアクセス
最初からこれらを考慮したクラウドネイティブなシステムを除き、ほとんどのケースでは
外部サイトへのアクセスが必要となります。
インターネットへのアクセスが必要な場合、通常はNATゲートウェイをVPCに構築しま
す。(NATインスタンスやForward Proxyという手段もあります )
Slide 12
Slide 12 text
ネットワークリソースの構築（詳細手順）
新規ネットワークを構築するには以下の手順で行います。
1. VPCの作成
2. インターネットゲートウェイの作成
3. パブリック用のサブネットの作成
4. パブリックサブネットの設定
5. プライベート用のサブネットの作成
6. NATゲートウェイの作成
7. VPCエンドポイントの作成（作成は任意、今回は割愛）
8. プライベートサブネットの設定
この順序は、マネジメントコンソールでの作業順序となります。ややこしいのですが、マネジメントコン
ソールで作成する場合と、Terraformなどで作成する場合で作業順序が異なることが多々あります。
Slide 13
Slide 13 text
VPCの作成
VPCの作成に必要なパラメータは名前とCIDRの2つです。
VPCの名前です。Nameタグに設定されます。他の人が見てもわかり
やすい名前をつけましょう。my-vpcとかは言語道断。
VPCのIPアドレス範囲です。他のVPCと同じでもエラーになりません
が、VPC間でのネットワーク接続が必要な場合は考慮が必要です。特
に理由がない限り16ビットで切るのが一般的です。
これらのパラメータは通常のケースではデフォルトで問題ないです。
IPv6でのアクセスが絶対に必要な場合はまずないでしょう。
Slide 14
Slide 14 text
VPCの作成
VPCを作成すると、以下のリソースがデフォルト生成されます。
● デフォルトのセキュリティグループ
● デフォルトのルートテーブル（メインルートテーブル）
これらのデフォルトで生成されたリソースは、VPCが存在する限り破棄できないため、
TerraformなどInfrastructure as Codeで管理する場合は基本的に利用しないほうがい
いです。
VPCに限らず、デフォルト生成されたリソースは基本的に無視したほうがTerraformなど
で管理しやすいです。自動生成されるリソースは、他にはDHCPオプションやRDSパラ
メータグループなどがあります。
Slide 15
Slide 15 text
インターネットゲートウェイの作成
VPCとインターネットを接続するための仮想ルータである、インターネットゲートウェイ
(IGW)を作成します。
インターネットからの接続が不要でも、NATゲートウェイ経由でインターネットへ接続する
際に必要になるため、作成するケースがほとんどです。踏み台インスタンスにも必須で
す。
Slide 16
Slide 16 text
インターネットゲートウェイの作成
作成したIGWをVPCにアタッチします。IGWをアタッチしない限り、VPCとインターネット
は相互通信不能です。(セキュリティインシデント発生時など、IGWをデタッチすることが
あります)
Slide 17
Slide 17 text
パブリック用のサブネットの作成
AWSにおいてAZで分割された仮想ネットワークをサブネットと呼びます。
インターネットから直接通信可能なサブネットをAWS用語でパブリックサブネットといい
ます。パブリックサブネットを構築するためには、まずパブリックサブネット用のサブネット
を作成します。
ややこしいのですが、パブリックサブネットというリソースは存在しません。作成されたサ
ブネットに対してIGWをルーティングすることで、そのサブネットはパブリックサブネットと
なります。
パブリックサブネットには、踏み台インスタンス、および外部からHTTP(S)でアクセスする
ためのELBを含めることになります。ELBをマルチAZで構築するためには、パブリックサ
ブネットを複数のAZに作成する必要があります。
Slide 18
Slide 18 text
パブリック用のサブネットの作成
サブネットの名前です。Nameタグに設定されます。SuffixにAZをつけ
るのが慣例です。
AZを選択します。マルチAZにする場合はサブネットを複数作成しま
す。サブネットのAZを後から変更することはできません。
サブネットのIPレンジをCIDRで指定します。通常、プライベートサブ
ネットよりもIPアドレスの個数は少なくすみますが、わかりやすくするた
め/24にすることが多いです。
Slide 19
Slide 19 text
パブリックサブネットの設定
パブリックサブネット用に作成したサブネットに割り当てるルートテーブルを作成します。
Slide 20
Slide 20 text
作成したルートテーブルに 0.0.0.0/0 宛（ローカルネットワーク以外のすべての通信）の
パケットをVPCにアタッチしたIGWにルーティングさせるように設定します。（ルートテー
ブルは上から評価されます）
パブリックサブネットの設定
VPC内のIPアドレスはすべてローカルネットワーク内の通信として扱われ、変更はでき
ません。そのため、他のVPCと通信する場合はIPアドレスの範囲がかぶらないようにし
なければなりません。
Slide 21
Slide 21 text
この設定が完了した時点で、関連づけたサブネットは便宜上、パブリックサブネットと呼
ばれるようになります。
パブリックサブネットの設定
作成したルートテーブルとパブリックサブネット用に作成したサブネットを関連付けます。
ELBなどをマルチAZ構成にする場合はAZの異なる複数のサブネットを関連付けます。
明示的に関連付けを行う前は、VPC作成時に自動生成されたデフォルトのルー
トテーブル（メインルートテーブル）と関連付けられています。
Slide 22
Slide 22 text
プライベート用のサブネットの作成
パブリック用のサブネットを作成した際と同様に、プライベート用のサブネットを作成しま
す。マルチAZが必須なケースがほとんどなので、複数AZで作成します。VPC内で大量
のリソースを作成する場合はCIDRを大きめに切ります。
当然ですが、パブリックサブネットと同じAZを選択したほうが通信のレイテ
ンシが少ないため、特に理由がない限りパブリックサブネットと同じAZを選
択します。
Slide 23
Slide 23 text
NATゲートウェイの作成
プライベートサブネット内のインスタンスがインターネットに接続可能なようにNATゲート
ウェイを作成します。
NATゲートウェイと関連付けるサブネットを選択します。ここで選択する
サブネットはIGWと通信可能でなくてはなりません。つまり、先に作成し
たパブリックサブネットを選択する必要があります。
Slide 24
Slide 24 text
プライベートサブネットの設定
プライベートサブネット用のルートテーブルを作成します。
Slide 25
Slide 25 text
プライベートサブネットの設定
作成したルートテーブルに、インターネット向けパケットをNATゲートウェイに送信するよ
うにルーティング設定を行います。
Slide 26
Slide 26 text
プライベートサブネットの設定
プライベートサブネット用に作成したサブネットを、ルートテーブルに関連付けます。これ
で、プライベートサブネット内に構築されるインスタンスがインターネットに対してパケット
を送信可能になります。
このキャプチャは保存前の状態です。
Slide 27
Slide 27 text
補足: NATゲートウェイの冗長化
ここまでの手順で、以下のリソースが作成されています。
● VPC
● インターネットゲートウェイ
● パブリックサブネット * AZ
● プライベートサブネット * AZ
● NATゲートウェイ
● ルートテーブル * 2 (パブリック用、プライベート用)
このままでもシステム運用可能ですが、NATゲートウェイがシングルAZになっているた
め、インターネット通信を頻繁に行うシステム（電子決済や外部認証など）では可用性が
問題になります。
Slide 28
Slide 28 text
補足: 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/月
Slide 29
Slide 29 text
補足: NATゲートウェイが不要なケース
以下に該当する場合はNATゲートウェイが不要な可能性があります。
● インターネット通信量や通信頻度が少ない場合
○ NATゲートウェイではなく、 NATインスタンスを構築する。
○ インターネット通信が必要な場合（デプロイ時や AMI作成時など）のみNATゲートウェイを構築して
ルーティングする。（この操作は Lambdaなどで実装する）
● 出口対策などでフォワードプロキシを構築する（もしくは構築済みの）場合
○ インターネット向けの通信をプロキシサーバを経由するようにルーティングする。
● 通信対象がAWSのサービスのみの場合
○ S3やCloudWatch LogsなどVPCエンドポイントがサポートされているサービスでは VPCエンドポイ
ントを利用する。
○ Amazon LinuxのyumリポジトリはS3なので、標準リポジトリのみ利用の場合は VPCエンドポイント
で代替可能。
● 接続先サイトに対してIPv6で接続可能な場合
○ Egress Only Internet Gatewayの利用を検討する。 （自分は使ったことないのであまり良く知りません・・・）
Slide 30
Slide 30 text
以上でネットワーク構築は完了です。
Slide 31
Slide 31 text
お気づきになりましたか？
ここまでで、セキュリティグループについて触れていません。
AWS初心者にありがちなのが、ネットワーク通信制御とセキュリティグループとを混同す
ることです（少なくとも私は最初混乱しました。インフラの人から見たらハナから別物なのかなあ・・・） 。
セキュリティグループで通信を許可しても、VPCでルーティングされていなければ通信は
不可能です。また、セキュリティグループは文字通り、リソースを通信単位でグルーピン
グするためのものです。ネットワーク設定とは厳密に異なります。AZやサブネットの概念
がありません。セキュリティグループはリソースありきとなるため、次の章から説明しま
す。
とはいえあまり複雑に捉えず、セキュリティグループはネットワーク設定の上にあるレイヤと思っておけば問題な
いです。
Slide 32
Slide 32 text
第2章
EC2 / EBS
Slide 33
Slide 33 text
サーバリソースの構築
EC2は仮想マシンを時間課金で起動するタイプの、いわゆるIaaSという概念に該当する
ものです。つい最近、ベアメタルインスタンス（物理マシン）のサポートも開始されました。
ELB、ECS、Elastic Beanstalk、EMR など数多くのサービスがEC2をラップしたサービ
スなので、EC2の概要を知ることはAWS利用の上で必須といえます。
実際に踏み台用のEC2インスタンスを作成する手順に沿って、EC2構築における概念
や考慮事項を説明していきます。
Slide 34
Slide 34 text
サーバリソースの構築
EC2を構築するうえで考慮しなければならないのは以下の事項です。
● OSとバージョン
● インスタンスタイプ（CPU、メモリ、ネットワーク帯域）
● ストレージの種類とサイズ、IOPS性能
● サーバの初期化処理（UserData =>プロビジョニングスクリプト）
● インスタンスプロファイル（IAMロール）
● Windowsの場合はドメイン、ライセンスなど考慮事項多数
Slide 35
Slide 35 text
OSとバージョン選定
EC2の作成では、まずOSとバージョンを選択します。
Slide 36
Slide 36 text
OSとバージョン選定
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など
Slide 37
Slide 37 text
OSとバージョン選定
どのOSのどのバージョンを利用するかは、目的によって異なると思いますが、特に理由
がない限りAmazon Linuxの利用をオススメします。
● AWS利用における情報量の多さ、AWSのサポート
● AWSが独自にパッチを当てたXenやKVMとの親和性
● パッケージリポジトリがS3に存在するため超高速インストール
● 通常のRHELやCentOSよりもパッケージが少し新しめ
● aws-ssm-agentなどAWSツールが標準リポジトリからインストール可能
なお、公式のAMIではカーネルパラメータやカーネルモジュールなどは汎用的な用途に
マッチするように初期設定されています。これらはgrubやmodproveの設定を変更した
状態でAMIを作成することにより、ユーザによってチューニング可能です。
Slide 38
Slide 38 text
OSとバージョン選定
RHEL や SUSE 、Windows など有料のOSのライセンスは従量課金の利用料金に含
まれています。
すでにライセンスを購入済みの場合は購入済みライセンスを適用することで従量課金額
を安くすることができます。(BYOL: Bring Your Own License)
Windows Server のライセンス形態は複雑すぎてよくわからないので、不安な場合はソ
リューションアーキテクトの方に相談してください。
※ただでさえ複雑なWindowsライセンスがAWSの独自エディションでわけわからなくなっています。
Windowsに限らず、BYOL利用の場合はソリューションアーキテクトへの相談は必要に
なるでしょう。
Slide 39
Slide 39 text
OSとバージョン選定 まとめ
● OS選定で最も重要なのは、インストールするパッケージのサポート。
● 次に重要なのは運用チームの習熟度。
● 特に理由がない限り、Amazon Linuxを選んでおけばOK。
● systemdを利用したい場合は RHEL7 か Amazon Linux 2。
● Windows向けの製品を利用したい場合。Windows向けだけではないけど、
Windowsに最適化された製品も多数存在する。(日立のCosminexusとか)
マネジメントコンソールでの作業だとわかりづらいですが、OS選択画面では、裏側で当
該OSがプリインストールされたAMIのIDが選択されています。AMIについては後述しま
す。
Slide 40
Slide 40 text
インスタンスタイプ選定
OSを選択したら、次にインスタンスタイプを選択します。
Slide 41
Slide 41 text
インスタンスタイプ選定
EC2には用途に応じてインスタンスタイプという区分が存在します。インスタンスタイプに
よって搭載される仮想CPUコア数、メモリ量や、ネットワーク帯域、ローカルストレージ容
量が変わります。
インスタンスタイプは用途を表すアルファベット1文字と世代を表す数字1文字、グレード
で表されます。用途と世代を合わせた2文字をインスタンスファミリーと呼称します。イン
スタンスファミリーは2文字以上のものも存在します。
例: m5.4xlarge の場合
● m => 汎用インスタンスを表す。
● 5 => 第５世代のインスタンスを表す。
● 4xlarge => インスタンスファミリーにおけるグレード。
○ 大きいほど高価で高性能。 4xlargeはxlargeの4倍という意味。
Slide 42
Slide 42 text
インスタンスタイプ選定
現行世代には以下のインスタンスファミリーがあります。
● 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 以外は低価格
帯での提供タイプがないものが多いです。
Slide 43
Slide 43 text
インスタンスタイプ選定
t2インスタンスは、普段はCPUが従来の20%しか利用できない代わりに時間単価がか
なり安いインスタンスタイプです。
時間経過とともにクレジット（単位は時間）が溜まっていき、このクレジットを消費すること
でクレジット分の時間だけバースト（CPU性能を100%利用可能な状態）することができ
ます。
また、Unlimitedオプションを有効にすると、クレジットが枯渇しても追加料金を支払うこと
でバースト時間を増やすことができます。
現行世代では低パフォーマンス帯のインスタンスタイプはt2でしか提供されていないの
で、今後利用する際にはt2ファミリーの利用が増えると思います。
Slide 44
Slide 44 text
インスタンスタイプ選定
インスタンスタイプごとに設定されているvCPU数やメモリ容量は理論値です。
実際にまったく同じインスタンスタイプのEC2インスタンスでも、パフォーマンスに大きく
差が出ることがよくあります。
これは、DCに設置されているKVMホストマシンもしくは接続機器の故障や老朽化によっ
て仮想マシンにパフォーマンス劣化の影響が出ているためです。
EC2インスタンスのパフォーマンスにバラツキがあるため、このような事象をEC2ガチャ
と呼んだりします。
なので、低パフォーマンスのEC2を引いたときでも即廃棄できるようにイミュータブルな
システムを構築することはクラウドにおいて必須と言えます。
Slide 45
Slide 45 text
インスタンスタイプ選定
一部のインスタンスタイプでは、EC2インスタンスの仮想マシンに物理接続されている
ローカルストレージであるインスタンスストア（エフェメラルディスク）が付いてきます。
このインスタンスストアはEC2終了時にデータが消去されますが、ネットワーク接続され
ているEBSと比べてI/Oが圧倒的に高速というメリットがあります。
なので、ログや中間ファイルなどをインスタンスストアに入出力することでシステム全体
のパフォーマンス向上に寄与します。
ただし、インスタンスストアは現行世代のインスタンスにはほとんど搭載されていませ
ん。つい最近まで m3.medium ですらあったのに、なんで！？
Slide 46
Slide 46 text
インスタンスタイプ選定 まとめ
● とにかく低コストにしたいのであれば t2
● AutoScaling前提のWebシステムであれば汎用の t2 か旧世代の m3
● 平常時のアクセス量が多い中規模以上のWebシステムであれば m5
● DBなどディスクI/O性能を求めるならストレージ最適化
● RedisやMemcachedなどオンメモリDBを利用するならメモリ最適化
● 機械学習など計算量が多いシステムならGPU最適化
● VMware on AWS など Hypervisor を利用したい場合は i3.metal
● エムスリーなので m3
Slide 47
Slide 47 text
ネットワークの設定
EC2インスタンスの詳細設定画面です。量が多いのでセクションごとに説明します。まず
はネットワーク周りです。VPCとサブネットを選択します。
EC2インスタンスは必ずVPC内のサブネットに属します。（昔はVPC外
に作成することができました。）
後からVPCやサブネットを変更することはできません。変更したい場合
はスナップショットを作成して起動しなおします。
踏み台インスタンスでは、EIPをアサインしてIPを固定にするた
め自動割り当てのパブリックIPは利用しません。
Slide 48
Slide 48 text
スポットインスタンス
スポットインスタンスは、入札により課金額が決定するインスタンスです。
通常のオンデマンドインスタンスより最大9割くらい安く稼働させることができますが、入
札額が相場を下回ると自動的に停止します。
ステートレスな処理を大量に行うバッチ処理などで有効です。Webシステムではスパイ
クアクセスなどによりトラフィックが急増した際に利用したりします。
また、AWS BatchやEMRなど一部のサービスではスポットインスタンスを利用する機能
が備わっているものもあります。
Slide 49
Slide 49 text
プレイスメントグループ
AZ内のEC2インスタンス間通信は十分に高速ですが、プレイスメントグループを作成す
るとさらに高速な通信が可能になります。
プレイスメントグループは、ネットワーク的に近いHW上にインスタンスを構築すること
で、通信のレイテンシを最小限におさえることが可能です。
ただし、「ネットワーク的に近い = 物理的な距離が近い」なので、災害などによりまとめて
死ぬことがありえます。
一般的なWebシステムでは、インスタンス間の通信は不要なことが多いため、プレイスメ
ントグループを利用することは少ないと思います。分散バッチなどでの利用がメインとな
るでしょう。他には、インスタンス間通信を前提としたErlang/OTPや、トライアド構成のシ
ステムなどでも有用かもしれません。
Slide 50
Slide 50 text
ネットワーク以外の設定です。IAMロールは後述します。モニタリングやテナンシーは今
回は割愛します。
その他の設定
EC2インスタンスに紐付けるIAMロールを選択します。IAMロールはイン
スタンスプロファイルを持っている必要があります。
Slide 51
Slide 51 text
IAMロール (インスタンスプロファイル)
EC2にはIAMロールを紐付けることができます。
IAMロールがアタッチされたEC2インスタンスからは、各AWSサービスに対してアクセス
キーなしでAPI実行が可能なため、セキュアにAWSのAPIを利用可能です。
EC2からAWSのサービスを利用する場合は、必ずIAMロールを設定するようにしてくだ
さい。
間違ってもIAMユーザーを作成して、アクセスキーをEC2上に格納しないように気をつけ
てください。
Slide 52
Slide 52 text
UserData (プロビジョニングスクリプト)
EC2では初回起動時に行うプロビジョニングの処理を設定することができます。これを
UserDataと言います。
Linuxであればshebangで実装言語を指定可能です。#cloud-config をshebangに指定
した場合は、YAMLで記述可能なCloud-Initの仕様を利用可能です。
Slide 53
Slide 53 text
UserData (プロビジョニングスクリプト)
BashでUserDataを記載する例を見てみます。
以下の例では、sshdのListenポートを変更しています。
※前職でよく使っていました。その時は443に変更してました。
Slide 54
Slide 54 text
UserData (プロビジョニングスクリプト)
Cloud-InitはクラウドサーバをプロビジョニングするためのDSL仕様で、ansibleみたいに
宣言的にサーバの状態を記述できるため非常に便利です。
以下のリンクに様々なユースケースでのサンプルコードが載っています。
http://cloudinit.readthedocs.io/en/latest/
初回起動時以外のイベント処理も記載可能で、冪等性も担保されます。
なお、ECSではクラスタインスタンスの利用でUserDataを必ず利用します。Elastic
BeanstalkではUserDataの代わりにインスタンスを初期化する手段があります。
Slide 55
Slide 55 text
EC2のストレージ (EBS)
Slide 56
Slide 56 text
EC2のストレージ (EBS)
EBSは仮想ブロックストレージです。仮想ハードディスクと思っておけば大体あってま
す。EC2のOSイメージや、アプリケーションバイナリ、ログファイルなどのファイルを格納
するための永続化ストレージです。
EC2そのものは永続ストレージを持っていません。EC2起動時にOS起動イメージが格
納されたEBSが複製・アタッチされ、アタッチされたEBSがマウントされた状態で起動し
ます。ファイルシステムはAmazon LinuxデフォルトだとXFSです。
また、EBSはEC2上で動作する他のサービスでも利用されます。代表的なもので、RDS
やElasticsearchがあります。これらのサービスはEBS上にデータを永続化しています。
ちなみに、API上ではEBSはVolumeというエンティティ名です。忘れやすいので注意。
Slide 57
Slide 57 text
EC2のストレージ (EBS)
EBSは最低で100 IOPSのベースライン性能が出ます(gp2の場合)。また、IOクレジット
があり、クレジットが枯渇しない限り最大3000 IOPSまでバースト可能です。
プロビジョンドIOPSストレージ(io1)の場合、IOPSを最大で60000まで指定することが可
能です。
EBSには gp2, st1, sc1 など種別があり、ランダムアクセスが得意、シーケンシャルアク
セスが得意、スループットが安定しているなどの特性があります。
通常のWeb利用ではストレージ速度を気にすることはあまりないので、汎用ボリューム
のgp2を選択することが多いです。
Slide 58
Slide 58 text
EC2のストレージ (EBS)
EBSはスナップショット機能があります。オンラインで取得可能なのでデータの信頼性が
重要なシステムでは重宝します。
ただ、リストアにそれなりに時間がかかるので、RTT（目標復旧時間）の指標が厳しい
ミッションクリティカルなシステムではEBSのスナップショットとは別に、OS内でファイル
システムのスナップショット(LVMスナップショットやxfs_dumpなど)を取得することもよく
あります。前職では2台のEC2でDRBDを組んだりしてました。
RDSの自動バックアップ機能はEBSのスナップショットにより実現されています。スナッ
プショットされたイメージはS3に格納されます。なお、S3のコンソールからスナップショッ
トを確認することはできません。
Slide 59
Slide 59 text
タグの設定
EC2においてタグは比較的重要です。Systems Managerによるパッチ適用やパッケー
ジインストールなどを行うにあたり、タグを利用するためです。サーバーロールや環境
名、サービス名などを入れておきましょう。
Slide 60
Slide 60 text
セキュリティグループの設定
セキュリティグループについては後述します。ここでは社内からのSSHを許可していま
す。
Slide 61
Slide 61 text
キーペアの選択
Slide 62
Slide 62 text
以上で踏み台インスタンスの構築は完了です。
Slide 63
Slide 63 text
セキュリティグループ
セキュリティグループは文字通り、通信を許可するリソースをグルーピングするための機
能です。通信の受信（Ingress）と送信（Egress）を、ホワイトリストとブラックリストにより
認可します。
設定可能な代表的なパターンは以下の通りです。
● 特定のセキュリティグループからのアクセスに対する認可
● セキュリティグループ内のアクセスに対する認可
● 特定のIPアドレス(CIDR)からのアクセスに対する認可
● 特定のIPアドレス(CIDR)へのアクセスに対する認可
● VPCエンドポイントへのアクセスに対する認可（今回は割愛）
Slide 64
Slide 64 text
セキュリティグループ
特定のセキュリティグループからのアクセスに対する認可
VPC内のリソースからのアクセスを制御するパターンで、頻出パターンです。EC2に対
するELBからのアクセス、RDSに対するEC2のアクセスなど、AWSリソース間でのアク
セス制御に利用します。非常にシンプルですが、設計を誤ると相互参照が発生します。
相互参照は作成する分にはエラーにはなりませんが、削除しようとするとエラーになるた
め、terraformなどで厄介です。
Slide 65
Slide 65 text
セキュリティグループ
セキュリティグループ内のアクセスに対する認可
同一セキュリティグループ内の通信を許可するパターンです。RDSやElastiCacheのセ
キュリティグループとして利用することが多いです。複数のセキュリティグループをオー
バーラップさせる前提となります。相互参照しづらくなるためterraformなどとの相性がい
いですが、人間にはわかりづらいというデメリットがあります。
Slide 66
Slide 66 text
セキュリティグループ
特定のIPアドレス(CIDR)からのアクセスに対する認可
踏み台インスタンスへのSSH接続、テスト環境へのWebアクセスなど、VPCの外にある
拠点からのアクセスを制限する場合に利用します。これには、VPN接続で接続されてい
る別のVPCや、Direct Connect経由で接続されているオンプレからのアクセスも含まれ
ます。
Slide 67
Slide 67 text
セキュリティグループ
特定のIPアドレス(CIDR)へのアクセスに対する認可
特定のIPアドレスへの通信のみを許可し、外部へのアクセスを制限するパターンです。
マルウェアや内部犯行対策として設定することがほとんどです。
Slide 68
Slide 68 text
ネットワークACL
IPアドレスに対する制限は（説明していませんが）ネットワークレイヤであるサブネットの
ACLでも可能です。
より堅牢にするのであれば、サブネットのACLとセキュリティグループを併用して同じ制
限をかけます。こうすることによって、誤ってどちらかの制限を解除してしまった場合でも
救済することができます。
当然、管理は煩雑になるのでterraformなどで管理したほうがいいでしょう。
Slide 69
Slide 69 text
第3章
AutoScaling / ELB
Slide 70
Slide 70 text
AutoScaling
AutoScalingは、最小インスタンス数と最大インスタンス数を指定して、スケーリングポリ
シーに応じてスケールアウト・スケールインを行う仕組みの総称です。AWSに限った用
語ではありません。
AWSでは、ロードバランサーから接続するWebサーバを負荷分散するために利用する
のが主な用途です。
なお、ロードバランサーは必須ではなく、バッチ処理を複数サーバで分散処理する場合
にも利用されます。
AutoScalingの機能自体はロードバランサーに依存していないため、多くのユースケー
スで利用が可能です。
Slide 71
Slide 71 text
Amazon Machine Image (AMI)
AutoScalingを説明する上で、AMIの説明は避けて通れないのでAMIを紹介します。
AMIとは、EC2起動前のVMイメージです。より具体的にはEC2のメタデータ（OSやデバ
イスマッピング情報など）と、OS起動イメージやファイルなどが格納されているEBSを圧
縮したアーカイブファイルです。
AWSから提供されているAMIでEC2を起動し、起動したEC2にミドルウェアやアプリケー
ションをインストールして、AMIを作成することができます。
EC2は必ずこのAMIから起動されます（起動時にAMIのIDを指定します）。
Slide 72
Slide 72 text
Amazon Machine Image (AMI)
AutoScalingでは、スケールアウトさせる際に、どのAMIを利用してEC2を起動するかを
予め定義しておく必要があります。
AWS提供のデフォルトAMIから起動してUserDataでもろもろ初期化してもAutoScaling
は可能ですが、パッケージインストールしてアプリケーションを展開して設定ファイルを生
成してなどをUserDataで行うと、スケールアウトまでの時間が非常に長くなってしまいま
す。
そのため、通常はアプリケーションなどをインストール済みの状態でAMIを作成してお
き、AutoScalingの起動設定でそのAMIを指定することで起動時間を短縮することがで
きます。
Slide 73
Slide 73 text
Amazon Machine Image (AMI)
起動設定に利用するAMIの戦略として、代表的なパターンとして以下があります。
● 必要なミドルウェアのみインストールされた状態のAMI
● アプリケーションまでインストールされた状態のAMI
● アプリケーションの設定や環境変数まで格納されたAMI
下に行くほど起動は高速になりますが、設定や環境変数まで格納したAMIを作成する
と、開発環境用AMI、本番用AMIなど非常に多くのAMIがバージョンごとに存在すること
になり、コストも増大します。
そのため、よく利用されるパターンとしては２番めの戦略となります。その場合、アプリ
ケーションの設定や環境変数は起動スクリプトなどで取得します。
Slide 74
Slide 74 text
Amazon Machine Image (AMI)
アプリケーションまで含めた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参照）
Slide 75
Slide 75 text
AutoScalingの起動設定 (非推奨）
AutoScalingを設定するためには、スケールアウト時にどのAMIを起動するかを予め設
定しておく必要があります。この設定をLaunchConfiguration(起動設定)といいます。
LaunchConfigurationの内容は、EC2の起動で入力したパラメータとほぼ同じです。
なお、LaunchConfiguration は現在非推奨となっています。
起動テンプレートを利用することが推奨されているため、今回は起動設定の説明を割愛
します。
起動テンプレートはローンチされたばかりの新しい機能です。そのため、Webで検索す
るとほとんどは起動設定がヒットします。注意してください。
Slide 76
Slide 76 text
Launch Template
LaunchConfigurationはAutoScalingでしか利用できませんが、Launch Templateは通
常のEC2起動に利用可能です。また、起動テンプレートはバージョン管理されます。以
下は起動テンプレート作成画面です。
Slide 77
Slide 77 text
Launch Template
起動テンプレートで起動するAMIのIDとインスタンスタイプ、キーペア名を指定します。
ネットワークタイプは必ずVPCを選択してください。Classicを使うことは将来的に見ても
ありません。
AutoScalingに利用する場合は、アプリケーションなどがインストールされ
たAMIのIDを指定します。
起動したEC2にSSHログインする必要がない場合は空にします。
ssm-agentを利用する前提であればSSHログインは不要です。
Slide 78
Slide 78 text
ネットワークインターフェイス、ストレージは空のままにします。
Launch Template
AutoScalingで利用する場合は、AutoScalingGroupの設定でネットワー
クを設定するため不要です。
ルートボリュームはAMIに含まれています。ルートボリューム以外をアタッ
チする必要がある場合のみ指定します。
Slide 79
Slide 79 text
タグを指定します。このタグはAutoScalingで起動されたすべてのインスタンスに設定さ
れます。これらとは別に、AutoScalingGroupのIDなどメタ情報のタグも設定されます。
Launch Template
Slide 80
Slide 80 text
セキュリティグループを指定します。起動されたすべてのEC2インスタンスがここで設定
したセキュリティグループに所属します。
Launch Template
まだELBを作成していないので、とりあえず同一セキュリティグループからのHTTPアク
セスを許可しておきます。
Slide 81
Slide 81 text
その他の詳細設定です。EC2起動時に設定
した内容と似ていますが、ElasticGPUなど
の項目が追加されています。
特定のAMIでのみ有効な項目もあります。
RAMディスクIDとカーネルIDはほぼ利用す
ることはないでしょう。
重要なパラメータとしてモニタリングがありま
す。次のスライドで説明します。
Launch Template
Slide 82
Slide 82 text
モニタリングは重要なポイントなので補足します。詳細モニタリングを有効にしなかった
場合、スケーリングの判断に必要なCloudWatchのメトリクスは最小でも5分間隔でしか
取得されません。
これはつまり、閾値を超えてスケールアウトが必要になるまでに最大で10分かかること
を意味します。そこからEC2が起動して準備完了になるまでさらに数分かかるため、ス
ケールアウトが完了するまでの時間は12〜15分くらいかかることになります。迅速なス
ケールアウトが必要なシステムでは必ず詳細モニタリングを有効にしてください。（ただ
し、詳細モニタリングはコストが上がります）
Launch Template
Slide 83
Slide 83 text
AutoScalingGroupの作成
起動テンプレートができたら、AutoScalingGroupを作成します。
作成した起動テンプレートを選択します。起動テンプレート画面から
AutoScalingGroupの作成を実行した場合はこの画面はスキップされます。
Slide 84
Slide 84 text
起動するテンプレートのバージョンとグループ名を指定します。
AutoScalingGroupの作成
「バージョンID」もしくは「最新」を選択可能です。起動テンプレートもCI/CDを行うのであ
れば、「最新」を選択してはいけません。新しいインスタンスが勝手に最新バージョンの
AMIで起動されてしまいます。
Slide 85
Slide 85 text
作成直後のインスタンス数と、起動対象となるVPCおよびサブネットを指定します。
AutoScalingGroupの作成
複数のサブネットを指定することでMulti-AZ構成となります。ここではプライベートサブ
ネットのゾーンAとゾーンCで起動するように指定しています。
Slide 86
Slide 86 text
なお、AutoScalingGroupの画面から直接ELBを指定することも可能ですが、今回は先
にAutoScalingGroupを作成するため、ここでは行いません。
AutoScalingGroupの作成
Slide 87
Slide 87 text
AutoScalingGroupの作成
AutoScalingで最も重要なパラメータである、スケーリングポリシーを設定します。最小
サイズ、最大サイズ、メトリクス、閾値などを指定します。
ここではCPU利用率以外には、ネットワークOut、ネットワークIn、リクエスト数が選択可
能です。他のメトリクスを利用する場合はCLIなどから設定します。AutoScalingGroup
については、マネジメントコンソールで可能な操作が極端に制限されています。以前より
も設定項目が減っています。
Slide 88
Slide 88 text
AutoScalingGroupの作成
スケーリングポリシーに関しては、AWSのキモと言ってもいい設定です。そのため、設定
内容は非常に細かく、マネジメントコンソールで設定しようとするとUIが非常に煩雑にな
るため、あえてシンプルな設定しかできないようにデグレードしたものと思われます。
シンプルなスケーリングポリシーを利用する場合は問題ありませんが、カスタムメトリク
スの利用や、細かい制御を行いたい場合はCLIやterraformでの設定が必須となりま
す。
そもそもスケーリングポリシーに関しては運用中に頻繁に見直すべき内容ですので、最
初はシンプルなもので設定しておくというのは理にかなっているのかもしれません。
Slide 89
Slide 89 text
AutoScalingGroupの作成
ライフサイクルイベント発生時の通知先を指定可能です。画面ではメールアドレスを指
定していますが、SNSトピックであれば何でもいいので、ライフサイクルイベント発生時
にフック処理を行う場合はSNS経由でLambdaを呼び出します。
Slide 90
Slide 90 text
AutoScalingGroupの作成
最後にタグを設定して作成完了です。
Slide 91
Slide 91 text
ELB(ロードバランサー)の作成
AWSのロードバランサーは以下の３種類が存在します。
● Application Load Balancer (ALB)
● Network Loadbalancer (NLB)
● Classic Load Balancer (CLB)
通常のWebシステムではALBを利用しますが、他の2つについても非常に重要なのでそ
れぞれの特徴について説明します。
Slide 92
Slide 92 text
ELB (Elastic Load Balancer)
各ELBを説明する前に、ELB全体についての説明をします。
ELBは負荷量に応じて自動でスケールアウトするロードバランサーのEC2インスタンス
です。スケールアウトは全自動で行われ、利用者が制御することはほぼできないので、
いつの間にか台数が増えたり減ったりしています。
スケールアウトした場合は当然IPアドレスが消費されるので、ELBを使うサブネットでは
スケールアウト分のIPアドレス余剰がなければいけません。（IPアドレスが足りないとス
ケールアウトが失敗しますが、ELB自体が無効になったりはしません）
また、キャンペーンや〇〇砲など、負荷増大が事前にわかっている場合は、ウォーム
アップ申請を行ってスケールアウトを高速化することが可能です。
Slide 93
Slide 93 text
ELB (Elastic Load Balancer)
ELBは通常のロードバランサーでよく見かける以下の機能があります。
● CookieによるSession Persistence
● ヘルスチェック（ロードバランサーだから当たり前）
● Connection Draining （切り離しても一定時間トラフィックを保持）
● X-Forwarded-XXX ヘッダ （リバースプロキシのためのヘッダ）
また、AWS特有の機能として以下があります。
● S3へのアクセスログ配信
● AWS WAF統合（ALBのみ）
● リクエスト追跡のためのヘッダ（X-AMZN-TRACE-ID）
これらの機能については今回は説明しません。
Slide 94
Slide 94 text
Application Load Balancer
HTTPに特化したL7ロードバランサーです。ホスト名もしくはパスに応じて振り分け先の
インスタンス（またはAutoScalingGroup）を動的に決定します。
ALBでは、HTTPもしくはHTTPSプロトコルのリスナーを追加して、プロトコルを有効にし
ます。HTTPリスナーが追加されていればHTTPが、HTTPSリスナーが追加されていれ
ばHTTPSが有効になります。
HTTPリスナーでは受信ポートを指定できます。HTTPSリスナーでは受信ポートに加
え、TLSの証明書を指定できます。TLSの証明書はACM(Amazon Certificate
Manager)に登録されている必要があります。
通常のWebシステムであればこのALBを利用します。構築方法については後述します。
Slide 95
Slide 95 text
Network Load Balancer
TCPのL4ロードバランサーです。ALBと違うのは、負荷分散対象がEC2インスタンス以
外に、静的なIPアドレスを対象にできるということです。
IPアドレスが疎通していればどんな対象にでもトラフィック可能なため、EC2インスタンス
に限らず、オンプレのサーバや他のAWSサービスに対しても負荷分散が可能です。
2018年6月現在ではTLS終端の機能は持っていないため、TLS終端処理はターゲット側
で行う必要があります。
主な用途としては、オンプレとの負荷分散、VPCエンドポイントの負荷分散、および
gRPCなどHTTP/2の負荷分散です。（ALBではHTTP/2の負荷分散はできません）
Slide 96
Slide 96 text
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が出る前の旧機能。
Slide 97
Slide 97 text
ALBの作成
作成済みのAutoScalingGroupに対して負荷分散を行うALBを構築します。
Slide 98
Slide 98 text
ALBの作成
今回はHTTPSは使わずにHTTPのみです。
Slide 99
Slide 99 text
ALBの作成
ELBのサブネットを指定します。インターネット向けのELBはパブリックサブネットに構築
しなければなりません。また、ELBは可用性のためMulti-AZで負荷分散することがほと
んどです。
Slide 100
Slide 100 text
ALBの作成
セキュリティグループを設定します。インターネット向けなのでHTTPを全公開していま
す。
スクリーンショットのために 0.0.0.0/0 を指定していますが、評価目的などでは
オフィスのグローバルIPからのみアクセスを許可してください。
Slide 101
Slide 101 text
ALBの作成
続いて、ALBの設定のキモであるターゲットグループを作成します。ここではデフォルト
（すべてのパス）のターゲットグループを作成します。
ターゲットへの通信はHTTP/1.1です。HTTP/2に対応していません。そのた
め、gRPCなどHTTP/2が必須の場合にALBが利用できません。
Slide 102
Slide 102 text
ALBの作成
ターゲットグループごとにヘル
スチェックの指定ができます。
成功コードは複数指定やレン
ジ指定が可能です。
Slide 103
Slide 103 text
ALBの作成
ターゲットのインスタンスを登録しますが、AutoScalingGroupを利用する場合はここでイ
ンスタンスを登録してはいけません。AutoScalingGroup側から追加します。ここで登録
してしまうとインスタンスが固定のためスケールアウトで追加されたインスタンスにトラ
フィックが到達しません。
Slide 104
Slide 104 text
ALBの作成
ALBの作成が完了したら、ルールを確認します。
Slide 105
Slide 105 text
ALBの作成
マネジメントコンソールから作成した場合、デフォルトのルールのみが存在します。これ
は、すべてのHTTPトラフィックをターゲットグループ edu-201806 にルーティングする
ルールを表しています。
Slide 106
Slide 106 text
AutoScalingGroupをALBに登録
AutoScalingGroupをALBのターゲットグループとして登録します。先ほど作成した
AutoScalingGroupの設定画面で、ALBのターゲットグループを入力して設定を保存しま
す。
Slide 107
Slide 107 text
AutoScalingGroupをALBに登録
すると、自動的にターゲットグループのターゲットにAutoScalingGroup配下のインスタン
スが登録されます。
Slide 108
Slide 108 text
セキュリティグループの設定
最初にAutoScalingGroupを作成してからALBを作成したため、ALBからEC2への通信
が許可されていません。そのためヘルスチェックに失敗します。
ALBからEC2への通信を許可するには2通りのやり方があります。
● ALBをEC2のセキュリティグループに参加させる。
● ALBのセキュリティグループからのアクセスをEC2のセキュリティグループで許可す
る。
Slide 109
Slide 109 text
セキュリティグループの設定
ALBをEC2のセキュリティグループに参加させる場合
ロードバランサーメニューで当該ALBを選択してセキュリティグループの編集
を行います。
Slide 110
Slide 110 text
ALBからのアクセスをEC2のセキュリティグループで許可する場合
EC2の起動テンプレートで設定したセキュリティグループに対してALBのセキュリティグ
ループからのアクセスを許可します。
セキュリティグループの設定
Slide 111
Slide 111 text
セキュリティグループの設定
どちらの手段で設定したとしても、ターゲットの状態がHealthyになりました。
Slide 112
Slide 112 text
ブラウザでの確認
ALBのDNS名を確認して、ブラウザでアクセスします。
Slide 113
Slide 113 text
ブラウザでの確認
起動テンプレートで指定したNginxインストール済みのEC2インスタンスに接続されるこ
とが確認できました。
Slide 114
Slide 114 text
作成したリソースの削除
● NATゲートウェイの削除（時間がかかるので最初に行う）
● AutoScalingGroupの削除
○ これをやらないとインスタンス削除しても復活してしまう
● SNSトピックの削除 (AutoScalingGroup消しても消えない)
● ロードバランサーの削除
● ターゲットグループの削除（ALB消しても消えない）
● インスタンスの削除、AMIの削除
● ALBセキュリティグループの削除
● VPCの削除
Slide 115
Slide 115 text
まとめ
今回説明した内容はAWSの基礎中の基礎となるサービスの、ごく一部の機能だけで
す。
膨大なスライドの量にもかかわらず、実際に作業してみると１時間もかかりません。
なので、取っ掛かりを得たら実際に手を動かして構築してみましょう。
ところどころ書きましたが、AWSをちゃんと使うためにはマネジメントコンソールでは限界
があります。
CLIやterraform、CloudFormationの使い方を理解してチャレンジしましょう。
Slide 116
Slide 116 text
Appendix
Nginx入りのAMI作成手順は以下のとおりです。
1. パブリックサブネットにAmazon LinuxのEC2を作成。キーペアを指定。
2. EC2にEIPをアタッチしてSSHで対象EIP宛にec2-userでログイン。
3. yumでnginxをインストール。chkconfig nginx onしてSSHを終了。
4. 起動中のEC2からイメージを作成。イメージが作成できたらEC2を削除。