AWS-SAA-躓いたメモ

私がテストでミスった部分の知識を共有します。

EC2

• キーペアは1つのVPCに5000個まで。

• 停止中にもEBSの料金が発生する。

• ストレージはEC2インスタンスストア(停止すると消える)かEBS
  -　スポットインスタンス：余ってるEC2使う。同じ性能で、最大90%off。
  -　EC2ImageBuilderはAMIの設定更新の自動化

• EC2フリートはオンデマンドインスタンスとスポットインスタンスで構成される

• インスタンス間のネットワークのレイテンシを最小限に抑える必要がある場合、クラスタープレイスメントグループにて、単一のAZ内のインスタンスを論理的にグループ化

• GPU持ってるやつは高速コンピューティング

• AMI

  • AMIの共有はアカウント番号を指定するだけで他のアカウントに共有可能
  • リージョン内のみで利用可能。別リージョンにコピーして別AMIとしても利用可

• 1つのリージョンで利用できるElasticIPの上限は5

• Directed Hostは別IAMグループとは物理サーバは共有せず、物理的にサーバを占有可

• スティッキーセッションは同一ユーザーの同じセッションのアクセスを全て同じEC2インスタンスに送信する

• Connection Drainingは登録解除されるが、異常が発生したインスタンスへの新規リクエスト送信を中止する機能

route53

• レイテンシベースルーティングはレイテンシの低いリソースへルーティング
• 位置情報ルーティングは、地理的に近いリソースへルーティング

VPC

• 1リージョン、最大5VPC

• VPCエンドポイントはグローバルIPをもつAWSサービスに対し、VPC内から直接アクセスする為の出口

  • ゲートウェイ型エンドポイント
    • サービスの宛先とするトラフィックのルートテーブルの宛先として指定できるゲートウェイ
    • DynamoとS3に適応可

• VPCフローログはVPC内の通信の解析

• ネットワークACLはVPC/サブネット単位で適応。+ステートレスで、インバウンドだけではアウトバウンドは許可されない

  • SG→インスタンス単位
  • ACL→VPC単位

AutoScaling

