【AWS初学者向け】AWS認定資格SAA直前対策

与えない。CloudFrontの料金は下記によって定まる。

• 配信地域
• リクエスト数
• エッジロケーションからのデータ転送アウト

できない。CloudFrontではOrigin Access Control（OAC）という機能を用いてオリジンとのアクセス制限を行う。

サードパーティーのCA証明書をCloudFrontとオリジンの両方に導入する。ただし，オリジンがELBの場合はACMによって発行されたSSL/TLS証明書を導入する。

エッジロケーション

SCPはOUに設定されたAWSアカウント全体を対象とし，アクセス許可の境界は個別のAWSアカウントを対象とする。詳しくは下記の記事を参照されたい。

STSはあくまでも認証情報の提供のみを行うが，結果としてアクセス権限を移譲することになる。

Cognitoは一時的，アクセスキーは永続的な認証のユースケースに利用される。

RDSでは利用できないが，ElastiCacheでは利用できる。

• IAM Access Analyzer：インターネットや別アカウントからのアクセスを解析
• Cloudtrail：同じアカウント内のアクセスを解析

IAMデータベース認証

Microsoft Active Directoryフェデレーションサービスを利用して，SAML2.0ベースの設定を行う。Web IDフェデレーションでは，GoogleやOpenID Connect互換のIdPなど外部IDプロバイダーを使用するため，要件とは合致しない。

カスタムIDブローカーアプリケーションを構築し，同様の機能を実装する。

• Simple AD
• AD Connector
• AWS Managed Microsoft AD

できない。構築できるのは，AWS Managed Microsoft ADであり，AD Connectorはあくまでも既存のADと連携する機能を提供する。

• Cognito：不特定多数のユーザーに対する認証・認可
• SSO：組織内のユーザーに対する認証・認可

• your user pools：Cognitoの認証基盤
• federated id：外部のIdP経由でのSSOで割り振られるid

AMIはリージョン間でコピーが可能であり，アカウント間で共有が可能である。

AutoScalingでインスタンスの作成に利用される設定。EC2単体の設定には起動テンプレートが利用され，起動設定は起動テンプレートに置き換わっている。

AMIをベースに個別のユースケースに最適化したリソースがゴールデンイメージ。DockerのベースレイヤーがAMIで，ビルドされたイメージがゴールデンイメージとざっくり理解する。

停止しない。

拡張ネットワーキングは，広帯域幅と低レイテンシを提供する。コンピューティング最適化インスタンスで利用できる。

すべて変わらない。

停止したインスタンスを再起動する際に，前回の状態から続行するための機能。メモリ内のデータをHDDに一時避難させてから，インスタンスの停止・再起動を行う。

• ホットアタッチ：実行中のインスタンスにアタッチ
• ウォームアタッチ：停止中のインスタンスにアタッチ
• コールドアタッチ：起動中のインスタンスにアタッチ

ENIのアタッチは，主にENIを切り替えるときに行う必要がある。ホット・ウォーム・コールドはバックアップリソースの切り替えに関する一般的な用語で，温度が高いほど瞬時に切り替えることができると理解しておくとよい。すなわち，ホットアタッチでは瞬時にENIを切り替えるために，起動中のインスタンスにアタッチする。ウォームアタッチではそこそこ早くENIを切り替えるために，起動予定だが停止中のインスタンスにアタッチする。コールドアタッチでは，新しいインスタンスの起動中にアタッチする。ウォームアタッチのアタッチ先は停止中のインスタンスであり，真っ新な状態からインスタンスを作成するコールドアタッチよりも実行中のステータスに近いことに注意する。

• 静的スケーリングポリシー
  • 常にDesired countだけ起動する
• ターゲット追跡ポリシー
  • CloudWatchメトリクスを指定された値で維持するようにスケーリングする
• ステップポリシー
  • CloudWatch Alarmの閾値にもとづいてcount数を定める
• スケジュールドスケーリングポリシー
  • 静的スケーリングポリシーを指定期間中に発動する
• 予測スケーリングポリシー
  • 機械学習の予測に基づいてスケーリングする

• EC2ヘルスチェックタイプ：EC2の状態のみを調べる
• ELBヘルスチェックタイプ：EC2に加えてELBの状態を調べる

