AWS

[ガラケー版(QRコード)]
アクセス記録[推移 / PV内訳(過去1日 / 過去1週間) / 外部アクセス元 (昨日 / 過去1週間) / ログイン論客足跡]
プロフィール私書(メール)
   /   /送済
評価(一覧   /)
投票   /共:   /
ファン登録
作品/情報/
DB構築()
ブログ
[書く]
攻略記事リンク集
My Play List
 作成日時分類記事タイトル
12015/06/12AWSAWS設定方法&活用マニュアル 2017..
22015/04/18AWS設定
32015/01/17AWSs3
 反応日時来客名来客者の最近のメッセージ
12017/02/25Merciこんばんは。サーバー移転後からだと思いますが、以前は見られた..
22017/02/17ねこじゃらしブログ投稿やコメントをしようとすると、たまにエラーになります..
32017/02/16Barnirunお世話になっております。https対応の影響か(またはhtm..
42016/11/10伏魔の剣こんばんわ。形式変更お疲れ様でした。 ところでこの改定につい..
52016/10/31雪霞いつもありがとうございます。ところで、ログアウトした時にポッ..
その他最近のコメント
1.
2015/06/12 AWS > AWS設定方法&活用マニュアル 2017」
[この書込みのみ表示(記事URL紹介用) / 編集 / 削除 / トラバ送信 / 共有分類に追加(タグ付け)]拍手:2個

1. 文章目的
2. AWSの良い所簡単まとめ
3. AWSを使うにあたっての注意所
    1. 関係者との調整
    2. Full AWSが正というわけではない
    3. ユーザーコミュニティに参加しよう&広めよう
    4. AWSの最新情報についていこう
    5. クラウドNativeのセキュリティに対応しよう
    6. クラウドデザインのベストプラクティスにのっとろう
        1. Independency(疎結合化)
        2. Maitainability(メンテのし易さ)
        3. Scalability(拡張性)
        4. Aavailability(可用性)
        5. Visibility(可視化)
        6. Rcoverability(復旧容易性)
        7. Replicapability(コピー容易性)
        8. Portability(移動容易性/切替容易性)
        9. その他: 全レイヤでのセキュリティ
        10. その他: ストレージの使い分け
    7. 移行にあたっては検証をしよう
        1. 既存システムはAWSで動くのか
        2. レスポンスに問題ないか
        3. 障害の検知・切り分け
        4. 社内で運用出来るのか
        5. 社内で運用出来るのか(2)
        6. 運用コストは上がらないかどうか、仮に上がるとしたら許容範囲かどうか
    8. 目標を持とう
        1. 最先端SaaS/PaaSの徹底活用
        2. 開発環境と本番環境の同一化
        3. テスト/品質チェックの徹底
        4. 運用の自動化と安定化
        5. ビッグデータの基盤として活用する
    9. 個別最適化にならない共通基盤を構築する
        1. ホリシー・カイトラインの確立
        2. ポリシー
        3. ガイドライン
        4. 標準化の推進①
        5. 標準化の推進②
4. AWSのサービスの整理
    1. 自分の用途で使う事が想定されるサービス
    2. 暫く自分の用途では使わないと考えられるサービス
    3. サービスをアイコンで表す
    4. Auroraについて
5. 設定手順 & 各サービス詳細
    1. 設定を始める前に
    2. アカウント取得
        1. 登録後1年間の無料枠
    3. 右上のリージョン
    4. CloudTrail
        1. 特徴
        2. 設定
    5. 開発者ならCLI(Command Line Interface)をインストール
    6. AWSルートアカウントでのMFA(AWS Multi-Factor Authentication)の設定
        1. 設定
        2. コマンドライン(CLI)での操作
    7. IAM(Identity & Access Management)
        1. 説明
        2. IAMのベストプラクティス10
        3. Adminsグループの設定
        4. ユーザーの追加
        5. IAMで作ったユーザーへのログイン画面の提供
        6. その他必要なグループの作成・整備
        7. プロバイダの設定
        8. CLI(コマンドラインインターフェース)での設定
    8. VPC (Virtual Private Cloud)
        1. 構成のベストプラクティス
        2. VPCの設定
        3. サブネット
    9. セキュリティグループ
        1. インターネットゲートウェイ
        2. コマンドラインターフェース(CLI)経由の操作
    10. EC2
        1. EC2の特徴
        2. EC2の性能: T2シリーズの場合
        3. EC2の性能: M3シリーズの場合
        4. EC2の性能: 全シリーズの一覧(オンデマンドの価格モデル)
        5. リザーブドインスタンスという価格モデル
        6. スポットインスタンスという価格モデルと仕組み
        7. インスタンスの利用可能数の上限とかを拡張する
        8. 使うOSの選択
        9. ブラウザーからの設定方法
        10. CLIでの操作
        11. Amazon マシンイメージ(AMI)
        12. swapfile
        13. Elastic IP
        14. EC2をWebコンソールから作る時に提示されるボリューム追加 / EBS (Elastic Block Store)
    11. Elastic Load Balancer (ELB)
        1. 価格
        2. 設定方法
        3. SSL証明書の設定
    12. RDS
        1. 特徴
        2. 設定方法
        3. マルチAZの設定について
        4. タイムゾーンの設定について
        5. スナップショットからのDBの復元
        6. インスタンスを削除する時の注意
    13. ElastiCache
        1. 設定方法
    14. S3
        1. 特徴
        2. 料金体系
        3. ブラウザーから使う
        4. コマンドラインを使ってのファイルのアップロード
        5. 静的ファイル置き場としてのサイトの公開
    15. CloudWatch
    16. Simple Email Service(SES)
        1. 設定方法
    17. CloudFront
    18. Lambda
    19. Cloud Search
    20. DynamoDB
    21. Redshift
        1. AWSサービス間のデータ連携
        2. データを活用するのに使えるAWSネイティブのサービス
    22. デプロイ系サービス
        1. Elastic Beanstalk
        2. OpsWorks
        3. CodeDeploy
        4. Cloud Formation
        5. AWS CLI
    23. Trusted Advisor
    24. Machine Learning
        1. 特徴
        2. 取り扱える予測モテルとアルコリスム
        3. 予測手法
        4. 使い方
        5. 現在利用可能なリージョン
        6. バッチ予測の流れ
    25. AWS Codecommit
        1. 特徴
        2. 料金体系
        3. 設定方法
6. AWS連携外部サービス
    1. 監視サービス
7. 参考文献

1. 文章目的

AWSの活用法・使い方について、紹介します。
業務で幾つかのシステムを構築してきましたが、現在このブログが書かれているサイト作品データベースもAWS上で動いています。
別記事で「AWSの各インスタンスのベンチマーク比較」を見る事も出きます。
筆者はAWS Certified Solutions Architect - Associate Level

の資格を持ってます。
2. AWSの良い所簡単まとめ

・インフラ周りの機能が充実&進化し続けていて、「インフラ機能」という点では頭一つ抜けている。
ここまで機能拡充が加速していくと、それがインフラといっても、ソフトウェア開発でオープンソースを利用せず、OSSの進化に乗らずに独りでやってたら取り残されちゃうよね?、のような他の人が進化させていく基盤に乗るから乗らないか、乗らなきゃ置いてかれかねない、といった話にも繋がる。


・2006年と他に先駆けたクラウドコンピューティングサービス提供開始により、歴史の積み重ね=安定性&他に比べて豊富な機能の利用が望める。

・データセンター&所有実ハードウェアが無くなる事による手間・調達時間・コストの削減は確かに大きい。
とはいえ、それはAWSに限らずの話なので、それ自体はAWSを選ぶという理由にはならない。
オンプレの代わりにクラウドサービスを選ぶ理由にはなるかと思いますが、これ自体はオンプレに対するクラウドサービスの一般的なメリットの話です。

・全パケットがチェックされていて、DDos攻撃に対しての防御等が優れてる。
これは毎週のようにDos攻撃で...とどこかの落ちまくってるVPS業者さんと比べるとこれはこれでメリットにうつりますね。

・世界中の多数の利用により、ユーザーによるコミュニティ・情報が他クラウドサービスに比べ充実している。
3. AWSを使うにあたっての注意所


    1. 関係者との調整

組織としてではなく個人でやるのならお好きなように、ですが、組織でやる時には、なるべく相談が必要と思われる所には抜けなく連絡をしておきましょう。
新しい事をするにあたっては相談相手を増やさない方がやり易いとか思うかもしれませんが、エンジニアにとっては大きな仕事の援助基盤となる反面、企業という観点で見ると大きな情報流出リスクの発生イベントである事は確かなので、事後連絡になるのは望ましい事ではありません。
社内規定・リスク管理担当者等、きっと筋を通すべき事は諸々あるでしょう。
    2. Full AWSが正というわけではない

使わないのは愚かだが、無思考で全てAWSというのも賢くはありません。
用途・状況をよく考えよう。
- オンプレミス基盤
- 社内基盤
- クラウド基盤

AWSは色々機能の進化が加速度的になっているという面が乗るという選択肢状では大きな誘因となっており、企業としてはそもそも人件費が大きいのだからそこの削減に繋がるAWSは合理的な面がありますが、そうはいっても個人にとってはVPSとかに比べまだ高いという面もあります。
また、AWSの機能が充実しているが故の、一見複雑に見える独自の作法を、今の所学んでまで移行するメリットがどうしても見出せない、という事もあるかもしれません。
そういう時にはVPSとか専用サーバーとかも考慮してみましょう。

2015年VPS比較(ベンチマーク)

実際、海外ではAWS高いという価格Sensitiveな人達にはDigital OceanのようなクラウドもどきVPSの利用が人気です。
    3. ユーザーコミュニティに参加しよう&広めよう

常に変わっていくサービスであるので、情報共有の場への参画を持っておきましょう。

関わり始めとしては、

http://eventdots.jp/tagpage/aws

http://jaws-ug.jp/

などで自分が参加し易いと思う会を探すと良いでしょう。
    4. AWSの最新情報についていこう

AWSの発表する公式情報は、常にチェックしておくようにしましょう。
主にブログで最新の情報は流される事が多いです。

日本語ブログ
http://aws.typepad.com/aws_japan/

英語ブログ
https://aws.amazon.com/jp/blogs/aws/
    5. クラウドNativeのセキュリティに対応しよう

- VPC
- IAM
- CloudTrail
はセキュリティの3種の神器。
セキュリティって何それ、美味しいの?、という方は、個人ではそれでも良いと思いますが、企業組織では他の方が整えてくれるまで待つ&待ったをかけた方が良いでしょう。
    6. クラウドデザインのベストプラクティスにのっとろう

どのようなクラウド環境・サービス構成にするかは、AWSにはAWSのベストプラクティス的なものがあります。
それを把握しておきましょう。
下記では図が続きますが、アイコンの指すものと照らし合わせたい方は「アイコンで表したAWS各サービス」をご参照下さい。
      1. Independency(疎結合化)

コンポーネントを独立させ、ブラックボックス化する。

サーハ冗長化:複数サーハを複数AZに冗化して設置し、ELBに紐付け

ELBの利用:ELBはAWSか冗長化しており、利用すれは自動て冗長化・疎結合化
サーハかちても他サーハて継続処し、可用性担保と負荷分散を同時に実現

      2. Maitainability(メンテのし易さ)


      3. Scalability(拡張性)

伸縮自在性があり、再起動が可能な構成にする。

Auto-Scaling:設定した負荷条件に応してサーハ数を増減、自動復旧
監視システムと連携し、サーハ負荷増加の場合は自動てサーハを追加、減少の場合は自動て削除する(サーハ上限/下限数,増加/削除単位,等を設定可能)
※起動するサーハを前もってイメーシ化して用意しておく(AMI)

      4. Aavailability(可用性)

あらゆるものはいつでも壊れる前提で設計する(Design for Failure)。

Multi-AZ DB(RDS)配置: テータを複数AZに同期保存し,障害発生時に自動フェイルオーハーすることによりRPOセロを実現
DB Snapshot: S3にDBのハックアッフを取得し、万かのリカハリ等て利用

      5. Visibility(可視化)

ログは「捨てるか正義」 から 「貯めるか正義」 へ

      6. Rcoverability(復旧容易性)


      7. Replicapability(コピー容易性)

新規PJやdev、stgなども、一度構築した資産を活用して、ぱぱっと立ち上げれるようにしておきましょう。

      8. Portability(移動容易性/切替容易性)

本番環境とそうでない環境を簡単に切り替えられるようにしておきましょう。

      9. その他: 全レイヤでのセキュリティ

AWSとの責任分担モデルを理解し、AWSの必ず設定すべきセキュリティポイントはおさえた上で、AWSでカバー出来ない所は自社でカバーしに行って、抜けが無いようにしていく。
管理画面へのログイン、Webサーバーへの接続、DBへの接続、等レイヤは複数あるので、そのレイヤとするべき事をきちんと整理して考えておくようにしましょう。
      10. その他: ストレージの使い分け

アクセス速度、冗長性の度合い、値段を把握して、EBSやデータベース、S3などのストレージを適切に使い分けましょう。
また、動的生成か要なファイルはS3に置くことて、ファイルの可性を向上させると共にEC2の負荷は軽減しておきましょう。

    7. 移行にあたっては検証をしよう


      1. 既存システムはAWSで動くのか


      2. レスポンスに問題ないか


      3. 障害の検知・切り分け


      4. 社内で運用出来るのか

人の観点。
アプリエンジニアの担当領域が増えるが出来るのか。
      5. 社内で運用出来るのか(2)

1) 運用フロー・手順書の整備
2) リファレンスアーキテクチャーの作成
3) 運用の自動化の推進
      6. 運用コストは上がらないかどうか、仮に上がるとしたら許容範囲かどうか

