AWS SAAの学習まとめ

AWS Certified Solutions Architect - Associateについて学習したことをまとめていきます。羅列しているだけなので、まとめて内容さらい直したい場合にご覧ください。

よく出てくるIT用語

・I/O処理 = データの出し入れのこと
・テンプレート = ymlファイル等、環境構築の設計図のようなもの。
・エンドポイント = そのサービスの接点
・単一障害点(SPOF) = そこに障害が発生するとシステム全体が停止してしまう箇所
・スループット = 処理性能の事

・スケール = 性能
・スケールイン = 台数を減らして性能を下げる
・スケールアウト = 台数を増やして性能を上げる
・スケールアップ = 機器自体の性能を上げる

・フェイルオーバー = 片方がぶっ壊れたら自動でもう一方に切り替えますよ機能のこと
・冗長化 = 影武者を用意しておいて、主が死んだらサブが昇格するシステム

■ネットワーク

リージョンとAZ

・リージョン：離れた拠点がある
・AZ：リージョンが更に分かれている
→ 数10km離れているので、災害が起きてもOK = 耐久性と信頼性
・マルチAZにした際、AZ同士の情報は遅延なく同期される

VPC(Virtal Private Cloud)

プライベートなネットワークをAWS内に作成

・VPCには好きなIPアドレスが振れる(/16 - /28)
・VPCの中には更に箱を作れる = サブネット
→ 作成時にAZを指定(後から変更不可)
→ 1箱に対してルートテーブルを1つ指定
→ 最初はメインルートテーブルで後から変更可
→ 1VPCに作れる箱は200個
→ セキュリティ：ネットワークACLが自動で適用(変更も可)
→ サブネットもマルチAZにする

リージョン > VPC > AZ > サブネット

接続方法が非常に出る。。

◎VPC - VPCを繋ぐ：VPCピアリング

通信相手は通信相手はEC2等のサービス本体なので、ゲートウェイは通らない

VPC
|
VPCピアリング
|
VPC

◎VPC - オンプレミスを繋ぐ：仮想プライベートゲートウェイ(VGW)

オンプレミスと接続するには「VGW」の後に下記を挟む必要がある
・DirectConect：物理的なコード
・VPN：仮想的なコード
・DirectConect Gateway：1つの接続で複数のAWSアカウントやVPCと接続可
・AWS Transit Gateway：複数のVPCとオンプレミスを仲介ハブを介して接続

DirectConectは物理的なコードなのでVPNに比べて「速い」「パケット損失の低下」「大量データの送信」が可能

VPC
|
仮想プライベートゲートウェイ(VGW)
|
DirectConect = 物理的なコード
|
オンプレミス

VPC
|
仮想プライベートゲートウェイ(VGW)
|
VPN
|
Customer Gateway = VPNが物理的なものでなく、宛先に迷ってしまうので設置が必要
|
オンプレミス

◎VPC - AWSの他サービスを繋ぐ：

インターネットゲートウェイ(IGW) or VPCエンドポイント or NATゲートウェイ

・基本的に重要な情報はPrivateサブネットに入れる
・インターネットに接続する場合Publicサブネットにする必要がある
→ セキュリティに考慮した構造にする必要がある

インターネット経由で接続(IGW)

VPC
 Public
 |
インターネットゲートウェイ(IGW)
 |
インターネット
 |
他のAWSのサービス

インターネット経由で接続 (NATゲートウェイ)

VPC
  Private
  |  NATゲートウェイ
  Public
  |
インターネット
  |
他のAWSのサービス

インターネットを経由しないで接続

VPC
|
VPCエンドポイント
|
他のAWSのサービス

※ゲートウェイエンドポイント：S3, DymanoDBと接続
※AWS PrivateLink：上記以外のサービスと接続

◎インターネットゲートウェイ

VPCに1つアタッチ(取り付ける)。インターネットとVPCの接続に使うやつ。

・単一障害点(SPOF)か？と思われがちだが、冗長化や障害時の復旧が自動でなされているので問題なし。

・ルートテーブルは下記内容で設定しておく

ゲートウェイ(通路) = インターネットゲートウェイ
ルート(宛先) = 0.0.0.0/0
→ サブネットをこのIPアドレスにすると「パブリックサブネット」になる

◎ルートテーブル

通信の経路(宛先アドレスと通る予定のゲートウェイ)が書いてある。
・個々のサブネットに1つずつ設定
・1つのルートテーブルを複数サブネットで共有可能
・VPCのデフォルトのルートテーブル = メインルートテーブル

◎セキュリティグループとネットワークACL

この２つの違いが非常に出るので違いを抑える。

