AWS CLF 1問1答（クラウドプラクティショナー問題集）

A.オンプレミス（On-premises）。

サーバーが必要になってから納品・設置まで数週間〜数か月かかり、使わなくなっても機器は残り続けるのがクラウドとの決定的な違いです。

A.使った分に応じて払う従量課金型。

電気や水道と同じで「契約して使った分だけ払う」形になるため、必要なときに必要な分だけIT資源を借りられます。

A.固定費が変動費に変わる。

先に大金を払わなくてよくなるという意味で、CLF試験では「先行投資が不要になる」「資本的支出が運用的支出になる」といった言い換えで出題されます。

A.キャパシティ予測が不要になる。

必要な量を後から増減できるため、予測を外したときの無駄な設備や機会損失が発生しません。「スケールによるコストメリット」はAWS側の調達規模の話なので別物です。

A.スケールによるコストメリット（規模の経済）。

利用者側の使い方ではなく、AWSという事業者側の規模が生む利点である点が「固定費が変動費に変わる」との違いです。

A.IaaS（Infrastructure as a Service）。代表例はAmazon EC2。

自分で管理する範囲がもっとも広い形態です。OS以上を任せたいならPaaS、完成品をそのまま使いたいならSaaSになります。

A.PaaS（Platform as a Service）。代表例はAWS Elastic BeanstalkやAmazon RDS。

RDSはデータベースの管理をAWSが肩代わりするためPaaSに位置づけられます。同じデータベースでもEC2に自分でインストールすればIaaSの使い方です。

A.SaaS。

SaaSはインフラもアプリも意識せず完成したソフトウェアをそのまま使う形態で、GmailやAmazon Chimeが例です。IaaSからPaaS、SaaSへ進むほど自分で面倒を見る範囲が減ります。

A.ハイブリッド。

既存資産や、法令上クラウドに置けないデータを残しつつ一部をクラウド化したい場合に選ばれる、段階的移行の王道パターンです。

A.AWS Direct Connect。

暗号化された仮想的な専用回線であるVPNと並ぶ選択肢で、どちらも社内データセンターとAWSをつなぐために使われます。

A.アベイラビリティーゾーン（AZ）。

多くのリージョンには3つ以上のAZがあり、複数AZに分散すれば1つのAZで災害や故障が起きてもサービスを継続できます。地理的に離れたエリア単位はリージョンです。

A.エッジロケーション。

リージョンよりはるかに数が多く、応答速度の高速化が目的です。リージョンやAZのようにシステム本体を構築する場所ではありません。

A.運用上の優秀性、セキュリティ、信頼性、パフォーマンス効率、コスト最適化、持続可能性。

「運用・セキュリティ・信頼性・性能・コスト・環境」の6つの評価軸と覚えます。持続可能性は比較的新しく追加された柱です。

A.信頼性。

止まらない・戻せるという可用性の観点が信頼性です。リソースを効率よく使って需要の変化に対応するのはパフォーマンス効率で、目的が異なります。

A.AWSとの契約・請求（支払い）の単位。

アカウントの中でAWSの全リソースを扱えます。誰が何をできるかを分けるのはアカウントではなくIAMの役目です。

A.ルートユーザー。

アカウント作成に使ったメールアドレスとパスワードでサインインします。他のどのユーザーにもできない操作ができるため、日常の作業には使わないのが鉄則です。

A.多要素認証（MFA）の有効化。

パスワードが漏えいしただけでは侵入されなくなります。あわせてルートユーザーのアクセスキーは原則作成しないことも推奨されています。

A.マネジメントコンソール、AWS CLI、SDK、IaC。

コンソールはブラウザのGUI、CLIはコマンドライン、SDKは各言語のライブラリ、IaCはCloudFormationやAWS CDKで構成をコードとして書く方法です。

A.AWS API。

入り口が違うだけで行き着く先は同じなので、コンソールでできることは基本的にCLIやSDKでもでき、その逆も同様です。