正確に計算しきる必要はありませんが、ざっとどんなものかな、という感覚位は持てるようにしておきましょう。

どんなサービス利用するのか目星を立てたら、料金簡易計算ツール

http://calculator.s3.amazonaws.com/index.html?lng=ja_JP

で、それに必要な費用を出してみましょう。
ネットワークの利用料を出すのは予測になるので難しいかもしれませんが、とりあえずはそれを除いた費用だけでも把握しておきましょう。

オンプレから移行する場合には、企業としてやっている限り、人件費等含めて基本安くなると考えて良いでしょう。

VPSとかさくらの専用サーバーとか元々クラウドな環境から移行する場合には、必ずしもそうではないでしょう。
AWSだから出来る事を軸に、それがサービスの向上に繋がるかどうか、冷静に考えましょう。
    8. 目標を持とう

ここら辺は出来たら、でしょうが、折角なので、開発の進め方について、世の中の先端の方に追いついていない部分は、追いつかせる良い機会になるでしょう。
特にAWS自体がクラウドなので、Github・CircleCIといった外部のクラウド型開発支援サービスを導入する良い機会になるかと思います。
      1. 最先端SaaS/PaaSの徹底活用


      2. 開発環境と本番環境の同一化

Dockerの活用
      3. テスト/品質チェックの徹底

CircleCIの活用等
      4. 運用の自動化と安定化

AWSのデプロイ・監視機能や、Ainsibleの活用等
      5. ビッグデータの基盤として活用する

S3をログ置き場として中心として、Spark等各種解析ツールと色々組み合わせてビッグデータ解析基盤として活用してみる。
何故S3がビッグデータ解析の中心となるのかといえば、ディスク単価が安いので、そこに只管ログを置いていく事になる&そこをデータソースに各種解析サービスを動かせるから。
    9. 個別最適化にならない共通基盤を構築する


      1. ホリシー・カイトラインの確立

[目的]
・属人化・属ベンダー化の抑止
・ベンダーに依存しないシステム構築の推進

[特徴]
・AWS利用に関するルールブック
・構築のノウハウ集
      2. ポリシー

変更を禁止する普遍の憲法

・利用方針
・役割分担方針
・テスト方針
・運用方針
・設計方針
      3. ガイドライン

基本ルール

・利用ガイド
・共通基盤利用ガイド
・設計ガイド
・運用ガイド
・テストガイド
      4. 標準化の推進①

[目的]
・設計~運用までを緩やかに統一
・プロジェクト期間の短縮

[特徴]
・AMIやスタックのカタログ化
・AWSの各種サービスのパラメーターを標準化
      5. 標準化の推進②

[要件定義]
・サービス選定基準

[設計]
・OSパラメーターシート
・AWSサービスパラメータシート

[構築]
・AWS構築標準WBS
・AWS構築チェックシート
・カタログAMI

[テスト]
・インフラ標準結合テストケース
4. AWSのサービスの整理


    1. 自分の用途で使う事が想定されるサービス

VPCAmazon Virtual Private Cloud。他から独立したクラウド領域を作れる。
IAMIdentity & Access Management。AWSの各リソースに対するアクション、アクセス権限を管理てきる
EC2VPSサーバー自体と考えれば良い
RDS運用面で優れたRDBM。でも人件費の削減を度外視すればAWSで一番費用がかかりかねない所(特にMulti AZにすると)
ElastiCacheインメモリキャッシュ
S3log/AMI/バックアップ
SESメール送信サーバー
CodeCommitAWSのgitレポジトリ
CodePipelineAWSのCIサービス
CloudTrailAW API の呼ひ出しを記録し、 ロクを残すことかてきるサーヒス。
Configリソース設定
CloudWatchAWS固有のサービス監視に使える
Trusted AdvisorAWSクラウド最適化支援ツール
Lambdaイベントをトリガーとする処理サービス(on node.js)
EC2 Container ServiceDockerコンテナの実行と管理
Glacierアーカイブストレージ(=安いけどリアルタイム利用には向かないディスク)
CloudFront画像データ等に使うCDN
DynamoDB予測可能でスケーラブルなNoSQL
Elastic Map ReduceHadoopクラスタ。S3、DynamoDBとの連携が容易。
Route 53可用性に優れたDNS
Redshiftペタバイトスケールのデータウェアハウスサービス
Elastic Beanstalk用意されたセットでサーバー群の利用を開始できるアプリケーションコンテナ
OpsWorksDevOpsアプリケーション管理サービス
CloudFormationテンプレートによるサーバー群・環境設定サービス
CodeDeploy自動デプロイ
Kinesisビッグデータストリームのリアルタイム処理
Data Pipelineワークフローに対するオーケストレーションサービス
Machine Learning機会学習プラットフォーム
SNSプッシュ通知、メール配信結果の取得に使える
SQSバウンスメール受信に使える
CloudSearchSolrベースのonクラウド型検索エンジン
CognitoユーザーID及びアプリケーションデータの同期
Mobile Analytics大規模なアプリケーションの使用状況データの把握

    2. 暫く自分の用途では使わないと考えられるサービス

Storage GatewayオンプレミスIT環境とクラウドストレージの統合
Direct ConnectAWSへの専用線接続
Directory Serviceクラウド上の管理型ディレクトリ
SWFアプリケーションコンポーネントを連携させるワークフローサービス
AppStream低速なアプリケーションストリーミング
Elastic Transcoder使いやすいスケーラブルなメディア変換サービス
WorkSpacesクラウド内のデスクトップ
WorkDocsセキュアなエンタープライズ向けストレージ及び共有サービス
WorkMailセキュリティに保護されたEメールとカレンダーサービス

    3. サービスをアイコンで表す

構成図を描く時によくアイコンが使われますが、添え字が付いていないので初心者には意味不明ですね。
参照用に一覧としてまとめると以下のようになります。



https://cacoo.com/store/items/10246

などがAWSの構成図を描くのに使えます。
    4. Auroraについて

なお、ここにはありませんが、RDSに将来入ってくるAuroraはかなり有望なサービスです。
(USの一部のリージョンで現在利用可能)
クラウト時代にAmazonか再設計したRDBMS
 MySQL5.6と互換かあり既存の資産を活かしやすい
- 高いクエリ実行並列度
- テータサイスかきい環境て性能を発揮
- 可用性
- 速なフェイルオーハ・PITRを実現

5. 設定手順 & 各サービス詳細


    1. 設定を始める前に

設定は最初は画面コンソールからやるのが良いと思いますが、再現性&手順の共有という意味では、一旦手動で設定して、それとは別にコマンドラインインターフェース(CLI)でやり直す、という手順を踏んでいく事は、後々役立ちます。
何でも設定をするという事が想定出来る場合には、手順の資産化を進める為にも、出来ればそういう手順を踏んでいきましょう。
但し、CLI化自体が目的ではないので(文章化で済ませるという手段もあるにはあるので)、リソース・PJの段階・立場を考えて、無理はせずに必要に応じてそこは手をつけていけば良いと思います。
    2. アカウント取得

まずは
http://aws.amazon.com/jp/console/
でサインアップしてアカウントを取りましょう。

クレジットカードが必要です。
      1. 登録後1年間の無料枠

登録してから1年間、一部が無料で使えます。
色々書いてあって逆に意味分からない、と初めての方はなるかもしれませんが、とりあえずEC2という無料の仮想サーバーが1つ1年無料で使える、といった所の認識から始めていけば良いかと思います。

2015/06/15時点
Amazon EC2750 時間 1 か月の Linux、RHEL、または SLES t2.micro インスタンス使用量 / 750 時間 1 か月の Windows t2.micro インスタンス使用量 / 一度に 1 インスタンスを実行するか、複数のインスタンスを同時に実行
Amazon S35 GB 標準ストレージ / 20,000 件の Get リクエスト / 2,000 件の Put リクエスト
Amazon DynamoDB25 GB ストレージ / 25 ユニット 書き込み容量 / 25 ユニット 読み込み容量 / 1 か月当たり最大 2 億リクエストの処理が十分に可能
AWS Lambda100 万回 1 か月当たりの無料リクエスト数 / 1 か月当たり最大 320 万秒 のコンピューティング時間
AWS Key Management Service2 万件 1 か月当たりの無料リクエスト数
Amazon Cognito無制限 ユーザー認証と ID 生成 / 10 GB クラウド同期ストレージ / 100 万回 1 か月あたりの同期操作
Amazon AppStream20 = 1 か月当たりの無料時間枠
AWS Trusted Advisor4 回のベストプラクティスチェック 性能とセキュリティ(サービス制限、セキュリティグループ、IAM、MFA)/ 通知とカスタマイズ機能
Amazon CloudFront50 GB データ転送(アウト) / 2,000,000 HTTP および HTTPS リクエスト
Amazon RDS750 時間 1 か月の single-AZ マイクロ DB インスタンスの使用量 / 20 GB DB Storage: General Purpose(SSD)または Magnetic の任意の組み合わせ / 20 GB バックアップ(RDS Magnetic ストレージを使用。 General Purpose [SSD] 上の I/O は別々に請求されません) / 1,000 万 I/O
Amazon Mobile Analytics1 億回 1 か月あたりの無料イベント
Amazon EBS30 GB Amazon EBS: General Purpose (SSD) または Magnetic のすべての組み合わせ / 200 万 I/O (EBS Magnetic 付き) / 1 GB スナップショットストレージ
Amazon ElastiCache750 時間 十分な時間数
Amazon ELB750 時間 1 か月あたり15 GB データ処理
Amazon Elastic Transcoder20 分 音声トランスコード / 20 分 SD トランスコード / 10 分 HD トランスコード
Amazon CloudWatch10 個のメトリックス / 10 個のアラーム / 100 万件の API リクエスト
Amazon SQS100 万件のリクエスト
Amazon SNS100 万件の発行 / 100 万件のモバイルプッシュ配信 / 10 万件の HTTP/S 配信 / 1,000 件のメール配信
Amazon SWF10,000 件のアクティビティタスク / 30,000 のワークフロー日 / 1,000 回の実行
AWS Data Pipeline3 個の低頻度の前提条件 / 5 個の低頻度のアクティビティ
Amazon SES62,000 件のメッセージ Amazon EC2 インスタンスから Amazon SES を呼び出すときに、受取人に対する 1 か月あたりの量。

    3. 右上のリージョン