共通部分：
・インバウンド：外 → VPC内への設定
・アウトバウンド：VPC内 → 外への設定

セキュリティグループ：

サービスに対してのセキュリティ
→ 対象：EC2, ELB, RDS等

・インスタンスに少なくとも1つ以上のセキュリティグループのアタッチが必要
・制御できるのはIPアドレス、ポート番号、セキュリティグループ
・状態はステートレス

◎ネットワークACL：

ネットワークに対してのセキュリティ
→ 対象：サブネット等

・制御できるのはIPアドレス、ポート番号
・デフォルトはアクセスを拒否
・状態はステートフル → エフェメラルポートを許可する必要がある。

◎VPCフローログ

通信のログ
送受信者のIP, ポート番号, プロトコル, データ量, 許可／拒否の記録
ENI単位で記録される。

◎サブネットとCIDR記法

これは基本情報などとも被る知識。
(例) 000.000.0.0/24
この場合頭から数えて24ビット目より後が、IPアドレスに使用可能なビット数になる。
赤の部分が、自由に使える部分
00000000.00000000.00000000.00000000

8ビットあるので、２進数でパターンは2^8=256
→ 256個のIPアドレスを利用できる。計算してベストなCIDRを設定することが重要。

Route53

ドメインの管理と権威DNS
→ IPアドレスをドメイン名に書き換えて管理してくれる。

◎用語：

・ホストゾーン = ドメイン名
・レコード情報 = ドメイン ←→ IPの変換情報　Aliasコード
・Zone Apex = 最上位ドメインのこと
・DNSフェイルオーバー = システムに異常が発生した場合、被害を最小限に抑える仕組み
→ フォールトトラントアーキテクチャという設計方法。具体的にはヘルスチェックを行い、その結果をみて発動する仕組み。

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

・EC2：仮想サーバー。Elastic Load Balancing, Auto Scalingで上手に負荷分散しよう
・ECS：Dockerコンテナ専用のサーバー。構築が楽。
・Lambda：サーバーなしでプログラムを実行

EC2

◎Amazon Machine Image(AMI)

→ インスタンスの元となるイメージ。これを使うと時間短縮(EC2作る際に選ぶOSのやつ。)

◎インスタンスタイプ：（例）m5.large

・5の部分 = 世代を表している
・largeの部分　= 性能(CPU, メモリ)を表している

◎インスタンスタイプの種類：

呼び方	特徴	インスタンスタイプ名の頭文字
汎用	CPUとメモリのバランスが良いタイプ
コンピューティング最適化	CPUの性能が良いタイプ	頭文字がC系統
高速コンピューティング最適化	CPU以外の性能(GPU)が良いタイプ	画像のP系, 機械学習のG系
メモリ最適化	メモリの性能が良いタイプ	頭文字がR系統
ストレージ最適化	対ローカル用。	HDDのD2, SSDのI3系

◎インスタンスの状態：

・起動中: Running
・停止中: Stopped
・削除済: Terminated
※EC2インスタンスを停止していても、この後出てくるEBSの料金はかかるので注意！

ELB

トラフィック(ネットワークに流れる情報量)の制御がしたい時に使用。
EC2インスタンスを複数並べて、ELBを前に置くと処理を分配してくれる
単一障害点(SPOF)を防ぐ、負荷分散用のもの

◎プレウォーミング申請：

急激な負荷増(スパイク)が予測できる場合は、予めプレウォーミング申請を行なっておく。

◎ヘルスチェック機能：

失敗するとEC2を切り離し、正常になったら再度紐付け

◎ELBの種類：

・CLB = L4, 7用 古いやつ
・ALB = L7用 HTTP(S)のプロトコル用
・NLB = L4用 HTTP(S)以外のプロトコル用

アプリケーションと出てきたら「ALB」それ以外は「NLB」
古いものは「CLB」でOK

Auto Scaling

EC2等の起動台数管理をしてくれる。増やす, 常に最小台数をキープすることが可能。
条件に合わせて台数の増減をしてくれるので、消されちゃうことも考えてステートレス & マルチAZにしておく必要がある。

◎スケジューリングポリシー

台数増減の条件は下記から設定する。

・スケジュールスケーリング
・予測スケーリング
・動的なスケーリング
┣ 簡易 = 域値を設定(CPUが70%を超えたら増加させる等)現在非推奨。
┣ ステップ = １つ〜複数の域値を設定
┗ ターゲット追跡 = 目標を設定して、その条件をキープ出来るように台数を調整

※インスタンス起動中はヘルスチェックを止める機能がある。猶予期間は300秒。しかしCLI, SDKで作成した場合はデフォルトfont color="tomato">0秒なので注意。