• PV AMI
  • Paravirtual（準仮想化）の略称で古くから提供されている仮想化方式
  • 後述のHVMに置き換えられている
• HVM AMI
  • Hardware-assisted VM（完全仮想化）の略称
  • 拡張ネットワーキングが利用可能

可能。むしろlambdaでは，サブネットとSGの組み合わせが大切。

行わない。ECS側で制御する。

起動プロセスが停止する。

1. 前段にAPI Gatewayを設置する
2. 関数URLをPublicに設定する

即時反映される。

lambda側でEventBridgeルールからのlambda:InvokeFunctionを許可する

旧来は，オンデマンドのキャパシティ予約の代わりにスケジュールドリザーブドインスタンスが利用されていた。イメージとしては，「RI」と「Saving Plan＋オンデマンドのキャパシティー予約」が概念的には並列になる。後者の方が柔軟性が高いような印象。

デフォルトではできない。

インスタンスのファミリー。インスタンスのサイズはどちらでも変更可能。

• EC2 Image Builder
• ゴールデンイメージ

AWSが提供するAMIやサードパーティが提供するAMIでは，今後ユーザにとって最適でなくなる可能性がある。

有効ではない。たしかに，VPCの拡張ネットワーキングはインスタンス間の低レイテンシを実現するが，EC2自体の処理速度が改善しないことにはボトルネックの解消には繋がらない。

T2などのバーストパフォーマンスタイプ。

サブドメインを含まないドメイン名。www.academ-aid.comではなく，academ-aid.comのことを指す。

RFC1912により，CNAMEと他のレコードが共存できないことが定められている。一方で，Route53でホストゾーンを作成すると，デフォルトでホストゾーンと同じ名前のNSレコードが自動的に作成される。したがって，デフォルトでZone Apexに対してCNAMEを設定することはできない。

エイリアスレコードは，デフォルトでCNAMEを設定できないという問題を解決するために開発されたAWS独自の機能。例えば，ALBのDNS名に対してacadem-aid.comというドメインを設定し，Aレコードを指定したい場合は，下記のように指定する。

できない。アクティブ/アクティブ構成に対しては，フェールオーバールーティング以外のルーティングポリシーを選択し，そのうえでフェールオーバー設定を行う必要がある。一方で，アクティブ/パッシブ構成に対してはフェールオーバールーティングを設定することが可能。

• Route53の位置情報ルーティングポリシー
• CloudFrontの地域制限

トラフィックフローを用いて順序が設定されたトラフィックポリシーを作成する。なお，トラフィックポリシーというのは，トラフィックフローを用いて作成されたルーティングポリシーやエンドポイントの集合のことを指す。

• オンプレミス上のDNSリゾルバがDNSクエリをVPC上のRoute53リゾルバに転送できるように，Route53リゾルバでインバウンドエンドポイントを作成する。
• VPC上のRoute53リゾルバがDNSクエリをオンプレミス上のDNSリゾルバに転送できるように，Route53リゾルバでアウトバウンドエンドポイントを作成する。

• 地理的近接性：ユーザを近くのリソースに（自動的に）ルーティングする
• 位置情報：ユーザを特定の地域に（カスタムルールに基づいて）ルーティングする

IAM。Route53はあくまでもSSL証明書とドメインの対応関係を検証するだけである点に注意する。

Route53のフェールオーバールーティング。Route53のフェールオーバー設定（アクティブ・アクティブ）では，常に両方のリージョンを利用することになり，迅速にバックアップに切り替えるという要件に適さない。

まず，TLS証明書はルート証明書・中間証明書・サーバ証明書の三種類に分けられる。これらの三種類が信頼の連鎖を構築している。CAは証明書の発行機関であることから，「CAがルート証明書・中間証明書・サーバ証明書」を発行するという関係性にある。そして，CAが発行した証明書はCA証明書と呼ばれることがあるため，DV/EV/OV証明書はCA証明書であるともいえる。なお，AWSはDV証明書のみに対応しており，EV/OV証明書には対応していない。

Route53のルーティング方法の一つにフェールオーバールーティングがあり，Route53のフェールオーバー設定はフェールオーバールーティング以外のルーティングに対しても適用できるという関係にある。

Route Origin Authorization（ROA）