A.IaC（Infrastructure as Code）。AWS CloudFormationやAWS CDKが代表例。

変更履歴もコードとして残せるのが利点です。同じ自動化でもCLIは手順を実行するスクリプト寄りで、IaCは環境の状態そのものを記述します。

A.レイテンシ（利用者との近さ）、料金、法令・データ所在地の要件、利用したいサービスの提供状況。

「近さ・値段・法令・サービスの有無」の4点セットで覚えます。サービスの価格や新機能の提供はリージョンごとに異なります。

A.東京リージョン。

日本のユーザーに近く低遅延で、個人情報保護法などの国内法令への対応もしやすいためです。国内のもう一つの選択肢として大阪リージョンがあります。

A.コンピュート。

実際に処理を行う計算資源のカテゴリで、EC2は仮想サーバーを借りる形、Lambdaはサーバーを管理せずコードだけ動かす形です。

A.ネットワーク。

VPCは自分専用の仮想ネットワーク、Route 53はドメイン名の管理、CloudFrontはコンテンツ配信です。データを置くS3やEBSはストレージ、誰が何をできるかを管理するIAMはセキュリティに分類されます。

A.IaaS（Infrastructure as a Service）。

EC2は仮想サーバーを貸し出すだけで、OSより上のレイヤー（OS設定・ミドルウェア・アプリ）は利用者が管理する。この責任分担がIaaSの定義そのもので、EC2はその代表例として問われる。

A.停止（Stop）。終了するとインスタンスは削除される。

停止は電源オフに近く、再び起動できる。課金も起動している時間に対して発生するため、停止中はストレージ分を除きインスタンス自体には課金されない。

A.リザーブドインスタンス（RI）。

常時稼働することが分かっているサーバー向けの選択肢。事前コミットが前提なので、使う量が読めない段階ではオンデマンドのほうが安全になる。

A.スポットインスタンス。

AWSの余剰計算力を使うため最安だが、2分前の通知で中断される。バッチ処理やCI/CDのように途中で止まってもよい処理に向き、途中経過を保存できない重要な処理には不向き。

A.Savings Plans。

特定の構成に縛られるリザーブドインスタンスと違い、金額ベースのコミットなので構成変更に強い。使用量は安定しているが構成は変えたい、というケースで選ぶ。

A.AMI（Amazon Machine Image）。

同じAMIから起動すればまったく同じ環境のサーバーを何台でも複製できる。カスタマイズしたAMI（ゴールデンイメージ）を作っておけば、同一構成のサーバーを一瞬で量産できる。

A.mはファミリー（汎用）、5は世代、largeはサイズ。

ファミリーは用途の系統を表し、汎用はt・m、CPU重視はc、メモリ重視はr・x、ストレージ重視はi・d、GPUはp・gとなる。世代の数字が大きいほど新しい。

A.ALB（Application Load Balancer）。

ALBはHTTP/HTTPSというレイヤー7を理解するため、内容に応じた振り分けができる。NLBはTCP/UDPのレイヤー4で超高速に処理し、固定IPや極めて高い性能が必要な場面で使う。

A.Auto Scaling。台数を増やすのがスケールアウト、減らすのがスケールイン。

ELBが「アクセスの振り分け」を担当するのに対し、Auto Scalingは「台数の自動調整」を担当する。この役割分担がそのまま問われる。

A.垂直スケーリング（スケールアップ）。

垂直は台数が変わらないため単一障害点が残る。台数を増やす水平スケーリングはELBと組み合わせることで可用性と弾力性の両方を高められ、クラウドではこちらが基本戦略になる。

A.実行された回数と実行時間（ミリ秒単位）に対してのみ。

呼び出されていない間は料金がかからない点が、常時起動して時間課金されるEC2との決定的な違い。イベントに反応して短時間動く処理ではコストを大きく抑えられる。

