AWS Solution Architect Associate 受験記(学習メモ1)

はじめに

前回からかなり間が空いてしまいました、、
(なかなか試験を受けに行く踏ん切りがつかないのと仕事が忙しく、、)

今回の記事はタイトルにもある通り、AWS Solution Architect Associateってなやつを受験してきましたので、学習記録として勉強していく中でメモしたものを知識ベース・箇条書きで残しておこうと思います.

では、早速いきましょう！！！

学習記録

• VPC内に設置したインスタンスがインターネット接続できない理由

  • 
インターネットゲートウェイがサブネットに設定されていない

  • ネットワークACLの設定でインターネットアクセスが許可されていない
  • セキュリティグループの設定でインターネットアクセスが許可されていない
  • パブリックIPが付与されていない

• S3の種類（コストに関して）

  • 
IA(Infrequent Access)： アクセス頻度が少ないが、要求された時はすぐに取り出せるようにしたい場合に選択する

• EBSボリュームのスナップショットを取っておくと使用していたデータ引き継ぐことができる

• ストレージボリュームの違いについて

• 汎用SSD（gp2）

  • デフォルトEBSボリューム
  • 3IOPS/GB、3000IOPSまでバーストできろが制限わり

• プロビジョンドIOPS SSD（io1)

  • 最高レベルのパフォーマンス、アクセス頻度が高い＆ディスク上が多いシステム向け
  • ストレージ容量の他にIOPSごとに費用がかかる

• スループット最適化HDD（st1)

  • 高速なHDD、安定したスループット向け
  • データセットやI/Oサイズが大きく、アクセス頻度が高いシステム向け

• Cold HDD(sc1)

  • 低コスト、バックアップなどの低速でアクセス頻度が少ない、大容量データ向け
  • EC2のブートボリュームには使用不可

• Amazon FSx for Windows：数百万のIOPSを実現

• S3クロスリージョンレプリケーション(CRR)：異なるリージョン内のバケット間でオブジェクトをコピーする

• リードレプリカ(RDS)の特徴

  1. ソースDBインスタンスが変更される度に非同期レプリケーションを使用して更新される
  2. 読み取り専用接続のみ許可されるのDBインスタンスとして動作
  3. リードレプリカに接続する方法はDBインスタンスの時と同じ
  4. 全てのDatabaseを複製

• Auroraレプリカ：ソースインスタンスと同じ基盤となるストレージを共有する.

  • 
コスト削減， レプリカノードへのコピー不要

• EC2の詳細モニタリング：1分間隔でデータを取得（基本は5分間隔、デフォルトでオン(課金なし))

  • 
CloudWatchにデータが送信される度に料金発生、データストレージは課金なし

• Snowballの種類

  1. Edge Storage Optimized:ローカルストレージや大規模データ転送に最適
  2. Edge Compute Optimized:遠隔地にあるデータ収集、機械学習の処理、保存を実行できる

• NATゲートウェイのタイプ：パブリック（デフォルト）：プライベートサブネットインスタンスはインターネットに

  アクセスできるが、インターネットからはアクセスできない

  • NATゲートウェイにはElastic IPが必要
  • Multi-AZ構成を取れない
    

• プライベート：プライベートサブネットインスタンスは他のVPCまたは主にオンプレミスのネットワークに接続可能

  • NATゲートウェイにはElastic IPが必要
    

• NATゲートウェイはインスタンスの送信元IPをNATゲートウェイのIPにする

  • 
パブリックはElasticIPに、プライベートはNATゲートウェイのプライベートIP

  • 
応答トラフィックは元の送信元IPに戻す

• 一時キュー：SQSでリクエスト・レスポンスなどのいパン的なメッセージパターンを使用する際に開発時間や費用削減に役立つ

