AWSome Day 2018 Tokyo メモ

オープニングセッション：はじめての AWS ～初級者から中級者への道筋。クラウドアーキテクチャの理解を深める～

亀田 治伸

アマゾン ウェブ サービス ジャパン株式会社 マーケティング本部 プロダクトマーケティングエバンジェリスト
クラウド市場の動向、AWS クラウドのメリットや AWS クラウドの最新状況について、事例を交えながらご説明します。

テクニカルエッセンシャル…ハンズオン付きの有償セミナー
↓
AWSomeday…無料、1日に集約

Twitterハッシュタグ #AWSomeday

AWSのビジョン

地球上で、最もお客様を大切にする企業であること

コミットメント

我々はお客様の生活をより楽にします

Amazon Go

レジのないコンビニ
画像認識を中心とした様々なテクノロジーで、手にとった商品を把握
お客様は商品をヒップアップして店を出るだけ

これまではICタグを付与して実現していたが、
ICタグのコストは商品に反映されてしまう

Amazon Robotics

Amazon倉庫の効率化をRobotで行う

日本ではAmazon川崎倉庫で利用中

これまでは注文書をもとに人が商品をピックアップし、箱詰めして発送していた
↓
注文されるとRobotが自動的に商品棚を箱詰め場所まで運んでくるようになった

米国ではドローン配送の実証実験中

Amazon.comインフラ

12/24がピークとなるので、Amazonを支えるクラウドのコンピュートリソースも増やしている

AWSは何ができるのか？

• AWSは汎用的な技術の総合体
• 既存の技術でできるものはAWSでもできる
• AWSではコスト効率を追求してるので、その基盤の上に乗るサービスもコストを抑えることができる

成長 → 低コスト体質・構造 → 低価格 → 顧客体験 → 顧客数 → 出店者 → 品揃え → 顧客体験 → （ループ）

クラウドとは新しいITリソース利用の形

• 初期投資が不要
• 必要な文だけ利用可能
• 変動費

クラウド活用企業のシェア

クラウド利用会社は年々増えている

クラウドを利用すべきかどうかではなく、クラウドとどう向き合うか

AWSの機能改善イノベーションのスピード

現在1,430のアップデートを提供

AWSのグローバルインフラストラクチャ

18のリージョン
11のローカルリージョン
55のアベイラビリティゾーン

東京リージョンでは、4アベイラビリティゾーン

データセンターを跨いだ冗長構成

AWSサービスのSLAは99.99（データセンターを跨いだ2台構成の場合）
1台構成の場合はSLAが適用されないので注意

大阪リージョンが2018年2月13日より利用可能に
※特定のお客様のみに利用を限定
日本のインターネットバックボーンは東京に集中している
大阪ローカルリージョンを利用する場合は、東京を経由せずにアクセスできる経路を確保すること

AZを跨いだ遅延は2m以下
ビックデータ・機械学習の場合以外は問題にならない

クラウドが選ばれる理由

• ビジネスの俊敏性
  必要なインフラが数クリックで手に入る
  これまでは、納品・取り付け・構築…と期間・工数が非常にかかる
  AWSなら数分で必要なITリソースが調達可能
  収益がはっきりしていれば既存の方式でも良かったが、新しい技術を使ったサービスでは収益がわからない
  →ミニマムスタートできる・青天井にならないよう上限を設定できるクラウドが有利

• 125を超えるサービス群
  AWSのサービスを手軽に利用可能
  AWSサービスへのロックインが問題になる場合は、EC2上に構築

• ビックデータアーキテクチャの進化
  データベース・ファイル・ストリーム → データウェアハウス
  S3（マネージドオンラインストレージサービス）に保存
  データレイクの基本コンセプト
  DBを用いなくてもストレージにSQLクエリ実行 → Athena
  データのELT作業 → Glue
  必要なデータを取り出し、高価なRedshiftやSageMakerに投入すると良い