A.イベント駆動。S3へのアップロードやAPIへのリクエスト、指定時刻などをきっかけに実行される。

Lambdaは「サーバー管理不要」「イベント駆動」「実行した分だけ課金」の3点をセットで覚える。リクエストが増えればLambda自体が並行実行数を自動で増やす。

A.Fargate。

ECS・EKSは「コンテナの置き場所を管理する仕組み」で、Fargateは「そのサーバー管理をなくすオプション」という関係。EKSはマネージドなKubernetes、ECSはAWS独自のオーケストレーションにあたる。

A.Elastic Beanstalk。

「とにかく早くアプリを公開したい」場合の選択肢。定額でシンプルなVPSのLightsail（小規模サイト・個人開発向け）、大量のバッチジョブを実行するAWS Batchと個性で区別すると覚えやすい。

A.ブロックはEBS、ファイルはEFS、オブジェクトはS3。

「OSに直接ディスクとして見せたいか」「複数サーバーでフォルダ共有したいか」「大量のファイルをAPI経由で保存・配信したいか」という目的の違いで使い分ける。

A.オブジェクトストレージ。

HTTP(S)経由のAPIでアクセスするのが特徴で、S3がその代表。OSから生のディスクとして見えるブロックストレージや、階層構造を持つファイルストレージとはアクセス方法自体が異なる。

A.バケット。名前はAWS全体でユニークである必要がある。

バケットの中に、ファイル本体・キー・メタデータからなるオブジェクトを保存する。自分のアカウント内だけでなく全世界で一意という点が問われやすい。

A.99.999999999%。

データが自動的に複数の設備へ複製されるため、極めて「消えにくい」設計になっている。耐久性（データが失われない度合い）であって、可用性（アクセスできる度合い）とは別の指標である点に注意。

A.バージョニング。

S3はHTML・CSS・JS・画像だけの静的Webサイトホスティングもできるが、それとは別に、誤操作からの復元を担うのがバージョニングである。

A.S3 One Zone-IA。

複数AZに保存するStandard-IAより安いが、そのAZが失われるとデータも失われる。再作成が可能な低頻度アクセスデータに向く。

A.S3 Glacier Deep Archive。

同じGlacierでも、Instant Retrievalはミリ秒単位、Flexible Retrievalは数分〜数時間で取り出せる。法令保存など長期間ほぼ開かないデータがDeep Archiveの用途。

A.ライフサイクルルール。

アクセス頻度が低いクラスほど保存料金は安いが取り出しに時間や料金がかかる、というトレードオフを、手作業なしで運用に落とし込む仕組み。アクセス頻度が読めない場合はIntelligent-Tieringで自動判定させる手もある。

A.1台。

EBSは1つのAZ内でのみ使える仮想ディスク（ブロックストレージ）で、OSの起動ディスクやデータベースのデータ領域が典型的な用途。複数台での共有はEFSの役割になる。

A.EFS（Elastic File System）。

EFSは複数AZにまたがって多数のインスタンスから同時マウントでき、容量も自動で拡張・縮小される。EBSのある時点の状態はスナップショットとしてS3にバックアップできる。

A.AWS Snow Family（Snowballなど）。

物理デバイスを取り寄せてデータをコピーし、AWSへ送り返す方式。回線が使えてオンラインで自動同期したい場合はDataSyncを選ぶ、という対比で覚える。

A.AWS Storage Gateway。

既存システムを大きく変えずにクラウドストレージを併用したい場合に使う。一度きりの大容量移送はSnow Family、オンラインでの継続的な同期はDataSyncと役割が分かれる。

A.マネージドサービス。

利用者は「サーバーをどう保守するか」ではなく「どんなデータをどう使うか」に集中できる。EC2に自分でMySQLを入れる形はマネージドではなく、運用作業はすべて利用者の責任になる。

A.高可用性。別のアベイラビリティーゾーンにスタンバイを用意し、障害時に自動でフェイルオーバーさせるため。