• EnableDnsHostnames：パブリックDNSホスト名を取得する
• EnableDnsSupport：VPC内ホストの名前解決を行う

• ENI（Elastic Network Interface）：プライベートIP・Elastic IP・SGを利用できる
• EFA（Elastic Fabric Adapter）：ハイパフォーマンスコンピューティングを利用できる
• ENA（Elastic Network Adapter）：拡張ネットワークを利用できる

プライベートサブネットのみをもつVPC。

各サブネットは単一AZに属する。

サブネットがデフォルトで関連付けられるルートテーブル。自分で作成するルートテーブルをカスタムルートテーブルとよび，カスタムルートテーブルを指定する場合は，メインルートテーブルとの関連付けは解除される。

• NATゲートウェイ：IPv4
• Egress-Onlyインターネットゲートウェイ：IPv6

NATゲートウェイはマネージド型サービスで，NATインスタンスはユーザが管理するEC2上動作するサービス。NATインスタンスでは，NATゲートウェイでは実現できなかったポート転送や踏み台サーバ機能を提供できる。

デフォルト設定ではインバウンド・アウトバウンドいずれもデフォルトで許可，カスタム設定ではデフォルトで拒否する。

• VPC
• サブネット
• ENI

可能ではない。ただし，リージョン内であればVPCをまたいだ分散は可能である。

NLB。1秒あたり数百万リクエストに達するようなユースケースで利用可能。

プライマリプライベートIPアドレスになる。

クロスゾーン負荷分散を有効にすると，AZ間のトラフィックの均衡は保たずに，AZという括りを無視して各ターゲットに対して均等にトラフィックを分散させる挙動になる。

• デフォルトSG
  • SGを指定しない場合に自動付与されるSG
  • sourceが同一SGのすべてのプロトコルに対するインバウンドがデフォルトで許可
  • destinationが0.0.0.0/0のすべてのプロトコルに対するアウトバウンドがデフォルトで許可
• カスタムSGのデフォルト
  • sourceが0.0.0.0/0のsshに対するインバウンドがデフォルトで許可

下記の記事をご参照ください。

できない。CloudHubを利用する。

InterfaceエンドポイントでSGが必要でおよびルートテーブルが不要なのは，作成されるENIに対して通信を行うためです。

HTTPS設定。Applicationレイヤーを扱うサービスであるため。

プライベートホストゾーン

正しくない。全てのルールを適用する。SGはデフォルトでトラフィックを拒否するホワイトリスト形式であるため，全てのルールを評価する際に矛盾しにくい設計になっている。

1024〜65535のいずれか。22ではないため注意。

VPC

メモリアクセス時に満たすべき性質のこと。例えば，結果整合性と強整合性が挙げられる。

• 結果整合性：データ変更後に参照されたデータが最新とは限らない
• 強整合性：データの変更が完了するまで参照できない。

インスタンスに対するストレージのマウントを簡素化するプログラム。AWSではEFSマウントヘルパーがよく利用される。

• http://bucket-name.s3-website-Region.amazonaws.com
• http://bucket-name.s3-website.Region.amazonaws.com 

不要。

HTTPステータスコードの200が返り，かつMD5チェックサムが適切であることを確認する。

検索性能が向上するため，アクセス速度が大きくなる。ハッシュだけでなく，カスタムプレフィックスを用いたパフォーマンス向上も可能である。

下記の記事を参照ください。

• ボールトアクセスポリシー：各ボールトに対して付与するリソースベースのポリシー
• ボールトロックポリシー：1つのボールトアクセスポリシーに付与してコンプライアンス要件を実現

オブジェクトロックはS3バケット内のオブジェクトを不変にするための機能であり，ボールトロックはS3 Glacierに保存されたアーカイブデータを保護するための機能である。

IAMなどの認証基盤を用いずに，URLを知っている人のみにS3へのアクセス権限を与える仕組み。URLを知っていれば誰でもアクセス可能になる点に注意する。

前。オブジェクトロックを有効にしたバケットにオブジェクトを格納するという順番。個々のオブジェクトそれぞれにオブジェクトロックを設定するのではなく，バケット作成時にオブジェクトロックを有効にするという点に注意する。

