AWS初心者がセミナーを受けて感じた雑感

##基本
* 従量制の考え方がガッツリ。その考え方に慣れる。
* 考え方をクラウドに慣れさせる必要あり。インスタンスは資源として割り切る。いらなくなったら、容赦なくターミネート。
* オンプレの考え方はある意味捨てる。(実は活用できるけど、足枷になるとよくないから)
マネージドを最大限利用する。
* EC2 はVM
* AZ, リージョンは最低限把握しておく必要あり。特にリージョン制限は厳しい。(グローバルじゃなければ、あんまり気にしなくてもいいかも)
* AZ で可用性を担保する。
* アクセス制御はセキュリテイグループが基本。あとは、VPCとNACLで細かく制御。
* サービスとしてのファイアウォールはなし。セキュリティグループとNACLでコントロール。
* キーペアは使い回せるから管理ベースで任意に作る。IAMと併せて検討。
* EC2 でも基本サービスは作れるけど、ELB,EC2,S3,RDSは最低限のセットとして考えたい。
* EC2コンソール上で、ELBや、Auto Scaling等々の設定をする。（EC2のコンソールで結構設定できる）

##S3
* S3 が地味に利いてる。いろんなとこで出てくるので、うまく使う。
* S3 はパケット配下にフラットにオブジェクトが配置されるけど、パスベースの階層化は実はできる。(キーにパスを指定する)コンソールでもバケットの中にフォルダを作れるので、裏ワザというわけではなさそう。
* 3か所以上のDCに情報保存。すごい堅牢性を持つ。
* Webサイト機能を保有していて、静的なコンテンツであれば公開可能。（画像ファイルなど）
* 暗号化にも対応胃できている。（AES-256）
* S3へのアクセスログを保存することが可能。（バケットアクセス）
* APIを利用して、署名付きURLを作成し、非公開オブジェクトに限定的にアクセスさせることができる。（期間限定公開などに便利）
* S3 は標準でバージョン管理機能も持っている。プロパティで有効化すれば簡単にバージョニング対応できる。（バケット単位）
* S3 のAPIを利用して柔軟に使うことができる。アプリケーション的にはかなり便利かも。

##Glacier（グレイシャー）
* S3と連携するバックアップ低価格ストレージ。
* 感覚的にはD2Dな感じ。テープにバックアップするようなデータを保存するストレージとして考ええる。（ストレージの階層化）
* コスト比で行くと、S3に比べて1/3に下がる。（ストレージの性質としてはS3と一緒なので、比較できる）
* 基本的には、S3からの自動アーカイブを想定しているので、直接の操作はGUI等ではできない。APIを利用すればできる。（使わないか…）
* S3のプロパティから、ライフサイクルを指定することでルールベースでS3からGlacierに退避される。Glacierに退避されると、S3上からは事実上削除されるが、コンソール上は残っているように見えるので要注意。（S3のAPI等からアクセスできなくなる）場所がどこにあるかは、S3の"Storage Class"で確認する。
* Glacierからの取り出しは、S3のコンソールから実施。取り出しには3-5時間かかるうえ、取り出し時に課金が発生する。なお、GlacierからS3に取り出した際も"移動"ではなく、"コピー"に近いイメージなので、Glacier上から消えることはない。
* Glacierから直接DLすることも可能。

##EBS
* EC2要のNAS型ブロックストレージ。
* EBSはEC2のルートボリュームとしても利用されているっぽいが、別として考える。
* EBSは1GB-16TBの範囲内で割り当て可能。
* EBSは通常のNASストレージと道央に任意の実行中のインスタンスに複数アタッチできる。（停止中でもOK）
* EBSボリュームはAZ内で自動的にレプリケーションされる。
* EBSはAZ内の利用が前提のため、リージョン単位で考えないように注意する。
* EBSスナップショットをS3に取得することで、データのバックアップとして利用可能。（EC2のスナップショットと同様に管理され、世代管理も可能）
* EBSスナップショットから自由にEBSボリュームを作成、復元することができる。また、この作成* 復元はAZをまたぐことができるし、他のアカウントに共有することもできる）
* EBSスナップショット作成時は、通常のバックアップと同様に静止点を作る必要があるので、OS上のアンマウントが望ましい。（xfsなど、ファイルシステムによっては、フラッシュ機能でフラッシュすることは可能）
* EBSボリュームをAZをまたぐ場合は以下手順
1. EBSボリュームのスナップショット作成
2. EBSスナップショットから復元の際にAZを指定。
* 一般的なNAS利用を想定すればOK。また、クラスタウェアと組み合わせてクラスターを作ることもできる。（RDSと組み合わせればよいから、DB的な使い道はないか…。ELBと組み合わせてもできないクラスタリングを考慮）
* EBS-Optimaized Instanceを利用すると、EBS I/O専用の帯域が割り当てられる。（通常のEBSは相乗りな感じ）EBSはi-SCSIなのか？
* EBS-Optimaized InstanceはMagnetic（HDD）、GeneralPurpose（汎用SSD）でも効果あり。インスタンスタイプによって、500Mbps-4000mMbpsを選択可。
* EBS-Optimaized InstanceはECインスタンス作成時に設定する。
* Magneticは1GBあたりは若干安いが、I/Oリクエスト単位での課金があるので要注意。
* Provisioned IOPSはI/Oの回数うを上げるオプションと考えた方がよい。（Disk容量の30倍まで指定可能）

