「2週間で学ぶAWS」勉強メモまとめ

本稿は以下の勉強メモをまとめたものです。

• 手を動かしながら2週間で学ぶ AWS 基本から応用まで
• クラウド活用資料集

1. AWSアカウント作ったらまずやること

1-1. 作業用のIAMユーザーを作成する
1-2. Cloud Trailを設定する
1-3. 料金アラートを設定する

1-1. 作業用のIAMユーザーを作成する

ルートユーザーは超特権。通常の作業にルートユーザーを用いてはならない
IAMユーザーを割り当てて使おう。利用者ごとに払い出しとかできる
手順：「IAM」サービスからユーザーを追加すればOK

1-2. Cloud Trailを設定する

AWSに関する操作ログを自動取得するサービス。
デフォルトで有効になってる！
90日ぶんのログを確認でき、S3に証跡を残すことで過去の操作ログを全て保持できる。
これ設定しないと「誰が何をやらかしたか」が分からない

ログは2種類。「管理イベント」と「データイベント」
「管理イベント」：EC２インスタンスの生成、S3バケットの作成とか
「データイベント」：S3バケット上のデータ操作、Lambda関数の実行とか
デフォルトでは「管理イベント」のみ有効になってる

手順：「CloudTrail」サービスに行って「証跡の作成」から!

1-3. 料金アラートを設定する

AWSの利用料金が＄xxを超えたら通知するように設定
CloudWatch機能を利用する形でせってー

1. IAMでも請求設定をできるように（済）
2. 「請求アラートを受け取る」設定をする
3. CloudWatchで料金アラートを設定する

補足：料金を調べる

基本は「EC2 pricing」とかで調べる
あとは、SIMPLE MONTHLY CALCULATOR
https://calculator.s3.amazonaws.com/index.html
が便利

2. EC2を使おうぜ

2-1. EC2とは？

2-1-1. EC2の概要

• AWSで一番有名ばサービス
• 仮想のコンピューティング環境。いわゆる「サーバ」
• OSより上のレイヤについては自由に設定可能！
• 従量課金制

2-1-2. EC2を使う上での５大ポイント

• OS/Imageの選択
• インスタンスタイプの選択
• ストレージの選択
• セキュリティグループの設定
• SSHキーペアの設定

ちなみにどれも無知かあやふやな知識でアタフタやってた

2-2. いろいろ

SSH接続

SSH接続するときのchmod 400ってのは、デフォルトで落としたpemの権限が644で大きすぎて自分だけ読めればいいから400にしようぜ。ってゆー意味。
これやんないpemで接続しようとすると「秘密鍵なのにノーガードすぎるんですけどww」って白黒画面にプギャられる

SSHとは：
暗号・認証技術を用いてリモートコンピュータと安全に通信するためのプロトコル。
公開鍵と秘密鍵の2つの鍵（キーペア）を使用して行う公開鍵認証方式の接続が主流。とっても安全だから。

AMIとSnapshot

AMI：EC2の断面←EC2インスタンスを作る元になる
Snapshot：ディスク（EBS）の断面←EBSを作る元になる
※どちらも静止点を取って取得しましょう
※書き込みの最中とかにAMIとかとるとデータの不整合が起きる可能性があるから、たとえばEC2ならインスタンスをストップした状態で静止点をとる

AMIの取り方

