AWSome Day Online セッション受講メモ

## 概要
AWSome Day Online @ [AWS Innovate Online Conference](https://aws.amazon.com/jp/about-aws/events/aws-innovate/)

AWSの基礎的な知識を学べるAWSome Dayのオンラインセッション版

AWSのオンラインカンファレンス "Innovate"にてオンデマンド配信（2019 年 4 月 8 日 〜 5 月 7 日）

以下の4つのセッションで構成

* Session1 AWS のグローバルインフラストラクチャと ネットワークおよびコンピューティング
* Session2 ストレージとデータベース
* Session3 AWS のセキュリティの基本
* Session4 Well-Architected Frameworkと料金の話

[AWSome Day 関連ページ](https://aws.amazon.com/jp/about-aws/events/2019/awsomeday/)

## Session 1 AWSのグローバルインフラストラクチャとネットワークおよびコンピューティング
### AWSを導入すると何が変わるのか？
* スケーラブル・高機能・手軽に導入
* オンプレ時代：理論上の最大ピークを予測していた？⇒不要
* オンプレ時代：必要なリソース（サーバ）の調達に時間がかかっていた？⇒不要

### AWSグローバルインフラストラクチャ
* AWSは複数のリージョン（地域）あり：日本なら東京リージョン
* アベイラビリティゾーン（AZ）：リージョンの中に複数存在する、独立した範囲
* 物理的・ネットワーク的にも離れ、障害発生時も他のAZに影響しない
    * 複数のAZでの実装が重要

### Amazon VPC(Virtual Private Cloud)
* AWS内の仮想プライベートネットワーク
* オンプレネットワークと同様の構成
* 自社内からの閉域網の構築も可能
* ネットワーク構成の完全なコントロール
* 主な機能
    * IP範囲指定
    * ルーティング設定
    * ネットワークゲートウェイ
        * インターネット
        * 仮想プライベートゲートウエイ
    * セキュリティ設定
        * セキュリティグループ
        * ネットワークACL
* AZをまたがって仮想プライベートネットワークを作成可能

### コンピューティングサービスいろいろ
* Amazon EC2
* Lambda
* Amazon ECS(Elastic Container Service)
* Amazon EKS(Elastic Container Service for Kubernetes)
* Fargate
* Lightsail

### Elastic Load Balancing(ELB)
* ELBの種類
    * Application Load Balancer
        * L7で動作
        * 柔軟なアプリケーション管理
        * HTTPとHTTPSトラフィックの高度なロードバランシング
    * Network Load Balancer
        * L4で動作
        * パフォーマンス、アプリケーション用の静的IP
        * TCPトラフィックのロードバランシング
    * Classic Load Balancer
        * 旧世代：新規では原則上記2つを利用する
* フルマネージド：負荷状況により自動スケール：Single Point of Failureになることはない

### EC2 Auto Scaling
* 負荷に合わせた適切な数のEC2インスタンスが自動で生成・削除される
* 期間や負荷（CPU使用率閾値など）に合わせた設定が可能
* CloudWatchによるパフォーマンスモニタリング利用
* Elastic Load Balancingとも連携

## Session 2 ストレージとデータベース
### ストレージって？
* WEBサイトのデータいろいろはどこに保存する？
    * ユーザ情報
    * 商品画像データ
    * 商品情報
    * 在庫情報
* データストアはいろいろ：データの種類に応じた適切なデータストアの選択

### Elastic Block Store(EBS)
* 低レイテンシーパフォーマンス、永続的なブロックレベルのストレージ
* EC2にマウントして使うローカルディスクのようなイメージ
* AZ内で自動的にレプリケート
* S3にスナップショットを安全に保存可能
* ユースケース
    * OS
    * データベースのストレージ利用
    * ビジネス継続性：EBSスナップショットによる定期的なバックアップ
    * アプリケーションをインストールして永続化
* EBSのボリュームタイプ
    * HDD/SSD
    * パフォーマンス異なるタイプあり（HDD2タイプ、SSD2タイプ）
* EBSボリュームの特徴
    * 暗号化
        * パフォーマンス影響なし
        * 追加コストなし
    * 伸縮性
        * キャパシティの追加
        * 別のタイプへの変更
    * 可用性
    * ドライブタイプ
        * ニーズ（パフォーマンス要件と価格要件）に最適なストレージ選択可能
    * スナップショット
        * ポイントインタイムスナップショット
        * 新しいボリュームをいつでも再作成可能

### Simple Storage Service(S3)
* 共有ストレージ
* HTTP(s)でアクセス
* 容量無制限
    * 1ファイル最大5TB
* 高い堅牢性(99.99999999999%：イレブンナイン)
* 安価：月額1GB/約3円
* スケーラブルで安定した性能：データ容量に依存しない性能
* S3の概念
    * データがバケットに保存される
    * アカウントあたり最大100のバケットを所有できる
    * バケットとそのオブジェクトのアクセスログを制御できる
    * オブジェクトに対してオブジェクトキーを含むURLが一つずつ割り当てられる
* ユースケース
    * アプリケーションファイルのホスト
    * メディアホスティング
    * ソフトウェア配信
    * ストレージとバックアップ
    * AMIとスナップショットの保存

### Relational Database Service(RDS)
* RDSのポイント
    * フルマネージドなRDB
    * シンプルかつ迅速にスケール
    * 高速、安定パフォーマンス
    * 低コスト、従量課金
    * 利用可能：Oracle,SQLServer,MySQL,PostgreSQL,MariaDB,Aurora
* RDSのバックアップ
    * 自動バックアップ：デフォルトで有効
        * 最大35日間までの保持期間指定可能
        * S3に保存
    * 手動スナップショット
        * ユーザによって開始、ユーザが削除するまで残る
        * S3に保存
* マルチAZによる高可用性
    * スタンバイインスタンスを他のAZに保持：自動構成可能
    * レプリケーションの自動構成も可能：リアルタイム同期
    * フェイルオーバーも自動：EC2とのエンドポイント等も自動で切り替え
* AWSマネージドデータベースサービス、他には？
    * DynamoDB:NoSQL
    * Redshift:DWH
    * ElastiCache:キャッシュ、インメモリ、KVS

### データストレージに関する考慮事項
* 万能のデータベースはない
* 以下を検討することによりデータ要件を分析する
    * データ形式
    * データサイズ
    * クエリの頻度
    * データのアクセス速度
    * データの保持期間

## Session 3 AWSのセキュリティの基本
* 責任共有モデル
* VPCのネットワーク制御
* AWSの認証とアクセスコントロール

### AWSのセキュリティ
* セキュリティはAWSの最重要事項
* AWSの責任共有モデル
    * グローバルインフラストラクチャ、基盤サービスのセキュリティはAWSが担保
* AWS利用におけるセキュリティ
    * EC2設定時のログインアクセス：キーペアによる認証
    * IAM：マネジメントコンソール、AWS API操作に関するセキュリティ確保レイヤ

### VPCのネットワーク制御
* ファイアウォール
    * 通信を通す・通さないの制御
    * セキュリティグループ／ネットワークACL
* ネットワーク経路制御
* インターネットとの通信
* オンプレミス環境との接続
* ファイアウォール
    * ネットワークACL：サブネットのファイアウォール
        * サブネット単位でのアクセス制御
    * セキュリティグループ：インスタンスのファイアウォール
        * インスタンス毎のアクセス制御
        * セキュリティ設定をグルーピング可能
            * どこからの（送信元）
            * プロトコル
            * ポート番号
            * 例）
                * インターネットからのHTTP/HTTPS
                * 企業管理ネットワークからのSSH/RDP
### AWSの認証とアクセス制御
* IAM:Identity and Access Management
    * AWSリソースへのアクセス制御
    * クラウドサービスへのアクセス
    * 機能利用可不可の管理
        * ※フェデレーティッドユーザー：別のサービスで認証受けたユーザはそのままサービスを使えるなど
    * AWSマネジメントコンソール利用の際の認証に利用
    * AWS CLIまたはSDK API利用の際の認証に利用
* IAMの利用
    * ユーザーとグループの作成
    * 権限とロールの付与
* AWSアカウントルートユーザー：アカウント作成で最初に作られるユーザー
    * AWSサービスの完全なアクセス権を持つ
    * ルートユーザの推奨事項
        * ルートユーザのアクセスキーを削除する（存在している場合）
        * IAMユーザを作成する
        * 管理者アクセス権を付与する
        * IAM認証情報を使用してAWSを操作する
        * ＝原則IAMユーザで接続・利用するべき
* IAM：認可
    * AWSのサービスへのアクセス：許可の付与
    * 権限の割り当て：IAMポリシーの作成：jsonにて記載
    * IAMユーザ、グループ、ロールそれぞれにポリシー割り当て
* アプリケーションのAWSリソースへのアクセス
    * 例）EC2のアプリケーションからS3へのアクセス
        * アクセスキーIDとシークレットアクセスキーによってS3へのアクセス許可可能
        * クレデンシャルキーをソースコードに書くなんて・・・
        * ではベストプラクティスは？⇒IAMポリシー（S3のアクセス権限付き）⇒IAMロールに割り当て⇒EC2に割り当て
* ロールはユーザ、グループ、リソースに割り当て可能
    * 一時的な割り当て（ユーザーが引き受ける）を活用：ユーザログイン中に動的に権限変更可能
* IAMのベストプラクティス
    * AWSアカウントのルートアクセスキーがある場合は削除
    * 個々のIAMユーザーの作成
    * グループを使用してIAMユーザに権限を割り当てる
    * 最小権限を付与
    * 強力なパスワードポリシーを設定する
    * 権限のあるユーザに対してMFAを有効にする
    * EC2インスタンスで実行されるアプリケーションに対してIAMロールを使用する
    * 認証情報を共有するのではなく、ロールを使用して委任する
    * 定期的に認証情報を更新する
    * 不要なユー後認証情報を削除する
    * 追加のセキュリティのために条件（Condition）を使用する
    * AWSアカウントのアクティビティをモニタリングする

## Session 4 Well-Architected Frameworkと料金の話
### Well-Architected Frameworkとは
* クラウド設計・運用のベストプラクティス集
    * 定期的なレビューとKAIZENによるシステム
* ベストプラクティスにのっとっていないことのリスクを判断するための材料としても
* AWSによるWell-Architectedフレームワークの目標
    * アーキテクチャを評価し改善できるようにする
    * 設計の決定がビジネスに与える影響を適切に理解できるようにする
* クラウドでの一般設計原則
    * 必要なキャパシティを勘に頼らない
    * 本番規模でのシステムテストを行う
    * アーキテクチャ試行の回数を増やすために自動化を取り入れる
    * 発展的なアーキテクチャを受け入れる
    * データ計測に基づいてアーキテクチャを決定する
    * 本番で想定されるトラブルをあらかじめテストし、対策する
* クラウドでの一般設計原則に加えて、Well-Architectedフレームワークの5つの柱
    * 運用上の優秀性
        * システムを実行およびモニタリングしてビジネスの価値を生み出し、サポートのプロセスと手順を継続的に向上する能力
            * オンプレ：運用をあまり変えずにリスク回避することが原則
            * クラウド：変化に対応して、進化する
        * 設計原則
            * 運用をコード化する
            * ドキュメントにコメントをつける
            * 頻繁に、小さく、可逆的な変更を行う
            * 運用手順を頻繁に見直す
            * 発生しうる障害を予測する
            * 運用上の失敗を改善に役立てる
    * セキュリティ
        * リスクの評価と軽減戦略によって、ビジネスの価値を生み出しながら、システム、アセット、情報を保護する能力
        * 設計原則
            * 強固な認証基盤
            * トレーサビリティ
            * すべてのレイヤーにセキュリティを適用する
            * セキュリティのベストプラクティスを自動化する
            * 転送中のデータと保存されたデータを保護する
            * データから人を遠ざける
            * セキュリティ事象に備える
    * 信頼性 
        * インフラ、サービスの障害からの復旧、必要に応じた動的なコンピューティングリソースの確保、設定ミスや一時的なネットワークの問題などによる中断を軽減するシステムの能力
        * 設計原則
            * 回復手順をテストする
            * 障害からの回復を自動化
            * システムの可用性を高めるため、水平方向にスケールする
            * キャパシティの予測をやめる
            * 変更作業を自動化する
    * パフォーマンス効率
        * システムの要件を満たすためにコンピューティングリソースを効率的に使用し、需要の変化とテクノロジーの進化に対してもその効率性を維持する能力
        * 設計原則
            * 最新技術を積極的に導入する
            * グローバル化を即座に実現する
            * サーバーレスアーキテクチャを使用する
            * 試行の回数を増やす
            * AWSのサービスをモニタリングする
            * 目的の実現に最適な技術を選択する
    * コストの最適化
        * 不必要なコストや最適ではないリソースを回避する、または排除する能力
        * 設計原則
            * 従量課金モデルを導入する
            * TCO（総保有コスト）を測定する
            * データセンター運用のための投資をやめる
            * 関連支出を分析する
            * マネージドサービスを使用して所有コストを低減する

### ベストプラクティスの質問を活用
* 質問に答えて、改善点・リスクを把握する
* AWS well-architected framework ホワイトペーパーに掲載
    * [AWS Well-Architected](https://aws.amazon.com/jp/architecture/well-architected/)
    * [ホワイトペーパー](https://d1.awsstatic.com/International/ja_JP/Whitepapers/AWS_Well-Architected_Framework_2018_JA_final.pdf)

### AWSの料金モデル
* 従量課金制
    * 定額の変動コスト
    * 必要な期間のみ支払
    * 変化するビジネスニーズに適用
* 予約による値引き
    * リザーブドインスタンス
* 使うほど単位当たりの支払いを値引き
    * ボリュームディスカウント
    * 使用料が増えるほど節約
* AWSの拡大に合わせてさらに値引き
    * 拡大に合わせて単価下がる：スケールメリットの還元
### 料金に関する詳細情報
* 支払い対象
    * コンピューティング
    * ストレージ
    * 送信データ転送
* 課金なし
    * 受信データ転送（ユーザからAWSへのアップロード）
    * 同一リージョン内のサービス間のデータ転送
* 送信データの料金の集約
    * 各サービスの送信データ量は集約のうえ課金