スタンバイは同期レプリケーションで常に同じ内容に保たれる。読み取り性能を上げるための仕組みではない点がリードレプリカとの決定的な違い。

A.リードレプリカ。

読み取り専用のコピーを複数作って性能を拡張する仕組みで、目的は「性能」。「障害対策」が目的のマルチAZと混同しやすいので、目的で区別して覚える。

A.MySQLとPostgreSQL。

AuroraはAWSが独自開発したエンジンだが、既存のMySQL/PostgreSQL資産をそのまま活かせる。RDSという製品ファミリーの中の1つのエンジンという位置づけ。

A.Aurora Serverless。

通常のAuroraはインスタンスの容量を指定して使うが、Aurora Serverlessは負荷に合わせて自動で伸縮するため、変動の大きいワークロードに向く。Auroraはストレージ容量も自動拡張される。

A.NoSQLデータベース。キーバリューやドキュメント形式でデータを保存する。

1桁ミリ秒単位の応答速度と、事実上無制限に近い規模までのスケールが特徴。SQLで複雑な検索やJOINを行う用途はRDS/Auroraの担当。

A.よい。スキーマレスなので項目ごとに柔軟な構造を持てる。

あらかじめ決めた表構造に従うリレーショナルデータベースとの大きな違い。可変な形式のデータ（セッション情報・ランキング・IoTデータなど）を扱いやすい。

A.ない。完全サーバーレスで容量管理を意識しなくてよい。

RDS/Auroraはインスタンスサイズを選んで運用するが、DynamoDBはサーバーの存在を意識せずに使える。この違いもシナリオ問題の判断材料になる。

A.Amazon ElastiCache。

RedisとMemcachedという2つのキャッシュエンジンに対応する。データベース本体への負荷を減らすのが役割で、分析用途のRedshiftとは目的がまったく違う。

A.前者がOLTP、後者がOLAP。

OLTPはRDS・Aurora・DynamoDBが得意で、OLAPはデータウェアハウスであるRedshiftが得意。試験では「分析基盤が欲しい」というシナリオでRedshiftを選ばせる形で問われる。

A.Amazon Neptune。グラフデータベースのサービス。

つながり自体が主役のデータに向く。表形式で複雑な関係をSQLで扱うRDS/Auroraや、キー指定の高速アクセスが中心のDynamoDBとは選ぶ軸が異なる。

A.AWS DMS（Database Migration Service）。

移行専用のサービスで、データベースそのものではない。CLF試験ではサービス名と用途の対応（用途からサービスを逆引きする形）で問われやすい。

A.Amazon VPC（Virtual Private Cloud）。

他の利用者のネットワークとは完全に分離され、自分だけの仮想的なデータセンターのように扱える。EC2やRDSはこのVPCの中に配置される。

A.CIDR（サイダー）ブロック。

この範囲の中をサブネットに分割し、EC2やRDSなどのリソースにIPアドレスを割り当てていく。VPCという「敷地」の広さを決める作業にあたる。

A.プライベートサブネット。

プライベートサブネットはインターネットから直接アクセスできない。外部からのアクセスを受けるWebサーバーはパブリックサブネットに置く、という組み合わせがWebアプリケーションの定番構成。

A.NATゲートウェイ。

ソフトウェアの更新を取りに行くような一方向の出口として使う。双方向の出入り口であるインターネットゲートウェイ（IGW）との違いが頻出ポイント。

A.ルートテーブル。

サブネットがパブリックかプライベートかは、実質的にルートテーブルがインターネットゲートウェイへの経路を持つかどうかで決まる。

A.セキュリティグループはインスタンス単位、ネットワークACLはサブネット単位。

通信はまずサブネットの門番であるネットワークACLを通り、次にインスタンスの門番であるセキュリティグループを通ってリソースに届く。

A.ネットワークACL。セキュリティグループは許可ルールのみ。