1. EC2インスタンスを停止
2. アクション→イメージ→イメージの作成
3. 左サイドバーの「AMI」に元気なAMIが！
4. あとはAMIを選択して「作成」でEC2インスタンス作成できる
   ※AMIで作ったやつでSSH接続するとき、「root」じゃなくて「ec2-user@(ry」でログインしろとか怒られるけどそしたらターミナルそこだけ書き換えてあげて

EIPを用いてIPアドレスを固定する

• EC2インスタンスは、いちど停止するとIPアドレスが変わってしまう
• EIPを利用して、停止しても不変であるようにIPアドレスを固定しよう！
• EIPの課金は、基本無料。ただし実行中のインスタントに関連づけられている追加のEIPアドレス、および実行中のインスタンスと関連づけられていないEIPアドレスには料金が発生する
• なので、EIPが紐づいたインスタンスを停止すればインスタンスの料金はかからないがEIPの料金はかかってくるので、インスタンスの料金とEIPの料金どっちが高いのかを比較しとこ
• ちな↑の場合のEIPって月額300円くらいの料金だから、だいたいインスタンス止めときゃ節約できる

3. AWSにおけるネットワーク

3-1. 基本知識

3-1-1. リージョンって何？

• 世界各国にある複数のデータセンターを束ねたもの
• 東京にあるデータセンターを束ねたものが「東京リージョン」

3-1-2. アベイラビリティーゾーンって何？

• で、その個々のデータセンターを「アベイラビリティーゾーン」（AZ）っていう
• たとえば東京AZはap-northeast-1a、ap-northeast-1c、ap-northeast-1dの３つ
• 上記3つはそれぞれ離れた場所に建てられている（震災とか障害対策とかで）
• ちなみにデータセンターの場所はAWSの中の人も知らないくらい極秘情報

3-1-3. VPCって何？

• それぞれのアカウントごとに独立したネットワークを作れるサービス
• VPCは、AZにまたがった形で作れる
• VPCは、アカウントの中に複数つくれる

3-1-4. サブネットって何？

• VPCの中の、一部のネットワーク帯域
• このサブネットはグローバルに晒していい、このサブネットはDBを置くからグローバルに晒したくないネットワークのレイヤーだよ、的な使い分けができる
• サブネットは、AZに紐づくかたちで作られる
• ひとつのAZに複数のサブネットはもちろん作れる
• サーバを絶対止めたくない場合、複数台構成で障害対策を図ることがよくあるが、そうした時に「AZが1aのサブネット」と「AZが1dのサブネット」って形にしてあげると、ひとつのAZが超ストップしたときでも安心！というかAWSの作法

3-2. VPCとかサブネットとか作ってみようぜ！

3-2-1. 前提知識

3-2-1-1. CIDR（サイダー）

• IPアドレスのレンジを示す表記
• IPアドレス→ 10.20.30.40/32 ←8+8+8+8+の32ビットで表してますよ
• CIDR→ 10.20.0.0/16 ←固定なのは前半16ビットだけ（後半の16ビットは自由に決められる）（*みたいな）
• 上のCIDRだと10.20.0.0 〜 10.20.255.255を表してますよ
• /32 だと1つのIPアドレス
• /28 だと16のIPアドレス帯（実際は11）
• /24 だと256のIPアドレス帯（実際は251）
• ※5つ分のアドレスはAWSで予約されてるから実際にはユーザーは使えない

3-2-2. これからつくるアーキテクチャの流れ！

• VPCつくる！
• Internet GWつくる！
• パブリックサブネットつくってWebサーバを構築！
• あとルーティングとか！
• あとプライベートサブネットでDBを構築するよ！

3-2-3. VPCをつくろう

ちなPublicサブネットとInternet GWもつくる

↓つくるもの
1aにPublic Subnet 10.0.11.0/24
1cにPublic Subnet 10.0.12.0/24
同じInternet GW

1. 「1個のパブリックサブネットを持つVPC」を選択
2. IPV4のCIDRブロックはとりまデフォ
3. 「パブリックサブネットの IPv4 CIDR」を今回は10.0.11.0/24にしとくか
4. これでVPCとサブネットができました！
5. ちなみにVPCつくった時にInternet　GWもアタッチして自動でつくられてる！
6. ちなみにVPCつくった時にVPCとサブネット用のルートテーブルもつくられてる！
7. VPCのルートテーブルだけど、中への接続はそのままlocalでおkだけど、それ以外の通信（0.0.0.0/0）は「ターゲット」で書かれているInternet GWに出て行ってくださいね的なルーティングの設定をしてくれてる
8. 同じVPCでもうひとつサブネットつくるときは、「サブネットの作成」でさっきのVPC選択してAZを指定してCIDR決めてドン
9. あれwwwルートテーブル「10.0.0.0/16」「local」だけだからパブリックじゃないんですけどwwwこれInternet GWに繋げないんですけどwwwww
10. 1aのと同じルートテーブルにする（0.0.0.0/0で同じInternet GWに接続するやつ）
11. これでさっきと同じように、VPC内の通信はそのままできて、VPC以外との通信はIGWに接続するような設定になった！

とりあえずこれで1つのVPCを作って、2つのAZにそれぞれパブリックサブネットを1つずつ作った！
あとInternet GWも！

3-3. VPCにEC2入れてWebサーバ構築してみようぜ！

3-3-1. EC2の作成

• ふつうにインスタンス生成するんだけど、「ネットワーク」をデフォルトVPCじゃなくて、さっき作ったVPCに変更する
• すると「サブネット」もさっき作ったやつの中から選べる（当たり前か）。ここでは「1a」のサブネットにwebサーバー入れたいので「1a」を選択
• 今回は固定IPを使わないので、「自動割り当てパブリックIP」を「有効」にして、固定ではないけどグローバルIPを割り当てられるようにする
• あとはデフォかなー
• あ。セキュリティグループはVPCごとに作れるから、前回と同じようにSSHとHTTPを0.0.0.0/0のフルオープンにしとく
• ちな本番では危険
• HTTPは世界中からアクセスされるから別にいいんだけど
• SSHは自宅のIPとか会社のIPレンジとかを設定しないとガバセキュリティでガバる（MyPCのアドレスが変わったら都度AWSコンソールから書き換えるとか？）
• あとは作成
• ちなみにキーペアはアカウントに紐づいてるから、こないだ作ったのを使いまわせる

3-3-2. あとはふつうにコマンドでApacheとか入れればおk

3-4. VPCにEC2入れてDBサーバ構築してみようぜ！

• ネット ⇄ GW ⇄ Public Subnet ⇄ Private Subnet
• Public Subnet ⇄ Private Subnet間はSSH通信のみ許可ァ！
• って単純な構成にしちゃうとPrivate Subnetはネットに出ていけないのでMySQLとかダウンロードできずに孤独死
• Private Subnet（ヒッキー）は、NATGWっていうコミュ力の鬼にプロキシ（みがわり）してもらわないと外（ネットの広大な世界）に出ていけない

3-4-1. NAT GWつくろう

ふつうにVPCの左サイドバーからつくれる。PublicのサブネットIDを指定してね！
ちなみにNAT GWは外に出て行く。からグローバルIPが必要。だからEIPを割り当てる必要がある。
フローのなかでテキトーに「新しいEIPの作成」押すだけで一瞬でできる。

3-4-2. ルートテーブルを編集しよう

NAT GWを置いたのはPublicサブネット。
ここで、PrivateサブネットのルートテーブルをNAT GWに向けてあげる必要がある。
というわけで0.0.0.0/0とかをターゲット：（さっき作成した）NAT GWにして設定終了。
これで、

• Public SubnetのルートテーブルはlocalとInternet GW
• Private SubnetのルートテーブルはlocalとNAT GW

になってるはず。
なってろ。
これでPrivate Subnetからでもsudo yum update -yとかできるようになった！
ネットは広大だわ！！！！！！！！！！

3-4-3. セキュリティグループおさらい

• Public SubnetのSGは
• SSH(22)は特定のIPからのみ許可
• HTTP(80)はフルオープン
• Private SubnetのSGは
• SSH(22)はPublic SubnetについてるSGがついてるEC2からのみ許可
• MySQL(3306)も同じく
• EC2ごとにファイアフォール的な！！はたらき！！それがSG！！！

3-4-4. MySQLインストール

• 初期パスワードが分からなすぎて2時間くらいハマった
• 変更もできなすぎて死ぬほど死んだ
• ↓最終的にcat /var/log/mysqld.log | grep 'password is generated'で解決した
• MySQL5.7.6以降での初期パスワード確認方法
• 解決した瞬間は深夜1時だったけど山本高広みたいな叫び声あげた
• と思ってログインしたら「先にパスワードを初期値から変更しろ」って怒られる
• と思って変更しようと思ったら「パスワードポリシーに準拠しろ」って怒られる
• このへんで破壊衝動に駆られる
• ↓を見てなんとか解決
• mysql5.7でパスワードを変更する
• テメMySQL次あったらいわすかんな？
• 動画推奨のMySQL5.7をインスコできなすぎて死んだ
• http://www.s-runoa.com/465
• 講座動画のコピペコードの中に正しいパスワード文字列が入ってて思考停止してコピペしてたから見つけられなくて3時間死んだ
• MySQLとか疎通とかに詳しくなったからムダじゃない。って思いたい。寝たい

3-4-5. NACL（ネットワークACL）

塩化ナトリウムではない
新アジアチャンピオンズリーグでもない

• Access Control List
• アクセス制御リスト
• NACLは、サブネット単位でのファイアウォールの動きをしてくれる

SGはステートフル

• 規定するのは入ってきたデータだけ
• 厳しくチェックするのはクライアントからのリクエストだけ

NACLはステートレス

• 規定するのは、入ってくるときも出て行くときも両方
• リクエストとレスポンスを両方チェックする
• 状態（ステート）を覚えていない（レス）から

ステートレスについて
http://yohei-y.blogspot.com/2007/10/blog-post.html

4.ネットワークの設計ポイント

4-1. VPC & サブネットは、将来を意識して適切な広さにする

• 「このサブネットって将来的にどれくらいPrivate IP必要になる？」
• サービス・機能ごとに要件を理解しておく！！！
• やみくもに広くすればいいわけやないんや工藤…（VPC Peeringとかあるしな）

4-2. アカウント分割・VPCの粒度について

• 異なるシステムはアカウント単位で切るべき。絶対にな！！
• 同一システムの各環境を構築する場合は……まあアカウント単位で分けちゃうのが最終的には絶対に楽！！IAMユーザー設計とかリソース分割とかで、とにかく根本的に事故を防げる！！

5. AWSのマネージドサービスRDS

5-1. マネージドサービスとは？

特徴

必要なもの

• オンプレ：電源、OSインスコ、パッチ当て、バックアップ、アプリ最適化
• MySQL on EC2：パッチ当て、バックアップ、アプリ最適化
• RDS：アプリ最適化

マネージドサービスは「機能」をサービスとして提供してくれるから、構築にかかる工数が少なくてすむ！
AWSエンジニアのベストプラクティスを横展開できる！

代表的なAWSマネージドサービス

• Amazon RDS
• Amazon RedShift
• Amazon ElasticCache
• Amazon S3
• Amazon Route53
• Amazon CloudFront
• Amazon SQS
• Amazon SES

5-2. RDSとは？

5-2-1. 概要

フルマネージドなRDBサービス
※RDB…リレーショナルデータベース

MySQLとかPostgreSQLとかMariaDBとかいろんなエンジンに対応してる

5-2-2. 特徴

特徴1. Master-Salve構成を容易に構築可能

• メインのDBとサブのDBを自動で用意してくれる
• メインDBが書き換わったらサブDBも書き換わるような自動レプリケーションも設定できる！
• EC2から接続するときは、SSHではなくエンドポイント
• エンドポイント接続！なのでメインDBが急死してもサブDBにアクセスできて可用性UP!!!!!

特徴2. リードレプリカでDBレイヤーの負荷を軽減できる

• 更新系DB・参照系DBと分けることで、負荷を軽減！

特徴3.自動バックアップ取得

特徴4.パッチあての自動実施

特徴5.パラメータ設定

• RDSインスタンスにはSSHできないという制約がある
• RDSだったらRDSコマンドで繋がなきゃならない
• でも、パラメータグループをつくることでマネージメントコンソールから設定できる！
• これは即時反映もできるし、次のメンテナンスウィンドウで反映することもできる！

5-3. RDSを作っていくぞ！

5-3-1. まずはサブネットグループの作成だ

• これから作るDBインスタンスを、どのサブネットで作るか？っていう指定をする
• DBはだいたいプライベートサブネットで作る。セキュリティ的にアレだから

5-3-2. 次はパラメータグループの作成だ

• DBにはSSH接続ができない
• なので、GUIを使ってMySQLの設定をしていくことになる
• それを可能にするのがパラメータグループ

5-3-3. RDSの作成

• 今日のエンジンはMySQLにしましょう
• Master-Slave構成にするので「別のゾーンにレプリカを作成します」
• あとなんかいろいろやって作成
• ちなみにスナップショットを手動で取得した場合、RDSインスタンスを削除しても自動では消えないので手動で消してあげる

5-4. RDSインスタンスのMySQLに接続する

• Webサーバに移動して、mysqlでエンドポイントを指定して接続
• 終わり！

5-5. スナップショットからRDSを復元する

• 復元ボタン押すだけ！
• エンドポイントが変更されてるから注意
• セキュリティグループが変わってるから元のやつに設定してあげよう
• 何か問題が起こったけどMySQLコマンドを叩いて修正するのウルトラ面倒……ってときはSnapShotからの復元をためしてみて

5-6. 補足

• Master-Slave構成のRDSインスタンスは停止することができない
• Single構成に戻すと停止することができる
• 7日間は止められるが、8日目には自動的に再起動しちゃう
• 方法は「マルチAZに配置する」を「いいえ」にするだけ
• 変更は「すぐに適用」でいんじゃね

5-7. できるようになったこと

• Master-SlaveなRDS構成を構築した！
• サンプルプログラムからRDSを参照した！
• バックアップ＆リストアでインスタンスを過去の断面に戻した！

6. ELB（Elastic Load Balancer）

6-1. ELBとは？

• AWSマネージドサービスのロードバランサー
• リクエストに応じて、Web層のインスタンスを呼び分ける
• 負荷分散になる！
• 障害対策にもな！
• あとAuto Scalingにも対応してる！（←超便利）

6-2. 設計をする際に常に意識することは「SPOFの有無」

SPOFとは？

• Single Point of Failure
• 単一障害点
• あるコンポーネントが異常を来たすと、そのシステム全体が障害に陥ってしまうようなコンポーネントの総称
• 設計は、これを作らないのが大事！

SPOF回避の例

NAT

NATインスタンスではなくNAT GWを用いる

インメモリキャッシュ

ElasticCacheのレプリケーション機能

メールサーバー

冗長性を持った設計に
SESを用いる

6-3. ELBの種類

ELBは3種類

• ALB(Application Load Balancer)
• NLB(Network Load Balancer)
• CLB(Classic Load Balancer)

それぞれの違い

ALB:L7レイヤー（アプリケーション層）での負荷分散

今回はWebサーバアプリケーションをロードバランシングするからコレを使う

NLB:L4レイヤー（トランスポート層）での負荷分散

CLB:なんか古いEC2使うときの負荷分散

もう更新されない。終わりゆくサービス。悲しみ

6-4. ELBの主要な機能

負荷分散

配下のEC2インスタンスの負荷を見て、負荷が均等になるようにリクエストを分散する
「WebサーバAにめっちゃ負荷かかってるから、WebサーバBにもタスクぶん投げよ！」的な

ヘルスチェック

• 正しい動きをしているインスタンスのみにリクエストを振る
• 正しい動きをしてないインスタンスは、ロードバランサーから切り離してあげちゃう

チェック項目となるパラメータは？

対象のファイル（例:index.php）

レスポンスが正しいステータスコードで返ってくるか否か

何秒にチェックするか（例:30秒）

何回お気に成功したらOK/NGとするか（例:2回連続で成功しなけりゃ切り離す）

Auto Scaling

条件を決めて配下のEC2の数を自動で増減させる（すげえ…）

例）
2~6台の範囲で
平均CPU使用率が70%超えたら+2台、20%割ったら-2台
時間指定のオートスケールも可能
Auto Scalingが立ち上がるまで10分とかかかる場合あるから、急激な増加に対応するには時間指定もいいかも

ちなみにELB自体もスケールする。
もう何でもできるじゃないすか…

6-5. ELBを使ってみる

6-5-1. ALBの作成

• なんかEC2の左サイドバーからいい感じにポチっていく

6-5-2. ターゲットグループの設定

• なんかEC2の左サイドバーからいい感じにポチっていく
• 対象となるEC2インスタンスを登録する

6-5-3. 作成完了

• たったこれだけ
• ロードバランサーのDNS名をコピペしてブラウザのURLに入れてページを何回か更新してると、Webサーバ1a/1cにそれぞれ置いたページにアクセスしてることが分かる
• Webサーバ1aだけstopすると502 Bad Gatewayのページがちょいちょい出てくるようになる
• でもヘルスチェックが行われるので20秒後とかにターゲットがunhealthyになってWebサーバ1cのページのみ表示されるようになる
• これがロードバランシングだ！

6-6. Auto Scalingを使ってみる

手順

1. ALBの作成
2. ターゲットグループの設定（ここまでは同じ）
3. 起動設定（起動するインスタンスの設定：どのAMIにするか、インスタンスタイプはどうするとか）
4. AutoScalingグループの作成（AutoScalingのルール設定：CPU使用率60%になったら+2台とか）
5. AutoScalingグループをターゲットグループに紐づけることで、自動的に増えたサーバもターゲットグループに紐づけられますよ

6-7. ELBを使う場合の設計ポイント

AZにまたがったサーバ配置にする

AZ障害に対応できるように

アプリケーションをステートレスに構築する

どのサーバに振られても処理を継続できるように
スケールインにも対応できるように
ひとつのサーバだけに必要な情報を持たせない
セッション情報とかはインメモリキャッシュやElastic Cacheとかで保存・活用してもおk

7. オブジェクトストレージ-S3

7-1. S3とは？

概要

• Amazon Simple Storage Service
• 安価で耐久性の高いオブジェクトストレージサービス
• 月10GBのデータを置いても月30円
• 耐久性99.999999999%(“イレブンナイン”)

特徴

• バケットの下にファイルやフォルダを作成できる
• アクセス管理がかなりできる（IAMでのユーザー制限、バケット単位での制限、IPアドレスなどの制限）
• Webサイトホスティング機能【便利!!】
• 静的なサイトであれば、S3だけで公開が可能
• 他のAWSサービスとの連携が豊富

S3がよく使われるシーン

• 静的なコンテンツの配信(例：ブログやっててimgだけはS3に置いとく)
• ログなどのエクスポート先
• バッチ連携用のファイル置き場
• 静的Webホスティング(例：ランディングページはS3だけで直接配信)

7-2. じゃあS3を使ってみよう

• S3バケットを作って、ファイルをアップロードします
• あまりにも簡単にできるので書くことがない
• ちなみにバケット名は全世界で唯一のものでないといけない

7-3. PHPでS3からファイルを取得し、RDSを更新する

構成

• （VPC外部の）S3に.csvを置く
• VPC内部にバッチサーバを構築
• バッチサーバは、毎日バッチでRDSを洗い替える

準備と実行

• IAMユーザーのアクセスキーを作成しておく
• 「このIAMユーザーの権限でプログラムを動かすぞー」
• アクセスキー入手 → ユーザーと同等の権限が使える
• あとはテキトーに

7-4. 静的Webホスティング機能を利用する

バケット名とドメイン名は一致させる必要がある

手順

• まずバケットを作成
• バケット作成 > プロパティ > Static website hosting > 「このバケットを使用してウェブサイトをホストする」
• 誰にバケットを見せるか
• アクセス権限 > バケットポリシー > なんかjsonぽいの書く
• あとはindex.htmlとかアップロードするだけ

8. Route53 – AWSのDNS

8-1. DNSとは？

概要

• Domain Name System
• （ざっくり言うと）ドメイン名とIPアドレスの紐づけを行う
• ドメイン名を投げると、IPアドレスを返してくれる

DNSのレコードタイプ

A

ドメインとIPアドレスの対応（1対1対応でマッピング）
例）example.com → 54.xx.xx.xx

CNAME

ドメインの別名をマッピング
例）xx.sun.com → xxx.moon.amazonses.com

NS

そのドメイン（ゾーン）を管理するネームサーバー
例）example.comを管理してるネームサーバーどれだっけ？　→ ns-xxxx.awsdns-xx.co.xx.

補足

「DNSサーバー」と「ネームサーバー」は同じ

8-2. Route53とは？

特徴1：DNSの機能を簡単に利用できる

GUIから設定可能
CLIやCloudFormationを用いた設定自動化も可能

特徴2：SLAは100%

もし止まったら返金しますよ的な意味を含む

特徴3：多様なルーティングポリシー

ルーティングポリシーを設定することで、NSの時点でWevサーバを振り分けたりできる

Simple

ふつうはこれ

Weighted

ドメインへの問い合わせを、重みに従ってルーティング
exam.comへのアクセスの95%はVPC-1に、5%はVPC-2に振り分け
ABテスト時とかで使う

Geolocation（位置情報）ルーティング

リクエスト元の位置情報によって優先度が変わる

Failoverルーティング

プライマリとセカンダリを指定する
プライマリへのヘルスチェックに失敗するとセカンダリへ
かんたんに正副構成を実現できる！

8-3. 独自ドメインを紐づけてみよう（単純なルーティング）

独自ドメインを用意

Freenomで無料のドメインをゲットだ

Route 53での作業

1. Create Hosted Zoneへ
2. 「Domain Name」に独自ドメインを
3. 「Type」はPublic Hosted Zoneで
4. ↑ここで独自ドメインのネームサーバーが4つ決まる

レジストラでの作業

さっきのNSのValue4つをレジストラの「ネームサーバー」に転写していく（最後の.は除く）

再びRoute53へ

• Hosted ZoneのAレコードに、AliasでELBのを指定
• Aliasを使うとELBとかも選べる！
• nslookup 独自ドメインとかやってIPアドレス引けるようになってたら勝ち
• その独自ドメインでブラウザからアクセスできるようになってる！
• 完了！

8-4. 独自ドメインを紐づけてみよう（DNSフェイルオーバー機能を用いたルーティング）

• 8-3で作ったものを元にしてみる
• AレコードのRouting Policyを「Failover」に
• 「Evaluate Target Health」をYesに
• S3の静的ホスティングページをAレコードにAlias、Failover、Secondary、で登録
• これでELBのサーバが止まったら（ヘルスチェックに失敗したら）自動的にS3のページが表示されるようになった！

9. IAM

9-1. IAMとは？

• AWS Identity and Access Management
• 「どのユーザーが何をやっていいか」を決める
• IAMポリシー：「何をやっていい」
• IAMユーザー：「誰がやっていい」
• IAMグループ：「何をやっていい」っていうポリシーをまとめてユーザーたちに紐づける
• IAMロール：「何をやっていい」っていうポリシーをサーバに紐づける

9-2. IAMポリシーを作成してみよう

よしなに

9-3. IAMユーザーを作成してみよう

IAMユーザー作ったらIAMポリシーを当てはめればいいんだ

9-4. IAMグループを作成してみよう

まあ何か9-3と似たような感じで

9-5. IAMロールを作成して割り当ててみよう

想像できたな？　それが答えだ

9-6. IAMベストプラクティス

• 利用者ごとにIAMユーザーを洗い出す
• IAMユーザーを使いまわさない
• 役割ごとのIAMユーザーを作成し、IAMグループに権限を振る
• 権限は必要最小限のものを割り当て、必要になったら増やす
• 定期的に棚卸し（整理整頓）をする
• プログラムから利用する場合、アクセスキー/シークレットキーではなく、IAMロールを利用できないか考える

10. CLIによるAWSの操作、そしてCloudWatchによるシステム監視

10-1. AWS CLIとは？

• AWS CLI(コマンドラインインターフェイス)
• ターミナルなどのコンソールから、コマンドでAWSリソースを閲覧/操作できる
• いちいち「EC2インスタンスを作成っていうボタンをクリック」とかしなくても、コマンドで一発
• 自動化とかスケールに超便利！
• マネージメントコンソールからできることは、AWS　CLIでも可能
• 「なんかこれ毎回やってるな」みたいなのがあったら、CLI使って！！

10-2. AWS CLIを導入しよう

• AWS CLIをインストール
• AWS CLIの初期セットアップ
• aws configureみたいなコマンド打ってく
• お　わ　り

10-3. AWS CLIの使い方

see 公式リファレンス

10-4. CloudWatchとは？

• 運用監視のマネージドサービスのこと！
• 各種AWSリソースの状況（メトリクス）を監視
• 事前にメトリクスに対して条件を設定し、その条件を満たしたら通知
• AWSデフォルトで定義されているものもあるし、独自に定義できるカスタムメトリクスもある
• EC2のCPU使用率が70％を超えたらAWS　SNS(Simple Notification Service – プッシュ方式のメッセージ送信サービス)に通知され、SNSが利用者にメールを送ってくれる、みたいなことができる
• SNSっていうのが間にあるとすごく便利。疎結合的な意味で

10-5. CloudWatchを設定しよう

CloudWatchでメトリクスと閾値（しきいち）を設定

どのインスタンスのどのメトリクスをどのくらいの閾値にするか？

SNSの通知先を設定

どこにどのように通知するか？

あとは「CloudWatch」の「アラーム」から頑張れ

11. CloudFrontとElastiCache

「コンテンツキャッシュ」と「インメモリキャッシュ」

11-1. コンテンツキャッシュパターンとは？

一言で言うと

CDN

くわしく言うと

• Webサーバがコンテンツを配信する際に、その前段としてCDN（Content Delivery Network）を配置
• コンテンツをキャッシュすることでWebサーバーの負荷を軽減
• キャッシュがないときは、サーバに取りに行く（キャッシュする）
• キャッシュがあるときは、CDNがコンテンツを返却
• つまりCDN

11-2. CloudFrontとは？

• AWSが提供するフルマネージド型のCDNサービス
• 世界中に100を超えるエッジロケーションが存在
• AWS WAF、AWS Certificate Manegerなど各種AWSサービスとの連携がかんたん！

11-3. CloudFrontを導入してみよう

導入の流れ

1. オリジンサーバの指定
2. キャッシュの振る舞いの設定
3. キャッシュTTLの設定
4. その他の設定

導入の手順

ネット > CloudFront > ELB > VPC > サーバ群
って感じで行きます

• サービス > CloudFront > Create Distribution
• Originに、作っといたELBを指定
• あとはまあ何かテキトーに
• ちなみにTTLは「有効期限」（Time To Live）のこと
• 完成！クッソeasy

11-4. CloudFrontを使う際のポイント

キャッシュTTLの設計

短すぎず長すぎずね

CloudWatchで監視する

よく見とくのが大事

Popular Object Reportsを参考に、定期的に設定を見直す

11-5. インメモリキャッシュパターンとは？

• CDNのデータベース版みたいな感じ
• 頻繁にアクセスするデータを、データベースではなくインメモリキャッシュに格納することで、データベースの負荷を軽減する設計パターン
• あとは「データの種類によって格納先を変える」みたいな時にも使える
• 代表的なのが「Webのセッション」
• セッション情報ってアクセスごとに見るからめっちゃ頻繁にDBにアクセスするじゃん？
• DB大変じゃん？
• それならインメモリキャッシュに置いちゃえばDB本来の業務データの書き換えとかの邪魔とかしなくていいじゃん？
• やべえじゃん？

11-6. ElastiCacheとは？

AWSが提供するフルマネージド型インメモリキャッシュサービス

必殺技かな？