• コスト削減

  • 常に必要以上の投資 → 無駄のない投資
  • 予測できないピークによる余剰キャパシティ・リソース不足 → 必要なときに必要なだけ瞬時に調達
  • EC2、1.1円〜/時間
  • ストレージEBS・S3、3.3円〜/1GB/月
  • データ転送、15.4円/1GB（上りは無料）
  • DDoS対策費不要
  • 代替機（利用しないときは停止することで費用不要に）
  • 死活監視・特権監視・監査対応
  • データセンター単位の冗長化
  • 定期的なコスト低下
  • リザーブドインスタンス 年間予約により、最大75%割引 1〜2ヶ月オンデマンドで試して問題なければリザーブド化する
  • スポットインスタンス

• 運用負荷軽減
  運用負荷が軽減されることで、これまでできなかったことに取り組める

  • Amazon RDS バックアップ・冗長構成・リードレプリカとのレプリケーションなどをAWSがサポート 管理者権限とポートのみ利用可
  • その他、多くのマネージドサービスを提供

クラウド時代のセキュリティ

• AWS責任共有モデル AWSがクラウドのセキュリティを担当 お客様自身はOSレイヤー以上のセキュリティを担当

AWS側については、第三者による監査レポートを閲覧可能

AWSではホワイトペーパーを提供

• セキュアな通信環境を構築するサービス

  • 仮想プライベートクラウド VPC
  • 専用線接続サービス Direct Connect
  • SSL/TLS証明書 Certificate Manager

• セキュアなアプリケーションを構築するサービス

  • 侵入防止
  • 暗号化
  • 認証
  • コンプライアンス

ユーザにとってクラウドは合理的な選択

• 改善アプローチ いままでできていたことを、より早く簡単に安く実現できる
• イノベーションアプリーチ 今までできなかったことをが実現できる 撤退コストも下げることができる

AWS利用料の一般的な内訳例

通常、仮想サーバ・データベースが利用料金の9割を占めるケースが多い
サーバ・DB・データ転送量が想定できれば、だいたいの金額が算出できる

ご不明点のお問い合わせは、hkameda@amazon.co.jp

セッション 1： AWS のグローバルインフラストラクチャとネットワークおよびコンピューティング

佐藤 礼

アマゾン ウェブ サービス ジャパン株式会社 AWS トレーニングサービス本部 テクニカルトレーナー
AWS の基礎であるグローバルインフラストラクチャと、その上でご利用いただく仮想ネットワークサービスの Amazon Virtual Private Cloud (VPC)、仮想サーバーの Amazon Elastic Compute Cloud（EC2）、クラウドならではの動的にサーバー台数を調整できる AutoScaling についてお話しします。
このセッションを通して、AWS のサービスの基本を学習することができます。

AWSの紹介と歴史

もともとはAmazonの社内サービス
2006年からAWSを開始

アベイラビリティゾーン

• 障害からのゾーンの保護
• 高可用性設計
• 他のゾーンを通してリクエストを処理

VPC（Virtual Private Cloud）

特徴

• AWSクラウド内の仮想プライベートネットワーク
• オンプレミスネットワークと同様の構成
• ネットワーク構成の完全なコントロール

コンピューティングサービス

• EC2 柔軟な構成と制御
• Lambda 使用した分のみ料金が発生 管理が不要
• Lightsail 仮想プライベートサーバを起動 単純なWebサーバとアプリケーションサーバを管理
• ECS マネージドコンテナ 極めてスケーラブル、高パフォーマンス
• Fargate
• EKS

EC2

• コンピューティング要件の変化に応じて、キャパシティを拡大縮小可能
• 新しいサーバインスタンスの取得と起動に要する時間を分単位に短縮
• コストは実際に使用したキャパシティのみ

EC2インスタンスの起動

1. AWSリージョンを決定
2. AMIからEC2インスタンスを起動
3. CPU・メモリ・ストレージ・ネットワーク要件に基づいてインスタンスタイプを選択
4. IPアドレス・セキュリティグループ・ストレージボリューム・タグ・キーペアを設定

デモ

リージョンを選択 → 東京

インスタンス作成
AMI選択 → AmazonLinux2
自分で作ったイメージも指定可能
サードパーティ製のイメージも購入可能

インスタンスタイプ選択 → m5.large
ファミリー … 何目的か
タイプ … ファミリー、世代、スペック（CPU・メモリ・ネットワークパフォーマンス）

サブネット
自動割当パブリックIP