「特定のIPアドレスを明示的に拒否したい」という要件はネットワークACLでしか実現できない。基本的な用途はセキュリティグループだけで足りることが多い。

A.ステートフル。行きの通信を許可すると、戻りの通信は自動的に許可される。

ネットワークACLはステートレスなので、行きと戻りを別々にルール設定する必要がある。また評価方法も違い、ネットワークACLは番号の若い順に評価して最初に一致した時点で確定する。

A.Amazon Route 53。

名前の「53」はDNSが使う通信ポート番号にちなむ。ドメイン登録、DNSルーティング、ヘルスチェックの3つが主な機能。

A.フェイルオーバールーティング。

新バージョンへ10%だけ流すような比率での振り分けは「加重」、最も応答が速いリージョンへ向けるのは「レイテンシベース」。目的とポリシー名の対応で覚える。

A.エッジロケーション。

利用者から見て最も近い拠点から配信するため表示が速くなる。キャッシュが無ければオリジンへ取りに行き、以降のためにキャッシュする。

A.オリジン。S3・EC2・ALB（ロードバランサー）などを指定できる。

多くのリクエストをエッジのキャッシュで処理するのでオリジンの負荷が減る。HTTPSでの暗号化配信や、AWS ShieldとのDDoS対策連携も利点。

A.AWS Site-to-Site VPN。

比較的手軽に短期間で構築できるのが利点だが、通信品質はインターネットの状況に左右される。小規模・迅速な接続やバックアップ回線に向く。

A.AWS Direct Connect。物理的な専用線を引く方法。

インターネットを経由しないため安定して高速だが、物理配線が必要で構築に時間がかかる。まずVPNで素早くつなぎ、要件が大きくなってからDirect Connectへ移行する構成もよく使われる。

A.AWS。クラウド「の」セキュリティ（Security of the Cloud）にあたる。

物理設備・ネットワークインフラ・ハイパーバイザーは利用者が手を出せない領域なのでAWSの責任。対して、データの暗号化やOSの設定、IAMの設定はクラウド「内」のセキュリティで利用者の責任になる。

A.利用者。ネットワークの設定はクラウド「内」のセキュリティにあたる。

「設定・データ側は利用者、物理・基盤側はAWS」が境界線。マネージドサービスを使って利用者の作業が減っても、データの中身と設定ミスの責任は常に利用者側に残る。

A.前者がIAMユーザー、後者がIAMロール。

ユーザーはパスワードやアクセスキーを持つ恒久的なIDで、ロールはパスワードを持たずEC2やLambda、他アカウントのユーザーが一時的に引き受ける。人にはユーザー・グループ、モノや一時的な作業にはロール、と使い分ける。

A.ポリシー。JSON形式のドキュメントで定義する。

ポリシーはEffect（許可か拒否か）・Action（対象の操作）・Resource（対象のリソース）の3点セットで書き、ユーザー・グループ・ロールにアタッチして初めて実際の権限になる。「誰が」の部分はアタッチされた側で決まる。

A.最小権限の原則（Principle of Least Privilege）。

「とりあえず全部許可」は事故が起きたときの被害範囲をそのまま広げてしまう。IAM自体は無料で使え、グループにポリシーを付けて所属ユーザーへ一括適用すると管理しやすい。

A.MFA（多要素認証）。ルートユーザーと管理者権限を持つIAMユーザーに必須。

「知っているもの（パスワード）」と「持っているもの（デバイス）」を組み合わせるため、パスワードが漏れただけでは突破されない。試験で「アカウント保護の最初の一手」を問われたらMFAの有効化とルートユーザーの非常用化を思い出す。

A.IAM Identity Center（旧AWS SSO）。

アカウントごとにIAMユーザーを増やすのではなく、ロールを引き受ける形に寄せて権限を一元管理するのがベストプラクティス。アクセスキーはコードに直接書かず、不要になったら削除し定期的にローテーションする。