• クールダウンのデフォルトは300sec
• ウォームアップ条件ステップスケーリングポリシー`によって設定

Aurora

• 3つのAZに配置、6個レプリケート可能
• 自動で10GBのセグメントに分割
• 最大15のリードレプリカ

RDS

• フェイルオーバーするとDBインスタンスのCNAMEを自動で切り替えられる
• Lambdaを連携させたい時、RDS Proxyを使用
• シャーディング可能(DB負荷分散)
• AutoScalingはストレージ増加させる

lambda

• cloud watch logsのログをLambdaへ連携する場合、cloudwatchLogsのサブスク機能
• 最大一時実行ボリューム512MB
• デフォルトタイムアウト3sec、max実行時間は15min

SQS

• メッセージサイズ最大 256kb(拡張clientライブラリ利用で、最大2GBまで)
• AutoScalingトリガーを構成する場合はSQSのキューサイズを確認
• ロングポーリングですぐにメッセージが受信可能

S3

• 特定のIPアドレスからのアクセスはIAMロールで設定
• AccessAnalyzerで不正アクセス確認
• ストレージ分析でいつ適切なデータをストレージクラスに移行するか判断
• S3 Intelligent-Tieringで低頻度アクセスのオブジェクトを自動的に低頻度アクセスに移動
• Glacier Deep ArcheveはS3のアーカイブ、長期バックアップ
  • Glacierより優位な点は
    • 3つ以上のAZにまたがって保存
    • 12時間以内に取り出せる
• S3 selectはオブジェクトからデータの一部のみを取り出し可
• クロスリージョンレプリケーションは異なるAWSリージョン内のS3バケット間でオブジェクトをコピーする機能
• 暗号方式
  • SSE-S3
  • SSE-KMS
  • SSE-C
• ボールドロック：ボールドロックポリシーでファイル削除とか禁止

cloudfront

• Gzip圧縮機能でエッジ側でコンテンツを圧縮して高速配信
• コスト算出法
  • エッジロケーションの場所
  • データ転送量
  • リクエスト数

ALB

• メリット
  • L7、パスルーティング
  • 1インスタンスに複数ポートを登録可
  • ターゲットグループでのヘルスチェック可
• デメリット
  • リージョン間無理。
  • ログファイル分析するには、S3でELBファイル収集、EMRで解析

cloudwatch

• 3つのステータス
  • OK(正常)
  • ALARM(警告)
  • INSUFFICIENT_DATA(データ足りていない)
• 拡張：Ec2にcloudwatchAgentをインストール

EBS

• DLM(Data Lifecycle manager)定時バックアップが可
• 最初、フルバックアップその後増分
• プロビジョンドIOPS
  • I/O負荷の高いワークロード、特にデータベースワークロードのニーズを満たすように設計
  • 複数のEC2アタッチ可能
• アクセス頻度低いけど、大事なデータの保存のストレージにはEBSのコールドHDDを選択
• 同一AZ内にアタッチ可
• 暗号化
  • ボリューム内の保存データ
  • ボリューム内のインスタンス間で移動されるデータ
  • ボリュームから作成されたスナップショット
  • スナップショットから作成された全てのボリューム

DynamoDB

• 1ミリ単位のレイテンシを要求する時
• 1アイテム400kBまで
• リードレプリカ無い

Elastic Cache

• ノード：最小単位
• シャード：1~6個のノードで構成
  • プライマリノード：データの更新と紹介
  • レプリカノード：プライマリをコピー、障害時に使う
• クラスター：複数のシャードで構成。マルチAZ複数AZに分散可

EFS

• NFSv4プロトコル

Elastic BeanStalk

• デプロイ、プロビジョニング、ロードバランシングなどできる
• Dockerの仕組みを利用

Trusted Adviser

• コスト最適化、パフォーマンス、セキュリティ、耐障害性、サービスの制限

EMR

• EC2とS3で構成されたHadoopフレームワーク

appSync

GraphQLの開発を容易にする完全マネージド型SB

---

単発

• Storage Gateway、S3 Glacierは標準で暗号化
• AD Connector:IAMとオンプレのADを連携
• Amazonマルチアップロード：大量のobjectをいくつかに分けて並列でアップロード、基本100MB以上の場所
• インスタンスのトラフィック分散はRoute53じゃなくてELB
• API Gatewayの処理性能向上は、スロットリング制限設定とキャッシュを有効化
• AWSでは/28が最小のCIDR単位
• IPフローティング：ELBやRoute53によるDNS情報の伝搬の際の一定のダウンタイムを防止するため、仮想IPアドレスを使って可用性を高めるサービス
• コストの可視化はCost Explorer
• PCIまたは HIPAA準拠(クレカ処理)の処理を実行している場合、監査のためには過去365日間のCloud Frontの使用状況を記憶すること
• Well-Architectedの5つの柱
  • 運用の優勢性
  • セキュリティ
  • 信頼性
  • パフォーマンス効率
  • コスト最適化
• VPN関連
  • AWS間のVPN接続の監視：CloudWatch TunnelStateを利用
  • オフィスと社内ネットワークとAWSのVPN接続を必要:AWS managed VPN

その他

• VMImport/Export：仮想マシン、イメージをEc2に移行したり
• AmazonLex；音声、テキストを使用して対話できる
• AmazonPolly：文章をリアルな音声に変換
• AmazonSageMaker：機械学習モデルを迅速に構築
• AmazonRekognition：画像分析、動画分析
• Aws Lake Formation：S3を利用したデータレイク構成
• AWS SAM(serverless application model)：サーバーレスアプリケーション。cloud formationと連携
• Amazon Simple Workflow：分散アプリケーションコンポーネント間での作業調整を用意するサービス
• AWS Global Accelerator：アプリケーションの障害による停止時間と割合と応答性能を改善するネットワークサービス
• フェイルオーバー：使用不可能になった時に、自動的に切り替わる
• Pop3:ローカルに落とす。IMAP4：リモートの内容を見る
• パイロットライト：停止した状態の最小限の構成を別リージョンに用意。