◎インスタンス増減の調整

・ウォームアップ
・クールダウン

◎その他用語

・ライフサイクルフック = インスタンスのスタート, 停止時にアクションの実行
・終了ポリシー = スケールイン(減らす)時に、どのインスタンスを消すのか設定

ECS

コンテナ簡単に作成できるサーバー(EC2の１つ)。
→ Dockerのサーバーと言ったらこれ。

・AutoScalingで動的にスケーリング可能
・コンテナごとにIAMロールの割り当ても可能

◎用語

・Task = コンテナのこと
・Cluster = EC2インスタンスのこと
・Task Definiton = コンテナの定義を設定(ymlファイル的な)
・Service = コンテナを同時条件で複数用意

その他コンテナのEC2

・AWS Fargate = インスタンス不要といったらこれ。
・EKS = kubernetesと言ったらこれ。
・ECR = Dockerのイメージを管理する。

Lambda

サーバーなしで簡単にメソッドを構築できる。
何(他AWSサービス)をトリガーに発動させるか？を設定して、メソッドを書く。

◎料金：

実行数と処理時間で変動
→ そのため、実行回数が数回のものに向いている

監視系

◎CloudWatch Logs

・機械視点
・エラーなどの記録
・条件に当てはまったら通知して処理などの設定も可能。

◎CloudWatch Events

・機械視点
・インスタンスが減ったら…とか状態の変化をトリガーにする
・スケジュール設定も可能。

◎CloudWatch エージェント

EC2でCloudWatchを使う時はこれが必要。

◎Cloud Trail

・人視点
・動作を記録
・監査に使える。監査と言ったらこれ。
・処理の実行は不可なので、人の動作で通知を…みたいにしたい時はCloud Watchと連携させる。

◎Cloud Config

・設定履歴の確認

■アプリケーションサービス

SQS

キューの実行。順序を保証したい系の文章が出てきたら大体これのFIFOキュー。

・水平スケーリングが得意
・メッセージサイズは256KBまで。処理に失敗したらデッドレターキューに移動する。

◎種類と設定:

・standardキュー = 速い、配信順序を保証しない
・FIFOキュー = 遅い、順序保証

・ロングポーリング = メッセージの有無を確認してからレスポンスする
・ショートポーリング = メッセージの有無は確認せずに、即レスする

・可視性タイムアウト = 同じメッセージの受信防止。デフォで30秒 ~ 最大12時間

◎すぐ処理したら問題のものには…

・遅延キュー = 受信メッセージを一定期間見えなくする
・メッセージタイマー = 受信メッセージを個別に一定時間見えなくする

その他のメッセージサービス

・SNS = プッシュ型通知
・SES = メール
・MQ = マネージド型メッセージブローカーサービス（メッセージを受け取って送る機能？）

■ワークフロー

・Simple Workflow(SWF) = 使いづらいらしい…？
・Step Functions = 可視化されていて使いやすいらしい

■ストレージサービス

EBS

・EC2インスタンスと1対１で作成する、DBを入れる用の箱。
・ファイルシステムの構築や、処理の速さと不揮発性を生かしてデータ分析に使用。
・拡張○
・縮小×
・ボリュームタイプの変更○
・スナップショット(特徴でメッッチャクチャ出る)
・自動でAZ内の複数ディスクに複製機能あり。
・暗号化も可能 → 途中からこの機能をONにする場合は、スナップショットを利用して新規に作成して設定の必要あり
・EBSマルチアタッチ = 複数のインスタンスから同一のEBSをアタッチ
・DeleteOnTermination ＝ EC2が消えたらEBSのデータも削除する機能。

◎ボリュームタイプ

これもめちゃくちゃ出る。。

呼び方	速度	向いているデータ量	向いているDB
汎用SSD	250MB/秒　 遅	少	通常
プロビジョンドSSD	1000MB/秒　速	少	I/O負荷の高いDB
スループットHDD	500MB/秒　 速	多	分析, 大容量
Cold HDD	500MB/秒　 遅	多	アクセスの低いアーカイブDB

EFS

複数EC2インスタンスから同時アクセス可能 → 複数人でファイルの共有

同時アクセスするために、１つの共通のアクセスポイントを作る。 = マウントターゲット

◎種類：

・汎用パフォーマンス: 通常のもの
・最大I/Oパフォーマンス: 数百 ~ 数千からアクセスする場合。ビックデータの並列処理など。
→ どちらにするかはCloudWatchのPrecentOlimitで計測して判断すると良い。

◎スループットモード