A.保管時はディスクやDBに保存中のデータ、転送時はネットワークを通信中のデータ。

保管時（Encryption at Rest）はディスクを物理的に抜き取られても中身が読めないようにするもの。転送時（Encryption in Transit）の代表的な方式はTLS/SSLで、盗聴されても内容が読めないようにする。

A.利用者専有の物理ハードウェアで鍵を管理する必要があるかどうか。必要ならCloudHSM、通常はKMS。

KMSはAWSがマネージドの共有基盤で鍵を管理し、S3やEBS、RDSなど多くのサービスと統合されている。規制上「専有ハードウェアが必須」という場合だけCloudHSMを選ぶ。

A.AWS Secrets Manager。

機密情報をコードに直書きせず、アプリから安全に取得できるようにする。SSL/TLS証明書の作成・管理・自動更新はAWS Certificate Manager（ACM）で、役割が違うので混同しない。

A.DDoSはAWS Shield、Webアプリへの攻撃はAWS WAF。

Shieldはネットワーク層・トランスポート層への大規模なDDoS攻撃を自動的に防御し、標準保護は無料。WAFはHTTP/HTTPSリクエストの内容を検査して悪意あるパターンをブロックするルールを設定する。

A.Amazon GuardDuty。

GuardDutyは「中で見張る」検知のサービス。EC2やコンテナイメージをスキャンして既知の脆弱性を洗い出すのはAmazon Inspectorで、対象が挙動か脆弱性かで区別する。

A.Amazon Macie。

Macieは機械学習でS3内のデータの中身を分析する。GuardDutyなどが検知した問題について関連ログを可視化し根本原因を調査するのはAmazon Detectiveで、こちらは「起きたことを調べる」役割。

A.AWS Artifact。無料で利用できる。

自社の監査対応で「AWS側の証拠」として提出できる窓口がArtifact。自社リソースの設定変更を継続的に記録し、ルールに沿っているか評価するのはAWS Configで、役割が逆方向になる。

A.AWS Config。

Configはリソースの設定変更を継続的に記録・追跡し、ルールへの準拠を評価する。そのデータを活用して監査に必要な証拠を継続的に収集し、監査準備を効率化するのがAWS Audit Manager。

A.認証・認可はIAM、調査はDetective。

CLFの設問は「この状況ではどのサービスを使うべきか」の形で出るため、防ぐ話（Shield・WAF）か、見つける話（GuardDuty・Inspector）か、鍵やデータの話（KMS・Secrets Manager・Macie）か、証明する話（Artifact・Config）かでカテゴリから絞り込むと答えにたどり着きやすい。

A.Amazon CloudWatch。

CloudWatchはメトリクス・ログ・アラーム・ダッシュボードの4機能を持ち、「今どうなっているか（性能・状態）」を見るサービス。「誰が操作したか」を追うCloudTrailとは役割がはっきり違う。

A.Auto Scalingを起動してサーバーの台数を自動的に増やすなどのアクション。

通知はSNSでメールを送る形になるが、CloudWatchの真価は「監視して自動で手を打つ」までをセットにできる点にある。CPUが80%を超えたら台数を増やす、といった運用が組める。

A.AWS CloudTrail。

マネジメントコンソール・CLI・SDKからの操作はすべてAPI呼び出しなので、CloudTrailはそれらを漏れなく記録する。不正操作の調査や変更の証拠に使う。

A.前者はCloudTrail、後者はAWS Config。

CloudTrailは操作（誰がやったか）、Configは構成（あるべき姿か）を見る。CPUなどの性能監視はCloudWatchで、この3つの区別はCLF試験の頻出ポイント。

A.設定変更の履歴（構成の変化の追跡）と、ルールへの準拠状況の継続的な評価。

