LoginSignup
1

More than 1 year has passed since last update.

AWS SAAの学習まとめ

Last updated at Posted at 2022-12-01

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

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

共通部分:
・インバウンド:外 → 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進数でパターンは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%を超えたら増加させる等)現在非推奨。
┣ ステップ = 1つ〜複数の域値を設定
┗ ターゲット追跡 = 目標を設定して、その条件をキープ出来るように台数を調整

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

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

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

◎その他用語

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

ECS

コンテナ簡単に作成できるサーバー(EC2の1つ)。
→ 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対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インスタンスから同時アクセス可能 → 複数人でファイルの共有

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

◎種類:

・汎用パフォーマンス: 通常のもの
・最大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 分 早めに取り出したいデータ

そこまで取り出し機会の多くない場合は、GlacierS3の低頻度アクセスモードを使う。ここの使い分けは「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

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

◎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 = 取得したデータを適切な形式に変換、S3に保存
※FirehoseはDynamoDBには格納不可

■鍵

◎CSE

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

◎SSE-S3

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

◎AWS KMS

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

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

終わり

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
1