リージョンが最初はUSの所が選ばれているので、「アジアパシフィック(東京)」を選びましょう。
    4. CloudTrail

公式文章: https://aws.amazon.com/jp/cloudtrail/
      1. 特徴

コンソール・API操作のログをこの機能をオンにする事で使えるようになります。
企業でやっているのなら絶対、個人でやるのでも出来れば自分の行動の履歴を後で追えるようにする為に、まず設定しておきましょう。
      2. 設定

ログはS3に保存されるので、ユニークな保存フォルダ名を入力します。
ログの保存領域分の課金等はされますが、そんなに大した額にはならない筈です。
とりあえずログを残す為にはそれだけで済みます。

なお、保存されたログの解析ソフトとしては、例えば、
Splunk App for AWS
https://splunkbase.splunk.com/app/1274/
とかが提供されていたりします。
必要に応じて利用を検討してみるのも良いでしょう。
    5. 開発者ならCLI(Command Line Interface)をインストール

コンソール画面から色々出来ますが、コマンドラインでも使えるようにしておきましょう。

公式文章: http://aws.amazon.com/jp/cli/

にWindowsとMacそれぞれのインストール方法が書いてあります。
sudo easy_install pip;
pip install cli
駄目だったら
curl "https://s3.amazonaws.com/aws-cli/awscli-bundle.zip" -o "awscli-bundle.zip"
unzip awscli-bundle.zip
sudo ./awscli-bundle/install -i /usr/local/aws -b /usr/local/bin/aws

ユーザーを作る時に使った認証情報を入力していきます。
まず使いたいユーザーについて、IAMの画面でユーザーを選んで、アクションからアクセスキーの作成を選んで、後で入力する情報を入れておきます。

そして以下のコマンドを打ちます。
aws configure

以下のような事が聞かれるので入れていきます。
AWS Access Key ID [None]: ...
AWS Secret Access Key [None]: ...
Default region name [None]: ap-northeast-1
Default output format [None]: json

後、結果がJSONで返ってきますが、それをパースして見易くする為、macだったら
brew install jq;

CentOSだったら
sudo yum install jq;
と打って、jqというソフトを入れておきましょう。

また、EC2をコマンドラインから作成する為には、EC2の画面に行って、左メニューから「キーペア」を選んで、キーペアを作って、.pemファイルを保存しておきます。
このファイルを使って、自分が作ったEC2サーバーに後で入れるようになります。
    6. AWSルートアカウントでのMFA(AWS Multi-Factor Authentication)の設定

IAMでユーザーを作ったのではない、元々のAWS契約したアカウントをAWSルートアカウントと言いますが、そこはセキュリティ上の急所なので、MFAという認証の仕組みを導入しておきましょう。
      1. 設定

IAMで作った画面からではなく、最初の操作で使っているアカウント(仮にrootアカウントと言いましょう)については、画面にパスワードを破られて入られたら、いくらサーバー側のセキュリティがあっても無駄なので、

http://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/GenerateMFAConfigAccount.html

を参考に、スマホの中のアプリの番号がログインした後に更に必要になるようにしましょう(AMF: AWS Multi-Factor Authentication=多重認証)。

スマホの中のソフトで管理出来る、仮想MFAの手順を見てください。
サーバー自体のセキュリティとは別に、Webコンソール画面のセキュリティも重要です。
そこを設定せず破られて、勝手に仮装サーバーを立ち上げられBitcoin掘りに使われて、とんでもない金額が請求された、といった事も起きています。

ただ、MFAの仮想デバイス(という名のアプリ)のGoogle Autheticatorとかは、スマホを無くしたら終わりです。
無くすリスクの方が大きく見えてしまうので、バックアップが欲しいですね。
そういう時の為のアプリとしては「Authy」というアプリがお勧めです。
インストールして、バックアップをとるという設定を選んで、QRコードの写真を撮っておきましょう。
既に他の仮想デバイスでやってしまった場合は、一旦MFAを削除して、また作り直せば、またQRコードを撮る手順に戻れます。
Authyの場合、携帯を無くした後、新しく同じ番号の電話を何とかゲットして、またAuthyを入れ直すと、前に登録していたメールアドレスの方に確認メールが来るので、そこからSMSまたは電話認証をすると、これまでのデータを復元できます。
      2. コマンドライン(CLI)での操作

・登録されてるものをリストで見る
aws iam list-virtual-mfa-devices;

なお、最初のrootとなるアカウントのMFAは、iphoneとか無くしたらコマンドラインからでも後後どうにもできなさそうなので注意。
それ以外のユーザーのMFAはコマンドラインから解除する方法もあります。
    7. IAM(Identity & Access Management)

公式文章: http://aws.amazon.com/jp/iam/
      1. 説明

利用開始時から活用するように。
IDについてはSAMLでActive DirectoryやLDAPで連携が出来る所まで構築出来ると素晴らしいけれども、最初はそういうのはないでしょうから、まずきちんとユーザー登録・権限管理をしていきましょう。

グループ・ポリシーの設定には、良い設計が必要。
フェーズの進行に従って、定期的に最適な構成が何か、というのは見直しましょう。

端的に言えば、最初のAWSコンソール画面から入るのは、AWSルートアカウントという急所のアカウントになるので、基本はそれとは別にそれぞれユーザーアカウントを作って(ログイン画面も別のURLになります)、適宜権限調整をしていく事になります。
その仕組みの事をIAMと捉えて頂いて良いかと思います。
      2. IAMのベストプラクティス10

1. AWSアカウントのアクセスキーをロック
2. 個々にIAMユーサを作成
3. 特権ユーサにはMFA
4. 強度の高いハスワート
5. 最小限の特権
6. EC2て動作するアフリにはIAMロール
7. ホリシー条件を使いこなす
8. ローテーション
9. アカウント履歴の監査
10. 不要な認証情報の削除

http://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/IAMBestPractices.html
が参考になる。
      3. Adminsグループの設定

https://console.aws.amazon.com/iam/

ナビゲーションペインで、[グループ] をクリックし、[新しいグループ] をクリック
[グループ名] ボックスに、Adminsと入力し、[次のステップ] をクリック
ポリシーのリストで、例えば AdministratorAccess ポリシーの横にあるチェックボックスを選択
[次のステップへ] をクリックし、[グループの作成] をクリック。
      4. ユーザーの追加

IAM ユーザーを作成するには、管理者グループにユーザーを追加し、ユーザーのパスワードを作成。

ナビゲーションペインで [ユーザー] をクリックし、続いて [新規ユーザーの作成] をクリックします。
ボックスにユーザー名を入力。
API経由での各種操作を許可しないのなら、[ユーザーごとにアクセスキーを生成] の横にあるチェックボックスをオフにする。
[作成] をクリック。
コマンドラインでの操作等が予測される場合には、ここで必要に応じて、認証情報を保存しておきましょう(後で作り直しも可能ですが)。

ユーザーのリストで、作成したユーザーの名前(チェックボックスではない)をクリック。
[グループ] セクションで、[Add User to Groups] をクリックします。
加えたいグループ(例えばAdmins) グループの横にあるチェックボックスを選択し、[Add to Groups] をクリック

[認証情報] と書いてある所まで下へスクロール。
[サインイン認証情報] で、[パスワードの管理] をクリック
[カスタムパスワードの割り当て] を選択し、[パスワード] ボックスと [パスワードの確認] ボックスにパスワードを入力。完了したら、[適用] をクリック。
企業で使うのなら、こちらで登録されたユーザーも、それぞれMFAの設定をしてもらうようにしましょう。
      5. IAMで作ったユーザーへのログイン画面の提供

IAMでユーザーを作ったといっても、ログインする画面はAWSのアカウントを作ったものと同じではありません。
他の方も使っていると考えるとユーザーIDにはユニーク性がないですからね。

「Identity and Access Management」
をクリックしたら出てくる、「IAM ユーザーのサインインリンク」という所に書いてあるURL、
または、右上からサポート→サポートセンター
と行って、そこに表示されるアカウント番号を使って、
https://アカウント番号.signin.aws.amazon.com/console
で作るURLが、IAMのユーザーのログイン画面として使えます。

新たに追加したIAMのユーザーには、IDと仮に設定したパスワードと合わせて、そのURLの情報を共有しましょう。
また、自分の方でも、どこにメモしておきましょう。
      6. その他必要なグループの作成・整備

例えば

Admins
AllUsers
Developers
Designers
Testers
Managers
SysAdmins

を作って、それぞれに必要なポリシーを割り当てましょう。
各従業員用ユーザーを作成し、各グループに割り当てます。
さらに全ユーザーを AllUsers グループに割り当てます。
      7. プロバイダの設定

これを活用する事で、SAML経由でのActive Directory / LDAPとの連携とかが出来るようになる筈です。


      8. CLI(コマンドラインインターフェース)での設定

ここは後述する
コンソール画面からではなく、後述するCLI(コマンドラインインターフェース)から設定する場合には以下のようにやります。

・IAMのグループ生成
aws iam create-group --group-name Admins;

・グループの確認
aws iam list-groups;
で確認。

・ポリシーの適用
aws iam attach-group-policy --group-name Admins --policy-arn arn:aws:iam::aws:policy/AdministratorAccess

・ポリシーの適用状況の確認
aws iam list-attached-group-policies --group-name Admins

・グループの削除(本当に必要なのを消さないように)
aws iam delete-group --group-name Admins;

・「ican」というユーザーを追加
aws iam create-user --user-name ican

・「ican」というユーザーを「Admins」グループに追加
aws iam add-user-to-group --user-name ican --group-name Admins;

・「ican」というユーザーのアクセスキーを作成
aws iam create-access-key --user-name ican;

・ユーザー一覧確認
aws iam list-users;

    8. VPC (Virtual Private Cloud)

公式文章: http://aws.amazon.com/jp/vpc/
      1. 構成のベストプラクティス