• ElastiCacheのモード2つ

  • 遅延ロード（遅延書き込み）：必要な時にのみキャッシュにデータを読み込む
    • メリット：リクエストされたデータのみキャッシュ、キャッシュは一杯になりにくい、リード障害も心配なし
    • デメリット：キャッシュミスで3回無駄アクセスが出る（キャッシュに対する最初のデータリクエスト、DBクエリ、キャッシュにデータを書き込む）
      • キャッシュミスの時だけデータが更新される場合、データが古くなる可能性
      • 対策としては「書き込みスルーモード」か「TTL」を検討
  • 書き込みスルー：データがDBに書き込まれる度にデータを追加 or キャッシュを更新
    • メリット：キャッシュデータが古くならない、1回の書き込みで2回の無駄アクセス（DBへの書き込み、キャッシュへの書き込み）
    • デメリット：ノード障害、スケールアウトによりデータの欠落がおこる
      • 対策は遅延書き込みを書き込みスルーで指定する
      • リソース浪費してしまう．
        • 対策はTTLを使うこと

• VPNソリューション：Site-to-Site VPN、トランジットゲートウェイ、EC2上のパートナーソリューション

• S3サービスは暗号化されたデータを受け取るだけで、暗号化/復号は行わない

  • クライアント側でデータを暗号化→S3に送るという風にする
    • 方法は「KMSに保存されているキーを使用」、「アプリケーション内に保存したキーを使う」

• Auto Scalingの作成順序は以下の手順で行う

  1. AMIの準備
  2. 起動テンプレートの設定
  3. AutoScalingGroupの設定

• NATゲートウェイ

  • プライベートサブネットからインターネット接続が可能だが、インターネットから直接インスタンスに接続することはできない
  • Multi-AZで構成が取れない
  • 作成方法
    1. 常駐先のパブリックサブネットを指定する
    2. プライベートサブネットのルートテーブルにNATゲートウェイを設定

• S3 Glacierのアーカイブ取り出し3種類


  • 迅速
    • 
1〜5分以内に使用可能
      
- 標準
    • 3～5時間以内に使用可能
  • 大容量
    • 0.0025USD/GBでデータの重要部にアクセス可

• EBSボリューム復元について

  • ミラーリング（回復性が高い）
    • 2つ以上のEBSボリューム間でRAID1を構成
  • インスタンス停止＆スナップショット取得（低い）
インスタンス停止& AMI取得（低い）

• S3のパフォーマンス最大化

  • プレフィックスを利用して日付ベースでアップロードを分散する
  • 3,500リクエスト/sでアップロード、5,500リエスト/sで取得（ダウンロード）をサポートできるよう自動で向上する

• Storage Gatewayの使用用途について

  • 保管理ボリューム
    • プライマリストレージはオンプレミス
    • 非同期にS3にバックアップする
  • キャッシュ型
    • プライマリストレージはS3

• SQSの保存期間

  • デフォルト4日、最大14日

• Cloud FormationはymlファイルにResouceという記法が必要

• S3のバケットアクセスurlの形式

  • http:<バケット名>.S3.<リージョン>amazonaws.com/~~~

• ユーザー数の増加に条軟に対応する典型型ユースケース

  • ELB, Auto Scaling, Route53, SQS
  • ELBはアプリケーションに弾力性を追加する理想的なソリューション
  • Route 53にルーティングポリシーを作成して加重ルーティングなどを使用→複数リソースを単一のDNS名に関連づけることができる

• Route 53のレコードタイプ

  • CNAME
    • あるドメインやホストの別名を定義するレコード
  • TXT
    • ホストに関連づけるテキスト情報を定義するレコード
  • MX
    • 対象ドメイン宛のメール配送先ホストを定義するレコード
  • A
    • ホスト（FQDN)とサーバーを調別するグローバルIPアドレスの関違づけ
  • DNAME
    • 別のドメインに対しDNSの部分木全体をマッピングする

• Auto Scaling Groupのライフサイクルフックでカスタムアクションを実行することができる

  • 一般的な例としては、インスタンスがElastic Load Balancingに登録されるタイミングを制御することで
    最後にロードバランサーに登録される前にアプリケーションがトラフィック受け入れ可能か確認できる

