AWS Cloud Practitioner Essentials

module 3

リージョン選択

1. コンプライアンス
2. 近接性（ユーザベースの近いところで運用する）
3. 利用可能サービス（リージョン毎に提供されるサービスが少しづつ違う）
4. 料金（税制等の違いにより、サンパウロよりオレゴンで運用するほうが50%程得だったりする）

ElasticLoadBalancer(ELB) は同リージョン用のサービスで、各々 AZ 向けのものは特に対応が要らない。
リージョンと AZ をごっちゃにしないこと。１つのリージョンに複数の AZ があり、EC2 インスタンスは AZ を分けろという話だった。AZ 毎に離れてはいるので災害対策としてはこれでもそれなりに働くという話らしい。データセンターが離れているというイメージ。

出典：https://www.aws.training

エッジロケーション

要はCDN。最寄りリージョンが東京でムンバイにサービスを提供したい場合にこれが使える。CloudFront。Route53 もこの範囲に入る。
AWS Outposts というサービスがある。これは何かしらの強い動機で自分のデータセンター内で AWS を運用したい場合使う。普通はしない。

AWSリソースプロビジョニング

1. Elastic Beanstalk
   EC2ベースの環境をプロビジョニングする。アプリケーション用のコードと設定スクリプトを書くなどしてどのような構造にするかを決めれる
2. CloudFormation
   必要なリソースなどをJSON, YAML等で指定することによって自動で作成される。Infrastructure as Code。EC2に限らず何でも設定される。

 
 
 

module 4

Amazon Virtual Private Cloud(VPC)

サブネットを構成することが出来る。これにより顧客に公開する範囲を自分でコントロールすることが出来る。データベース等。
仮想プライベートゲートウェイを置いてこれが入口となる。その先にロードバランサがあり、更にその後ろにデータベースなどがあるが、これらはVPCによって守られる。
AWS Direct Coonnect は仮想プライベートゲートウェイまでの間をプライベート接続出来るサービスらしい。これによりレイテンシを下げたりなど出来るらしい。

出典：https://content.aws.training/

サブネットとネットワークアクセスコントロールリスト

1. 1. AccessControlList(ACL)：ステートレス
   2. セキュリティグループ：ステートフル

が説明された。どちらもサブネットのアクセスコントロールにまつわる話。
ACL はファイアウォールと思って良い。通す通信をリスト化したホワイトリスト。ステートレスはサブネットを通る場合に in/out いつでも必ずリストでのチェックが入る。リストは ip アドレスと思われる。サブネット単位に設定される。

一方セキュリティグループはパケット到着時にはチェックするが、出ていく分にはチェックしない。また、サブネット1 内インスタンス A から出てサブネット2 内インスタンス B に行き戻ってきたパケットにもチェックしない。これは自分から出たパケットの応答かどうかの情報を持っているからであり、それを持ってステートフルとしている。セキュリティグループは port 毎に開放していたはず。http には 80 のような形で指定し、どのグループを適用するのかを指定するような形だったはず。インスタンス毎に必ず指定する必要がある。

デフォルトの挙動として、ACL はすべて通す。セキュリティグループはすべて通さない。カスタムネットワーク ACL というのがあるらしく、これはすべて拒否するらしい。

グローバルネットワーク

CloudFront と Route 53 の連携について説明された。
具体的には aws training のページを見に行ったほうが良いが、簡単にリスト化すると、

1. 1. クライアントが Route 53 に AnyCompany.com について問い合わせる
   2. Route 53 が AnyCompany.com の ip アドレスを返す。これは実際には CloudFront へのアクセス先。
   3. クライアントが CloudFront へリクエストするとジオロケーション等を参考にコンテンツを届ける。

動画内では Route 53 が 3. の内容をやることもありそうな説明だったが、これは CloudFront の仕事だと思われる。

 
 
 

module 5

インスタンスストアと Amazon Elastic Block Store (Amazon EBS)

インスタンスストアとは EC2 でインスタンスを起動した際にストアされるストレージ。インスタンスを止めると消えてしまうので継続的なデータの保管には使えない。
インスタンス再起動時にメモリや CPU などハードが別なものが割り当てられることがあり、インスタンスストアはそういったハードと紐付いたものなので毎回同じものが使えるとは限らない。
それに対して継続的に使えるのが EBS。こちらはデータを永続的に保管しており、インスタンス起動時にアタッチされる。スナップショットを作成することで増分バックアップも可能。

Amazon Simple Storage Service (Amazon S3)

ストレージクラスという括りでいくつか設定がある。基本的には頻度がクラス分割の基準。
S3 Glacier が丁寧に説明されていたが、頻度が低くいつかどこかで使うことがあるかもしれないくらいの温度感。アーカイブという機能が提供されるような感じ。
コンプライアンス要件（領収書の保管など）によりデータを一定期間保持する必要がある場合は S3 Glacier ボールトロックポリシーというのを使用してロック、編集不可にすることも出来るらしい。
S3 はウェブホスティングに使えることを忘れないように。

