初めに

AWS認定ソリューションアーキテクト(AWS Certified Solutions Architect - Associate)を受験しようと決めた。（理由は割愛。）
ただ、日々の社畜生活の影響もあり、勉強時間が確保できないと言い訳し、絶対いつまで経っても勉強しない。
そこで、Qiitaに進捗を報告することによって、皆さんに監視してもらい、サボらず勉強しようと思う。

※ 2018年8月17日追記
受験して落ちました。
合格はしていないですが、こちらの記事の更新は一旦終了します。
詳しくは下の記事をご覧ください。
AWS認定ソリューションアーキテクトアソシエイト(SAA)不合格体験記

※ 2018年2月22日追記
ダラダラと勉強を続けています。
こちらの記事は更新中です。
表で対策するAWS 認定ソリューションアーキテクト - アソシエイト(SAA) ※ 随時更新

※ 2019年4月15日に追記
2019年3月末に受験し、また落ちました。
その体験談と勉強方法を記事にしました。
10ヶ月勉強してもAWS認定ソリューションアーキテクト-アソシエイト-に合格できないので、勉強方法を振り返る - Qiita

※ 2019年7月5日追記
2019年6月中旬に受験し、合格することができました。
1年かけてAWS認定ソリューションアーキテクト-アソシエイト-に合格できたので、勉強法を振り返る - Qiita

第2章．リージョン／アベイラビリティーゾーン

リージョンとは

2018年5月現在だと世界17ヶ所の地域がある。
複数のアベイラビリティーゾーン(AZ)が存在する。
以下AWS公式より

No.	コード	名前
1	us-east-1	米国東部（バージニア北部）
2	us-east-2	米国東部 (オハイオ)
3	us-west-1	米国西部 (北カリフォルニア)
4	us-west-2	米国西部 (オレゴン)
5	ca-central-1	カナダ (中部)
6	eu-central-1	欧州 (フランクフルト)
7	eu-west-1	欧州 (アイルランド)
8	eu-west-2	欧州 (ロンドン)
9	eu-west-3	EU (パリ)
10	ap-northeast-1	アジアパシフィック (東京)
11	ap-northeast-2	アジアパシフィック (ソウル)
12	ap-northeast-3	アジアパシフィック (大阪: ローカル)
13	ap-southeast-1	アジアパシフィック (シンガポール)
14	ap-southeast-2	アジアパシフィック (シドニー)
15	ap-south-1	アジアパシフィック (ムンバイ)
16	sa-east-1	南米 (サンパウロ)
17	-	GovCloud

GovCloudは通常の利用者は利用できない。
米国政府の業務専用らしい。
マネジメントコンソールのURLを見るとコードが分かる。
https://ap-northeast-1.console.aws.amazon.com/console/home?region=ap-northeast-1#

アベイラビリティーゾーンとは

物理的なデータセンター群で、AZと略される。
1つに障害が発生しても、他のAZには影響ないように設計されている。
なので、複数のAZを使えば、簡単に冗長構成ができる。

AWSサービス

AWSのサービスは3種類に分類される。

グローバルサービス

どこのリージョンからでも共通のサービスとして利用できる。代表されるサービスは以下の通り。

サービス名	概要
IAM	アクセス権を管理するサービス。
Route 53	DNSサーバ。
CloudFront	コンテンツデリバリネットワーク(CDN)。ウェブコンテンツを高速で配信できるサービス。

リージョンサービス

リージョンごとに作成・管理される。代表されるサービスは以下の通り。

サービス名	概要
S3	FTPサーバみたいなサービス。
DynamoDB	その名の通りデータベース。
SQS	メッセージキューを提供するサービス。
CloudSearch	検索サービス。

AZサービス

AZごとに作成・管理される。代表されるサービスは以下の通り。

サービス名	概要
EC2	仮想サーバ。Windows、LinuxどちらもOK。
RDS	その名の通りRDS。MySQL、Aurora、PostgreSQL、Oracle、SQL Server、MariaDBが使える。
ELB	ロードバランサ
ElastiCache	アプリケーションにキャッシュ機能を簡単に追加できるサービス

第3章．責任分担セキュリティモデルとAWSにおける認証(IAM)

責任分担セキュリティモデル

利用者の責任は"クラウドにおけるセキュリティ” を担当する。
AWS の責任は"クラウドのセキュリティ"を担当する。
3種類のサービスがあり、それぞれ利用者の責任範囲が異なる。

インフラストラクチャサービス
コンテナサービス
抽象化サービス（アブストラクトサービス）

ルートアカウント

AWSコンソールにログインするときに使用するメールアドレス = ルートアカウントという。
普段はルートアカウントは使用せず、ユーザを作成して使用すべし。

IAM

AWS Identity and Access Managementの略。
グループ(IAMグループ)(IAMユーザ)やユーザ管理やリソースに対するアクセス制御の設定(IAMポリシー)を行うサービス。
IAMグループとIAMユーザを作成すると、最初は何も権限が与えられていない状態でできる。
IAMユーザは「アクセスキー」と「シークレットアクセスキー」を設定する。（AWS CLIやAWS SDK）の認証情報として利用する。
IAMグループは、IAMユーザの集合。アクセス権限を指定でき、ユーザのアクセス権の付与が用意。
IAMロールは、AWSに対するアクセス権限の管理ができる。（Oracleのロールと同様のイメージ）

利用方法	認証方法
コンソール	ユーザ名／パスワード
AWS CLI（コマンド）	アクセスキー／シークレットアクセスキー
AWS SDK	アクセスキー／シークレットアクセスキー

IDフェデレーション(ウェブIDフェデレーション)