• Kinesis Data Streamはシャード単位でストリーミングメッセージを処理できるが,1秒あたり1,000メッセージもしくは1MB/sしか扱えない

• Simple Queue Serviceはフルマネージド、サーバレスでアプリケーションの切り離し（疎結合）とスケーリングが可能

• Aurora ServerlessはAuroraのAuto Scaling設定

  • アクティブ状態のDB容量に対して課金

• EC2起動時のプレイスメントグループ3つ

  • クラスター：AZ内でインスタンスをまとめる、ノード間通信が低レイテンシーネットワークパフォーマンス
  • パーティション：基盤となるハードウェアを異なるパーティション同士で共有しないようにする
    • Hadoop, Cassandra, kafkaなど大規模なワークロードに使用
  • スプレッド：相関性エラーを減らすために少数のインスタンスをハードウェア全体に配置

• ShieldとWAF ざっくり

  • ShieldはDDoS
  • WAFはSQLインジェクションやクロスサイトスクリプティングなど脆弱性を狙った悪意ある攻撃を防ぐ
    • また、ACLのルールに基づいてリクエスト許可/ブロック可（地理的条件も可）

• Aurora グローバルデータベースは複数リージョンにまたがって配置されるハイパフォーマンスDB

  • データのマスターは1つのプライマリリージョンで構成
  • 最大5つの読み取り専用セカンダリリージョン
  • 書き込みオペレーションはプライマリDBクラスターに直接発行

• Dynamo DBには2つモードがある

  • オンデマンド
    • 容量計画なしで数千リクエスト/sを処理できる
    • 以下の条件はオンデマンドが適切
      • 不明なワークロードを含む新しいテーブル作成
      • アプリケーションのトラフィックが予測不可
      • わかりやすい従量課金を希望
  • プロビジョニング済み（無料対象）
    • 秒間あたりの読み込み/書き込み回数を指定する
    • 以下の条件はプロビジョニングが適切
      • アプリケーションのトラフィックが予測可
      • トラフィックが一定or 徐々に増加
      • キャパシティーを予測してコスト管理できる

• AWS Transit Gateway

  • 中央ハブを介してVPCとオンプレミスネットワークを接続
  • 異なるVPC同士のリソース共有回避&自己完結型ネットワーク

• NAT Gatewayにはセキュリティグループは関連付けられない

  • NATの後ろにあるリソースに紐づける

• ストレージ種別

  • EC2に単体でつけるストレージ→EBS
  • 複数つけられるストレージ→EFS
  • 共有ストレージ x ハイパフォーマンス → FSx for lustre (windows,Linux,MacOSで使用可)

• 自動バックアップのルール

  • DBインスタンスがavailableであること
  • コピーが同じDBインスタンスの同じリージョンで実行されている間はバックアップもスナップショットも作成できない！

• Route 53のルーティングポリシー

  • シンプル：ドメインで特定の機能を実行する単一のリソースを指定
  • フェイルオーバー：アクティブ／パッシブフェイルオーバーを構成する
  • ジオロケーション：ユーザーの位置情報に基づき、トラフィックを分散
  • 地理的近接性：リソースの場所に基づいてトラフィックを分散
  • レイテンシー：複数のリージョンにリソースがある場金、より少ない往復時間で最良のレイテンシーを実現する
  • 複数値国：ランダムに選ばれた最大8つの正常なレコードを使用してDNSクエリに応答
  • 加重：指定した比率で複数のリソースにトラフィックをルーティング

• Global accelerator

  • トラフィックパフォーマンスを最大60%向上
  • アプリケーションへのパス最適化→レイテンシーを低く保つ

• Aurora マルチマスタークラスター：継続的な可用性＝すべてのDBインスタンスで読み書きが可能
ダウンタイムが発生しない

• セキュリティグループ→インスタンス単位、ACL→サブネット単位