・バースト = データサイズ普通、スループット1GBあたり50KB/秒
・プロビジョニング = データサイズ小、アクセス多、スループット値の増減は前の作業から24時間以上開ける
→ どちらも急激に上がるのはOK。CloudWatchのBurstCreditBranceで計測して判断すると良い。

EC2関連で、EFCとEBSの選択肢が良く出る。
ファイルシステムと言ったらEFC, それ以外はEBS
他、違いを押さえておく。

S3

長期間、大容量、消えたら困るデータを保管するのに使用する。

◎用語：

・メタデータ = オブジェクトの管理情報
・イレブンナイン = 耐久性
・99.9 = 可用性
・バージョニング = 1つのオブジェクトに対して複数バージョン管理
・ACL = バケットとオブジェクトの公開、非公開を切り替えられる
・クライアント暗号化 = AWS SDK
・ブロックパブリックアクセス機能 = 外部からのアクセスを禁止する
・S3 Access Analyzer = S3バケットの監視と保護
・S3 select = オブジェクト取り出しの際に、フィルターをかけられる
・S3 Transfer Acceleration = 遠隔地のS3データ転送をサポート

◎種類：

通常のS3意外に、下記種類がある。

・S3 OneZone
→ 単一AZでデータを複製。Glacierと低頻度アクセスの間の存在

・S3 Intelligent - Tiering
→ 30日以上参照されなかったデータは標準から低頻度モードになる

・Glacier
→ ほぼ取り出さない、アーカイブデータ保存用。

◎Glacierの取出時間：

モードによって取り出し時間が変わる。めちゃくちゃ出る。

名前	取り出し時間	用途
Deep Archive	12 時間	ほぼ使わないデータ。 料金が安い
大量	5 - 12 時間	大容量データ
標準	3 - 5 時間	標準
迅速	1 - 5 分	早めに取り出したいデータ

そこまで取り出し機会の多くない場合は、GlacierかS3の低頻度アクセスモードを使う。ここの使い分けは「5分待てるか」である。
Glacierの方が安いが、一瞬で取り出さなければいけない場合はS3の低頻度アクセスモードを使わないといけない。

Storage Gateway

オンプレミス - AWSのサービスでデータを連携(移行というより連携)
・暗号化される
・CHAP認証でなりすましを抑える

◎種類：

・ファイルゲートウェイ
→ ファイル形式で保存

・ボリュームゲートウェイ
→ キャッシュ型：メインをS3とする。高速
→ 保管型：メインをオンプレミス、スナップショットなどをS3に保存する

・テープゲートウェイ
→ データのバックアップ用

FS× for Lustre

これもストレージ系の一つ。
2回目のアクセス以降はキャッシュを利用するので高速。
LinuxのサービスでNAS(クラウド上のファイルサーバー(情報の置き場))のように使える

データベース

◎RDS：

・SQL方式
・自動バックアップ
・手動スナップショットからデータのリストアも可能
・ポイントインタイムリカバリー = 5分前 - 35日前のDBの状態で新規DBを作成可能
・マルチAZ構成, リードレプリカ構成どちらも可能
→ リードレプリカ = 参照用のDBインスタンスを作成できるサービス

◎RDSのAurora：

・AWS独自開発のDBエンジン
・容量を最初に決める必要なし、データ量で最大64TBまで自動的に拡縮
・マルチAZ構成ができないので、レプリカを作成する

◎Red shift Specturum：

→ S3内のデータを分析可能

◎Athena：

→ S3内のデータにクエリを実行できる。これも分析などで使える。

◎DynamoDB：

・単一障害点(SPOF)を持たない
・メタデータの保存が得意
・Time to Live(TTL) = 有効期限が過ぎたデータを削除する機能
・DynamoDB Streams = 24時間以内の操作ログを保存
・DymnamoDB Accelerator(DAX) = キャッシュを使って読み込みがマイクロ秒になる機能。コストが高い。

※AppSync ＝ DynamoDBの値をいじれる。今までLmbdaとAPIGatewayが必要だったが、これ1つで可能になった。

◎ElastiCache：

・キャッシュしてしょっちゅう使うデータの取り出しパフォーマンスを上げる
・Memcahedと多くのデータ型が使える + 永続性のRedisがある。
・Redisはクラスタモードでリードレプリカを作成する
・ユーザーのマッチング処理、 おすすめ表示機能、　画像データの高速表示などで使用
→ 同じ動作を繰り返し行う + 高速に処理したい場合におすすめ

◎Neptune：

→ グラフ用データベース

◎QLDB：

→ 台帳用データベース