EBS と S3 のサービスの違いが説明されていたが、上の内容を理解していれば問題ない。

Amazon Elastic File System (Amazon EFS)

自動スケールするファイルサーバ。
EBS との違いとして、EBS は AZ 単位だが、EFS はリージョン単位。

Amazon Relational Database Service (Amazon RDS)

リレーショナルデータベースの話。
Amazon Aurora が話としては面白い。
AZ 施設間でレプリカが作られ、S3 へのバックアップが継続的に取られ、特定の期間のデータへのリカバリも対応しているらしい。

Amazon DynamoDB

NoSQL の話。

Amazon Redshift

ビッグデータ対応の分析処理データベース。
データウェアハウスというらしいが、ビジネスに直接的に関係がある分析をするためのソフトウェアということになる。
例にもあったが、過去終わったことに対して分析をするには使える。今コーヒーは何個残っている？ のような問に答えるためのサービスではない。

AWS Database Migration Service

データベース移行サービス。オンプレミスからもクラウドからも対応。同種間異種間どちらでもよい。
ダウンタイムゼロは無理っぽい。だが移行期間中もデータベースは利用できるようだ。
データベースの継続的なデータレプリケーションもこれでやるのがおすすめらしい。

その他のデータベースサービス

1. Amazon DocumentDB

MongoDB

2. Amazon Neptune

グラフデータベース。SNS でのユーザ間関係など。

3. Amazon Quantum Ledger Database (Amazon QLDB)

変更履歴保存など。金融規制当局の話があった。ブロックチェーンでは技術的にまだ改ざんの余地がある。

4. Amazon Managed Blockchain
5. Amazon ElastiCache

データベースにキャッシュを利用できる。Redis と Memcached が使える。

6. Amazon DynamoDB Accelerator

DynamoDB のインメモリキャッシュ

 
 
 

module 6

セキュリティ、アクセス権など。
責任共有モデル

出典：https://content.aws.training/

IAM

• IAM ユーザー、グループ、ロール
• IAM ポリシー

ポリシーが具体的な権限。ユーザ、グループ、ロールはそれが割り当てられる先。
ロールが分かりづらいが、ロールを変更可能な権限を本人に渡してやり、本人が職務（ロール）を切り替えると権限がロールに割り当てられたポリシーに従ってもらえるものらしい。
そしてロールは例としては人に割り当てているが、これはアプリケーションや AWS サービス等に対しても割り当てることが出来る概念らしい。

AWS Organizations

ユーザのアカウント等を階層的に一元的に管理するための仕組み。
サービスコントロールポリシー (SCP)というのがある。いまいちなんなのかはわからず。
組織単位 (OU, OrganaizationUnit) でポリシーの適用をまとめて行ったり出来るっぽい。
適用単位は組織のルート、個別のメンバーアカウント、OU らしい。
IAM ポリシーとの違いは、IAM ユーザー、グループ、ロールに適用できることで AWS アカウントのルートユーザーには適用できないとのこと。いまいちわからん。

AWS Artifact

法令遵守、コンプライアンスのためのサービス。
ちなみに例として紹介されていたが、GDPR にまつわるあれこれ等に対応する予定がない場合、除外するリージョンを設定することが出来るらしい。
それにより AWS 側でデータがレプリケートされたりするのを防ぐことが出来る。

サービス妨害攻撃

DDoS が有名な攻撃。リソースを使い切らせることによりサービスを続けられなくする。

1. UDP フラッド -> セキュリティグループ
2. HTTP レベルアタック、スローロリスアタック -> ELB(Elastic Load Balancer)