「S3バケットは暗号化されているべき」といったルールを定めておけば、そこから外れた構成を継続的に検出できる。名前は似ているがCloudWatchはメトリクスとログ、CloudTrailはAPI操作の記録で、見ているものが違う。

A.AWS Organizations。

主なメリットは一括請求（Consolidated Billing）とSCPによるガードレールの2つ。開発用・本番用・部署ごとにアカウントが増えたときの統治の土台になる。

A.すべてのアカウントの使用量が合算されるため、ボリューム割引やリザーブドインスタンスの共有が効くから。

請求を親（管理）アカウントにまとめられるので支払い管理も楽になる。アカウントごとにバラバラに使うより、合算したほうが割引の階段を上りやすい。

A.サービスコントロールポリシー（SCP）。

SCPはOrganizationsのガードレール機能。なお、Organizationsを土台にベストプラクティスに沿った複数アカウント環境（ランディングゾーン）を自動でセットアップするのはAWS Control Towerで、役割が異なる。

A.AWS Trusted Advisor。

使われていないリソース、公開されすぎたポート、MFA未設定、上限に近づいているクォータなどを指摘してくれる。無料のBasicサポートではチェック項目が限られ、Business以上のサポートプランで全項目が開放される。

A.AWS Health Dashboard。

「AWSで障害が起きていないか」「自分のリソースに予定されたメンテはあるか」を確認する場所。環境を点検して改善を助言するTrusted Advisorとは目的が違う。

A.AWS CloudFormation。作られたリソースの集まりをスタックと呼ぶ。

これがIaC（Infrastructure as Code）の実現手段で、再現性・バージョン管理・一貫性という利点が生まれる。同じテンプレートから開発用と本番用の環境を寸分違わず作れる。

A.AWS Systems Manager。

CloudFormationが「作る」を自動化するのに対し、Systems Managerは「運用する」を自動化する、と対比で捉えると混同しない。

A.従量課金（Pay-as-you-go）。使った分だけを後払いする。

オンプレミスのように先に大きな設備投資をするのではなく、実際に使ったメーターの分だけ請求される。前払いの固定費が不要な点がクラウドの費用面の利点。

A.外へ出ていく通信（アウトバウンド）。

インバウンド（AWSへのアップロード）は基本的に無料で、アウトバウンドが課金対象。「イン無料・アウト課金」は試験で狙われる定番のひっかけ。

A.12か月間無料・常に無料・トライアル（短期のお試し）の3種類。

EC2の t2.micro 月750時間は「12か月間無料」、Lambdaの月100万リクエストは期限のない「常に無料」にあたる。どの枠に属するかを問う形で出る。

A.TCO（総所有コスト）。

見えている機器代だけを比べると誤った結論になるため、運用にかかる費用まで含めて比較する。AWSは初期投資と運用の手間を減らせるためTCOで有利になりやすい。

A.スポットインスタンス。

AWSの余剰キャパを最大9割引で使えるが、キャパが必要になると中断される。止まると困る本番用途には向かず、中断耐性のある処理が前提。

A.RIは1年または3年の「利用期間」、Savings Plansは「1時間あたりの利用金額」をコミットする。

どちらも長期利用を約束する代わりの割引だが、Savings Plansは利用量ベースなのでインスタンスの種類変更などに強く、RIより柔軟。

A.使わないものは止める、大きすぎるものを適正サイズにする（ライトサイジング）、長く使うものはコミットして割引を受ける。

ストレージ側ではS3のストレージクラスを使い分け、アクセスの少ないデータを安いクラスへ移すのが同じ考え方の実践。

A.AWS Pricing Calculator。

事前の見積もりがCalculator、事後の分析がCost Explorer。時間軸で覚えると混同しない。提案書や予算作りの場面で使う。

A.可視化・分析はAWS Cost Explorer、予算アラートはAWS Budgets。

Cost Explorerは実績の傾向をつかむ事後分析、Budgetsは予算超過を見張って未然に防ぐ役割。名前と役割の対応がそのまま設問になる。