日付などのプレフィックスを用いて並列化を行う。以前はハッシュを用いてランダムなプレフィックスを設定する必要があった。少なくとも，アップロードで3500rps，データ取得で5500rpsを実現可能。

5TB。ただし，単一のPUTでアップロードできる最大オブジェクトサイズは5GBであるため，5TBのオブジェクトをアップロードするためにはマルチパートアップロードを利用する。

S3アクセスポイント

オブジェクト単位でのアクセス制御を行うとき

• SSE-S3
  • S3がキーの生成と管理を行う。最も手軽だがオブジェクトにアクセスできる人は復号可能。
• SSE-KMS
  • KMSがキーの生成と管理を行う。キーへのアクセス制限を実現でき，CloudTrailで追跡可能。
• SSE-C
  • ユーザがキーの生成と管理を行う。サービスの要件に準拠したい場合など。

バケットポリシーの referer キーを利用して特定のURLからの参照のみを許可する

EBSのバックアップは増分バックアップであるが，最新スナップショットだけでバックアップが可能な仕組みになっている。

Amazon Data Lifecycle Manager（DLM）。EBSのバックアップの有効化だけでは定期的なライフサイクルを設定することはできないため，DLMで設定する。DLMではAMI管理も自動化できる。

削除される。

• ボリューム内のデータ
• ボリュームとインスタンス間で移動されるデータ
• ボリュームから作成されたスナップショット
• スナップショットから作成されたボリューム

下記の記事をご参照ください。

ボリュームにファイルシステムを作成する。/dev/xvdaや/dev/sdfみたいなやつ。

io1ボリュームの場合50:1で，io2ボリュームの場合は500:1となる。例えば，100 GiBのio1ボリュームは最大5,000 IOPSでプロビジョニングでき，100 GiBのio2ボリュームは最大50,000 IOPSでプロビジョニングできる。

できない

EC2インスタンスとEFSのプロキシ的な役割を果たすENI。EFSはVPC外に存在するため，EC2インスタンスからはマウントターゲット経由でアクセスする。マウントターゲットはAZ毎に作成する。

EFS

下記の記事を参照ください。

汎用モード。最大I/Oモードは，レイテンシを犠牲にしてスループットを高める。

下記の記事を参照ください。

EFS標準の方が高い。

いずれも対応していない。SMBを利用するには，Amazon FSxなどを利用する。EFSはNFSv4・NFSv4・NFSv4に対応している。S3はSFTPに対応している。

• MySQL：TCP/3306
• PostgreSQL：TCP/5432
• リモートデスクトップ：TCP/3389

• スナップショット：毎日
• トランザクションログ：5分ごと

• 利点：インスタンス自体の管理が不要で自動スケーリングすること。
• 欠点：別VPCに設置されるため，VPCエンドポイント経由でAPIを噛ませて通信する必要がある。結果として，Auroraと比べて性能が出にくい。

存在する。単一のAuroraを複数のリージョンで運用できる機能。

あくまでもデータ容量のスケーリング。読み取り負荷の分散という要件には合致しない。

• MySQL/PostgreSQL以外のエンジンを利用したい：RDS
• フェールオーバを重視したい：Aurora
• コストを削減したい：多くの場合Aurora

デフォルトでは，データベースインスタンスのCPU・メモリの使用率は取得するが，スレッドのCPU・メモリの使用率は取得しない。RDSの拡張モニタリング機能を用いることで，取得できるようになる。

行えない

RDSプロキシとして接続する。RDSエンドポイントとlambda関数を接続すると，毎回新しいコネクションを張るため非効率である。

できない

まず，キーの種類には下記がある。

• パーティションキー
• ソートキー
• プライマリキー

パーティションキーは，データがどのパーティションに保存されているかを定める識別子。ソートキーはパーティションの中でどのようにデータを並び替えるかを定める識別子。プライマリキーは，パーティションキーもしくはパーティションキーとソートキーの複合キーとなる。

次に，インデックスの種類には下記がある。

• グローバルセカンダリインデックス（GSI）
• ローカルセカンダリインデックス（LSI）

グローバルセカンダリインデックスは，あるテーブルから異なるパーティションキーおよびソートキーが設定されたテーブルを作成する仕組み。ローカルセカンダリインデックスは，あるテーブルからパーティションキーはそのままで異なるソートキーのテーブルを作成仕組み。