高度な詳細 … サーバ作成時にインストールしたいソフトウェア・シェルスクリプト処理などを記載し実行可能

ストレージの追加 → デフォルト
タグの追加 → Name:awsomeday demo

セキュリティグループ
仮想的なパーソナルFW
受信トラフィック（インバウンド）について、許可するトラフィックを設定
* 送信元（ソース）
* プロトコル
* アクセスを許可するポート番号

キーペア選択 → 既存の鍵を選択

起動後、SSHできることを確認する
接続時、キーペアで指定した鍵を利用する

起動したEC2の詳細情報

インスタンスを選択すると画面下部に表示される

ベストプラクティス：スケーラビリティを確保する

• そのアーキテクチャが需要の変化に対応できるようにする
• クラウドのメリットはリソースの需要の変化に迅速に対応できること

管理者が手動で新しいサーバを起動する ← アンチパターン
↓
クラウド上での監視により、キャパシティが上限に達するまでに自動的にサーバが起動される

Webアプリケーションの伸縮性

ELBとAutoScalingグループを利用する
CloudWatchによりキャパシティ不足を検知するとアラームを発砲する
これを受け、AutoSlacingがサーバの台数を増加させる
増えたサーバは自動的にELBにアタッチされる

AutoScaling

サービスは無料
起動したサーバに課金される
負荷による増減・スケジュールでの増減に対応
最小台数・最大台数を指定
オートヒーリング（最小1台、最大1台にすることで、障害発生時に自動で復活できる

• 障害耐性の向上
• 可用性の向上
• コスト管理の強化

ELB

複数のインスタンスにトラフィックを分散
正常に可動していないEC2をヘルスチェックで検知可能 そのEC2にはバランシングしない

• ALB ← L7レベルLB、HTTP・HTTPSのバランシングが可能
• NLB ← L4レベルLB、TCPなどバランシングが可能
• CLB

CloudWatch

AWSクラウドリソースをグラフ化
アラーム機能
他のサービスと連携可能

Q&A

AWSのサービスを疎結合化して使用するのがベストプラクティスと聞いたが、実際はどうか？

密結合している → モノリシックアーキテクチャ
デリバリパイプラインが1つとなり、頻繁なアップデートが難しい

AWSではマイクロサービスアーキテクチャをおすすめしている
AWSのサービスはHTTPSのRESTで疎結合する

疎結合化により、
局地的にアプリケーションをアップデートさせることができる

アプリケーションが細かく分割されるため、
障害発生時の影響を最小限にすることができる

ただ、すべてのシステムを疎結合化するのではなく、
「SoR：企業内部でデータを厳格に運用」では不要なパターンもある。
また、「SoE：顧客主体で新しいコンセプトの提唱」のようなパターンでは疎結合が有効である

セッション 2： ストレージとデータベース

吉田 慶章

アマゾン ウェブ サービス ジャパン株式会社 AWS トレーニングサービス本部 テクニカルトレーナー
このセッションでは、ストレージサービスであるAmazon Simple Storage Service（S3）とAmazon Elastic Block Store（EBS）について、また、Amazon Relational Database Service（RDS）、Amazon DynamoDBをはじめとする各種データベース機能について体系的にご理解いただきます。

データストア＝データを保存する場所

サーバ自身からしかアクセスできない
* ローカルストレージ（EBS）

複数のサーバからアクセスできる

• データベース（RDS）
• データベース（NoSQL）
• 共有ストレージ

EBS

永続的なブロックレベルのストレージボリューム
AZ内で自動的にレプリケート
S3にスナップショットを安全に保存

ユースケース

• OS用ボリューム、ブート・ルートボリュームやセカンダリボリューム
• データベース

EBSのタイプ

ニーズによって選択する

• 汎用SSD：ブートボリューム、小規模から中規模のDB IOPSの上限が10,000なので大規模には向かない
• プロビジョンドSSD：IOPSが32,000なので、大規模DBに向く
• スループットHDD
• コールドHDD

IOPS：1秒あたりに書き込みできる回数

EBSのライフサイクル

EBSを作成
EC2にEBSをアタッチ
EC2からフォーマット
スナップショットをS3に保存
不要になれば削除

