AWSざっくり理解しました
ヒストリー
Amazon社内のインフラ構築で都度構築だと無駄が多くなってきた->一括構築＆分割利用というスタイルを取ってできたのがAWSで、もともとは社内のツールだったそう
インフラ構築の課題 -> 解決したことをサービスとして提供
AWSの90%以上のサービスは顧客の要求から生まれたものらしい
サービスは200を超える
Infrastracture
24のリージョン、84アベーラビリティーゾーンがある
日本は東京リージョン・大阪リージョン
リージョンは複数のアベイラビリティーゾーンで構成
アベイラビリティーゾーンとはデータセンターの事（一つ以上で構成）
アベイラビリティーゾーンの情報は公開されていない
例えば東京リージョンは４つのアベイラビリティーゾーンで構成されている
アベイラビリティーゾーンは意味のある距離（災害など）離れているが、あまりに距離が離れていると通信に影響でるので約100kmぐらいの間隔とされている
リージョンの選択の基準
コンプライアンス（例えば国外にデータを置いてよいのか？）
ユーザとの近さ
リージョン内で利用可能なサービス
料金
サーバを立ち上げるサービスは特定のアベイラビリティーゾーン(データセンター）に閉じられてしまうので、災害対策をするのであれば別のアベイラビリティーゾーンにもバックアップサーバを構築する必要がある
CoreService
EC2 Elastic Compute Cloud
仮想サーバを立ち上げるサービス
従量課金サービス（１秒ごと）
Web三層サービスのうちWebサーバとAPサーバの代わりとなる
多数のOSをサポート、ライセンス料込
数分で起動できる
サーバの性能を選べる
例）c5d.xlarge
c=インスタンスファミリー ※サーバの用途
汎用/コンピューティング最適化/ストレージ最適化/メモリ最適化/高速コンピューティング
5=インスタンス世代 ※新しいものが良い
d=追加性能 ※ネットワーク待機が強化、メモリ追加など
xlarge=インスタンスサイズ ※大きい方がCPUやメモリの容量がUP、コストもUP
サーバの性能はいつでも変更できる
仮想CPU数追加、メモリ追加など
Amazon VPC ： Amazon Virtual Private Cloud
定義した仮想ネットワーク内でAWSのリソースを起動できる
この中にEC2やRDBを入れる
VPC単独で使うことはない
サブネットを中にいれて分離する
VPCが家ならサブネットは部屋のイメージ
リージョンの中にVPCを作成->VPCを分けるサブネットを作る->サブネットそれぞれにアベイラビリティーゾーンを設定する
つまりサブネットを分けることで複数のアベイラビリティーゾーンにそれぞれWebサーバを立ち上げることができる
サブネットはパブリックとプライベートを分けられる
パブリックはIGW(インターネットゲートウェイ)を通して外からアクセスされる
プライベートはVPC内部からしかアクセスできない
DBサーバはここに
例えばAPサーバを構築するなら
ロードバランサーをパブリックにするならWebサーバはパブリックにする
同じVPCに所属しているのであれば、プライベートでもアベイラビリティーゾーンも気にせず相互に接続できる
インターネットゲートウェイ（IGW）
VPCはIGWがないと外からサクセスできない
仮想プライベートゲートウェイ
プライベート接続するためのゲートウェイ
サイト間VPNネットワーク接続
VPNはインターネットを通るが暗号化（IPsec）してプライベートネットワークとすること
インターネットを使うため遅延が発生することはある
AWS Direct Connect
AWSのデータセンターへ直接通信線をひく
コストも時間もかかるが安定・安全な接続が可能
100%安全ではないので、VPN接続も併せて使う場合もある
AWS ストレージサービス
ブロックストレージ Amazon EBS（不揮発性） Elastic Block Store
ES2にマウント可能なSSDやHDDと同じようなもの
EBSはサイズ・タイプの変更が可能
バックアップ可能（S３にスナップショット保存）
タイプ選ぶ
SSD 性能〇、コスト×
HDD 性能×、コスト〇
EBSは複数のEC2から接続はできない
オブジェクトストレージ Amazon S3 Simple Storage Service
HTTP(s)でアクセス可能（インターネット上のどこからでもアクセス可能）
容量無制限 コストはかかる
耐久性が高い ※アップロードしたファイルが壊れない可能性
複数のアベイラビリティーゾーンに保存される
Amazon EFS
EBS＋ 複数のEC2から接続できるファイルストレージ
共有ファイルサーバのような使い方
ELB Elastic Load Balancing
各EC2インスタンスへリクエストを振り分ける
EC2 Auto Scaling
CPUの使用率によりEC2のインスタンスを増減させる
リレーショナルデータベースの構築
On EC2
RDBを自分でインストールする
Amazon RDS Relational Database Service
MySQL, Oracle, SQLServer, PostgreSQL, MariaDB, Auroraから選択可能
AWSが自動でインストールしてくれている
自動バックアップ、スナップショット、パッチ更新など自動化されている（マネージドサービス＝すべてをAWS側でやってくれること）
料金について
物理サーバ購入（オンプレミス）とAWSの比較とメリット
初期投資が不要
実際の使用分のみ支払い（従量課金）
継続的な値下げが期待できる
スケールアウト／インが簡単
スピードメリット
無料利用枠
常に無料
Lamda 100万件/月までのリクエスト
12か月間無料 ※登録後
T2マイクロなど
トライアル枠
Amazon EC2 購入オプション
オンデマンド：時間課金型インスタンス
リザーブドインスタンス：年間（複数年）の利用予約をすることで割引
スポットインスタンス：使われていないインスタンスを格安利用（価格変動）
Amazon S3 料金
ストレージ 一か月の保存容量
リクエスト＆データ取り出し回数
データ転送 ダウンロード回数
AWS Organizations
複数のAWSアカウントの支払いを共通化できる
セキュリティー
AWS上で稼働しているシステムのセキュリティーに対して誰が責任を持つのか？
責任共有モデルを参照 ※マネージドサービスの場合は責任範囲が少し変わる
AWS側とユーザ側は明確に分かれている
ユーザ側の管理部分はAWS側が操作できないような仕様になっている
AWSデータセンターのセキュリティー
データセンターの場所は非公開
職務の分離がされている（運用、管理など完全に分かれている）
AWSのインフラストラクチャのセキュリティー
ユーザ側の責任
例）DDos対策（デフォルトで有効）
データの観点
所有権と管理権は全てユーザ側
AWS側では操作不可
リージョン（国）はユーザが指定
AWSは第三者機関の認証も取得済み AWS Artifact（認証証明確認可能）
IDアクセス管理
IAM Identity and Access management
IAM 登場人物
IAM ユーザ
IAM ポリシー (○○を使うor禁止ルール)
IAM グループ(ユーザをまとめる)
IAM ロール(権限を与える)
AWSアカウントを作成すると
ルートユーザが作られる（作成時のIDとPWでログイン）
全ての権限を持っている
普段は使わないもの（運用など）
請求関係や削除する場合のみ使用
IAMユーザを作成する
管理者権限を与える
役割の権限のみを与えるようにする
普段はこのアカウントで運用をする
多要素認証をONにする（ワンタイムパスワード）
IAM ロールの使い方
AWSリソースにアクセス権を与える
例）EC2へS3へのアクセス権限を与える
IAM ユーザに一時的に権限を与える
AWS以外の認証ユーザへAWSの操作権限を与える
Amazon Cloud Watch
監視、アラート、アクションをトリガーする
AWS CloudTrail
IAMユーザごとに誰がどんな操作したか記録するもの
AWSの操作方法は
GUI : AWSマネージメントコンソール
CUI : AWSコマンドラインコンソール
SDK : ソフトウェアディベロップメントキット
操作は全てREST APIなのでそのログを取っているだけ
Amazon GuardDuty
AWSアカウントへの悪意のある操作に対して異常な操作を検知＆通知してくれる（ディフォルトはOFF、従量課金）
AWS Shield
DDos攻撃（大量のリクエストを送り付ける）に対するもの
スタンダードProtectionはディフォルトでON
アドバンスドProtectionは有料サービス
AWS Key Management Service
データの暗号化に対する管理ができる
AWS Trusted Advisor
コスト最適化、パフォーマンス、セキュリティー、耐障害性、サービス制限の項目で評価アドバイスがもらえるサービス
Well-Architected-Framework
６つの観点で評価される
運用の優位性
セキュリティ
信頼性
パフォーマンス効率
コスト最適化
持続可能性（環境保全の観点）
AWSのコンテナサービス
マイクロサービスで開発したいが例えばすべてをEC2で構築するとコストが気になる
コンテナ導入で一つのEC2インスタンスに複数のコンテナを入れられる
コンテナの管理が複雑になると困る
どのEC２インスタンスにどのコンテナをのっけたか分かりにくくなる？
Amazon Elastic Container Service(Amazon ECS) コンテナオーケストレーションサービスを使うと
コンテナ化されたアプリケーションを実行しスケールする
シンプルなAPIコールを使用してDocker対応アプリケーションを制御する
Kubernetesを使いたいなら Amazon Elastic Kubernetes Service (Amazon EKS)が使える
AWS Fargateでサーバ管理から解放される？
例えばEC2インスタンスの管理から解放される
自分でEC2インスタンスを立ち上げたらその後の世話もしないといけない
AWS Lambda
サーバレス技術
AWSのフルマネージメントシステム
本来EC2インスタンスを構築してコンテナのせてみたいな処理の代わりに直接処理が実行できる
EC2は時間課金だけどLambdaは呼び出し回数課金
仕組み
コードをアップロードする
イベントソースからトリガーされるようにコードを設定
トリガーされたらコード実行
AWS メッセージングサービス
マイクロサービス間のデータ受け渡しができる？
小さなテキストデータでやり取りする
Amazon Simple Queue Service
コンポーネント1対1で連携させる場合
Amazon Simple Notification Service
コンポーネント1対1以上で連携させる場合
AWSへのマイグレーション
VMware Cloud on AWS への再配置
SaaS採用、クラウド型ライセンス費用へ
外部サービスを使ってしまう
単純移行でAWSへ
OSやアプリケーションに変更を加えずそのまま移行
単純移行でAWSへする中で一部マネージドサービスを使う
AWSですべて作り変える
移行手順ツール
サーバ移行
AWS Application Migration Service
オンプレミスのサービスから徐々にAWSへデータ移行してくれる
DB移行
AWS Database Migration Service(DMS)
オンプ -> AWS or AWS -> オンプレに移行できる
他にも DB on EC2 -> RDSもできる
AWS Schema Conversion Tool (AWS SCT)
種類の違うDB移行を実現する
データの移行
AWS Direct Connect AWSへの専用線接続サービス
AWS Snowball Edge / AWS Snowcone
物理的にデータを移行させる（インターネットを経由させない）
サーバレスについて
メリット
サーバ管理が不要
柔軟なスケーリング
十二分に考慮された高可用性
アイドル時のリソース確保が不要
従来（オンプレミス 3層構造）との比較
Webサーバ ： API Gateway HTTPS REST
APPサーバ ： Lambda 処理ロジック
DBサーバ ： DynamoDB データ管理