##基本
- 従量制の考え方がガッツリ。その考え方に慣れる。
- 考え方をクラウドに慣れさせる必要あり。インスタンスは資源として割り切る。いらなくなったら、容赦なくターミネート。
- オンプレの考え方はある意味捨てる。(実は活用できるけど、足枷になるとよくないから)
マネージドを最大限利用する。 - 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をまたぐ場合は以下手順
- EBSボリュームのスナップショット作成
- 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なインスタンスをキープすること）
- いろいろあるけど、端的にいうと以下の流れで作っていく。
- AMI作る
- Launch Configuration作る
- Auto Scaling Group作る
- 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に任せていたようなことができる。