ここの構成はセキュリティ上かなり重要ですが、まずはセオリー通りの構成から始めてみましょう。

セオリーとは?
1) Production(本番環境)
2) Staging(検証環境)
3) Development(開発環境)
4) Management(管理用環境)
一つのリージョンに4つのVPC。
Production、Staging、Developmentは相互には通信出来ないように独立させる。


VPCの中は
1) Public

2) Private

3) Secure
の3階層に捉えてセキュリティを分ける。

      2. VPCの設定

まず、デフォルトで存在するVPCについては、特に初心者の場合、後々でその設定との照らし合わせ参考の為にも残しておく。

上記の図の設計に基づいて新たに4つのVPCを作る。
例えば
prod: 10.0.0.0/16
stg: 10.1.0.0/16
dev: 10.2.0.0/16
admin: 10.3.0.0/16

なお、アカウントが異なれば、同じ範囲のVPCを作れますが、異なるアカウント間のVPC間で通信をする為には、それが重ならないようにしないといけません。
そこだけ必要に応じて調整して設定しないといけません。
仕組み的にはVPCピア接続 http://docs.aws.amazon.com/ja_jp/AmazonVPC/latest/UserGuide/vpc-peering.html と呼ばれるものになります。


ちなみに、VPCピア接続でのVPC間通信には、残念ながら費用がかかってしまうので、そこは考えつつシステム構成を作る必要があります。
      3. サブネット

ネットマスクとサブネットの関係を見ながら設定する。
IP/CIDRマスクホスト数
a.b.c.d/32255.255.255.2551
a.b.c.d/31255.255.255.2542
a.b.c.d/30255.255.255.2524
a.b.c.d/29255.255.255.2488
a.b.c.d/28255.255.255.24016
a.b.c.d/27255.255.255.22432
a.b.c.d/26255.255.255.19264
a.b.c.d/25255.255.255.128128
a.b.c.0/24255.255.255.000256
a.b.c.0/23255.255.254.000512
a.b.c.0/22255.255.252.0001,024
a.b.c.0/21255.255.248.0002,048
a.b.c.0/20255.255.240.0004,096
a.b.c.0/19255.255.224.0008,192
a.b.c.0/18255.255.192.00016,384
a.b.c.0/17255.255.128.00032,768
a.b.0.0/16255.255.000.00065,536

例えば、

VPC: dev: 10.2.0.0/16
にサブネットを作るのなら、
subnet1: 10.2.0.0/24
subnet2: 10.2.1.0/24
subnet3: 10.2.2.0/24

VPC: 10.0.0.0/21
にその範囲を使い切る形でサブネットを8つ作るのなら
subnet1 10.0.0.0/24
subnet2 10.0.1.0/24
subnet3 10.0.2.0/24
subnet4 10.0.3.0/24
subnet5 10.0.4.0/24
subnet6 10.0.5.0/24
subnet7 10.0.6.0/24
subnet8 10.0.7.0/24

VPC: 10.0.0.0/24
にその範囲を使い切る形でサブネットを4つ作るのなら
subnet1 10.0.0.0/26
subnet2 10.0.0.64/26
subnet3 10.0.0.128/26
subnet4 10.0.0.192/26

といった感じで作る。
なお、vpcにはIDが振られますが、どれがどれだかそれを見てるだけだと分からないので、名前を実際につけておくようにしましょう(VPCの一覧画面で選んで設定する事が出来る)。

あと、もう問題ないな、となったら、デフォルトでAWSから用意される形で存在するVPCは破棄してしまって問題ありません。
    9. セキュリティグループ

VPCのSubnetに対して、それぞれどこからどの通信を許可するといった設定を行う。
VPCをproduction用、subnetをpublic, pribate, secureという形で切っていたら、そのパターンのセキュリティグループを作れば良い。
例えば、
productionのpublicネットワークは、ポート80(http),443(https)を全てのアクセス元に対して開放、privateはpublicのサブネットの領域からのアクセスについてはは全て開放、secureはprivateからのアクセスについては全て開放、といった形でルールを作っておき、それぞれのサブネットで立ち上げられるインスタンスにルールを適用する。
      1. インターネットゲートウェイ

インターネットに繋げる為には「インターネットゲートウェイ」で作成を押して、既存のインターネットゲートウェイを参考にして作り、作ってあるVPCに「アタッチ」する(くっつける)。

それからルートテーブルで、インターネット接続させたいVPCを選んで、ルートを選んで、編集を押し、そこから別ルートの追加を押し、
0.0.0.0/0
を入れて、後は先に作ったインターネットゲートウェイを選ぶ。

そうすると、後でEC2インスタンスを作っている場合、sshで接続出来るポートが開く。
      2. コマンドラインターフェース(CLI)経由の操作

・prod, dev, stg, admin用に4つのVPCを作る
aws ec2 create-vpc --cidr-block 10.0.0.0/16;
aws ec2 create-vpc --cidr-block 10.1.0.0/16;
aws ec2 create-vpc --cidr-block 10.2.0.0/16;
aws ec2 create-vpc --cidr-block 10.3.0.0/16;

もっと小さく作るのなら(例えば10.0.0.0の範囲縛りで作る&サブネットは/24で切る&1つのVPCに8つのサブネットを作ると考えるのなら)
aws ec2 create-vpc --cidr-block 10.0.0.0/21;
aws ec2 create-vpc --cidr-block 10.0.8.0/21;
aws ec2 create-vpc --cidr-block 10.0.16.0/21;
aws ec2 create-vpc --cidr-block 10.0.24.0/21;

・VPCのリスト情報を得る
aws ec2 describe-vpcs;

・VPCのタグの名前で絞り込むんでvpcidを得る
aws ec2 describe-vpcs | jq -r '.Vpcs[] | select(.Tags[].Value=="Dev") | .VpcId'

・10.0.0.0/16に対しpublic, private, secure用サブネットを作る
aws ec2 create-subnet --vpc-id $VPCのID --cidr-block 10.0.0.0/24 --availability-zone ap-northeast-1c;
aws ec2 create-subnet --vpc-id $VPCのID --cidr-block 10.0.1.0/24 --availability-zone ap-northeast-1c;
aws ec2 create-subnet --vpc-id $VPCのID --cidr-block 10.0.2.0/24 --availability-zone ap-northeast-1c;

なお、ロードバランサーを使う時には、複数のAvailability Zoneの利用が求められるので、上記に対応する別ゾーン用として
aws ec2 create-subnet --vpc-id $VPCのID --cidr-block 10.0.100.0/24 --availability-zone ap-northeast-1a;
aws ec2 create-subnet --vpc-id $VPCのID --cidr-block 10.0.101.0/24 --availability-zone ap-northeast-1a;
aws ec2 create-subnet --vpc-id $VPCのID --cidr-block 10.0.102.0/24 --availability-zone ap-northeast-1a;
といったのも作っておく。

・Subnetのリスト情報を得る
aws ec2 describe-subnets;

・上で作ってあるサブネットにタグ付けして名称をつけておく
aws ec2 create-tags --resources $サブネットID0 --tags Key=Name,Value=public1
aws ec2 create-tags --resources $サブネットID1 --tags Key=Name,Value=private1
aws ec2 create-tags --resources $サブネットID2 --tags Key=Name,Value=secure1

aws ec2 create-tags --resources $サブネットID100 --tags Key=Name,Value=public2
aws ec2 create-tags --resources $サブネットID101 --tags Key=Name,Value=private2
aws ec2 create-tags --resources $サブネットID102 --tags Key=Name,Value=secure2

・インターネットゲートウェイの作成
aws ec2 create-internet-gateway;

・インターネットゲートウェイ一覧を見てインターネットゲートウェイIDの情報を得る
aws ec2 describe-internet-gateways;

・インターネットゲートウェイをVPCに結びつける
aws ec2 attach-internet-gateway --internet-gateway-id $インターネットゲートウェイID --vpc-id $VPCのID;

・ルーティングテーブルリスト一覧を見てルートテーブルIDの情報を得る
aws ec2 describe-route-tables | jq '.RouteTables[] | {RouteTableId, VpcId, Routes}'

・インターネットゲートウェイとルーティングテーブルを結びつける
aws ec2 create-route --route-table-id $ルートテーブルID --destination-cidr-block 0.0.0.0/0 --gateway-id $インターネットゲートウェイID

    10. EC2

公式文章: http://aws.amazon.com/jp/ec2/
      1. EC2の特徴

EC2はECって電子取引...?と思い浮かべてしまうかもしれませんが、Elastic Compute Cloudの略で、AWSにおける仮想サーバーになります。

E = Elastic
C2 = Compute Cloud

という事ですね。

つまり、オンプレのサーバーとかをそのまま移行するのなら、これを使う事になります。
性能によって金額は異なっています。

CPU的には以下のようになっています。
H51Xeon プロセッサーファミリーストレージ最適化
G2Xeon E5-2670 
T2Xeonプロセッサーファミリーバースト機能有り。切らすと低能
M3Xeon E5-2670 v2バランス
M4Xeon E5-2676 v3バランス取れててより高性能
I2Xeon E5-2670 v2I/O最適化
R3Xeon E5-2670 v2メモリー最適化
C3Xeon E5-2680 v2コンピューティング最適化
C4Xeon E5-2666 v3最高性能

      2. EC2の性能: T2シリーズの場合


1年無料の対象となるのはT2 microですが、T2シリーズは一定時間はCPUバーストといって100%の状態で使えますが、使い切るとガクンと性能が落ちてしまうという特徴があります。

Unix Benchの結果
AWS t2 micro(1コア/1G/Ubuntu14/CPUバースト非使用時)227CPUバーストを使い果たすと最低レベルになる
AWS t2 micro(1コア/1G/Ubuntu14/CPUバースト時)1920CPUバースト出来る限りは素晴らしい

T2の各モデルを見てみると、以下のような説明が書いて有ります(意味が分かり易いように言葉を書き換えています)。

モデルvCPU1時間に回復出来るバースト用時間(分)最大貯められるバースト用時間(分)バースト時間を使い果した時に使えるCPU率メモリ(GiB)
t2.nano13分72分コアの5%0.5
t2.micro16分144分コアの10%1
t2.small112分288分コアの20%2
t2.medium224分576分コアの40%4
t2.large236分864分コアの60%8

t2.microは最初の一年は無料ですし、安いですが、CPUバースト時間を使い果たすと、性能が1/10になってしまうので、そこら辺は怖い所ですね。
バースト用時間を使い切らないか心配になるかと思いますが、価格帯性能比で言えば一応t2.microがベストという事になります。
      3. EC2の性能: M3シリーズの場合

CPU、メモリのバランスが良い仮想サーバーです。
モデル vCPUメモリ(GiB)SSD ストレージ(GB) 
m3.medium13.751 x 4
m3.large27.51 x 32
m3.xlarge4152 x 40
m3.2xlarge8302 x 80

これらはEC2のように、CPUバーストがない代わりに、落ちる事もありません。
安定してずっと使いたい、という時にはm3とかは利用候補になるかと思います。

Unixbenchの結果
m3.medium840

出来ればm3以上を使いたいけど、お値段の割には性能低いなぁ、と「2015年VPS比較(ベンチマーク)」を見ていると思ってしまうかもしれませんが。
なので、仮想サーバーにあたる「EC2だけ使う」という場合には、必ずしもAWSはベストとは言えないという事は見えるかなと思います。
ELBやS3やRDS、VCL/IAMなどと組み合わせて活用する事で、その価値が生まれます。
      4. EC2の性能: 全シリーズの一覧(オンデマンドの価格モデル)