A.AWS Cost and Usage Report（CUR）。

Billing Consoleは今月の請求額や内訳を見る基本画面、CURはそれより粒度の細かい明細で、分析基盤に取り込んで使う。

A.一括請求（Consolidated Billing）。

AWS Organizationsの機能。費用をプロジェクトや部署の単位で仕分けたいときは、これとは別に「コスト配分タグ」を使う。

A.Business以上。

Basicは技術サポートなし、Developerは平日・メールのみ。Trusted Advisorの全項目が使えるようになるのもBusiness以上で、本番運用なら最低でもBusinessが目安。

A.Enterprise。

サポートは Basic・Developer・Business・Enterprise On-Ramp・Enterprise の5段階で、専任TAMは最上位のEnterpriseの特徴。On-Rampは24/7に一部の専門支援が付く中規模向け。

A.AWS Marketplace。

多くは従量課金で、支払いはAWSの請求にまとめられる。自前で構築せず「買ってくる」選択肢。導入支援を頼む相手はAWS Partner Network（APN）で、役割が違う。

A.65問・90分。

単純計算で1問あたり80秒ほど。迷った問題に時間を使いすぎないよう、時間配分の目安として覚えておく。

A.1000点満点中700点。

素点の正答率そのものではなくスケールドスコアで判定される。出題形式は1つ選ぶ多肢選択と、2つ以上選ぶ複数選択の2種類。

A.「クラウドのテクノロジーとサービス」で34パーセント。

次に大きいのがセキュリティとコンプライアンスの30パーセントで、この2つだけで6割を超える。配点の大きい順に復習するのが効率的。

A.12パーセント。

残りは「クラウドの概念」が24パーセント。請求ドメインは配点こそ小さいが、料金モデルやサポートプランの境界線など、覚えれば確実に取れる問題が多い。

A.順にS3・EBS・EFS。

長期保管のアーカイブはGlacier。用途の言い回しからサービス名を選ばせる形で問われるので、カテゴリ＋ひとことの対応で覚える。

A.DNSはRoute 53、CDNはCloudFront。

どちらもネットワーク系で名前が並びやすい。オンプレミスとの専用線はDirect Connect、仮想ネットワーク本体はVPCと、役割ごとに1対1で押さえる。

A.セキュリティグループはインスタンス単位、ネットワークACLはサブネット単位。

さらにSGはステートフルで許可ルールのみ、NACLはステートレスで許可と拒否の両方を書ける。CLFで毎回のように問われる代表的なペア。

A.CloudWatchは監視（性能）、CloudTrailは監査（誰が操作したか）、Configは構成（設定の変化）。

「APIの呼び出し履歴をたどりたい」ならCloudTrail、「リソース設定が変わった記録を追いたい」ならConfig、と設問の言い回しで切り分ける。

A.ShieldはDDoS攻撃、WAFはSQLインジェクションやXSSなどのWebアプリケーション攻撃。

大量の通信で押しつぶす攻撃がShieldの担当、リクエストの中身が悪意あるものかを見てブロックするのがWAFの担当。

A.IAMユーザーは人に対する恒久的なID、IAMロールは一時的に引き受ける権限（サービスなどに付与する）。

EC2からS3へアクセスさせたい場合は、アクセスキーを埋め込むのではなくロールを付与するのが正解。「一時的な認証情報」という言葉が出たらロール。

A.リージョンは地理的なエリアで、AZはそのリージョン内にある独立したデータセンター。

1つのリージョンは複数のAZで構成され、複数AZに分散させることで可用性を高める。地理的に離した冗長化はマルチリージョン、と混同しないこと。

A.アソシエイトレベルで、代表はSAA（ソリューションアーキテクト アソシエイト）。

認定は基礎→アソシエイト→プロフェッショナル／専門とレベルが上がる。アソシエイトにはほかにSOA（運用）とDVA（開発）がある。