EBSまとめ

暗号化可能

S3

インターネット対応のストレージ
常にオンラインでHTTPでアクセス可能
どのような量でも、データの保存、取り出しをいつでもウェブ上どこからでも可能

S3の概念

バケット：S3を利用するさいのトップレベルのネームスペース、世界的に一意である必要がある
オブジェクト：ファイル

S3の冗長化

リージョン内で冗長化されて保存される
東京リージョンの場合、2箇所のAZ障害でも対応できる

S3のスケーラビリティ

保存容量に制限がない

ユースケース

• アプリケーションアセットの保存
• 静的ウェブホスティング
• バックアップと災害対策（DR） リージョンを跨いだ冗長化も可能
• ビッグデータ用のステージング領域

デモ

• S3バケットを作成する

  • 汎用的な名前（logsなど）を指定し、作成できないこと → 「バケット名はすでに存在しています」と表示される
  • 識別子を含めるなど、ユニークな名前なら作成できること → バケットが作成され、バケット一覧に表示される

• S3バケットに画像ファイルをアップロードする

  • 初期状態では非公開になっていること ファイルをクリックすると、対象ファイルへのリンクが表示される → そのリンクをクリックしても、アクセス権で表示できない
  • 公開設定をすると画像を参照できるようになるということ 公開ボタンを押す → リンクをクリックすると、表示できるようになっている

RDS

RDB＝リレーショナルデータベース
データは行と列を持つ表（テーブル）で保持
データにはSQLでアクセス
トランザクション処理を実行可能
複数レコードの更新を複数のユーザーが同時に実行しても矛盾なく更新できる
MySQL,PostgreSQL,MariaDBなど

サイズ変更が可能なキャパシティ
時間のかかるデータベース管理タスクが不要になる
Aurora,MySQL,MariaDB,Oracle,Microsoft SQL Serverなどと互換性がある

マネージド型サービスの利点とは？

RDSの場合、以下が不要となる

• スケーリング
• 高可用性
• データベースのバックアップ
• DBソフトウェアのパッチ適用・アップデート
• DBソフトウェアのインストール
• OSのインストール・パッチ適用
• サーバのメンテナンス
• ラックおよびスタック
• 電源、HVAC、ネットワーク

お客様は「アプリケーションの最適化」に集中できる

RDSバックアップ

• 自動バックアップ
  データベースを特定時点まで復元する
  デフォルトで有効
  最大35日間で保持期間を選択できる

• 手動スナップショット
  スナップショットから新しいDBインスタンスを作成できる
  ユーザーによって開始され、ユーザーに削除されるまで保持される
  S3に保存される

クロスリージョンスナップショット
別のAWSリージョンに保存されているDBスナップショットのコピー
災害対策のためのバックアップ

RDSのセキュリティ

• VPC内で実行される
• IAMポリシーでRDSへのアクセスを制限できる
• セキュリティポリシーを使用する
• RDSとそのバックアップを暗号化できる

RDSのベストプラクティス

• メモリ・CPU・ストレージの使用状況をモニタリングする
• マルチAZ配置を使用し可用性を高める
• DBフェイルオーバーをテストする AWSコンソール上にボタンがある

Aurora

Amazonがクラウド時代に再設計したデータベース
MySQL5.6,5.7,PostgreSQL9.6に互換性あり

64TBまでディスクがシームレスにスケールする
レプリケーション遅延は10-20ms

Auroraストレージ

3AZのそれぞれ2ディスクに書き込まれるので可用性が高い

Auroraの使い所

クエリ同時実行数やテーブルサイズが大きい
データ量の増加が多い

RDSデモ

マネジメントコンソールからRDS（Aurora）を作成・起動

DBエンジンを選択 → Aurora
DBインスタンスタイプを選択 → db.r4.xlarge
マルチAZ配置 → 異なるゾーンにレプリカを作成

時間の都合で起動までは割愛

NoSQLDB DynamoDB

NoSQL = Not Only SQL
従来のシステム構成ではDBといえばRDBMSだった
データの特性に合わせてRDBMS以外のアーキテクチャのデータベースを利用しようという標語的な意味合いを持つ

KVS型、NoSQL型がある