出来れば良いサーバーを使いたいですね。
しかし、サーバーの性能に比例して、お値段は上がります。
性能だけではなく、お財布の事も考えて、どのタイプを使うのかを決めしょう。
以下、1ドル125円で計算した結果です。
ドル払いなので、円相場の変動の影響を受けます(円安なら費用が上がり、円高なら費用が下がる)。
1年に1回位は値段が下がる事があります。

タイプvCPUECUメモリ(GiB)インスタンスストレージ(GB)料金/1時間(ドル)料金/30日(円) 
一般的な目的  現行世代       
t2.nano0.5可変1EBS のみ$0.0101.2864
t2.micro1可変1EBS のみ$0.0202.41728
t2.small1可変2EBS のみ$0.0405.03456
t2.medium2可変4EBS のみ$0.08010.06912
t2.large2可変8EBS のみ$0.16020.013824
m4.large26.58EBS のみ$0.17422.916470
m4.xlarge41316EBS のみ$0.34845.832940
m4.2xlarge82632EBS のみ$0.69591.565880
m4.4xlarge1653.564EBS のみ$1.391183.0131760
m4.10xlarge40124.5160EBS のみ$3.477457.5329400
m3.medium133.751 x 4 SSD$0.09612.08640
m3.large26.57.51 x 32 SSD$0.19324.117370
m3.xlarge413152 x 40 SSD$0.38548.134650
m3.2xlarge826302 x 80 SSD$0.77096.369300
コンピューティング最適化  現行世代       
c4.large283.75EBS のみ$0.13317.512600
c4.xlarge4167.5EBS のみ$0.26534.925110
c4.2xlarge83115EBS のみ$0.53169.950310
c4.4xlarge166230EBS のみ$1.061139.6100530
c4.8xlarge3613260EBS のみ$2.122279.3201060
c3.large273.752 x 16 SSD$0.12816.011520
c3.xlarge4147.52 x 40 SSD$0.25531.922950
c3.2xlarge828152 x 80 SSD$0.51163.945990
c3.4xlarge1655302 x 160 SSD$1.021127.691890
c3.8xlarge32108602 x 320 SSD$2.043255.4183870
GPU インスタンス  現行世代       
g2.2xlarge8261560 SSD$0.898112.380820
g2.8xlarge32104602 x 120 SSD$3.592449.0323280
メモリの最適化  現行世代       
r3.large26.5151 x 32 SSD$0.226.318900
r3.xlarge41330.51 x 80 SSD$0.39952.537800
r3.2xlarge826611 x 160 SSD$0.798105.075600
r3.4xlarge16521221 x 320 SSD$1.596210.0151200
r3.8xlarge321042442 x 320 SSD$3.192420.0302400
ストレージの最適化  現行世代       
i2.xlarge41430.51 x 800 SSD$1.001125.190090
i2.2xlarge827612 x 800 SSD$2.001250.1180090
i2.4xlarge16531224 x 800 SSD$4.002500.3360180
i2.8xlarge321042448 x 800 SSD$8.0041000.5720360
d2.xlarge41430.53 x 2000 HDD$0.844105.575960
d2.2xlarge828616 x 2000 HDD$1.688211.0151920
d2.4xlarge165612212 x 2000 HDD$3.376422.0303840
d2.8xlarge3611624424 x 2000 HDD$6.752844.0607680

なお、
Linuxhttp://a0.awsstatic.com/pricing/1/ec2/ri-v2/linux-unix-shared.min.js
RHELhttp://a0.awsstatic.com/pricing/1/ec2/ri-v2/red-hat-enterprise-linux-shared.min.js
SUSEhttp://a0.awsstatic.com/pricing/1/ec2/ri-v2/suse-linux-shared.min.js
Windowshttp://a0.awsstatic.com/pricing/1/ec2/ri-v2/windows-shared.min.js
Windows with SQL Serverhttp://a0.awsstatic.com/pricing/1/ec2/ri-v2/windows-with-sql-server-standard-shared.min.js
Windows with SQL Server Web Sharedhttp://a0.awsstatic.com/pricing/1/ec2/ri-v2/windows-with-sql-server-web-shared.min.js
データ通信http://a0.awsstatic.com/pricing/1/ec2/pricing-data-transfer-with-regions.min.js
にアクセスする事で、JSON形式で価格の情報を得る事が出来ます。
後述するスポットインスタンスを利用するプログラムを作る時に役立つでしょう。
      5. リザーブドインスタンスという価格モデル

リザーブドインスタンス
http://aws.amazon.com/jp/ec2/purchasing-options/reserved-instances/
といって、年 or 3年契約といった長期契約をすると、かなり大きな割引がされる契約もありますが、ある意味クラウドの柔軟性&後々の進化の可能性を犠牲にする事にもなるので、そこら辺は最初は契約せず、本当にずっとそのまま使っていくという目処が見えたら、リザーブド契約をすると良いでしょう。
      6. スポットインスタンスという価格モデルと仕組み

入札的なものによって値段が決まるスポットインスタンスという買い方もあります。

http://aws.amazon.com/jp/ec2/purchasing-options/spot-instances/

価格は、オンデマンドの価格の14%~1000%。

入札価格 >= 変動価格

の間は使えますが、

入札価格 < 変動価格

になると、インスタンスの利用が強制終了させられます。
起動時に「入札価格 < 変動価格」なら、起動させる事は出来ません。

また、インスタンスの立ち上げも、入札といフェーズを経るので、オンデマンドとか(3分位)より起動時間がかかります(7分位)。

1000%とか高くなっているのに何で払うの?と思うかもしれませんが、一度起動してしまったインスタンスの強制終了を避ける為に、そういう入札仕合での極地としてそういうことになります。
なお、上限の1000%になったら、インスタンスの奪い合いは張り合っている相手とはお金の叩きつけ合いでは決着を付けられないという事で、そのインスタンスが死ぬか生きるかは運次第となります。

こうした特性があるので、何の工夫もなく使う事はできませんが、CLIで条件をスポットインスタンスを使う状況について上手くプログラミングすれば、通常より安く使う事ができます。
「Infrastructure as code」をベタで行く領域になります。
継続的な保障レベルが必要なサービス(Webサービス)には余り向かないかと思いますが、BIの解析系等バッチ系処理で上手く使えば、費用を大きく抑えるのに活用できます。

なお、価格はリージョン内で統一ではなく、アベイラビリティゾーン毎に値段が違うという特性があります。
例えば同じタイプのインスタンスでも一時間あたりの費用が
ap-northeast-1a0.1336
ap-northeast-1c0.8981
という差が出たりします。

なお、t2シリーズは選ぶ事が出来ません。

あと、実情として、比較的低位のプランの方が価格は安定していて、高位のプランの方が価格のボラティリティが激しい&高くなり気味という傾向があります。

解析系での活用事例として参考になるスライドを紹介させて頂きます。

まさに外道

なお、価格は
Spot Instance(直近5分)http://spot-price.s3.amazonaws.com/spot.js
からJSON形式で得る事が出来ます。
      7. インスタンスの利用可能数の上限とかを拡張する

デフォルトだと、例えば現在1アカウントで立ち上げれるオンデマンドインスタンスの上限数は20個だったりますが、お問い合わせフォーム
https://aws.amazon.com/jp/contact-us/
からリクエストする事で、その上限を上げる事ができます。
      8. 使うOSの選択

ブラウザーからEC2インスタンスを作る時にはまずOSの選択が求められます。
OSの中でも、Linuxのディストリビューションの選択に迷うかと思いますが、Linux系を使いにあたって主に候補となるディストリビューションには以下のような特徴があります。

Amazon Linuxクイックスタートの中にある。AWSの環境に最適化されてAmazonがメンテナンス。ベースはCentOSなのでyum等が使える。但し他のクラウドサービスなどでは利用出来ないので、ベンダーロックポイントになってしまいかねない事には注意
Ubuntuクイックスタートの中にある。海外ではこちらの方がマジョリティの模様。サポート期間とか無視して、最新版にすれば一般的にかなり最新版に近しいパッケージが利用可能になる。
Cent OSMarketplaceの中にある。Redhat Enterpriseベースで、一つ一つのバージョンのサポート期間が長い。日本のクラウド系サービスではマジョリティ

2015/07時点の各OSディストリビューションのパッケージのバージョン情報
OSkernelfilesystemapachenginxgccnode.jsperlphppythonrubycython
amazon linux3.14.42ext42.4.121.6.24.8.2(epel)0.10.365.16.35.6.92.7.92.0.0p645(epel)0.19.2
ubuntu143.13.0ext42.4.71.4.64.8.40.10.255.18.25.5.92.7.61.9.3p484 
ubuntu15.043.19.0ext42.4.101.6.24.9.20.10.255.20.25.6.42.7.92.1.20.21.1
centos7.13.10.0-229xfs2.4.6N/A4.8.3N/A5.16.35.4.162.7.52.0.00.19

なお、ubuntu15.04には、クイックスタートでインストール出来るubuntu14からOSアップグレードでそこに到達させました。

使い分けのイメージとしては、自分の場合は、
・とにかくなるべく最新版が良い&結果としての最高の性能が欲しい&他クラウドでも使えるようにしたいのならUbuntu
・AWSの中の安定性と最新性のバランスを求めるのならAmazon Linux
・他クラウドでも使えての安定性を求めるのならCentOS
といった使い分け方をイメージしています。

自分の場合は、パッケージは出来るだけ新しい方が良いので、CentOSはペケで、AWSの中でやる限りはとりあえずAmazon Linuxで良いかなと思っていますが、他との絡みも考えるとUbuntuの最新版も捨て難い、という事には一般的になるのではないかと思います。
      9. ブラウザーからの設定方法

まず、.sshのキーがあるなら、後々の手間を減らす為、左メニューのキーペアに、id_rsa.pubの中身を登録しておきましょう。
それを使って、新規に立ち上げるインスタンスにログインできるようになります。

AWS Console画面からEC2を選び、そこで「インスタンスの作成」というボタンを押します。
そこで「Amazon マシンイメージ(AMI)」というもの中で自分の用途と合ったものを選び(OS+その上のソフトのセットイメージ)、仮想サーバーを立ち上げます。
「クイックスタート」「コミュニティ」のAMIは全部無料ですが、「Marketplace」にあるものには、有料のものもあるので気をつけましょう。

そして自分のニーズに合ったOSを選んで立ち上げます。

作る時には、サーバーの役割に応じて先に作ったVPCの中から適切なものと、適切なサブネットを選びます。

最後に作成する時に「キーペア」について新たに作るかどうかと聞かれますが、もしも先に登録していなければそこで作って、それを大切にどこかに保存しましょう。
このファイルを使ってサーバーにsshログインとかします。
壊して無くさないように、PC以外にクラウド的などこかにも置いておくのが良いかとは思います。

例えばクイックスタートでインスタンスを立ち上げている場合、

・Amazon Linuxの場合
ssh -l ec2-user サーバーのIP -i キーペアファイル

・Ubuntuの場合
ssh -l ubuntu サーバーのIP -i キーペアファイル

