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をまたぐ場合は以下手順
• 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に任せていたようなことができる。