• オブジェクトをS3標準からS3 One Zone-IAに移行できるようにする最低保存期間は30日→30日経過後、違う保存クラスに移行できる

• インスタンス起動時に使用できないストレージタイプは、コールドHDDとスループット最適化HDD

  • 基本的にHDD系はブートボリュームに不可

• ストレージ料金の比較：(S3標準のストレージコスト < EBS < EFS)

  • S3→格納した分だけ課金（例：1GBあたり$0.023）
  • EBS→ストレージサイズ（1GB）あたり課金（例：1GBあたり→$0.10）
  • EFS→使用したリソース分だけ課金（例:1GBあたり→$0.30）

• Guard Dutyの追跡対象：色々あるがメインどころはVPCフローログ、DNSログ、Cloud Trail

• Auto Scailingのターグット追跡ポリシー

  • スケーリングターゲットを選んで、メトリクスとターゲット値に
指定された目標値に近づくようにスケーリングを行う
  • （例）平均総CPU使用率が50%に保つようにスケーリングするなど

• Cloud Frontでリージョンエッジキャシュをスキップするコンテンツは動的コンテンツと
PUT/POST/PATCH/OPTIONS/DELETEのプロキシメソッド

• Direct Connect とVPNを使用すると、、、

  • メリット
    • 1つ以上のDirect Connect専用ネットワーク接続をVPN・VPCと組み合わせられる
    • IPSecで暗化されたプライベート接続が可能
    • ネットワークコスト削減
    • 帯域幅のスループットも向上、VPN接続単体よりも良い
  • 注意点
    • Direct Connectを使用している＝充分な期間が必要
  • ちなみにDirect Connectのみでは暗号化された接続はできない

• インターネットから画像を転送する場合、S3データ転送料金は不要

  • また、S3 Transfer Acceleration(S3TA)は高速化された転送に対してのみ料金が必要

• Kinesisざっくり

  • Data Streamはストリーミングビッグデータのリアルタイム処理
  • Data Firehoseはストリーミングデータをロードするためのコンポーネント
  • Analyticsは SQLクエリと高度なJavaアプリケーションの構築用（リアルタイム処理ではある）

• Kinesis Data Streamは最大365日データを保存可能

• Guard Dutyの追跡ログなどを残す方法としては、一般設定でサービスを無効にする

• Cloud FrontはVPCではなく、エッジロケーション

• Key Management Service (KMS)でカスタマーマスターキ(CMK)を削除するにはキーの削除をスケジュールする必要がある（待期期間が強制されている）

  • min 7日、max30日で設定可、デフォルトは30日

• SQS FIFOはmaxで300メッセージ/sしか処理できない

  • しかし、1操作あたり10メッセージ（最大）をバッチ処理させることができ、その場合3,000メッセージ/sを処理させることができる

• EC2インスタンスのフリートを構築するための最もコスト最適でリソース効率が高いのはインスタンスストアベースのEC2インスタンス（インスタンスストアの使用料金に含まれる）

• Guard Duty -> S3

• Inspector -> EC2

• Storge Gateway：クラウドストレージにオンプレミスでアクセスできる

  • テープゲートウェイ：テープバックアップを提供
  • ファイルゲートフェイ：SMBまたはNFSベースのアクセスを提供
  • ボリュームゲートウェイ：iSCIブロックストレージボリュームを提供

• API Gateway: RESTful APIとWebSocketAPIを作成することができる

  • HTTPベース
  • ステートレスなクライアントサーバ通信
  • クライアントとサーバー間のステートフルな全二重通信を可能にするwebsocketプロトコルに準拠

おわりに

かなり分量が多いので第一弾としてここまでにしておきます.
第二弾はまたそのうち更新します.

それにしてもいろいろな知識が必要なのと箇条書きすぎて情報がまとまっていなくてほんとに学習メモになっているなと実感しております、、、

自身の復習のタイミングで更新していくことにします.

ではまた、次の記事でお会いしましょう.
(Part2はこちらになります)