食べられません

プログラミングとか漫画とか生活とか

AWSの無料枠についてまとめた

登録から12ヶ月間無料で使える枠と、その後も引き続き無料で使える枠がゴッチャになるのでまとめた

新規利用から12ヶ月間(毎月)無料の枠

  • EC2
    • t2.micro Linux 750時間
    • ELB 750時間 + 15GB分のデータ処理
    • EBS 30GB + 1GB分のスナップショットストレージ
  • S3
    • 5GBの標準ストレージ
    • 20,000 Getリクエスト
    • 2,000 Putリクエスト
  • RDS
    • micro DBインスタンス Linux 750時間(Single-AZ)
    • 20GBのストレージ
    • 1000万のI/O
    • 自動バックアップと任意スナップショット用 20GBストレージ
  • CloudFront
    • 50GBのデータ転送(アウト)
    • 2,000,000件のHTTP/HTTPSリクエスト
  • Cognite
    • 10GBのクラウド同期ストレージ
    • 1,000,000回の同期操作
  • AppStream
    • 20時間分
  • データ転送
    • 全てのサービスを総合して帯域幅「送信(アウト)」15GB
  • DataPipeline
    • 低頻度の前提条件 3つ
    • 低頻度のアクティビティ 5つ
  • ElastiCache
    • マイクロキャッシュノード 750時間

12ヶ月後も引き続き(毎月)無料で利用できる枠

  • DynamoDB
    • 25GBのストレージ
    • 25ユニット読み込み容量
    • 25ユニット書き込み容量
  • Cognite
    • 無制限のユーザー認証とID生成
  • SWF
    • 開始する1,000件のワークフロー実行
    • 合計10,000件のアクティビティタスク、シグナル、タイマー、マーカー
    • 使用する30,000ワークフロー日
  • SQS
    • 1,000,000件のリクエスト
  • SNS
    • 1,000,000件のリクエスト
    • 100,000件のHTTP通知
    • 1,000件のEメール通知
  • ElasticTranscoder
    • SDトランスコード20分 または HDトランスコード10分
  • CloudWatch
    • 10メトリックス
    • 10アラーム
    • 1,000,000APIリクエスト
  • MobileAnalytics
    • 100,000,000の無料イベント
  • KeyManagementService
    • 20,000件の無料リクエスト
  • Lambda
    • 1,000,000件の無料リクエスト
    • 3,200,000秒のコンピューティング時間

AWSのMultiAZについて調べたので残しておく

AvailabilityZoneとは

各リージョン(TokyoやOregon、Frankfurt等)内で、物理的に離れた箇所にあるデータセンターの事を言う。
Tokyoリージョンには

  • ap-northeast-1a
  • ap-northeast-1b
  • ap-northeast-1c

の3つのAvailabilityZoneが存在する。
また、必ずしもユーザーAのリージョンとユーザーBのリージョンが同じになるとは限らないようだ

ユーザーAの1aは物理センターのAだが、ユーザーBの1aは物理センターのBという場合もある

Multi-AZとは

一つのAZに対してアプリケーションを構築する(EC2やRDS等)Single-AZに対して、
複数のAZに対して構築することをMulti-AZと呼ぶことが多い。

Multi−AZという言葉自体は、RDSのオプションでしか存在しない(?

なぜMulti-AZ

障害耐性を上げるため、に尽きる。
ある程度の障害ならまぁなんとかなるだろ、とにかく安く済ませたい!ならSingle−AZでどうぞ

Multi-AZでどうなる

EC2

ELBにつけるEC2がMulti-AZになっている場合、AZ単位で障害が発生した場合にも別AZのEC2が応答するのでダウンタイムは存在しない。
これは単に障害だけの話ではなく、Amazonが何か緊急のセキュリティパッチを当てたい時などにAZ単位でインスタンスの強制再起動などが発生する場合にも同じことが言える。

EC2をMulti-AZにするためには、意識してインスタンスの起動AZを変更しておかなければならない。
また、起動しているインスタンスのAZを別のAZに移すといったことは出来ない。

RDS

RDSでのSingle-AZは、障害発生時の復旧は基本的に手動で行わなければならない。
Multi-AZの場合、障害発生時には自動フェイルオーバーが行われ、
1分から6分程度でスタンバイがメインとして動き始める。
これはインスタンスタイプの変更等で再起動を要する変更の場合にも適応される

自身で再起動を行う場合は、フェイルオーバーするかどうかは選択可能

フェイルオーバーによりAZが変更されるためIPは変更されるが、EndPointは同じままなので、再接続に問題はない。

当然だが、2インスタンス使うため料金は倍掛かる。

ELB

Multi-AZにするにあたり、AutoScalingで問題が発生する。
ELBがアクセスをAZに対して均等に振り分けた後、AZ内で均等に振り分けるため、AZ間でのインスタンス数が違うと負荷が偏る問題。
これについては、ELBのCrossZone-LoadBalancingを有効にすることで回避出来る。

Multi-AZの注意点

AZ間の通信には(同一リージョンであっても)1G/$0.01かかる点には注意しなければならない。