【AWS】1章シンプルに始める～サーバーレスシングルページアプリケーション（OREILLY本）まとめ～
ちょっと前に掲題の本を買いました。
平日の朝早く出勤して1時間程＋土日数時間使って勉強を始めてます。
総学習時間はどれくらいになるか。。
この章でわかること
・サーバーレスの概要とメリットデメリット
・AWS CLIからS3へのデプロイ
1.1.1 サーバーレスデザインの利点
・サーバー不要
CPUやメモリ使用率のモニタリング、ログローテーション、ディスクスペースの枯渇などを気にしなくて良い。
・スケールしやすい
スケール作業そのものをクラウドサービスに任せられる。
・高可用性
アプリケーションアップデートのためのサーバ停止、設定反映の為の再起動も必要無い。
・ローコスト
AWSの無料利用枠を使ったりすれば費用は最小限。
・マイクロサービスフレンドリー
マイクロサービスやその他様々なサービス、システムに簡単導入可能。
・少ないコード量
従来はサーバ、クライアント両方で重複したコードがあった場合、その重複に気づきづらかった。
サーバーレスでは全てクライアント側でコードを記述するため、問題解決がしやすくなる。
1.1.2 サーバーレスデザインの制限
・ベンダーロックイン
プロバイダをサポートしたWEBサービスを使う必要がある。
Amazon等に依存してしまうため、Amazonが買収、破産してしまった場合に他のプロバイダでは動かないサービスになってしまう可能性がある。
・見慣れぬログ
多くのアプリケーションサーバーのログとは形式が異なる。
・異なるセキュリティモデル
よくあるセキュリティリスクの一部はなくなるが、馴染みのない問題にぶつかる。
ブラウザ内で入力されたデータをセキュリティ目的で安全に検証・チェックすることは不可能。
悪意あるユーザーが、ブラウザが取得した認証情報を奪ってアクセス許可されたWEBサービスを直接悪用する可能性を考慮する。
・異なるアイデンティティモデル
ユーザープロファイルをアプリケーションの他のデータと一緒に格納するのではなく、外部のデータストアに置く場合、お馴染みのDB操作（UserテーブルをIDで結合するなど）が適用出来ない可能性がある。
・コントロール欠如
外部のサービス（AWS）にDDos攻撃などのセキュリティコントロールを任せる為、自身でコントロール出来ない。（する必要がないのだが）
・ビッグスケール、ビッグマネー？
コストについての理解が必要。
スケールしやすい代わりに、支出も増えやすい。
1.3 Amazon S3にデプロイする
まず本番にデプロイ可能であることを確認する
1.3.1 AWS CLIをセットアップする
pipをインストール（CentOS6）
rpm -iUvh http://dl.fedoraproject.org/pub/epel/6/x86_64/epel-release-6-8.noarch.rpm
yum install python-pip
1.3.1.1 アクセスキーをもつAWSユーザを作成する
コンソールより作成。（プログラムによるアクセス許可）
アクセスキー、シークレットキーをCSVダウンロード。（チャンスは一度切り）
aws configure --profile admin
AWS Access Key ID [None]: xxxxxxxxxxxxxx
AWS Secret Access Key [None]: xxxxxxxxxxxxxxx
Default region name [None]: us-east-1
Default output format [None]:
/root/.aws/credentialsに入力した内容が保存される。
1.3.2 S3バケット作成
./sspa create_bucket learnjs.hogehoge.com
※S3バケット名はグローバルの為、他人が利用している名前は利用出来ない。
デプロイコマンド
（当然同じ名前で）
./sspa deploy_bucket learnjs.hogehoge.com
エンドポイントブラウザからアクセス
http://learnjs.hogehoge.com.s3-website-us-east-1.amazonaws.com/