・CentOSの場合(これはマーケットプレースのCentos.org提供版)
ssh -l root サーバーのIP -i キーペアファイル

で接続できるようになります。
「...too open」
というアラートが出た時には、キーペアファイルのセキュリティ設定が緩すぎる(自分しか見れないようにしないといけない)、ということなので、
chmod 600 キーペアファイル
とファイルの属性を自分しか見れないようにする。
      10. CLIでの操作

・インスタンスリストの確認
aws ec2 describe-instances;

・jqでinstaince idに情報を絞る
aws ec2 describe-instances | jq '.Reservations[].Instances[].InstanceId';

・jqでinstance id, private ip address, public ip address, status, instance nameを得る
aws ec2 describe-instances | jq '.Reservations[].Instances[] | {InstanceId, PrivateIpAddress, PublicIpAddress, State, InstanceName: (.Tags[] | select(.Key=="Name").Value)}'

・jqでrunning中の特定のサブネットID上のインスタンスのPrivate IP addressとPublic IP addressを得る
aws ec2 describe-instances --filter "Name=instance-state-name,Values=running" | jq '.Reservations[].Instances[] | {PublicIpAddress, PrivateIpAddress,SubnetId} | select(.SubnetId=="サブネットID")'

・インスタンスの削除
aws ec2 terminate-instances --instance-ids インタンスID;

      11. Amazon マシンイメージ(AMI)

作ったEC2のインスタンスをイメージとして保存して、その状態を再現する形で新たにインスタンスを立ち上げる事が出来ます。
なので、これから作っていくであろうサーバーのタイプに応じて、ある程度作業を進めたら、AMIを作って保存しておくと良いでしょう。
これはEC2でAMIを作りたいインスタンスを選んで、後はメニューの操作から行う事が出来ます。
なお、作ったAMIは、世の中に共有(有料で販売という形も可能)する事も出来ます。

異なるアカウントで、そこに限って共有したい場合には、

1. AMIを所持している方のアカウントでEC2のAMIを表示
2. 共有するAMIを選択してアクションから「イメージパーミッションの変更」をクリック
3.「AWS アカウント番号」に共有先AWSアカウントのアカウント番号入力して追加してから保存。AWSアカウント番号は右上のサポートセンターのページの右上で確認する事が出来ます。

利用したい側では

1. EC2のAMIを表示(共有元と同じリージョンにする)
2.「Filter」が「Owned By Me」になっている場合は「Private Images」にすると共有されたAMIが表示される
3. EC2を作る際も、AMI選択画面で「マイAMI」の「自分と共有」を選択すれば共有されたAMIが選択出来る
      12. swapfile

t2 microとかEBSしか利用出来るディスクがないサーバーの場合、swap領域がありません。
なので、そういう場合には自分で作る必要があります。

sudo dd if=/dev/zero of=/swapfile bs=1M count=1024
sudo chmod 600 /swapfile;
sudo mkswap /swapfile;
sudo swapon /swapfile;

それからvi /etc/fstab
<code>
/swapfile swap swap defaults 0 0
</code>

をfstabに追加。
一列目はLabelまたはpathなのでこの書き方でAmazon Linuxでは問題なし。
      13. Elastic IP

EC2は再起動する度にIPアドレスが変わってしまいます。
それでは困るという場合には、Elastic IPと呼ばれる仕組みで、IPアドレスを取得し、それをEC2のインスタンスに割り当てる事で、固定のIPアドレスにEC2のIPアドレスを変える事が出来ます。
EC2の設定の左メニューの中にあります。

なお、利用には価格がかかりますが、JSON形式ですと
EIPhttp://a0.awsstatic.com/pricing/1/ec2/pricing-elastic-ips.min.js
で得る事が出来ます。
      14. EC2をWebコンソールから作る時に提示されるボリューム追加 / EBS (Elastic Block Store)

EBS (Elastic Block Store)は、

・レプリケートされるので冗長化は一般的に不要。
・ネットワークストレージ
・セキュリティグループによる通信制御の対象外

という性質があり、EC2でマウントする形で使えるようになるディスク領域です。

アクセス速度・価格に応じて、3タイプのものを選ぶ事が出来ます。
ボリュームタイプEBS 汎用(SSD)EBS プロビジョンド IOPS(SSD)EBS マグネティック
ユースケースブートボリューム、小/中規模 DB、開発とテストI/O 集約型、リレーショナル DB、NoSQL DBデータアクセス頻度が低い
ストレージメディアSSD タイプSSD タイプ磁気ディスクタイプ
最大 IOPS/ボリューム1万件2万件40~200
月ドル価格(tokyo 2015)$0.12/GB$0.142/GB、$0.074/IOPS あたり$0.080/GB、$0.080 /100万I/O リクエスト
月園価格(tokyo 2015)15円/GB17.75円/GB、9.25円/IOPS あたり10円/GB、10円/100万I/O リクエスト
※125円/ドルのレートで計算

Json形式で現在価格を得る事も出来ます。
EBS 汎用(SSD)http://a0.awsstatic.com/pricing/1/ebs/pricing-ebs.min.js
EBS プロビジョンド IOPShttp://a0.awsstatic.com/pricing/1/ec2/pricing-ebs-optimized-instances.min.js

なお、これを使っていないと、インスタンスを停止・削除をすると、データは消えてしまいます。

なお、途中から容量を増やしたい場合には、EC2を停止し、EBSのスナップショットを作り、そのスナップショットを選択した状態で容量を増やしたデバイスを作る。
EC2から以前使っていたEBSをデタッチし、新しく作ったデバイスを目的のEC2にアタッチします。
その時ボリューム名の設定が必要ですが、適切なデバイス名を設定する必要があります。
    11. Elastic Load Balancer (ELB)


公式文章: http://aws.amazon.com/jp/documentation/elasticloadbalancing/
      1. 価格

項目ドル/時円/時円/月
Elastic Load Balancing 時間(または 1 時間未満)あたり$0.0273.24円2333円
Elastic Load Balancing によって処理されるデータ 1 GB あたり$0.0080.96円691円

      2. 設定方法

ロードバランサーを使って、それを通してEC2のサーバーにアクセスさせるようにする事が出来ます。
EC2の左メニューの中にロードバランサーというのがあるので、そこから選びましょう。
また、この時複数のAvailability Zoneのサブネットを選ぶ必要があるので、注意しましょう。
結びつける用のEC2も用意しておきます(後から追加で結びつける事もできますが)。
また、生き死にチェック用のURLパスも、必要に応じて編集しておきます(デフォルトは「/index.html」です)。

なお、Health Checkのプログラムは、ELBをRoute 53のドメインと結びつけていると、そのドメインでアクセスしてきますが、大元のドメインでアクセスしてくるだけで、個別に結びつけたドメイン、つまりはサブドメインの場合、SDRT7890-^\
Q
      3. SSL証明書の設定

LBを使う時には、SSL証明書はWebサーバーに設定するのではなく、ELBに設定をします。
HTTPSを通す対象として設定しょうとすると、SSL証明書の記入が求められるので、3つの記入欄全て入れて、確実に動くようにしましょう。

チェーンは一番長い中身のファイル、プライベートキーはprivate_keyとかいてあるファイル、証明書はその他のファイル、と覚えておくと良いでしょう。
    12. RDS


      1. 特徴

公式文章: http://aws.amazon.com/jp/rds/

MySQL等と互換性を得られるRDBM。
Multi AZ構成で高可用性を簡単に得られるのが特徴。

なお、AWSを使っていると、一番高いのはここだという事になり易い。

企業の観点で見れば人件費・セキュリティ費用としてPayはするのでしょうが...高いよ!
まあ、RDBMのマスター依存の仕組み自体が、段々と時代遅れなのだとも言えるかもしれませんが。
      2. 設定方法

まずは、MySQL等、どのタイプのRDBMかを選ぶ事になります。

そして、開発用ではなく、公開するようでしたらば、
「はい、このインスタンスの作成中はデフォルト値として マルチ AZ 配置 と プロビジョンド IOPS ストレージ を使用します」
を選んで、可用性と速度を担保しましょう。

それからインスタンスのタイプや、先に作ってあるサブネット等を選んでいく事になります。

必要なければパブリックアクセス(=インターネットから直接Amazon RDS in VPCにアクセス)は、セキュリティの為許可せず、EC2とかからのみアクセス出来るようにしておきましょう。
因みにパブリックアクセスが可能かどうかは、後から変える事はできません。
実運用をよく考えて決めましょう。

バックアップをとる時間、システムアップデートをする時間を指定できますが、UTC時間で現在は入力が求められます。
UTC時間は9時間プラスした時間が日本時間になりますので(例:UTC時間が1時AMなら日本時間は10時AM)、それを考えて深夜のリクエストが少なそうな時間を、ちょっと時間をずらした形でそれぞれ指定しましょう。

ストレージは、本番で使うものは「プロビジョンド IOPS(SSD)」で良いのではないかと思います。

ボタンを押してからの設定は、EC2とかに比べて時間がかかります。

インスタンスができたらEC2からアクセスしてみましょう。
EC2からアクセス出来ない場合は、セキュリティグループがEC2のIPを許可する設定になっていないかどうか、という点を確認してみて下さい(ブラウザーからの設定だと、デフォルトではその時アクセスしているIPが許可範囲になってしまうので)。
      3. マルチAZの設定について

本番用のRDSの運用では別リージョンにスタンバイとなるRDSを用意しておいて、そのリージョンのRDSへのアクセスに問題が発生した時に、そのスタンバイが使えるRDSに変わるという仕組みです。
実装の仕組みとしては、RDSが死んだ時に、スタンバイDBインスタンスをポイントするようにDBインスタンスのDNSレコードが自動的に変更される、という事なので、RDSヘのDBアクセスについては、提供されているDNSレコード名で行って、IP指定はしないように気をつけておく必要があります。
それが発生する条件は以下の通りになります。

- アベイラビリティーゾーンの機能停止

- プライマリ DB インスタンスのエラー

- DB インスタンスのサーバータイプ変更

- DB インスタンスでソフトウェアをパッチ適用中

- DB インスタンスの手動フェイルオーバーが [Reboot with failover] を使用して開始された
      4. タイムゾーンの設定について

デフォルトはUTC時間で提供されていますが、/etc/my.confが触れるといったものではないので、工夫が必要になります。
dbにマスターアカウントで接続します。
drop procedure mysql.store_time_zone;

DELIMITER |
CREATE PROCEDURE mysql.store_time_zone ()
IF NOT (POSITION('rdsadmin@' IN CURRENT_USER()) = 1) THEN
SET SESSION time_zone = 'Asia/Tokyo';
END IF
|
DELIMITER ;

CALL mysql.store_time_zone;

SELECT NOW();

コマンドラインで
aws rds create-db-parameter-group --db-parameter-group-name=store-time-zone --db-parameter-group-family=mysql5.6 --description=store-time-zone;

aws rds modify-db-parameter-group --db-parameter-group-name=store-time-zone --parameters="ParameterName=init_connect,ParameterValue='CALL mysql.store_time_zone',ApplyMethod=immediate"

aws rds describe-db-instances | jq '.DBInstances[] |{DBInstanceIdentifier,Endpoint}'
でDB InstanceのIDentifierを確認して
aws rds modify-db-instance --db-instance-identifier=DBInstanceIDentifier --apply-immediately --db-parameter-group-name=store-time-zone;