フェデレーションってなんだ？

インターネットの各サービスのユーザー認証の連携のこと。
例えば、GitHubのアカウントを使用して、Qiitaの認証およびアクセス可能にする仕組み。

AWSにおけるIDフェデレーション

S3バケットにアップロードさせるためには、S3へのアクセス権が必要。
↓
頻度が高ければユーザ登録するが、毎月1回だけ利用するユーザだったら面倒
↓
Security Token Service(STS)という一時的に認証情報を付与するサービスが、IDブローカー(IDプロバイダー)を利用して、自社の認証基盤で認証されたら、S3へのアップロードを一時的に許可する。IDフェデレーション

第4章．AWSにおけるネットワーク

Virtual Private Cloud (VPC)

AWSアカウント専用の仮想ネットワーク。
利用者ごとにプライベートなネットワークにAWSリソースを起動して、外部ネットワークの接続を可能にする。
（外部ネットワークと各AWSサービス間のルーティング制御と覚える。）

VPCを構築する手順

3つのAZからなるリージョンに、Webサーバ(EC2)、DBサーバ(EC2)、オンプレミスの基幹システムにアクセスしたいサーバ(EC2)があるとする。

1. VPCの作成

リージョンを作成してプライベートネットワーク空間を作成（これもVPCと呼ぶらしい。）
プライベートネットワークのいずれかの値を使用
- クラスA：10.0.0.0 ～ 10.255.255.255
- クラスB：172.16.0.0 ～ 172.31.255.255
- クラスC：192.168.0.0 ～ 192.168.255.255

2. サブネットの作成

VPCの中にサブネットを作成する。
サブネットはAZをまたがることはできない。
サブネット選択＝ AZ選択は同義。
冗長的に配置して「故障に備えた設計で障害を回避」するために、同じ役割のサブネットを複数のAZに作成する。

3. ゲートウェイの作成

VPCと外部ネットワーク間で通信するゲートウェイを作成し、VPCにアタッチ(接続)する。

インターネットゲートェイとバーチャルプライベートゲートウェイの2種類が存在する。

4. ルートテーブルの設定

インターネットとのアクセスを許可するサブネット：パブリックサブネット
インターネットとのアクセスを許可しないサブネット：プライベートサブネット

パブリックサブネットかプライベートサブネットかを決めるのがルートテーブル

5. NATインスタンスの作成

サブネットをプライベートサブネットに作成すれば、インターネットからアクセス不可。＝セキュリティレベルを高めることができる。
↓
いざアクセスしたい場合にはNAT(Network Address Translation)インスタンスを利用する。

NATインスタンスとは？
実態はEC2インスタンス。
プライベートサブネット内のEC２からトラフィックを受信、EC2のプライベートIPアドレスをNATインスタンスに割り当てられたグローバルIPアドレスに変換し、インターネットへのアクセスを可能にする。
利用するためには、「送信元／送信先チェック」機能を無効化する必要がある。EC2インスタンスの機能。

NATインスタンスをパブリックサブネットに作成できたら、プライベートサブネットに適用しているルートテーブルのデフォルトゲートウェイのターゲットとして、NATインスタンスを指定。

EC2インスタンスのIPアドレス

VPCのサブネット内に起動するEC2インスタンスには、サブネット内のプライベートIPアドレス、グローバルIPアドレスを割り振る必要がある。
AWSのグローバルIPアドレスには、次の二種類がある。

Public IP
EC2を起動した際にランダムで割り当てられる動的なグローバルIPアドレス
Elastic IP
アカウントに割り当てられる固定のグローバルIPアドレス。アタッチ／デタッチが可能。

EC2のアドレスの紐づけは、VPCの仮想ネットワークで行われる
↓
ipconfigやifconfigを実行しても、プライベートIPアドレスの値しか表示されない

セキュリティグループとネットワークACL

ファイヤウォール機能

	セキュリティグループ	ネットワークACL
運用単位	EC2やRDS、ELBなどインスタンス単位	サブネット単位
作成可能なルール	許可のみ	許可／拒否
デフォルトルール作成時	インバウンド：すべて拒否インバウンド：すべて許可	アウトバウンド：すべて許可アウトバウンド：すべて許可
デフォルトルール	アクセスキー／シークレットアクセスキー	ステートレス

VPCピア接続

2つのVPCを接続する機能
本番環境と開発環境の間で通信する必要がある場合とかに使用する。
プライベートIPで通信する

VPCピア接続の制約
- 接続するVPCは同じリージョンに存在すること
- 接続するVPCのプライベートネットワークアドレス空間が重複していない
- 1対1の接続

第5章．AWSにおけるコンピューティング

EC2インスタンスの初回起動する手順

Amazon Machine Imange(AMI)の選択
インスタンスタイプの選択
ネットワーク／IAMロール／ユーザデータなどの設定(インスタンスの詳細設定)
ストレージの設定
タグ付け
セキュリティグループの設定
ここまでの設定の確認
キーペアの選択

1. AMIの選択

Windows Serverや各種Linuxディストリビューション、AWS Marketplaceで購入できる各種ソフトウェアのインストール済みのイメージや、利用者が作成したカスタムAMIを利用／選択できる

2. インスタンスタイプの選択

仮想CPUコア数やメモリ容量の組み合わせでEC2インスタンスのマシンスペックを規定する
それによって、インスタンスファミリーと呼ばれるグループに分けられる

インスタンスファミリー	ネットワークACL
汎用(バランス重視)	t2.nano, m4large, m3.mediumなど
コンピューティングの最適化(CPU重視)	c4.large, c3.largeなど
GPU	g2.2xlarge, g2.8xlarge
メモリの最適化	r3.large, r3.xlargeなど
ストレージの最適化	i2.xlarge, d2.xlargeなど