NoSQL
* 水平スケーラビリティ
* スキーマレス
* シンプルなデータアクセス

スケーラビリティとは

処理負荷に合わせてシステムの処理能力を柔軟に増減できる能力のこと

スペックを上げる：垂直方向のスケーラビリティ
インスタンスを増やす；水平方向のスケーラビリティ

DynamoDB

保存できるデータ量に制限なし
書くテーブルに必要なリクエストキャパシティを容易にプロビジョニング・変更できる
1秒間に何回書き込み・何回読み込みたいかを指定するだけでOK
フルマネージド型NoSQLサービス

ユースケース

• 順位表・スコア表
• 一時データ

DynamoDBの使い方

パーティションキー（UserIDなど）によってデータが書くパーティションに分割配置される
ソートキーと組み合わせてデータを管理する

プロビジョンドスループット

書き込みキャパシティ：最大1KBの項目に対して、書き込みを1秒あたり1回
読み込みキャパシティ：最大4KBの項目に対して、強い整合性のある読み込みを1秒あたり1回
→ 常に最新のデータを返す
結果整合性のある読み込みを1秒あたり2回
→ 最近の書き込みの結果が反映されていないことがある
応答には古いデータが含まれる場合がある
分散管理の同期によって発生する
1秒程度で同期されるので、許容できる場合は最新のデータを返すことになる

その他

データベースに万能はない
データ形式・データサイズ・クエリの頻度・データアクセス速度・データの保持期間を考慮し、決定する
Redshift：ペタバイト規模
ElastiCache：インメモリKVS

Auroraフェイルオーバデモ

クラスタエンドポイントに1秒間隔にアクセスし、
手動でAuroraをフェイルオーバする

デモ環境では7秒程度でフェイルオーバした

Q&A

起動済のEC2をELBやAutoscalingグループに追加は可能か？

→ 可能ではある。起動済みのインスタンスを選択すると追加する項目がある。
だが、実運用では使えないと思われる。

RDSで複数リージョンを跨いだクラスタは可能か？

→ 現時点では不可能。Auroraならマルチリージョンリードレプリカは可能。
DynamoDBは可能。

Aurora Multi-Masterは開発中。

Auroraでスケールされる最に一時的な性能低下はあるのか？

→ Auroraでも瞬断は発生する。

Aurora PostgreSQLと RDS PostgreSQLの使い分けとは？

→ 実際に発生する費用差はある。
Auroraが対応している対応バージョンはRDS PostgreSQLのほうが狭いので、対応していなければRDSを使うしかない

セッション 3： AWS のセキュリティの基本

佐藤 礼

アマゾン ウェブ サービス ジャパン株式会社 AWS トレーニングサービス本部 テクニカルトレーナー
AWS を安心してご利用いただくための機能についてのセッションです。Amazon Virtual Private Cloud（VPC）により AWS リソースを起動するための仮想ネットワーク環境をどのようにコントロールするかを学び、AWS Identity and Access Management（IAM）によるユーザーアクセスコントロールについてご理解いただきます。
また、AWS が考えるセキュリティの基本および AWS で用意している各種セキュリティのための取り組みについてご紹介します。

AWSセキュリティの紹介

セキュリティはAWSの最重要事項

AWS側のセキュリティ

• お客様のデータを守る
• 継続的な改善
• 従量制課金
• コンプライアンス要件への準拠

AWS Service Catalog

ポートフォリオにCloudFormationを設定できる
現場では、↑を利用してサーバを構築する
誰でもセキュリティ設定の漏れがないように作業できる仕組みを用意

責任共有モデル

EC2の場合、OSレイヤー以上はお客様、それ以外はAWSの責任で運用している
RDSなどのマネージドサービスの場合、OSレイヤー以下はAWS、それ以外はお客様責任となる
S3、DynamoDBの場合、お客様はデータのみ、それ以外はAWS責任となる

認証とアクセス管理

ログイン時、ユーザー名にメールアドレスを使用している場合、
ROOTアカウントを使用している可能性があるので注意
IAMユーザーを作成し、MFAを設定することでセキュリティを担保できる

IAM

AWSリソースへのアクセスを制限