適用が終わったら
aws rds reboot-db-instance --db-instance-identifier=DBInstanceIDentifier
でRDSを再起動。
再起動が終わったら
select now();
で作動を確認。
コンソール画面で見て、パラメーターグループが「再起動の保留中」のままだったら、手動でコンソールから再起動。
      5. スナップショットからのDBの復元

作られているスナップショットを選んで、そこからスナップショットの復元というボタンを押して、DBインスタンスを作る。
      6. インスタンスを削除する時の注意

RDSのインスタンスを削除する時には、いかなる理由があってもインスタンスのコピーはとって削除するようにしましょう。
そのインスタンスのコピーを削除するかどうかは、後で新しいRDSが正常に稼動してから判断しましょう。
    13. ElastiCache

公式文章: http://aws.amazon.com/jp/elasticache/
      1. 設定方法

MemcacheかRedisのどちらかか、インスタンスのタイプに応じたメモリーのサイズを指定。
また複数のゾーンでクラスターするには2ノード以上を指定。
    14. S3

公式文章: http://aws.amazon.com/jp/s3/
      1. 特徴

容量無制限のデータ置き場。
同一リージョン内のEC2間との通信とかは無料だが、外との通信にはGETの回数等でも課金される。
分析環境における最重要ホイントはS3にテータを集約する事。
データ分析はEMR、Sparkとかと組み合わせて行う。
静的ファイル置き場とした上で、ホスティング基盤としても使える。
      2. 料金体系

料金は安いとは言われますが、複雑な課金の仕組みになっているので注意。
以下は東京リージョンの価格です(2015/07時点)。

ストレージ料金表
 スタンダードストレージ低冗長化ストレージGlacier ストレージ
最初の 1 TB/月$0.0330 /GB$0.0264 /GB$0.0114 /GB
次の 49 TB/月$0.0324 /GB$0.0259 /GB$0.0114 /GB
次の 450 TB/月$0.0319 /GB$0.0255 /GB$0.0114 /GB
次の 500 TB/月$0.0313 /GB$0.0250 /GB$0.0114 /GB
次の 4,000 TB/月$0.0308 /GB$0.0246 /GB$0.0114 /GB
5,000 TB/月以上$0.0302 /GB$0.0242 /GB$0.0114 /GB

リクエスト料金表
 料金
PUT、COPY、POST、または LIST リクエスト$0.0047 : 1,000 リクエストあたり
Glacier アーカイブおよび復元リクエスト$0.0571 : 1,000 リクエストあたり
削除リクエスト無料
GET および他のすべてのリクエスト$0.0037 : 10,000 リクエストあたり
Glacier データ復元無料

※ 標準オブジェクトまたは RRS オブジェクトの削除リクエストには料金はかかりません。Glacier にアーカイブされたオブジェクトについては、90 日経過前にオブジェクトを削除する場合、0.0342 USD/GB の料金が日割りで請求されます。

※ Glacier は、データ復元があまり行われず、データが長期間保存されることを想定して設計されています。無料で復元できるのは、1 か月当たり月平均 Glacier 保管量の 5% まで(1 日ごとに案分)です。1 か月間に復元するデータの量がこれを上回る場合は、復元料金(0.0114 USD/GB から)が請求されます。

データ転送料金表
以下の価格は、Amazon S3 に「受信(イン)」/「送信(アウト)」されるデータ転送量を基にしています。
 料金
Amazon S3 へのデータ転送受信(イン) 
すべてのデータ転送受信(イン)$0.000 /GB
Amazon S3 からのデータ転送送信(アウト) 
同じリージョンの Amazon EC2$0.000 /GB
別の AWS リージョン$0.090 /GB
Amazon CloudFront$0.000 /GB
Amazon S3 からインターネットへのデータ転送送信(アウト) 
最初の 1 GB/月$0.000 /GB
10 TB まで/月$0.140 /GB
次の 40 TB/月$0.135 /GB
次の 100 TB/月$0.130 /GB
次の 350 TB/月$0.120 /GB

      3. ブラウザーから使う

ブラウザーから使う時にはバケットを作って、フォルダを作って、そこにファイルをアップロードするといった流れ
      4. コマンドラインを使ってのファイルのアップロード

Linuxの場合は
http://sourceforge.net/projects/s3tools/files/s3cmd/
から最新版のs3cmdをダウンロード。
解凍して
python setup.py install
でインストール。

Macでbrewを入れている場合には
brew install s3cmd
でインストールする事ができます。

ファイルをアップロードする為のコマンドは以下の通り。
s3cmd put -P -rr [ファイル名] s3://[BUCKET]/

# この例でのオプションの意味
# -P : ファイルのパーミッションをPublic Readableに。
# -rr : ストレージタイプをReduced Redundancy Storageに。
といった形でファイルをアップロード。
ファイルはディレクトリでもいけます。

ファイル・ディレクトリをGETするためのコマンドは
s3cmd get s3://[BUCKET]/ファイル名

ファイル・ディレクトリの削除は
s3cmd del s3://[BUCKET]/ファイル名

色々なオプションがコマンドでは利用可能なので
s3cmd --help
で確認してみましょう。
      5. 静的ファイル置き場としてのサイトの公開

バケットをドメイン名で作る。
Route53でそのドメイン名をAliasとして使う形でAレコードを作る。
バケットのポリシーでのアクセス許可について
https://docs.aws.amazon.com/ja_jp/AmazonS3/latest/dev/example-bucket-policies.html
に書かれている適切なものを貼り付ける。
あとはファイルをアップロードして、該当URLにアクセスして確認。
    15. CloudWatch


公式文章: http://aws.amazon.com/jp/cloudwatch/

- AWSリソースの死活、性能、ログ監視
- 取得メトリックスのグラフ化(可視化)
 各メトリックスをベースとしたアラーム(通知)、アクションの設定

多くのAWSサービスの監視が可能。
また、AWSの課金情報の監視も可能。
    16. Simple Email Service(SES)


公式ページ http://aws.amazon.com/jp/ses/

メールを送信するSMTPサーバーとして使えます。
スパムメール判定されるリスクの低減をする事が出来ます。
      1. 設定方法

東京リージョンに2015/07の時点ではないので、一番近いリージョンを右上で設定して選びます(2017/07時点だと「オレゴン」)。
何も設定していないと、登録したメールアドレスに対してでしかメールを送れない&それからしか送れない、ということになるので、その制限の解除の申請がまず必要になります。
「Request a Sending Limit Increase」
から1日で送れるメールの件数の上限を上げる申請をすると、それが承認されると、同時にメールの送信の制限も解除されます。

また、送り元が独自ドメインでroute53でそのネームサーバーを管理している場合、「Identities => Domains => Verify a New Domain」で送信で使うドメインとしての登録と同時に、Dkimの登録もRoute53に連携して行う事が出来ます。

SES専用のIAMユーザが作られますが、その時に得られるsmpt user idとsmpt user passwordを使って、後は公式ページの説明を見ながら、sendmailまたはpostfixの設定をして下さい。

relayをする時には、/etc/hostsの自分のIPの所にそのサービスの該当ドメインと同じものがセットされていると、自分のドメイン宛のメールはlocalhostにメールが来てしまうので、名前はずらしておきましょう。
    17. CloudFront

画像などを配信するコンテンツデリバリネットワークと設定して使います。
世界中にユーザーがいる場合には、ユーザーにより近い所でそれが配信されるので、速度向上面等でユーザー経験向上に役立ちます。
基本的にはs3に置いたファイルに対してCDNとして設定します。
Route53と組み合わせて、簡単にドメイン設定も行えます。
ただ、s3へのファイルのアップロードとは完全には同期していないので、完全に同期する必要があるものには使えない、という点で、画像や清的ファイルの属性に応じて使い分けるのが良いかと思います。
    18. Lambda

画像がアップされたらサムネイル生成等、イベントをトリガーにして独自のコードを実行させるComputeサービス。
リクエストの処理時間に対して課金される。

オンプレ→クラウド→サーバーレス(サバー筐体という概念自体がなくなりサービスになる)

というインフラの未来の方向性を示すサービスの象徴とも言える。
    19. Cloud Search

裏はSolr。
使い所に応じて、形態素解析・Bigramと分かち書きの仕方を使い分ける事が出来る。
オートスケールに対応してるよ。
ユーザー事例: nanapi、chatwork、lancers
    20. DynamoDB

可用性に優れたKVS。
ただし、課金の仕組みがスループットベースであるという事に注意する必要がある(全データなめるとかには向いていない)。
    21. Redshift


      1. AWSサービス間のデータ連携

S3がハブとなり、他のAWSサービスと連携
- MySQL内のレコードをS3にCSV出力 (Talendとか使える)
- CSVファイルをRedshiftにロード
 Webのアクセス・ログをEMRを使って変換
- Redshiftにロード
      2. データを活用するのに使えるAWSネイティブのサービス

- DataPipeline
- Kinesis
- Lambda
    22. デプロイ系サービス

AWSの環境構築を支援するサービスです。
      1. Elastic Beanstalk

公式文章: http://aws.amazon.com/jp/elasticbeanstalk/

オートスケールなサーバー群構成を作るのに使えます。
インスタンスの種類、インスタンスのsubnetでの配置箇所等の指定はしないとなぁ、というのはあるので、単純にボタンだけ押してローンチするのではなく、細かく選べるリンクの方から設定していきましょう。
実際には使わなくても、一回どういう構成・設定でそれはできるのか、という形で見てみるのもありだと思います。
      2. OpsWorks


      3. CodeDeploy


      4. Cloud Formation

サンフルコート&テンフレート:
http://aws.amazon.com/jp/cloudformation/aws-cloudformation-templates/

CloudFormationのワークフロー
1. JSONを編集
2. CloudFormationに JSONファイルをロート
3. スタックの完成

VPCの定義例
CloudFormation
"Resources" : { "VPC" : {
"Type" : "AWS::EC2::VPC", "Properties" : {
"CidrBlock" : “10.0.0.0/16",
"Tags" : [ { "Key" : “Name", "Value" : “VPCName“ } ] }
},
"PublicSubnet" : {
"Type" : "AWS::EC2::Subnet", "Properties" : {
"VpcId" : { "Ref" : "VPC" }, "CidrBlock" : “10.0.1.0/24",
} }
}
"Tags" : [ { "Key" : "Network", "Value" : "Public" } ]
}
}
}

      5. AWS CLI


公式文章: http://aws.amazon.com/jp/cli/

既に何度か上で記述してありますが、コマンドラインでAWSは操作できるので、それをshellとして記録をしておけば、環境構築の使い回しに活用できます。
個人的には、AWS CLIのSDKとかも組み込まれていると思われるAnsible
http://docs.ansible.com/guide_aws.html
で環境構築は行っています。
    23. Trusted Advisor

公式文章: https://aws.amazon.com/jp/premiumsupport/trustedadvisor/

構成について、費用面等含めて、自動的なチェック&アドバイスをしてくれます。
有料版だとチェックポイントが増えます。
    24. Machine Learning

公式文章: http://aws.amazon.com/jp/machine-learning/
      1. 特徴

・機械学習の導入を非常に容易にしてくれる。
機械学習やそのためのシステムについての専門家かいなくても可能。
Amazon本家サイトで鍛えられた技術の粋が利用可能。
・S3やRedshiftにテータかあれはすくにても使いはしめることかてきる。