##RDS
* RDS はすごく便利だけど、色々検討はすべき。使うなら、考え方をクラウドに慣れさせるべき。(EC2にデータベースを作るのは個人的にはナンセンスかな)
* RDS はマルチAZで耐障害性を確保。これ、基本！
* RDS は基本で、レプリケーション、フェイルオーバー、ポイントインタイムリカバリが可能。DBAにとっては、泪チョチョギレ。
* RDS のインスタンスはもちろんカスタムできる。基本はEC2と一緒。

##ELB
* ELB は一般的な機能はすべてある。AZを跨ぐことができるので耐障害性あり。
* SSL もサポートしてるので、アクセラレータとしての利用もバッチリ。
* もちろんセッションアフィニティもサポート。(Web系の機能に限る)
* ロードバランサーの機能としては十分な気がするけど、スタートアップが独自で構築してるところもみると、一行の余地はあるのかな？(リバプロ的な考えか？)

##CloudWatch
* 監視はCloudWatchを念頭に構築。
* EC2、ELBなどのサービスごとに監視項目（メトリクス）があるので、適度にアラームを設定する。（閾値設定）
* 通知は、メールとかSNS。（SNMP等々はないみたい）
* CloudWatchと他の監視SW（JP1とか）と連携させる場合は、監視SW側がAPI呼び出しのCloudWatchに対応するもしくはCSV連携等が必要。（CSVはS3から取り出す感じ）
* CludWatch Logsを設定することによって、OS、APとうとうのログからエラーをTrapすることができる。
* CludWatch LogsはAgentベース。ログデータはS3に格納されるっぽい。
* ちなみに、実態はCloudWatchのAPIをAgentが呼ぶ形式っぽくて、APIを呼ぶことで課金が発生する。（logの量？）
* モニタリングは割り切ったアラーム設定が基本。
* ログ監視もできるが、S3と連携するなど、制限はあり。要検討。

##Auto Scaling
* Auto Scalingが結構いけてる。
* Auto ScalingはAMI作成、Auto Scaling Group、Launch Configuration、Auto Scaling Policyを作る必要あり。Auto Scaling Policyをどう作るかがポイント。
* Auto Scaling Policyはスケールアウト（Increase Group Size）、ダウン（Decrease Group Size）の両方あり。ここ、ポイント。
* Auto Scaling PolicyはCludWatchのアラームと連携した負荷ベースと、スケジュールベースあり。ハイブリッドが基本かな。
* AMI、Lauch Configurationがキモ。アプリケーションもこれを意識して作る必要あり。
* Auuto Scaling発動時は、Lauch Configurationによって定義されたAMIベースのインスタンスが起動する。（Security Group等も設定されている）
* Auto Scaling Groupはスケーリングする最少、最大インスタンスを指定できる。（最少台数うは常に維持される。サーバをTerminateした場合もすぐに復帰する）
* 最少、最大インスタンスを同数にすることで、Auto Healingとして利用することもできる。（常に同一台数のHealthyなインスタンスをキープすること）
* いろいろあるけど、端的にいうと以下の流れで作っていく。
1. AMI作る
2. Launch Configuration作る
3. Auto Scaling Group作る
4. Auto Scaling Policy作る（ここは複数作って設定するイメージ）

##CloudFront
* CloudFrontはAkamai等々と同じ、大規模キャッシュサービス。（CDN）
* CloudFrontで利用できるエッジロケーションは50以上ある。（ちなみに、リージョンは9個※北京、GOVリージョンは申請制）
* CloudFrontも従量制というのは結構新しい感じ。（Akamai等々はコミットメントが必要だったはず）

##その他
* アプリケーションも最大限、awsの構成を生かせるように作るべき。各リソースの使い方もそうだし、インスタンスがスケールアウトしたときに自動でクラスタグループに参加できる準備がいるなと。
* Amazon VPD、AWS DirectConnectなどを使ってアクセス接続性を保持。（セキュリティも別途保持）

##IAM
* AWS利用者の認証とアクセスポリシーを管理する仕組み
* ユーザとグループで管理できる。
* IAMは重要。テンプレートの考え方を常に念頭にいれる。
* 多要素認証（MFA)デバイスにも対応
* IAMはオペレーションだけではなく、APIアクセス（アクセスキー、シークレットキーでアクセス）にも使用する。
* ベストプラクティスだが、最初のアカウントはrootユーザとして使用せず、利用用途ごとにIAMユーザを作って配布する形式がベスト。
* Deny/Allowポリシーに基づいて設定、判断させる。（Deny優先）

##CrowdFormation
* JSON形式で記載される。
* Elastic Beanstalkとはサブセットの関係
* テンプレートにしたがって、スタック単位（EC2インスタンスやS3バケットなどのリソースの集合）で作成、破棄することができる。
* テンプレートを作れば、同じ構成を複数簡単に作成できる。（開発環境や、テスト環境の構築など）
* AWSとして、サンプルテンプレートが複数登録されている。（システムアーキテクチャの再利用）
##Simple Queue Service（SQS）
* フルマネージドの分散マネージドキュー
* AWSクラウドをオンプレの間のやり取りでも使える。（便利そう）

##DynamoDB
* IOPSを指定可能。
* 大量データでも高速アクセスかつ速度劣化がない。
* 低コスト。
* NoSQLデータベース（Key/Valueストア）
* Sessionデータのキャッシュや、固定値のキャッシュ、ショッピングカートのキャッシュなど、memchashdに任せていたようなことができる。