• 認証
  • マネジメントコンソール
  • CLI SDK
• 認可
  • IAMポリシー

管理方法

• ユーザー・グループの作成（管理のしやすさから、グループに権限を付与し、ユーザーをグループに所属させること）
• 権限とロールの付与

AWS CLI・SDK API

• アクセスキーとシークレットキーが必要 この情報が流出すると、他人にAWSにアクセスされてしまう GitHub等に誤ってアップロードすると悪用される 上記のキーを使用しない方法は後ほど紹介

aws s3 ls
# バケット一覧が表示されること

AWSアカウントルートユーザー

• メールアドレスとパスワードでサインイン
• AWSサービス全てにアクセス権がある
• ルートユーザーでアクセスキー・シークレットキーは発行しないこと（AWSで利用を非推奨）

アプリケーションのAWSリソースへのアクセス

• EC2インスタンスにAWS認証情報を設定する（非推奨） EC2にpython,boto3をインストールし、S3にアクセスする 認証情報を追加する前では、アクセス権限が不足しているエラーが出力される
• EC2にロールを付与する（推奨） 一時的にAWS STSにより認証されトークンが発行されそのトークンを用いて実行できる トークンの情報はEC2メタデータサービスより表示することができる

一時的にユーザーに権限を付与する

事前にユーザーにロールの切り替え権限を付与しておく必要あり。
ロールの切り替えで、一時的に権限を切り替えて作業できる。
アカウントを跨いで、別のアカウントのユーザーへの権限も付与可能。

ベストプラクティス

IAMユーザーを発行し、グループに最小権限を付与しそのグループにユーザーを紐付ける
MFAを使う（IAMユーザー・ルートアカウント）
AWSアカウントのアクティビティをモニタリングすること

セキュリティコンプライアンスプログラム

• 業界の認定を取得
• ホワイトペーパーを公表（セキュリティ統制の作業など）

Trusted Advisor

AWSアカウント上のコスト最適化・セキュリティなど、診断してくれるサービス
無料
契約プラン「エンタープライズ」「ビジネス」の場合、機能をフルで利用可能

セキュリティリソース

Q&A

データベースの読み書きやサーバとの通信の暗号化の遅延はどのぐらいか？

→HTTP2を使っての通信のため、暗号通信のオーバーヘッドは考慮しなくて良い
TLS通信が普及することでより短くなる

RDSでリードレプリカを使用する場合のエンドポイントの使用方法について

→for XXXの場合、エンドポイントの切り替えが必要
Auroraの場合、クラスタのエンドポイントが提供されるため考慮不要で利用できる

AutoScalingで起動するEC2のロールはどのように設定できるか？

→AutoScalingグループの設定で、IAMロールを設定する項目がある

事業部側でのAWSアカウント乱立はどのように対処すればよいか？

→デジタルな対応はできない。
アナログな対応の場合は、経理部とネゴし、事業部には作らせないようにする。

EC2インスタンスを作成するIAMユーザーには、その権限のみを付与するのがベストプラクティスか？

→IAMのベストプラクティスページを参照すると良い。

ELBからALBの移行で注意する点はあるか？

→ALBはL7、ELBはUDP・TCPで処理をしていないかをチェック。
マイグレーションツールがあり、マイグレーション費用や作業を自動化できる
ALBはセッションで費用が発生するため、IoTデバイスの受信など大量セッションで利用する場合はコストが増える可能性もあるので注意。

セッション 4： Well-Architected Framework と料金の話

吉田 慶章

アマゾン ウェブ サービス ジャパン株式会社 AWS トレーニングサービス本部 テクニカルトレーナー
ここまでのセッションの中で登場して来た様々なリソースを、いかに効率よく構成するかが実装の観点では重要となります。
AWS では、これまでの実践を通してベストプラクティスや設計の原則を『Well-Architected Framework』として提供しています。その考え方の基本を紹介し、各種利用料金の考え方についてご理解いただきます。

Well-Architected Framework

このフレームワークの目標
お客様がアーキテクチャを評価し改善できるようにする
設計の決定がビジネスに与える影響をお客様が適切に理解できるようにする

（例）
コスト目標を達成するために、適切な料金モデルを選択しているか？