tやmなどの後のづうじはインスタンスタイプの世代を示す。
その後の文字がマシンスペックの規模。
例えば、m4.largeは仮想CPUコア数が2, メモリが8GiBスペック。

3. ネットワーク／IAMロール／ユーザデータなどの設定(インスタンスの詳細設定)

EC2インスタンスを起動するVPCやサブネットを選択、必要な場合は動的なグローバルIPアドレスであるPublic IPやIAMロールを割り当てたり、ユーザデータを設定したりする。
ユーザデータはOSの起動スクリプトのようなもの。
「Apache Webサーバをインストールして、Webサービスを起動して、OS再起動時にもWeb サービスが起動する」ように設定したりすることができる。

ユーザデータの中で、固定のグローバルIPアドレスであるElastic IPを初回起動してくるEC2インスタンスに関連付ける設定できる。
その場合、「aws ec2 associate-address」というコマンドを使用する。
コマンドの引数に、EC2のインスタンスIDまたはネットワーク・インターフェースのIDが必要。
インスタンスIDは、EC2インスタンスが作成されてから割り振られる固有のIDでユーザデータを設定する時点では値が決まっていない。＝記述できない。
↓
そんなときはメタデータ
メタデータは、インスタンスIDやIPアドレス、ホスト名など、EC2インスタンス自身に関するデータで、EC2インスタンスの設定や管理のためのメタデータを利用することができる。

メタデータ	説明
ami-id	インスタンスの作成に使用されたAMI ID
hostname	ホスト名
iam/security-credentials/role-name	IAMロール名
instance-id	インスタンスのID
local-ipv4	プライベートIPアドレス
public-ipv4	Public／Elastic IPアドレス

4. ストレージの設定

EC2インスタンスに接続するストレージデバイスを設定。
デフォルトでEC2インスタンスに接続しているストレージ・デバイスにOSをインストール。

ストレージデバイスにはEBSとインスタンスストアの2種類

5. タグ付け

タグとは、キーと値のペアで構成され、例えば「Name」キーに「Web Server」値というタグをEC2インスタンスいｎつけると、そのタグをもとに検索をかけたり、コマンドで操作する際の絞り込み条件として指定すること。

6. セキュリティグループの設定

セキュリティグループの設定
EC2インスタンスには、少なくとも1つのセキュリティグループを適用する必要あり。

7. ここまでの設定の確認

これまでの設定の確認。

8. キーペアの選択

公開鍵はAWS上で保管されて、秘密鍵はローカルにダウンロードされる。(.pemファイルでダウンロードされる)
初回起動するときに、キーペアを選択でき、AWS上に保管されている公開鍵がEC2インスタンスに埋め込まれる。
Linuxの場合は、SSHの認証に利用。
Windowsの場合は、暗号化されているAdministratorユーザのパスワードの復号化に利用。

EC2インスタンスのライフサイクル

初回起動をかけるとpennding状態、起動処理が終了するとrunning状態
runnning状態になっても、次の2種類のステータスチェックがかかってEC2インスタンスにアクセス出来ない場合がある。
1. System Status Checks：インフラストラクチャのチェック
2. Instance Status Checks：OSのチェック
上２つのチェックを通ると、「2/2 checks passed」となって、正常起動していることになる。

runningになった時点から請求が発生、stoppedまたはterminatedになるまで発生

EBSとインスタンスストア

EC2インスタンスに接続できるブロックストレージには次の２種類。

Amazon EBS(Elastic Block Store)
- ネットワーク接続型のプロックストレージ
- 不揮発性(永続的なデータボリューム)
インスタンスストア
- 物理ホストの内蔵ストレージ
- 揮発性(一時的なデータボリューム)、インスタンスを停止すると保存データは削除される

EC2インスタンスには、
1. EBS-backedインスタンス
- OSがインストールされるのがルートボリューム
- インスタンスの停止、起動、再起動、削除が可能
2. instance store-backedインスタンス
- OSがインストールされるのがインスタンスストア
- インスタンスの再起動と削除が可能

の2つのタイプがある。
AMIが異なっている。
instance store-backedインスタンスは、s3-backedインスタンスという別名がある。

EBSのタイプ

EBSの3タイプ

General Purpose SSD
Provisioned IOPS SSD
- EBSディスク性能を高めることができる
- ネットワーク接続型のストレージのため、ネットワークがボトルネック
Magnetic(磁気ディスク)

EBSスナップショット

EBSは任意のタイミングでスナップショットを作成することが可能。
スナップショットを取得するときは、ディスクI/Oを停止する必要あり。
Linuxならば、EBSボリュームをアンマウントしてからスナップショットを取得することを推奨。
スナップショット取得開始後は、取得完了を待たずに再びマウントして使用することが可能。

プレイスメントグループ

各AZは、地理的に離れた場所に存在している。(自然災害に対しても冗長性を担保するため。)
そのため、異なるAZ内のEC2インスタンスへのアクセスの場合は遅延が発生する。
それを防ぐためにプレイスメントグループを作成する。

プレイスメントグループ内のEC2インスタンス間のネットワーク速度を高速にすることができる。
ただし、ネットワークの高速化のために冗長性を犠牲にしているので注意。

Dedicatedインスタンス

EC2インスタンスを起動する物理ホストにおいて、自アカウント以外のEC2インスタンスが起動しないことを保証されたEC2インスタンス。

第6章.オブジェクトストレージ(S3／Glacier)