それぞれ -> の先で示されたサービスで対応する。
基本的な方針としては AWS 全体に攻撃が向くようにすることで攻撃側のコストを上げる事により自分のサービスが守られるようにする。
AWS WAF(Web Application Firewall) はファイアウォール。AWS SHIELD は DDoS 用。
こちらのブログによれば(https://www.wafcharm.com/blog/aws-waf-vs-aws-shield-for-beginners/)

AWS WAFはOSI参照モデルの7層で行われるDDos攻撃を緩和できますが、AWS ShieldはOSI参照モデルの3層および4層で行われるDDos攻撃からWebサービスを防御します。

とのこと。

その他のセキュリティサービス

• AWS Key Management Service (AWS KMS)

キー管理サービス。S3 でのデータ保管時や SSH での転送時のデータ暗号化等を補助する。

• AWS WAF

上で簡単に説明されたがファイアウォール。ACL(Access Control List) を使って特定のリクエストを許可及びブロックしたり出来る。

• Amazon Inspector

セキュリティ評価を実行して自分のサービスを分析してもらいそれに応じて脆弱性やセキュリティのベストプラクティスからの逸脱を検出出来る。
ただし当たり前だがここで検出されたものに対応したからと言ってアマゾンにケツを拭ってもらえることはない。

• Amazon GuardDuty

Inspector と似ているが、こちらは継続して行われ続ける分析で、クラウド内で起こるイベントや既知の悪意のある ip アドレスからの保護がされたりする。

 
 
 

Module 7

AWS 環境のモニタリング方法

Amazon CloudWatch

メトリクスを設定することにより、SNS 等を使ってアラームを出すことが出来る。
動画の例ではコーヒーを100杯作ったかどうかのようなものになっていたが、テキストでは CPU の利用率をみてインスタンスの停止忘れ等がないかのアラームを出すのがあった。
他にも EC2 インスタンスの CPU 利用率をみて自動的にインスタンスを追加したりすることも出来る。

AWS CloudTrail

(おそらく)AWS 内で起きたイベント(API)をすべて記録し、S3内に無制限に記録するサービス。
改変は不可能なので監査等で提出する場合などを想定している。もちろん自サービスを提供するにあたって誰が何をしたのかを記録したい場合にも使える。

AWS Trusted Advisor

自動で解析して問題があることを検出してくれる。

1. コスト最適化
2. パフォーマンス
3. セキュリティ
4. フォールトトレランス（耐障害性）
5. サービスの制限

Trusted Advisor のダッシュボードにアクセスするとこれらの項目についてレポートが見れる。
E メールアラートを設定して各担当（経理、運営、セキュリティなど）にチェックさせることが出来る。

 
 
 

module 8

料金とサポート

無料利用枠

3種類のオファー: 12 か月間無料、無期限無料、トライアル

一括請求 (コンソリデーティッドビリング)

AWS Organizations の一括請求 (コンソリデーティッドビリング) ではボリュームディスカウントや EC2 のリザーブドインスタンスの使用などを組織で一括して利用できる。

AWS Budgets

予算を作成してサービスの使用量、サービスのコスト、インスタンスの予約を計画できます。
予算とバッファの設定でアラートを飛ばすことも出来る

AWS Cost Explorer

AWS のコストと使用量を可視化して把握し、管理できるツール

AWS サポートプラン

• ベーシック
• デベロッパー
• ビジネス
• エンタープライズ

ベーシックは無料。デベロッパーは開発段階。ビジネスは運用段階。エンタープライズはミッションクリティカルな場合に必要とされているらしい。
いくつかのサービスに制限がかかったりするらしいが細かいところはここには記載しない。

AWS Marketplace

データベースやアプリケーションサーバ、監視ツールやBIツールなどがインストールされたAMI(仮想サーバの構成イメージ)を提供しているオンラインストアです。
出典：https://recipe.kc-cloud.jp/archives/5666

EC2 でインスタンス選択時に出てくるあれ。特定のパッケージが既インストールで開始できる。
ツールも利用料に応じて料金を払ったり料金オプションを設定できたりなどするらしい。

 
 
 

module 9

オンプレミスや他クラウドから AWS への移行のサービス

Cloud Adoption Framework

AWS プロフェッショナルサービスチームは、このプロセスを管理するのに役立つ AWS Cloud Adoption Framework と呼ばれるガイダンスを作成しました。Cloud Adoption Framework は AWS への迅速かつスムーズな移行を可能にするためのアドバイスを企業に提供するために作成されました。
出典：https://content.aws.training

とあり、特定のサービスを指すものではない。
移行にあたって必要な知識や技術等がありながら、人それぞれの立場によって内容は異なる。
それを６つの領域に分けて説明するドキュメント。

• ビジネス
• 人員
• ガバナンス
• プラットフォーム
• セキュリティ
• オペレーション

上の３つはビジネス、下の３つは技術寄り。

移行戦略

1. リホスト(丸ごと移行。何も手を入れない)
2. リプラットフォーム(アーキテクチャ等は手を入れない。データベースだけクラウドに置き換えたり)
3. リファクタリング/アーキテクチャの再設計
4. 再購入 (Repurchase) 、ライセンスを新しいものに移行したり別の製品にしたり
5. 保持 (Retain)
6. リタイア

6 つの R で説明されたもの。
リタイアに関しては辞めろではあるが、未使用であったり不要になったものを止めろという話。
移行を辞めろ、みたいな話ではない。

AWS Snow ファミリー

データの移行にあたってデータ全体のサイズが大きく転送に時間がかかる場合に物理的なデバイスを利用して転送するサービス。
8TB からあるので個人での利用も想定しているように思う。Snowmobile では 100PB に対応していてトラックを手配してくれるらしい。
特にネットワークが不安定な場所のデータを移行する際にも役に立つ。

 
 
 

module 10

AWS Well-Architected フレームワーク

ソリューションアーキテクトの助けを借りて行う必要があったアーキテクチャの評価を自動化するもの。
いくつかの質問に答えていくと評価が出るらしい。
5 つの柱

• 運用上の優秀性
• セキュリティ
• 信頼性
• パフォーマンス効率
• コスト最適化

AWS クラウドの利点

• 先行支出を変動支出に切り替える
• 圧倒的なスケールメリットを享受できる
• キャパシティーの予測が不要になる
• スピードと俊敏性が向上する
• データセンターの維持管理にかかる費用が不要になる
• 数分で世界中にデプロイできる