一般的な設計原則

• 必要キャパシティの推測をやめる
• 本稼働スケールでシステムをテストする
• 革新的なアーキテクチャを許容する
• Game Day：本番で想定される事態を予めテストする サーバやDBの障害テストだけではなく、突発的なアクセスなど様々なものをテストする システムテストのタイミングだけでなく、週一など定期的に行う など

5つの柱

• 運用上の優秀性
  • モニタリングを実施している
  • 運用をコード化する
  • 頻繁に、小さく、可逆的な変更を行う
• セキュリティ *
• 信頼性
• パフォーマン氏効率
• コストの最適化

セキュリティの柱

• 設計原則
  • 全てのレイヤーにセキュリティを適用する
  • 転送中のデータと保存されたデータを保護する

信頼性の柱

• 回復手順をテストする
• システムの可用性を高めるため、水平方向にスケールする

パフォーマンス効率の柱

• 最新技術を積極的に導入する
• グローバル化を即座に実現する
• 試行の回数を増やす

コスト最適化の柱

• 需要と共有の一致

• 従量課金モデルを導入する

• マネージドサービスを使用して所有コストを低減する

Well-Architectedフレームワーク（URLあり）

対障害性と高可用性

耐障害性
運用可能な状態を保つというシステムの能力
アプリケーションのコンポーネントに組み込まれた冗長性

高可用性
システムは通常は機能しアクセス可能
ダウンタイムは最小限
必要な人的操作は最小限
前払いの財政投資は最小限

高可用性：オンプレVSAWS
従来
高価
重要な役割を担うアプリケーションのみ
AWS
複数のサーバ・AZ・リージョン
対障害性の高いサービス

料金の基礎

• 従量課金制
• 予約による値引き
• 使うほど単位あたりの支払いをさらに値引き
• AWSの拡大に合わせて支払いをさらに値引き

従量課金制

• サービスが必要な期間のみの支払い

予約による値引き

• リザーブドインスタンスの購入
• 最大75%節約
• オプション
  • 全額前払（AURI）
  • 一部前払い（PURI）
  • 前払いなし（NURI）

使うほど単位あたりの支払いをさらに値引き

S3・EC2などは料金が階層化されている

S3公式の料金ページ（URL）

AWSの拡大に合わせて支払いをさらに値引き

AWSが選ばれる10の理由（URL）

AWS無料利用枠

AWS無料枠（URL）

料金に関する詳細情報

詳しくは各サービスの料金表を確認すると良い

EC2

オンデマンドインスタンス
リザーブドインスタンス
スポットインスタンス

ELBでは実行時間と処理するデータ量で課金される

CloudWatch

詳細モニタリングでは別途費用がかかる

S3

ストレージ料金
リクエスト料金
データ転送料金

ストレージクラス
* 標準ストレージ
* 低頻度アクセス（IA）
* Glacier

リクエストの数
リクエストのタイプ
GETリクエストは料金が異なる

データ転送
S3から送信されるデータの量に基づき課金される
※S3にアップロードする料金には課金されない

EBS

ボリュームタイプ
IOPS
スナップショット

RDS

時間単位の請求

エンジン
サイズ
メモリクラス

オンデマンド
リザーブド

複数DBインスタンス（リードレプリカなど）

ストレージ

データ転送

CloudFront

リクエスト
リクエストの数・タイプ
地理的リージョン
エッジロケーションから送信されるデータ量

簡易見積りツールとTCO計算ツール

簡易見積りツール

TCO計算ツール
オンプレからAWSへ移行する最にAWSに乗せるとどのぐらいの費用になるかレポーティングするツール

クロージング・アンケート

今後の AWS クラウドの学習方法についてご説明します。

AWSトレーニングサービス

AWSクラスルームトレーニング
ロールごとにコースが用意されている
今回のイベントは AWS Tecgnical Essential1コース相当

トレーニングにはバウチャーあり
期間限定で5%OFF

Amazon Bissinessから購入可能

AWS認定のロードマップ

ベーシック：初学者向け、AWS認定のエントリーポイント
アソシエイト
プロフェッショナル

クラウドプラクティショナー

対象
クラウドビジネスに関わる方全て