S3オブジェクト／オブジェクトとストレージクラス

S3(Amazon Simple Storage Service)は、安価で非常に耐久性のあるオブジェクトストレージ。
格納したデータ(オブジェクト)の利用用途ごとにストレージクラスがある。
1. 用途に適したスタンダードクラス
- 失われることが許されないデータを格納する用途
2. 低冗長化(RRS)クラス
- 失われても再作成可能なデータを格納する用途

S3の整合性

1. 新しいオブジェクトの書き込み(PUT)

書き込み後の読み取り整合性
新しいオブジェクトを書き込んだあと、すぐに一覧表示操作を行うと、オブジェクトが表示されないことがある。
S3から「完了」が返されると、正しく表示できるようになる。

2. 既存オブジェクトの上書き(PUT)

結果整合性
既存のオブジェクトを上書きし、「完了」が表示された後でも、古いデータが返されることがある。
時間が経てば新しいデータが返される。

3. オブジェクトの削除(DELETE)

結果整合性
オブジェクトを削除し、「完了」が返された後でも、一覧に表示されたり、データにアクセスできたりする。
時間が経てばパケット一覧から削除され、アクセスできなくなる。

(スタンダートクラス)
パケットにオブジェクトがアップロードされると、自動的にリージョン内の３箇所のデータセンターに複製される。
その結果、２箇所のデータがロストしても、データが失われることはない。

S3のアクセス制限とセキュリティ

以下の３種類。
- アクセスコントロールリスト(ACL)
- パケットとオブジェクトそれぞれについて、読み取り／書き込みの許可を他のAWSアカウントに与える。
- パケットポリシー
- パケットごとに、自アカウント内のIAMユーザやグループ、他アカウントのユーザに対してアクセス許可を与える。
- IAM(ユーザ)ポリシー
- AWSリソースに対するアクセス可否。

これの他に、アクセス許可設定をしていない特定のオブジェクトを指定した期間を限定してHTTPSアクセスを公開する「署名(期限)付きURL」という方法。
エンドユーザが商品を購入したときに、10分だけ有効なURLを生成される…ような使用方法。

オブジェクトの暗号化のアクセスログ

格納オブジェクトを任意で暗号化して、データ保護が可能。
- サーバサイド暗号化
- AWSが管理する鍵やユーザが管理する鍵を使ってS3上で暗号化する
- クライアントサイド暗号化
- クライアント側で事前に暗号化したデータをS3バケットにアップロードする

S3バケットへのアクセスログを任意で同様のS3バケットまたは異なるS3バケットに取得することができる。
ログの格納は、実施のアクセスから時間をおいて行われる。

S3の静的Webサイトホスティング機能

静的Webサイトなら、ホスティング可能。
PHPやJSP、ASP.NETなどはホスティング不可。
EC2を利用するよりも運用の負荷やコストを抑えることができる。

S3のバージョニング機能

オブジェクトを上書きしたり、削除したあとでも、操作前のオブジェクトを復元することができる。
バージョニング機能を有効にした場合、キーの他にバージョンIDが付与される。

S3のライフサイクル機能とGlacierへのアーカイブ

普段アクセスすることがほとんどないデータは、Amazon Glacierストレージに格納することで、コストを低く抑えることができる。
データを格納する方法は、
- S3のライフサイクル機能を利用するもの
- S3に格納したオブジェクトを指定した日数が経過したあとに、Glacierに移行したり、削除したいるすることができる機能
- SDKを利用して直接格納するもの

第7章.データベース(RDS/ElastiCache/DynamoDB)

マネージドサービス

OSやミドルウェア／ソフトウェアをインストールすることなくサービスを利用できる。
バックアップやバッチ適用といった面倒な管理作業をAWSが管理してくれる。
データベース、負荷分散サービスのELB(Elastic Load Balancing)やキューサービスのAmazon SQS(Simple Queue Service)などが該当する。

マネージド型データベースサービス

以下の4種類。
- リレーショナルデータベースサービス：Amazon EDS
- NoSQLデータベースサービス：Amazon DynamoDB
- インメモリキャッシュサービス：Amazon ElastiCache
- データウェアハウスサービス：Amazon Redshift

RDS

RDSで選択できるデータベースエンジンは次の6種類。
- Amazon Aurora
- MySQL
- MariaDB
- PostgreSQL
- Oracle
- Microsoft SQL Server

RDSの主要機能について。
- ①マルチAZ配置
- ②自動バックアップ機能
- ③パッチ適用
- ④ストレージ

①マルチAZ配置

複数のAZにRDSインスタンスを配置して可用性を高める機能。その名の通り。
MySQL、MariaDB、PostgreSQL、Oracleでは、同期物理レプリケーション という仕組みを使っている。
（スレーブのデータをマスターに合わせて最新の状態に維持。）
SQL Serverは、同期論理レプリケーション を使用している。
（スレーブのデータをマスターに合わせて最新の状態に維持。）

マルチAZ配置のRDSインスタンスのマスターが停止もしくは障害が発生したら、スレーブへのフェイルオーバーが自動的に開始される。
アプリ側ではデータベースと再接続するだけで済む。(RDSインスタンスへの接続設定を変更する必要なし。)
パッチ適用などのメンテンス、手動のRDSインスタンス再起動時にも、フェイルオーバーする。

②自動バックアップ機能

1日1回自動的にデータのバックアップ(スナップショット)を取得する。
バックアップ中は、多少読み書きが遅くなることがある。
自動バックアップのほかに、トランザクションログを自動的に取得している。
自動バックアップとトランザクションログで、RDSインスタンスを復元することができる。
バックアップは、利用者が削除するまで保持。