個人的に混ざるものの比較：
・RDS = SQLで取得可能、表(リレーショナルデータ)形式
・DynamoDB = SQLのクエリは使えない、オブジェクト型

・Aurora = RDSの種類の1つ。AWSオリジナルのDB
・Athena = S3分析用
・Neptune = グラフ用

S3とDB系の使い分けも苦手。。

■権限

◎IAM系：

呼び方	対象
IAMユーザー	人
IAMグループ	人々のグループ
IAMロール	一時的な人(アカウント) AWSのサービスとサービスをつなぐ等
IAMポリシー	ルールの内容を書くところ(これを人に割当)

IAMポリシーはAWS管理と、カスタマー管理がある

◎AWS Certificate Manager：

AWSが認証局となって、証明書の発行をしてくれる。無料。

■Code系

サービス名	概要
Code Commit	ソースコードの管理、Git的な。
Code Build	ビルドとテストをしてくれる
Code Deploy	デプロイ
Code Pipeline	上の3つを束ね、一連のプロセスを自動化
Code Star	Code Pipelineをテンプレートから構築可能
CodeGuru	機械学習を使ったコードレビュー
CodeArtifact	pipやnpmなどパッケージ化したものを配布

■自動化

◎Elastic Beanstalk

インフラ系の自動化。EC2と言ったらこれ。
Eclipseから使うときはAWS Toolkit for Eclipsが必要

◎Ops Works

・OS以上のレイヤー自動構築
・chef, puppetと言ったらこれ。
・Clientローカル方式 = 各サーバーでレシピを使う
・Server/Client方式 = マスターサーバーがレシピを管理

◎Cloud Formation

・OS以下の構築
・webアプリ、テンプレートと言ったらこれ。

まとめると。。

サービス名	対象領域	キーワード
Elastic Bean Stalk	インフラ	EC2
Ops Works	OS以上のレイヤー	chef, puppet
Cloud Formation	OS以下のレイヤー	webアプリ、テンプレート

正直Elastic Bean Stalk と Ops Works の違いは良くわからないので、完全にキーワードで判断している。。

■分析

◎EMR

→ 分散処理、スポットインスタンス(EC2のちょっとだけ使うやつ)と相性が良い

◎Kinesis

・Datastreams, Data Firehose = センサーやログをリアルタイム解析
※データの変換にはLambdaを合わせて使う

・Video Streams = 動画処理
・Data Analytics = 収集したデータの可視化と分析

StreamsとFirehoseの違い
・Kinesis Data Streams
＝ 処理が早いのでリアルタイム処理向け

・Kinesis Data Firehose
＝　処理に60秒以上必要なので時間関係ないもの向け

◎Data pipeline

→ データ処理、移動を支援
※Code Pipelineとめちゃくちゃ混ざる。。

◎Glue

→ データレイク、データウェアハウスを利用

■その他

◎AWS STS, IAM cognito

→ アプリなどのユーザーがパスワードなどを使ってサインインできる機能。
この２つの違いはわからない。

◎App Sync

DynamoDBをつかって超リアルタイム処理(Lambdaよりも高速)

◎Snowball

ここらへんも良く出る。。条件が書いてあって、この場合に一番いい方法は？
A: Snowball 2つ
B: Snow mobile 1つ
的な感じである。。難しい。

サービス名	容量	かかる時間	届くもの
Snowcone	8 TB	約 1 週間？	小さめの箱
Snowball	80TB	約 1 週間	箱
Snow mobile	100PB	10 日未満	車

さらにSnowballの中にも種類あり
・Snowball Edge Compute Optimized
→ 42TB、機械学習データなどに

・Snowball Edge Storage Optimized
→ 80TB

◎AWS Shield

DDos攻撃から保護
・Standard = 無料 L3, L4が対象
・Advance = 有料 上記に加えて、L7も対象

◎WAF

複数の攻撃から保護。対象はL7, DDosも防げる。

AWS ShieldかWAFかは、レイヤーの幅が広い方がいいか、攻撃防御の幅を広げるかといった感じである。

◎Amazon Kinesis Data　Streams と Firehose

・Amazon Kinesis Data　Streams　 = IoTデータの取得
・Amazon Kinesis Data　Firehose = 取得したデータを適切な形式に変換、S３に保存
※FirehoseはDynamoDBには格納不可

■鍵

◎CSE

ユーザーで鍵を暗号化、ユーザーが管理

◎SSE-S3

S3を使って鍵を管理
自動で暗号化される

◎AWS KMS

これを使ってユーザーが暗号化キーを作成、管理可能

監理をどれだけユーザーがやるか
SSE-S3 < AWS KMS < CSE

終わり