Amazonか提供するアルコリスム
 利用者は自分てアルコリスムの実装や詳細な チューニンクを行う必要かない
ハッケーシサーヒスとしての提供
 必要なワークフローか予め提供されている
スケーラヒリティ
 利用者はシステムの拡張やその運用について も考える必要かない
      2. 取り扱える予測モテルとアルコリスム

取り扱える予測モテルとアルコリスム
二項分類: ロジスティック回帰
多クラス分類: 多項式ロジスティック回帰
回帰分析: 線形回帰
      3. 予測手法

・バッチ予測
・リアルタイム予測
      4. 使い方

1. 教師用/評価用テータを準備
2. モテルを作成(学習、トレーニンク)
3. モテルの品質評価
4. 実際の予測の実施
      5. 現在利用可能なリージョン

・us-east-1のみ
・ただし他のリージョンのS3も利用可能
Tokyoリージョンに来るのが待たれます。
      6. バッチ予測の流れ

データ on S3 => EMRで処理 => 処理済みデータ on S3 => Machine Learning => 予測データ on S3
    25. AWS Codecommit


      1. 特徴

公式文章: http://docs.aws.amazon.com/codecommit/latest/userguide/welcome.html

今の所大した機能はないけれども、とりあえずgitレポジトリとして使える。
CI連携の機能が拡充されているく予定
      2. 料金体系

無料?と思いきや、そこまでではないけれども、お金はかかる。
CodoCommitはもう利用可能であり、今日から使い始められます!
1アクティブユーザ(一意なIAMユーザやロール、federatedユーザ、またはrootアカウント)あたり1ヶ月$1が課金されます。
各ユーザは10GBのストレージと2,000回のGitリクエスト(pushやpullといったレポジトリのオブジェクト転送)が毎月の利用枠としてあり、各AWSアカウントでユーザにまたがってプールされます。
追加のストレージコストは$0.06/GB/月で、追加のリクエストは1回あたり$0.001です。
      3. 設定方法

公式文章を参考に。

初めて使う時にはまず使うIAMのアカウントでcodecommitの権限を付与する。
また、新しい機能なので、awsのCLIも最新版にアップデートしておく。
pip install awscli --upgrade

その上で、
aws configure --profile CodeCommitProfile
ここで聞かれる情報で、regionについては、東京リージョンに来ていない2015/10時点では
us-east-1
を入れる。

git config --global credential.helper '!aws --profile CodeCommitProfile codecommit credential-helper $@'
git config --global credential.UseHttpPath true

レポジトリを作る時にはCLIで

aws codecommit create-repository --repository-name プロジェクト名 --repository-description "プロジェクトの記述" --region=us-east-1

といった感じでスタートすると良いでしょう。
なお、リージョンは少なくとも今は日本では提供されていないので、現在利用出来るリージョンを指定する必要がある。

後はGitのレポジトリをcloneしてきて、利用を開始する。
git clone https://git-codecommit.us-east-1.amazonaws.com/v1/repos/レポジトリコード

初回のgit pushの時だけは
git push --set-upstream origin master
と打つ。
6. AWS連携外部サービス


    1. 監視サービス

http://newrelic.com/aws
から登録すると、Lite(=ログ1日分/台数無制限)ではなくStandardプラン(=ログ1週間分/台数無制限)が無料で利用できるようになる。
7. 参考文献

「AWS Summit Tokyo 2015」開催レポート

コメントする2個

2.
2015/04/18 AWS > 設定」
[この書込みのみ表示(記事URL紹介用) / 編集 / 削除 / トラバ送信 / 共有分類に追加(タグ付け)]

1. まずはec2から
2. IP割り当て
3. 性能見てみる
4. 自動化(Ansible)

    1. まずはec2から

subnetは1cで
    2. IP割り当て

立ち上がったらelastic ipを割り当てる
    3. 性能見てみる

http://sakuhindb.com/pj/6_B4C9CDFDBFCDA4B5A4F3/20121226.html
を参考に

Version 5.1.3 Based on the Byte Magazine Unix Benchmark

Multi-CPU version Version 5 revisions by Ian Smith,
Sunnyvale, CA, USA
January 13, 2011 johantheghost at yahoo period com

1 x Dhrystone 2 using register variables 1 2 3 4 5 6 7 8 9 10

1 x Double-Precision Whetstone 1 2 3 4 5 6 7 8 9 10

1 x Execl Throughput 1 2 3

1 x File Copy 1024 bufsize 2000 maxblocks 1 2 3

1 x File Copy 256 bufsize 500 maxblocks 1 2 3

1 x File Copy 4096 bufsize 8000 maxblocks 1 2 3

1 x Pipe Throughput 1 2 3 4 5 6 7 8 9 10

1 x Pipe-based Context Switching 1 2 3 4 5 6 7 8 9 10

1 x Process Creation 1 2 3

1 x System Call Overhead 1 2 3 4 5 6 7 8 9 10

1 x Shell Scripts (1 concurrent) 1 2 3

1 x Shell Scripts (8 concurrent) 1 2 3

========================================================================
BYTE UNIX Benchmarks (Version 5.1.3)

System: ip-172-31-22-216: GNU/Linux
OS: GNU/Linux -- 3.13.0-48-generic -- #80-Ubuntu SMP Thu Mar 12 11:16:15 UTC 2015
Machine: x86_64 (x86_64)
Language: en_US.utf8 (charmap="UTF-8", collate="UTF-8")
CPU 0: Intel(R) Xeon(R) CPU E5-2670 v2 @ 2.50GHz (5000.2 bogomips)
Hyper-Threading, x86-64, MMX, Physical Address Ext, SYSENTER/SYSEXIT, SYSCALL/SYSRET
14:34:03 up 17 min, 1 user, load average: 0.21, 0.10, 0.07; runlevel 2

------------------------------------------------------------------------
Benchmark Run: Sat Apr 18 2015 14:34:03 - 15:02:06
1 CPU in system; running 1 parallel copy of tests

Dhrystone 2 using register variables 33106094.2 lps (10.0 s, 7 samples)
Double-Precision Whetstone 4260.8 MWIPS (9.9 s, 7 samples)
Execl Throughput 4818.9 lps (30.0 s, 2 samples)
File Copy 1024 bufsize 2000 maxblocks 1241123.8 KBps (30.0 s, 2 samples)
File Copy 256 bufsize 500 maxblocks 334574.2 KBps (30.0 s, 2 samples)
File Copy 4096 bufsize 8000 maxblocks 3424006.7 KBps (30.0 s, 2 samples)
Pipe Throughput 2452003.5 lps (10.0 s, 7 samples)
Pipe-based Context Switching 362076.4 lps (10.0 s, 7 samples)
Process Creation 15885.8 lps (30.0 s, 2 samples)
Shell Scripts (1 concurrent) 8773.1 lpm (60.0 s, 2 samples)
Shell Scripts (8 concurrent) 1154.8 lpm (60.0 s, 2 samples)
System Call Overhead 4547527.7 lps (10.0 s, 7 samples)

System Benchmarks Index Values BASELINE RESULT INDEX
Dhrystone 2 using register variables 116700.0 33106094.2 2836.9
Double-Precision Whetstone 55.0 4260.8 774.7
Execl Throughput 43.0 4818.9 1120.7
File Copy 1024 bufsize 2000 maxblocks 3960.0 1241123.8 3134.2
File Copy 256 bufsize 500 maxblocks 1655.0 334574.2 2021.6
File Copy 4096 bufsize 8000 maxblocks 5800.0 3424006.7 5903.5
Pipe Throughput 12440.0 2452003.5 1971.1
Pipe-based Context Switching 4000.0 362076.4 905.2
Process Creation 126.0 15885.8 1260.8
Shell Scripts (1 concurrent) 42.4 8773.1 2069.1
Shell Scripts (8 concurrent) 6.0 1154.8 1924.7
System Call Overhead 15000.0 4547527.7 3031.7
========
System Benchmarks Index Score 1919.5
メモリー量が多くない&マルチコアではない等は別として、シングルコアとしては悪くはない
    4. 自動化(Ansible)

AMI(ベースとするイメージ)をまず作ってAMI-idを得る。

https://console.aws.amazon.com/iam/home

で適切な権限のグループを作り、ユーザーを割り当てる

route53にdns設定する

key_nameは
https://ap-northeast-1.console.aws.amazon.com/ec2/v2/home
のキーペアの値

セキュリティグループを設定する
httpが必要なのはhttp、sshが必要ならsshも

pip install boto
./ec2.py --list
export ANSIBLE_HOSTS=`pwd`/ec2.py

aws configure --region ap-northeast-1

コメントする

3.
2015/01/17 AWS > s3」
[この書込みのみ表示(記事URL紹介用) / 編集 / 削除 / トラバ送信 / 共有分類に追加(タグ付け)]

ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"
brew install s3cmd

コメントする
RSS購読
RSS
ブログ表示スタイル
リスト/携帯(QRコード)
画像/動画/音声/リンク
表示開始年月
分類
全て
1.このサイトについて
2.作品DB開発/運用
3.ホームページ制作技術
4.Perl
5.C言語 / C++
6.検索エンジン&SEO
7.サッカー
8.自分のこと
9.Linux
10.旅行
11.思ったこと
12.パソコン
13.Berkeley DB
14.その他技術系
15.企画
16.スマートフォン
17.鑑賞
18.皆声.jpニュース
19.インターネット業界
20.運用マニュアル(自分用)
21.技術系以外実用書
22.料理
23.ALEXA
24.アニメ
25.会計
26.漫画
27.設計書
28.色々サイト作成
29.サーバー
30.自分専用
31.生活
32.OP/ED/PV
33.ゲーム
34.DB整備
35.新規開始作品紹介
36.英語圏の話題
37.大道芸
38.映画
39.PHP
40.ダイエット
41.Mac
42.JavaScript
43.MySQL
44.介護
45.作品DB作品追加作業
46.BI
47.Web API
48.パフォーマンス
49.インターネットの活用方法
50.Riak
51.Androidアプリ開発
52.Cassandra
53.スパム
54.写真
55.iOSアプリ開発
56AWS
57.マーケティング
58.Web漫画
59.法律
60.mongodb
61.開発環境整備
62.Google Apps Script
63.meteor
64.Pentaho
65.Ansible
66.VPS
67.技術書メモ
68.Vagrant
69.Docker
70.dokuwiki
71.Apple Watch
72.Webサービス
73.セキュリティ
74.Elastic Search
75.Wordpress
76.クラウド
77.英語
78.MVNO
79.シンガポール
80.マレーシア
81.管理人さん
82.管理人さん
日記の主な内容
サイト運営/開発
検索エンジン情報
・技術ネタ(Berkeley DB,
Linux, Perl, サイト作成)等

サイト管理
全まとめ
サーバー管理
定期処理状況
開発予定
削除提案
作品追加依頼
OP/ED追加依頼
OP/ED not found
作品提案承認欄

格言 fromスクライド
この世の理は即ち速さ
20年かければ馬鹿でも
傑作小説を書ける

助けられたら助け返す
それが俺のルール

強くなるには
一番弱い考えをする事だ
そしてその考えに反逆する




右側に何か入れてみるテスト


仕事でのサイト
介護DB
Helpyou
Doctor career
Nurse career
上へ ↑上へ 最速検索作品DB皆声