③パッチ適用

メンテナンスウィンドウで指定された曜日／時間帯にパッチ適用される。
パッチ適用時には数分のダウンタイムが生じることがある。
マルチAZなら、スタンバイに先にパッチが適用され、フェイルオーバーしたら旧マスターでパッチが適用される。
機能を無効化していても、自動的に適用されることがある。(重要なセキュリティ脆弱性が発生した場合に限る。)

④ストレージ

EC2と同様に3パターンある。（General Purpose SSD、Provisioned IOPS SSD、Magnetic(磁気ディスク)）

DynamoDB

ストレージ容量が自動的に拡張
病患あたりのI/O性能(スループット)を指定できる
ストレージはSSDのみで安定したI/O性能を提供
データを3つのデータセンターに複製することで高可用性と高い耐久性を提供
読み込み整合性の強弱を指定することで、性能と整合性のバランスを選択可能
アクセス制御はIAMで行う(EC2インスタンス上で実行されるプログラムの認証は、IAMロールを活用。)

ElastiCache

インメモリキャッシュのマネージドサービスで、MemcachedとRedisの２つのキャッシュエンジンから選択して利用できる。
ElastiCacheはAZサービス
VPCサブネットをグループ化したサブネットグループに配置
アクセス制御は、セキュリティグループとサブネットのルーティングテーブルによってアクセス制御
RDSへのクエリ結果をキャッシングしてRDSへのアクセス負荷を軽減
読み書き性能向上や、DynamoDBと同様のセッションデータの格納がある。

Memcached
- Key-Value Store形式のインメモリキャッシュ
- マルチノードのキャッシュクラスタ
Redis
- Key-Value Store形式のインメモリキャッシュ
- マスタースレープ構成

第8章.AWSにおける監視と通知(CloudWatch／SNS)

CloudWatchにおけるモニタリング

CloudWatch = AWSのモニタリングサービス
メトリクス（監視項目という意味）で集計される。 ※ メトリックスとも言う
各AWSリソースから送られてきたモニタリングデータを保存して、メトリクスごとにグラフ化して表示することができる。
保持期間は2週間。それ以降は破棄される。
月次のモニタリングデータが欲しい場合は、破棄される前にダウンロードしておく必要がある。

以下メトリクスの例(デフォルト)

EC2インスタンスのCPU使用率
EBSのディスクIO
S3の格納オブジェクト総数

EC2のモニタリング

CloudWatchは、AWSリソースから送られてきたモニタリングデータを保存／可視化するサービス。
データを送る仕組みは、EC2やRDSなどAWSリソースが用意する必要がある。
RDSはマネージドサービスなので、デフォルトでデータを収集してCloudWatchに送信するエージェントがインスタンスに導入されている。
EC2はマネージドサービスではないので、ハイパーバイザが収集できるモニタリングデータのみ収集して、CloudWatchに送信する。
そのため、EC2のメトリクスは、次の2種類に分類できる。

標準(デフォルト)メトリクス
- ハイパーバイザが取得するメトリクス
カスタムメトリクス
- OSにインストールしたエージェントが取得するメトリクス

標準メトリクスは次の12種類(https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/viewing_metrics_with_cloudwatch.html)

メトリクス	説明
CPUCreditUsage	CPUクレジット利用数
CPUCreditBalance	CPUクレジット累積数
CPUUtilization	CPU利用率
DiskReadOps	1秒あたりのDisk読み込み回数
DiskWriteOps	1秒あたりのDisk書き込み回数
DiskReadBytes	インスタンスストレージの読み取りバイト数
DiskWriteBytes	インスタンスストレージの書き込みバイト数
NetworkIn	受信したバイト数
NetworkOut	送信したバイト数
StatusCheckFailed	OS／インフラストラクチャステータスチェックの成功
StatusCheckFailed_Instance	OSステータスチェックの成功／失敗
StatusCheckFailed_System	インフラストラクチャステータスチェックの成功／失敗

モニタリングデータのプロット間隔は、AWSリソースに依存しており、1分間隔だったり5分間隔だったりする。

EC2は２種類の間隔で取得可能

基本モニタリング
- ３種類のステータスチェックは1分間隔、その他は5分間隔
詳細モニタリング
- 標準メトリクスはすべて1分間隔

アラームとアクション

CloudWatchの各メトリクスに対して、アラームを設定することができる。
(例).EC2インスタンスのCPU利用率が70%という閾値を超えたらアラーム状態に遷移する。
次のようなアクションを呼び出すことをできる。

メールなどの通知(Simple Notification Service)
Auto Scalingポリシー(EC2インスタンス数の増減)
EC2アクション(停止／削除／再起動／復旧)

7つのベストプラクティスの1つ「伸縮自在性を実装」を実現。
アラームには、3つの状態がある。

OK
アラーム
不足

(例).EC2インスタンスの1分間のCPU利用率の平均が閾値の７０％を3分連続で上回っている場合に、EC2インスタンスを2台に増やす。

SNS

SNS = Amazon Simple Notification Service
通知サービス。
ユーザやアプリケーションにメッセージを送信することができる。

3つの用語

メッセージ：通知するメッセージ
サブスクライバ：受信者を指し、サポートされているプロトコル
- Eメール
- SMS
- モバイルプッシュ通知
- HTTP／HTTPS
- SQS(Simple Oueue Service)
- Lamdba(サーバなしのプログラムコード実行サービス)
トピック：単一／複数のサブスクライバをまとめたもの

CloudWatchのアラームアクションからSNSを利用する流れ