DynamoDBの料金は下記の三要素によって定められる。

• キャパシティユニット
• ストレージ容量
• データ転送量

キャパシティユニットとは，事前に設定する書き込み/読み込み容量の上限のこと。書き込みキャパシティユニットはWCU，読み込みキャパシティユニットはRCUと称される。

• WCU
  • 1KBまでの項目を1回書き込むのに1個のCUが必要
• RCU
  • 4KBまでの項目で結果整合性を担保して1回読み込むのに0.5個のCUが必要
  • 4KBまでの項目で強力な整合性を担保して1回読み込むのに1個のCUが必要
  • 4KBまでの項目でトランザクションを1回読み込むのに2個のCUが必要

起こり得る。プロビジョニングモードでDynamoDBを使用した上で設定されたスループットを超えた場合には，自動的にスケーリングせずにHTTP400とProvisionedThroughputExceededExceptionエラーを返す。

DynamoDBストリーム。CloudWatchEventsよりもよく使われる。

Amazon DynamoDB Accelerator（DAX）

取得できない。代わりにポイントインタイムリカバリを利用してバックアップを取得する。

有さない。lambdaなどでテーブルの変更ステータスの履歴を処理する。

AppSync

連携できない

マルチAZ構成は可能だが，マルチリージョン構成できない。代わりに，スナップショットを別リージョンに保存して冗長性を確保する。

Redshiftではルートテーブルごとマネージドされているため，拡張VPCルーティングとよばれる機能を使う。

RedshiftのWLM（Work Load Management）を利用する。SQSとは連携しない。

コンピュートノード。リーダーノードに対しては料金は発生しない。

• Kinesis Data Streams：ストリーミングデータの処理
• Kinesis Data Firehose：ストリーミングデータの配信
• Kinesis Data Analytics：ストリーミングデータの分析

向いていない。

• ストリーム
  • データを格納する箱
  • もしくはストリーミングデータそのものを表す
  • 複数のシャードから構成される
  • 性能はシャード数によって左右される
• データレコード
  • シャードに格納されるデータの塊
  • BLOB/シーケンス番号/パーティションキーで構成される
• BLOB
  • ストリーミングデータそのもの
  • BLOBは一般的に「通常のデータ型のフィールドには格納することができないバイナリ」を表す
• シーケンス番号
  • データレコードの識別子
• パーティションキー
  • ハッシュ値がシャードへの割り当てに利用される
  • シーケンス番号が適切に振り分けられないとホットシャードの問題が生じる

24時間

lambdaと連携する。Kinesis Data Firehose自体に高度なフィルタリング機能は存在しないため注意。

• lambda
• S3
• Redshift
• OpenSearch Service
• Splunk

なお，DynamoDBを連携することはできないため注意する。

FirehoseのPutRecordおよびPutRecordBatch操作が無効となるため，Kinesis AgentによるFirehose配信ストリームへの書き込みができなくなること。Kinesis Data StreamsをFirehoseの配信ストリームのソースとして設定する場合は，Kinesis Agentを利用しないようにする。

Amazon Kinesis Data Streams自体にAuto scaling機能がある訳ではないため，AWS Application Auto Scalingを利用する。

• ホットシャード：想定以上のデータを受信するシャード
• コールドシャード：想定以下のデータを受信するシャード

ホットシャードを分割して，コールドシャードをマージする。分割は容量を半分にするのではなく，同じ容量のシャードを生成するイメージで，この操作はリシャーディングと呼ばれている。分割するとコストは増えるため注意。

ない。Kinesis Data Analyticsから直接S3に配信できる。

Streams。Streamsと比べてFirehoseは実行レイテンシーが高い。

できない。lambdaと連携する。

守る。

Aurora Serverless

Redisは，スナップショットの取得やレプリケーションに対応している。Memcachedは，マルチスレッドに対応していてシンプルな設計が可能。

DMSはデータベースの移行，MGNはアプリケーションの移行。MGNの方がスコープが大きいイメージ。

Redshift Spectrumはクラスター構成の手間とコストがかかり，Athenaは簡易的にS3バケット内のデータをクエリ解析できる。Redshift Spectrumのキーワードはクラスターとビックデータ解析。