SampleTopicというシステムのアラートが通知されるトピックを作成、運用管理者のEメールアドレスをサブスクライバとしてSampleTopicに登録
CloudWatchでEC2インスタンスをモニタリング、SamppleTopicにメッセージを通知するアクションを設定(1分間の平均CPU利用率が８０％を１回超えたというアラームが発生した場合)
平均CPU利用率が８０％を超えてアラームが発生すると、「CPU利用率が８０％を超えてアラームの状態がOKからALARMに遷移した」というメッセージをSampleTopicに送信
SNSはSampleTopicに登録されている運用管理者のEメールアドレス(サブスクライバ)にメッセージを送信

第9章.AWSにおける拡張性と分散／並列処理(ELB/Auto Scaling/SQS/SWF)

密結合と疎結合

各サーバがそれぞれ可用性を高めて、極力ダウンすることがないように設計する。
各サーバの台数やIPアドレスは固定されていることが多く、各サーバは接続先のサーバのIPアドレスを登録 → お互いに密接に関係
これを密結合の構成という。

各層のサーバの結びつきが弱い構成を疎結合という。

ELB

ELB = マネージド型の負荷分散サービス

ELBの機能は次の通り。

(1). 複数のAZにまたがる負荷分散
(2). EC2インスタンスのヘルスチェック
(3). ELB自体の自動スケーリング
(4). SSLのオフロード
(5). Connection Draining
(6). アクセスログ記録
(7). スティッキーセッション

(1). 複数のAZにまたがる負荷分散

複数のAZにEC2インスタンスを冗長的に配置して、可用性の高いシステムを構築することができる。
7つのベストプラクティスの1つ「故障に備えた設計で障害を回避」を実現。

(2). EC2インスタンスのヘルスチェック

異常を検知したら、そのインスタンスに対するトラフィックの分散を止めて、正常なインスタンスのみにトラフィックを分散する。
ELBは異常を検知したインスタンスの分析や復旧作業は行わない。

(3). ELB自体の自動スケーリング

受信したトラフィックの流量に合わせて、自動的にその実体を増幅させる。
(その実体ってなに？？）

DNS名が作成され、ELBの実体が持つIPアドレスと名前解決／関連付けされる。
負荷に応じてELBの実体が増えれば、DNS名と新たなIPアドレスとの関連付けが行われ、逆にELBの実体が減れば、関連付けが削除される。

ELBを利用したシステムでは、ELBの実体のIPアドレスがわかったとしても、IPアドレスを使わずにDNS名を使用する。
ELBの実体に割り当てられるIPアドレスは、VPCのサブネット内のIPアドレスになる。

(4). SSLのオフロード

クライアントとAWS上のシステムの間でSSLの通信したい場合は、ELBにSSL証明書を配置して一元管理。
（EC2インスタンスに配置しない。）

(5). Connection Draining

ELB配下のEC2インスタンスの登録解除するときに、新規リクエストについてそのインスタンスへのトラフィック送信を停止し、登録解除前にそのインスタンスで処理中だったリクエストについては完了まで待つようにする機能。

(6). アクセスログ記録

ELBに送信されたアクセスログをS3に保存することで、アクセスログの一元管理が可能。

(7). スティッキーセッション

システムにアクセスしているクライアントを特定のEC2インスタンスに紐付ける機能。
ユーザ認証成功時に、WEBサーバでセッション保持することがある。
ELBでEC2インスタンス(WEBサーバ)が2つある場合、スティッキーセッションを利用して、クライアントを特定のEC2インスタンスに紐付け可能。
↓
認証手続きを複数回求められる状況の発生を防ぐ。

スティッキーセッションは「伸縮自在性を実装」に影響を及ぼすので注意。（ステートレスにならないため。）

分散／並列処理

EC2インスタンスが性能不足の場合、対処方法は2パターン

スケールアップ：インスタンスタイプをスペックが良いものに変更
スケールアウト：EC2インスタンスの台数を増やす

スケールアップの注意点

インスタンスタイプを変更するので、EC2インスタンスを停止する必要がある。
インスタンスタイプのサイズは上限があるので、限界がある。
EC2インスタンスの台数はそのままなので、「故障に備えた設計で障害を回避」を実践できない。
システム負荷の状況によっては、オーバースペックになる可能性がある。

スケールアウトのメリット

オンプレと違って、EC２インスタンスに台数に制約がない。
並列化することで、「故障に備えた設計で障害を回避」を実践できる。
サーバ負荷が上がるタイミングだけ、EC2を複数台起動して処理を分散すれば、オーバースペックになることはない。

スケールアップではなく、スケールアウトを実践するようにする。

Auto Scalling

EC2インスタンスでAuto Scallingグループを構成すると。設定に従って自動的にEC2インスタンスの台数を増減させる。

ユースケース

負荷状況に基づいた利用
- Webサイトへのアクセスの増減
- ランダムに要求が発生するバッチ処理のジョブ数の増減
スケジュールに基づいた利用
- 毎月まとまった時間に発生するバッチ処理
- チケット販売などで、販売開始日が決まっているWebサイト
正常なEC2インスタンスの台数を維持するための利用
- 数分のダウンタイムが許される1台構成のシステム

CPU使用率が70％を超過したら、アラーム状態に遷移して、Auto Scallingが発動。
Auto Scallingが発動して、EC2インスタンスか増える。あるいは減らすといった増減を自動化したりできる。

3つのコンポーネント

グループ「どこに、どんあ規模のグループ？」という設定。起動するサブネットや、どのELB配下か、などのどこに？最小／最大台数などグループの規模を決める設定

スタートのグループサイズ(EC2インスタンス数)
サブネット
ELB(ヘルスチェックを含む)
最小／最大グループサイズ

起動設定「どんなEC2インスタンスを起動するか」という設定。次の項目を設定することができる。

AMI(Amazon マシンイメージ)
インスタンスタイプ
IAMロール
CloudWatch詳細モニタリング
ユーザデータ
IPアドレス
ストレージ(EBS, インスタンスストア)
セキュリティグループ
キーペア

スケーリングプラン

「いつ、何台増減させるか？」という設定。

アラームXが発生した際／指定した日時
N台追加／削除
猶予時間(インスタンスの増減後に、次の増減アクションが発生するまｄねおクールダウン時間)

2つの特徴

インスタンスのヘルスチェックをかけている
- 正常なEC2インスタンスを希望する台数維持するため。
Auto Scallingグループが複数のAZにまたがるとき、AZ側でEC2インスタンス数を均等にする

EC2インスタンスが削除される順番

Auto ScallingによってEC2インスタンスが削除される場合、次の順番で削除される。(デフォルト設定)

起動している台数が最も多いAZのインスタンス
起動設定が最も古いインスタンス
次の課金タイミングが最も近いインスタンス

SQS

SQS = メッセージキューサービス
ELBと並ぶ、コンポーネントを疎結合にするサービス。
リージョンサービスに分類される。
プライベートサブネットからキューの操作をするためには、NATインスタンスが必要。

※ メッセージキューサービスが分からなかったので、こちらの記事も参考にしました。

SQSの特徴

(1).Pull型

アプリケーションからポーリングしてもらう必要がある

(2).順序性を保証はしない(FIFOが保証されない)

配信すべきメッセージが損失しないように、複数のストレージにメッセージを保持している。
そのため、後から登録したメッセージが先に登録したメッセージよりも先に取得されることがある。

(3).最低1回の配信保証

明示的に削除するまでは、特定のアプリケーションからメッセージを取得されたとしても、削除することはない。

(4).可視性タイムアウト

メッセージを取得したアプリケーションが処理実行中に、他のアプリケーションがキューに残っている同じメッセージを取得して同じ処理をしないように、可視性タイムアウト機能がある。
デフォルトだと30秒。

(5).メッセージサイズは最大256KB

処理対象データが大きい場合は、S3などを活用する。

SWF

SWF = Amazon Simple Workflow = マネージド型のタスクコーディネータ
商品の発注／請求処理のワークフローのような、重複を許さない、原則1回回切りの順序性が求められる処理に使用する。

SWFの3要素

ワークフロースターター：ワークフローを開始する。
ディサイダー：ワークフロー中の各処理を調整する。
アクティビティワーカー：ワークフロー中の各処理を実行する。

第10章.DNSとコンテンツ配信(Route 53／CloudFront)

エッジロケーション

リージョンとAZ以外に、エッジロケーションというデータセンターが世界に50箇所以上ある。
エッジロケーションでは、EC2, S3, RDS, Route 53, CloudFront, WAFが動作している。
エッジロケーションを利用して、DNSサービスやコンテンツ配信(CDN)サービスの提供が行われている。
世界に50ヶ所以上ある。

参考：https://aws.amazon.com/jp/about-aws/global-infrastructure/

Route 53

マネージド型のDNSサービス。
53番ポートを利用しているからRoute 53という名前。

主な3機能

ドメイン名を登録する
インターネットトラフィックをドメインのリソースにルーティングする
リソースの正常性をチェックする

Route 53がサポートしているレコードタイプ

A
AAAA(IPv6)
CNAME
MX
NS
PTR
SOA
SPF
SRV
TXT
ALIAS(エイリアス：AWS独自レコード)

ALIAS

Zone Apex = ゾーンの原点。
DNSのしようとして、CNAMEレコードを定義した場合、その名前を別のレコードで名前解決することができない。
CNAMEレコードでは対応できないZone Apexの名前解決をサポートすることができる。

wiki - DNSレコードタイプ一覧

加重ラウンドロビン

各レコードに重みづけをし、ある名前を対するクエリに指定された比率で異なる値を応答する。
（優先順位つけ？？）

レイテンシーベースルーティング

その名の通り、クライアントへのレイテンシー（遅延）を小さくすることができる。

位置情報ルーティング

クライアントのIPアドレスをもとに地理ベースでクライアントの接続元地域を特定し、地理的に近いレコードの値を返す。
また、特定のコンテンツを地理情報ルーティングを利用して、特定の地域にだけ配信することもできる。

ヘルスチェック機能

名前解決しているWebサーバが異常状態になった場合、そのWebサーバに対するクエリが発生しても、WebサーバのIPアドレス／名前を返さなくなる。
このとき、フェイルオーバー先の設定をしていれば、そのフェイルオーバー先のIPアドレス／名前を返す。

CloudFront

利用方法

① 動画などのコンテンツをS3やEC２インスタンス／ELB、またはオンプレサーバに格納。（オリジンサーバと呼ぶ）
② CloudFrontディストリビューションを作成する。ディストリビューションは、「example123.cloudfront.net」のようなドメイン名で、S3バケットなどのオリジンサーバが設定されている。
③ CloudFrontディストリビューションにエンドユーザがアクセスすると、DNSによる名前解決の際、地理データベースにより、コンテンツにアクセスしようとしているエンドユーザには、地理的にもっとも近いエッジロケーションのIPアドレスを返す。
④ エンドユーザは、返されたIPアドレスに従い、地理的に最も近いエッジロケーションにアクセスし、コンテンツがキャッシュされていればそこからコンテンツをダウンロードする。コンテンツは、最初にエンドユーザからのアクセスがあった際に、オリジンサーバからダウンロード／キャッシュされる。

コンテンツ配信サーバの負荷を下げることができる。
コンテンツを世界各地のエッジロケーションにキャッシュすることで、動画などの大きなコンテンツを高速にダウンロードできる。

CloudFrontのSSL証明書、あるいは利用者独自のSSL証明書を利用した暗号化通信が可能。
S3バケットに格納しているコンテンツについて、CloudFront経由でアクセスさせる際にも、「署名｛期限）付きURL」によるコンテンツ配信が可能。

第11章.AWSサービスのプロビジョニング／デプロイ／構成管理(CloudFormation／Elastic Beanstalk／OpsWorks）

CloudFormation

プロビジョニングサービス = CloudFormation

※ プロビジョニングとは？
必要に応じてネットワークやコンピューターの設備などのリソースを提供できるよう予測し、準備しておくこと

利用者が用意した定義(コード)に従ってAWSリソースを自動的にプロビジョニングする。
自動化により、AWSリソースの構築／管理を効率化できる。
インフラストラクチャをコード化して、インフラのバージョン管理が可能。

テンプレート
- プロビジョニングするリソースを規定するJSON形式のテキストファイル
- https://aws.amazon.com/jp/cloudformation/aws-cloudformation-templates/
スタック
- CloudFormationによってプロビジョニングされるリソースの集合／管理単位

テンプレートは、AWSから提供されるサンプルテンプレートを元に利用者が編集したり、独自に作成できる。
CloudFormerというツールを利用して作成できる。
- 利用者のアカウントで現在作成されているAWSリソースを元にテンプレートを作成できるツール
- 利用者がテンプレートを自作する際の開始点として利用

テンプレートには条件を記載できるので、本番／検証環境ごとにテンプレートを個別に作成する必要はない。

Elastic Beanstalk／OpsWorks

Elastic Beanstalk／OpsWorksは、CloudFormationから呼び出し可能。
CloudFormationとElastic Beanstalkを組み合わせて、VPCを含めたインフラ部分の作成からアプリのデプロイまでを自動化。
CloudFormationとOpsWorksを組み合わせて、アプリの設定まで自動化。

Elastic Beanstalk

アプリケーションのデプロイツール
開発者が自身で開発環境をAWSに構築して、デプロイすることができる。
Elastic Beanstalkを使って、バージョン管理も可能。

構築できるものは、

ELB
EC2インスタンス
S3バケット
RDS

OpsWorks

アプリケーションサーバの構成管理ツール
ELBやEC2インスタンスを作成し、Chefのレシピを実行してソフトウェアのインスタンスや設定などを自動化できる。

※ インフラストラクチャ自動化フレームワーク「Chef」の基本

第12章.EC2の料金モデル(オンデマンドインスタンス／リザーブドインスタンス／スポットインスタンス)

オンデマンドインスタンス

EC2インスタンスのデフォルトの課金方式でEC2インスタンスが起動している時間だけ、1時間単位で支払いが発生する。

オンデマンドインスタンスの1時間あたりの料金は、3つの要素で決定される。

リージョン
インスタンスタイプ
OS(Amazon Linux／RHEL／Windows Serverなど)

リザーブドインスタンス

参考：http://blog.takuros.net/entry/20130613/1371076928

1年あるいは3年契約結ぶことにより、オンデマンドインスタンスよりも割安にEC2インスタンスやRDSインスタンス、ElastiCacheやRedshiftを利用できる課金方式で、RI(Reserved Instance)と略した名称で呼ばれることがある。

支払方式	契約期間
全額前払い	1年あるいは3年
一部前払い	1年あるいは3年
前払いなし	IAMロール名

一定以上使うと安くなるのが、リザーブドインスタンス
稼働率が低ければ、オンデマンドインスタンス

1年契約より3年契約のほうが割引率が高い
けど、3年契約期間中に新しい世代のインスタンスタイプが発表されたり、値下げが行われても、リザーブドインスタンスはその恩恵を受けることができない。

リザーブドインスタンスは、利用料金の割引だけではなく、ITリソースキャパシティの予約にもなる。
AWSのITリソースの需要が高まっても、リザーブドインスタントして予約しているインスタンスは、いつでも確実に起動できる。

スポットインスタンス

参考：https://sadayoshi-tada.hatenablog.com/entry/20151209/1449671785

安価になるけれど、利用するインスタンスの利用価格が変動しており、自分が入札した価格を利用価格が上回ると強制的にインスタンスが削除される。

計算クラスタノードの一部や、AutoScalingの増加分のインスタンスなど、スポットインスタンスが突然削除されてしまっても問題ないところに利用する。

削除される前の対策

スポットインスタンス上のデータは、頻繁にチェックポイントを設けてS3やEBS、DynamoDBといった不揮発性のストレージに書き出す必要あり。
インスタンスが終了(ターミネート)の2分前に通知されるので、通知をトリガーにして外部ストレージに書き込み。

進捗状況

6月のデスマを乗り越えたので、7月は真面目に勉強します。
あとは練習問題を解きまくり、公式ドキュメント読み漁って、受験＆合格するまでは更新し続けます。

雑感

インフラに関する知識がなさすぎる。
もう少し予備知識をつけてから勉強を始めればよかったと後悔している。
新試験は受かる気がしないけど、旧試験も受かる気がしない。

参考文献

合格対策 AWS認定ソリューションアーキテクト-アソシエイト(Amazonのリンク)

AWS認定ソリューションアーキテクトアソシエイトを合格するまで更新するのをやめないッ！

初めに