標準キュー。FIFOキューはS3イベントと連携不可。

EC2フリートを用いてAutoScalingさせる方式を説明している。具体的には，各インスタンス上で構成されたSQSにおいてインスタンスあたりのバックログ と呼ばれる基準を採用する。これはキューの長さをフリートの実行キャパシティで割った値で，これを基準にしたターゲット追跡ポリシーの利用が推奨されている。

• Amazon SQS に基づくスケーリング｜AWS公式

• 可視性タイムアウト
  • キューの重複処理を防ぐことが目的
  • 最初にポーリングされたインスタンス以外から一定時間キューを隠蔽する
• 遅延キュー
  • すべてのメッセージに対してキューへの追加を遅らせる
• メッセージタイマー
  • 特定のメッセージに対してキューへの追加を遅らせる

300メッセージ/秒

10個

• IAMポリシー：自アカウント内の権限制御
• SNSポリシー：自アカウントおよび他アカウントの権限制御

前者はアイデンティティベースのIAMポリシー，後者はリソースベースのIAMポリシーとよばれている。詳しくは下記を参照されたい。

できない。SNSを利用する。SESはあくまでもアプリケーション側でメールの一斉送信などを扱いたい場合に利用する。

4日間

SQSに格納されているメッセージの総容量。SQS自体の容量ではないため注意する。

• 標準キュー：無制限
• FIFOキュー：300件/秒

データを暗号化する鍵とは別の鍵を用意し，データを暗号化する鍵自体を暗号化する技術。

されない。KMS APIが利用される。

AWS暗号化SDK。AWS KMS SDKという名前ではないため注意する。

正しくない。ローテーションではなく削除が推奨されている。

HTTP API GatewayはREST API Gatewayの主要機能に特化することで，低コストかつ特定のユースケースにおいて高性能なAPIを構築することができるサービス。

public subnetに配置したEC2とprivate subnetに配置したRDSでシンプルなリクエスト・レスポンスを実現するアプリケーション。public subnetに配置したEC2の代わりに，API Gateway + lambdaを利用すると，サーバレスなアプリケーションを構築可能。

過剰なリクエストを制限することで，サーバの負荷軽減を行うこと。具体的には，バックエンドまたは特定のクライアントを基準として，あるリクエスト数の上限を超えた場合に，HTTPステータスコードの 429 Too Many Requests を返すなどといった実装例が挙げられる。

ドリフト

• マルチサイト（アクティブ/アクティブ）
  • セカンダリではプライマリと同程度のスペックのDBとアプリケーションを起動させて同期しておき，プライマリからの切り替えを可能にする。
• ウォームスタンバイ（アクティブ/パッシブ）
  • セカンダリではスペックの低いDBとアプリケーションを起動させて同期しておき，復旧時はスケールアップすることによりプライマリからの切り替えを可能にする。
• パイロットライト（アクティブ/パッシブ）
  • セカンダリではスペックの低いDBを起動させて同期しておき，復旧時はスケールアップすることによりプライマリからの切り替えを可能にする。
• バックアップ&リストア
  • 定期的なバックアップを取得して，災害発生時には特定ポイントに復旧する。

RTOを復旧時間目標（Recovery Time Objective），RPOを目標復旧時点（Recovery Point Objective）とすると，これらの方式は下表のようにまとめられる。

長時間のDDoS攻撃を受けてコストが急増した場合に，保護を受けられること。

Route53。マスターアカウントやルートアカウントが介在するとマニュアルの準備が必須になり，自動化という要件と合致しなくなる。

できない。

• EC2リザーブドインスタンス
• RDSリザーブドインスタンス
• ElastiCacheリザーブドキャッシュノード
• DynamoDBリザーブドキャパシティ
• Redshiftリザーブドノード

リアルタイムストリーミング処理

AWS Application Migration Service（MGN）。以前はAWS Server Migration Service（SMS）が利用されていた。

適切な方針ではない。ベストプラクティスとしては，タグは少なすぎるよりも多く利用した方がよく，必要に応じてタグの変更を行うべきであるとされている。ただし，将来的な変更の影響を見越してタグの設計を行う必要がある点に注意する。

任意のタイミングで取得するバックアップのこと。AWS Backupで設定できる。