AWS クラウドプラクティショナー(CLF-C02)想定問題集
クラウドテクノロジーとサービスの要点整理と想定問題
公式の試験ガイドの「コンテンツ分野 3: クラウドテクノロジーとサービス」にあたる分野です。まず要点整理で全体をつかみ、下の演習で 97 問を 1 問ずつ解けます。答えると A〜D すべての解説が出ます。
この分野の小項目
- 3.1 AWS へのアクセス方法(コンソール・API・SDK・CLI)(4 問) AWS サービスにアクセスするさまざまな方法を知り、プログラムによるアクセス(API、SDK、CLI など)や AWS マネジメントコンソールなどのオプションを決定する。
- 3.1 IaC と 1 回限り/反復可能な作業(5 問) プロビジョニングと運用のさまざまな方法を知る。Infrastructure as Code(IaC)を含むオプションを決定し、要件を評価して 1 回限りのオペレーションと反復可能なプロセスのどちらを使うかを判断する。
- 3.1 デプロイモデル(クラウド・ハイブリッド・オンプレミス)(3 問) クラウドデプロイモデルの種類(クラウド、ハイブリッド、オンプレミスなど)を特定する。
- 3.2 リージョン・アベイラビリティーゾーン・エッジロケーション(4 問) AWS リージョン、アベイラビリティーゾーン、エッジロケーションと、それらの関係を説明する。エッジロケーションの利点を理解する。
- 3.2 複数 AZ による高可用性(4 問) 複数のアベイラビリティーゾーンを使用して高可用性を実現する方法を説明し、アベイラビリティーゾーン間で単一障害点が共有されないことを認識する。
- 3.2 複数リージョンを使うケース(4 問) 複数のリージョンを使用するケース(ディザスタリカバリ、事業の継続性、エンドユーザーのための低レイテンシー、データ主権など)を説明する。
- 3.3 EC2 とインスタンスタイプ(5 問) AWS のコンピューティングサービスを知り、さまざまな Amazon EC2 インスタンスタイプ(コンピューティング最適化、ストレージ最適化など)の適切な使用方法を認識する。
- 3.3 コンテナ(ECS・EKS)(4 問) さまざまなコンテナオプション(Amazon ECS、Amazon EKS など)の適切な使用方法を認識する。
- 3.3 サーバーレス(Lambda・Fargate)(4 問) さまざまなサーバーレスコンピューティングオプション(AWS Fargate、AWS Lambda など)の適切な使用方法を認識する。
- 3.3 自動スケーリングとロードバランサー(5 問) 自動スケーリングにより提供される伸縮性を認識し、ロードバランサーの目的を特定する。
- 3.4 マネージド DB とリレーショナル DB(RDS・Aurora)(4 問) EC2 でホストするデータベースと AWS マネージドデータベースのどちらを使うべきかを判断する。リレーショナルデータベース(Amazon RDS、Amazon Aurora など)を特定する。
- 3.4 NoSQL とインメモリ DB(DynamoDB・ElastiCache)(4 問) NoSQL データベース(Amazon DynamoDB など)とメモリベースのデータベース(Amazon ElastiCache など)を特定する。
- 3.4 データベース移行(DMS・SCT)(3 問) データベース移行を理解し、データベース移行ツール(AWS Database Migration Service [AWS DMS]、AWS Schema Conversion Tool [AWS SCT] など)を特定する。
- 3.5 VPC の構成要素(サブネット・ゲートウェイ)(4 問) AWS のネットワークサービスを知り、VPC コンポーネント(サブネット、ゲートウェイなど)を特定する。
- 3.5 VPC のセキュリティ(セキュリティグループ・ネットワーク ACL)(4 問) VPC でのセキュリティ(ネットワーク ACL、セキュリティグループ、Amazon Inspector など)を理解する。
- 3.5 Route 53 と AWS への接続(VPN・Direct Connect)(4 問) Amazon Route 53 の目的を理解し、AWS へのネットワーク接続オプション(AWS VPN、AWS Direct Connect など)を特定する。
- 3.6 S3 とストレージクラス・ライフサイクル(4 問) オブジェクトストレージの用途を特定し、Amazon S3 ストレージクラスの違いを認識する。ライフサイクルポリシーのユースケースを理解する。
- 3.6 ブロックとファイル(EBS・インスタンスストア・EFS・FSx)(4 問) ブロックストレージソリューション(Amazon EBS、インスタンスストアなど)とファイルサービス(Amazon EFS、Amazon FSx など)を特定する。
- 3.6 Storage Gateway と AWS Backup(3 問) キャッシュ済みファイルシステム(AWS Storage Gateway など)を特定し、AWS Backup のユースケースを理解する。
- 3.7 AI/ML サービス(4 問) AWS の AI/ML サービスと、各サービスが実行するタスク(Amazon SageMaker AI、Amazon Lex など)を理解する。
- 3.7 分析サービス(4 問) データ分析のためのサービス(Amazon Athena、Amazon Kinesis、AWS Glue、Amazon Quick Sight など)を特定する。
- 3.8 アプリケーション統合(EventBridge・SNS・SQS)(4 問) アプリケーション統合サービス(Amazon EventBridge、Amazon SNS、Amazon SQS)を知り、メッセージの配信やアラートと通知の送信に適切なサービスを選ぶ。
- 3.8 ビジネスアプリケーションとカスタマーイネーブルメント(Connect・SES・サポート)(3 問) ビジネスアプリケーションサービス(Amazon Connect、Amazon SES)とカスタマーイネーブルメントサービス(AWS サポートなど)を知り、ビジネスのニーズやサポートに適切な選択肢を選ぶ。
- 3.8 デベロッパーツール(CodeBuild・CodePipeline・X-Ray)(3 問) デベロッパーツールのサービスと機能(AWS CodeBuild、AWS CodePipeline、AWS X-Ray など)を知り、アプリケーションの開発、デプロイ、トラブルシューティング向けツールを特定する。
- 3.8 エンドユーザーコンピューティング・Amplify・IoT(3 問) エンドユーザーコンピューティングサービス(Amazon AppStream 2.0、Amazon WorkSpaces、Amazon WorkSpaces Secure Browser)、フロントエンドウェブとモバイルのサービス(AWS Amplify)、IoT サービス(AWS IoT Core など)を知り、用途に合うサービスを特定する。
要点整理
AWS へのアクセス方法(コンソール・API・SDK・CLI)
AWS の操作方法は 4 つ:画面・コマンド・プログラム・ブラウザのシェル
AWS の操作は、裏側ではすべて API の呼び出しです。人がどこから操作するかで、使う道具が変わります。
AWS マネジメントコンソールはブラウザで開く管理画面です。プログラミングなしで、各サービスの画面に一か所から入れます。
AWS CLI はコマンドで AWS を操作するオープンソースのツールです。コマンドをシェルスクリプトに書けば、決まった作業を自動化できます。
AWS SDK は Python や Java などの言語向けのライブラリです。署名の計算、再試行、エラー処理を引き受けるので、アプリに AWS の機能を組み込むときに使います。
AWS CloudShell はコンソールから起動するブラウザのシェルです。サインインの認証情報がそのまま使え、AWS CLI も入っています。PC にツールを入れられないときに便利です。
| こうしたい | まず思い出す手段 |
|---|---|
| 画面で確かめたい・たまに設定を変えたい | AWS マネジメントコンソール |
| 決まった作業をスクリプトで自動化したい | AWS CLI |
| 自分のアプリから AWS を呼び出したい | AWS SDK |
| PC に何も入れずにコマンドを試したい | AWS CloudShell |
出典: AWS マネジメントコンソールとは/AWS Command Line Interface とはどのようなものですか/AWS CloudShell とは/Amazon EC2 Auto Scaling とは(AWS SDK とクエリ API の説明)
IaC と 1 回限り/反復可能な作業
IaC:繰り返す作業はコードに、1 回限りの作業は手で
Infrastructure as Code は、インフラをアプリのコードと同じように扱う考え方です。構成を宣言的に書いてソース管理し、同じ環境を何度でも作れるようにします。
AWS CloudFormation はテンプレート(JSON か YAML)に書いたとおりにリソースを作るサービスです。作ったリソースのまとまりをスタックと呼び、1 つの単位で作成・削除できます。
AWS の名前空間のリソースを使う限り、CloudFormation 自体に追加料金はかかりません。作った EC2 などには通常の料金がかかります。
AWS Cloud Development Kit を使うと、TypeScript や Python などでインフラを定義し、CloudFormation を通じてデプロイできます。
CloudFormation StackSets は、複数のアカウントとリージョンに 1 回の操作でスタックを展開します。本番の更新前には変更セットで影響を確かめられます。
試験では「1 回限りか、繰り返すか」で選び分けます。翌日に消す検証用のリソースならコンソールで十分です。何度も同じ環境を作るならコード化します。
| 場面 | 向く方法 |
|---|---|
| 検証用に 1 回だけ作ってすぐ消す | AWS マネジメントコンソールや AWS CLI |
| 開発・検証・本番で同じ環境をそろえる | AWS CloudFormation のテンプレート |
| 普段の言語でインフラを書きたい | AWS Cloud Development Kit |
| 多数のアカウント・リージョンへ配る | CloudFormation StackSets |
| 更新の影響を先に確かめたい | 変更セット |
出典: Infrastructure as Code(AWS での DevOps の概要)/CloudFormation とは/AWS CloudFormation の料金/AWS CDK とは/StackSets を使用したアカウントとリージョン全体でのスタックの管理/変更セットを使用して CloudFormation スタックを更新する
デプロイモデル(クラウド・ハイブリッド・オンプレミス)
デプロイモデル:クラウド・ハイブリッド・オンプレミス
デプロイモデルは、IT の資源をどこに置くかの形です。AWS の資料は 3 つに分けています。
クラウドは、アプリのすべての部分をクラウドで動かす形です。新しく作る場合も、既存の設備から移す場合もあります。
ハイブリッドは、クラウドの資源とクラウド外の既存の資源をつなぐ形です。社内のシステムを残したまま、AWS に新しい仕組みを足す場面がこれにあたります。
オンプレミスは、自社の設備に仮想化などの仕組みを入れて使う形で、プライベートクラウドとも呼ばれます。専用の資源が必要な場合に選ばれますが、クラウドの利点の多くは得られません。
AWS Outposts は、AWS のインフラとサービスを自社施設まで広げるサービスです。低レイテンシーやデータのローカル処理が必要な場合に使います。
出典: クラウドコンピューティングのタイプ(Amazon Web Services の概要)/リージョンとゾーン(AWS Outposts)
リージョン・アベイラビリティーゾーン・エッジロケーション
リージョン・AZ・エッジロケーションの関係
AWS リージョンは、世界の別々の地理的エリアです。各リージョンは他から完全に分離されるよう設計されています。リソースはリージョン間で自動では複製されません。
1 つのリージョンの中に、複数のアベイラビリティーゾーン(AZ)があります。AZ は、独立した冗長な電源・ネットワーク・接続を持つ 1 つ以上のデータセンターです。
エッジロケーションは、Amazon CloudFront などがコンテンツの写しを置いて配る拠点です。利用者の近くから届けるので、遅延が減り、表示が速くなります。
利用者のさらに近くで計算を動かす仕組みもあります。AWS Local Zones は大都市の近くにある、リージョンの拡張です。AWS Wavelength は 5G ネットワークの端に AWS のサービスを置きます。
| 名前 | 何か | 主な使い道 |
|---|---|---|
| AWS リージョン | 世界の地理的エリア。互いに分離 | データの置き場所や、利用者への近さで選ぶ |
| アベイラビリティーゾーン | リージョン内の独立したデータセンター群 | 複数使って障害に強くする |
| エッジロケーション | コンテンツを配る拠点 | Amazon CloudFront で配信を速くする |
| AWS Local Zones | 大都市の近くのリージョンの拡張 | 低レイテンシーのアプリ |
| AWS Wavelength | 5G 網の端の拠点 | モバイル端末向けの超低レイテンシー |
出典: リージョンとゾーン(Amazon EC2 ユーザーガイド)/Amazon CloudFront とは何ですか?/AWS Local Zones とは
複数 AZ による高可用性
複数の AZ で止まりにくくする
AZ どうしは最大 100 km 程度の意味のある距離だけ離れ、停電や洪水などで同時に影響を受けないよう設計されています。発電機や冷却装置は共有せず、単一障害点を持たない作りです。
一方で、AZ 間は専用の高速・低レイテンシーの回線で結ばれています。そのため、AZ をまたいで同期レプリケーションができます。
ウェブサーバーは 2 つ以上の AZ に分けて置き、Elastic Load Balancing で通信を振り分けます。1 つの AZ が止まっても、別の AZ のサーバーが処理を続けます。
データベースでは、Amazon RDS のマルチ AZ 配置を使います。別の AZ に同期スタンバイを置き、障害時は自動で切り替えます。
スタンバイが 1 つの構成では、スタンバイは読み取りを処理しません。読み取りを増やしたいときはリードレプリカか、スタンバイが 2 つのマルチ AZ DB クラスターを使います。
| やりたいこと | 使うもの |
|---|---|
| ウェブサーバーを AZ 障害に強くする | 2 つ以上の AZ + Elastic Load Balancing |
| RDS を AZ 障害時に自動で切り替える | マルチ AZ 配置 |
| RDS の読み取りを分散する | リードレプリカ・マルチ AZ DB クラスター |
出典: アベイラビリティーゾーン(AWS の障害分離境界)/Amazon RDS のマルチ AZ DB インスタンスデプロイ/Elastic Load Balancing とは?
複数リージョンを使うケース
複数のリージョンを使う理由と、災害対策の 4 つの戦略
複数のリージョンを使う主な理由には、ディザスタリカバリ、事業の継続、世界の利用者への低レイテンシー、データ主権があります。
データ主権では、法令でデータを特定の国に置く必要がある場合に、保存するリージョンを選んで対応します。
災害対策の目標は 2 つです。目標復旧時間(RTO)は止まってから復旧までに許す時間です。目標復旧時点(RPO)は、どれだけ前までのデータ損失を許すかです。
AWS は戦略を 4 つに分けます。バックアップと復元が最も安く簡単で、パイロットライト、ウォームスタンバイと進むほど復旧が速くなります。
マルチサイトアクティブ/アクティブは最も複雑で費用も高い戦略ですが、多くの災害で復旧時間をほぼゼロにできます。
データの複製には、Aurora グローバルデータベースや DynamoDB グローバルテーブルが使えます。EC2 は Amazon マシンイメージを別のリージョンへコピーしておくと、すぐ起動できます。
| 戦略 | 別リージョンに用意しておくもの | 復旧の速さと費用 |
|---|---|---|
| バックアップと復元 | バックアップだけ | 最も遅いが、最も安い |
| パイロットライト | データの複製と中核のインフラ。アプリは停止 | 起動が必要。費用は低め |
| ウォームスタンバイ | 本番の縮小版が常に動く | すぐ受けられ、規模を広げるだけ |
| マルチサイトアクティブ/アクティブ | すべてのリージョンで本番が動く | ほぼゼロ。最も複雑で高い |
出典: クラウド内での災害対策オプション/事業継続計画 (BCP)(復旧目標 RTO と RPO)/リージョンとゾーン(Amazon EC2 ユーザーガイド)/Amazon EC2 の Amazon マシンイメージ
EC2 とインスタンスタイプ
EC2 のインスタンスタイプは「用途の系統」で選ぶ
Amazon EC2 では、インスタンスタイプでCPU・メモリ・ストレージの組み合わせが決まります。名前は「シリーズ・世代・オプション」と「サイズ」でできています。
例えば c7gn.xlarge なら、c がシリーズ、7 が世代、gn がオプション、ピリオドの後ろの xlarge がサイズです。
試験では、処理の性質から系統を選ぶ問題がよく出ます。計算が中心ならコンピューティング最適化、メモリに大きなデータを載せるならメモリ最適化です。
大量のランダム I/O が必要ならストレージ最適化を選びます。普段の負荷が低く、たまに上がるだけならバーストパフォーマンスインスタンスが費用効率のよい選択です。
| 系統(文字の例) | 向く処理の例 |
|---|---|
| 汎用(M・T) | ウェブサーバー、コードリポジトリ、中小規模の DB |
| コンピューティング最適化(C) | バッチ処理、メディアの変換、ゲームサーバー |
| メモリ最適化(R・X) | インメモリ DB、データ分析 |
| 高速コンピューティング(P・G など) | GPU を使う計算やグラフィックス処理 |
| ストレージ最適化(I・D) | 高スループットの DB、データ処理 |
| HPC 最適化(Hpc) | 大規模なシミュレーション |
出典: Amazon EC2 instance types/Amazon EC2 インスタンスタイプ/Amazon EC2 インスタンスタイプの命名規則
コンテナ(ECS・EKS)
コンテナ:ECS と EKS の選び分け
コンテナは、アプリと動かすのに必要なものを 1 つにまとめた実行単位です。たくさんのコンテナを配置・管理する仕組みをオーケストレーションと呼びます。
Amazon Elastic Container Service(ECS)は、AWS が提供するフルマネージドのオーケストレーションです。アプリの設計図はタスク定義に書きます。
Amazon Elastic Kubernetes Service(EKS)は、オープンソースの Kubernetes を動かすマネージドサービスです。コントロールプレーンは AWS が管理します。
EKS は自社データセンターでも動かせます(EKS Anywhere や EKS Hybrid Nodes)。Kubernetes の道具や知識をそのまま生かしたい場合に向きます。
コンテナイメージの保存場所は Amazon Elastic Container Registry(ECR)です。ECS と EKS のどちらからも使います。
| こんなとき | 選ぶもの |
|---|---|
| AWS のサービスと手軽に組み合わせたい | Amazon Elastic Container Service |
| Kubernetes の運用をそのまま使いたい | Amazon Elastic Kubernetes Service |
| コンテナイメージを保存・共有したい | Amazon Elastic Container Registry |
サーバーレス(Lambda・Fargate)
サーバーレス:Lambda は短いイベント処理、Fargate はコンテナ
サーバーレスは、サーバーの用意や管理をせずにアプリを動かす形です。容量の調整やパッチ適用は AWS が行います。
AWS Lambda は、イベントや API の呼び出しに応じてコードを動かします。料金はリクエスト数と実行時間で決まり、前払いは要りません。
Lambda 関数は、1 回の呼び出しで原則最大 15 分(900 秒)まで動きます。Lambda マネージドインスタンスの非同期呼び出しなど一部は最大 90 分ですが、それより長い処理は 1 回の呼び出しでは終わりません。
AWS Fargate は、サーバーを管理せずにコンテナを動かすエンジンです。ECS と EKS の両方で使え、インスタンスタイプを選ぶ必要がありません。
使い分けの目安は、短いイベント処理なら Lambda、コンテナにまとめた長めの処理なら Fargate です。
出典: AWS Lambda とは/Lambda クォータ/Amazon ECS の AWS Fargate 用のアーキテクト/AWS Fargate を使用してコンピューティング管理を簡素化する(Amazon EKS)
自動スケーリングとロードバランサー
Auto Scaling で伸び縮み、ロードバランサーで振り分け
Amazon EC2 Auto Scaling は、EC2 インスタンスを Auto Scaling グループとしてまとめ、最小・最大・希望の台数の範囲で数を保ちます。追加料金はなく、使ったリソースの分だけ払います。
ヘルスチェックで異常な台を見つけると、新しい台に置き換えて希望の台数に戻します。複数の AZ に均等に分けて置くこともできます。
台数の変え方は、時刻が決まっていればスケジュールに基づくスケーリング、いつ増えるか読めなければ動的スケーリングです。日ごと・週ごとの傾向に先回りするなら予測スケーリングを使います。
Elastic Load Balancing は、届いた通信を複数の AZ のターゲットに分け、正常なものだけに送ります。Auto Scaling が起動・終了した台は、自動で登録・解除されます。
ロードバランサーには種類があります。ウェブの HTTP・HTTPS なら Application Load Balancer、TCP・UDP で高性能と固定 IP が必要なら Network Load Balancer を選びます。
EC2 に限らず、DynamoDB のテーブルや Aurora のレプリカなど複数のサービスの容量をまとめて自動で調整するなら AWS Auto Scaling を使います。
| 種類 | 層 | 向く場面 |
|---|---|---|
| Application Load Balancer | レイヤー 7(HTTP・HTTPS・gRPC) | ウェブアプリの柔軟な振り分け |
| Network Load Balancer | レイヤー 4(TCP・UDP・TLS) | 非常に高い性能と固定の IP アドレス |
| Gateway Load Balancer | レイヤー 3 のゲートウェイ+レイヤー 4 | セキュリティ機器などのアプライアンスへの分散 |
| Classic Load Balancer | レイヤー 4・7 | 前の世代。現行世代への移行が勧められている |
出典: Amazon EC2 Auto Scaling とは/スケーリング方法を選択する(Amazon EC2 Auto Scaling)/Elastic Load Balancing とは?/Elastic Load Balancing features/Gateway Load Balancer とは?
マネージド DB とリレーショナル DB(RDS・Aurora)
DB を自分で運用するか、マネージドに任せるか
AWS でリレーショナルデータベースを動かす方法は、大きく 2 つです。EC2 に DB ソフトを自分で入れる方法と、Amazon RDS のようなマネージドサービスを使う方法です。
RDS は、バックアップ、ソフトウェアのパッチ適用、障害の検出と復旧を管理します。公式は、ほとんどのリレーショナル DB で RDS を既定の選択肢として勧めています。
RDS を使っても、SQL のチューニングやアプリの最適化は利用者の仕事として残ります。RDS が対応しない DB ソフトを使う場合は、EC2 で自分で運用します。
Amazon Aurora は RDS の一部で、MySQL・PostgreSQL と互換のある DB エンジンです。データは 1 つのリージョンの 3 つの AZ に写しを持ち、量に応じてストレージが自動で大きくなります。
| 作業 | EC2 で自分で運用 | Amazon RDS |
|---|---|---|
| アプリの最適化 | 利用者 | 利用者 |
| スケーリング・高可用性・バックアップ | 利用者 | AWS |
| DB ソフトと OS のパッチ適用 | 利用者 | AWS |
| サーバーの保守・ハードウェア | AWS | AWS |
出典: Amazon Relational Database Service (Amazon RDS) とは/Amazon Aurora とは/Amazon Aurora ストレージ
NoSQL とインメモリ DB(DynamoDB・ElastiCache)
NoSQL とインメモリ:DynamoDB と ElastiCache
NoSQL は、表の形に限らない柔軟な形でデータを扱う DB の総称です。AWS の代表は Amazon DynamoDB です。
DynamoDB はサーバーレスでフルマネージドの NoSQL DB で、キーバリューとドキュメントの形に対応します。利用者が 10 人でも 1 億人でも、一貫した 1 桁ミリ秒の性能を目指して作られています。
DynamoDB は既定で 3 つの AZ にデータを複製します。さらに速い読み取りが必要なら、マイクロ秒の応答を出す DynamoDB Accelerator を使います。
Amazon ElastiCache は、Valkey・Memcached・Redis OSS と互換のあるインメモリのキャッシュです。よく読むデータを置くと、応答が速くなり、元の DB の負荷も減ります。
ほかの NoSQL もあります。ドキュメント型の Amazon DocumentDB や、データのつながりを扱うグラフ型の Amazon Neptune です。
| DB の種類 | AWS のサービス | 向く用途の例 |
|---|---|---|
| リレーショナル | Amazon RDS・Amazon Aurora | 表を結合する複雑なクエリが必要な業務 |
| キーバリュー | Amazon DynamoDB | ショッピングカート、ゲームの状態 |
| インメモリ | Amazon ElastiCache | キャッシュ |
| ドキュメント | Amazon DocumentDB | JSON のような半構造のデータ |
| グラフ | Amazon Neptune | 不正の検出、レコメンド |
出典: Amazon DynamoDB とは/DynamoDB Accelerator (DAX) とインメモリアクセラレーション/Amazon ElastiCache とは/AWS で組織に適したデータベースを選択する
データベース移行(DMS・SCT)
データベース移行:スキーマは SCT、データは DMS
AWS Database Migration Service(DMS)は、リレーショナル DB・データウェアハウス・NoSQL などを移すサービスです。1 回限りの移行に加え、変更を継続的に複製して移行元と移行先を同期できます。
エンジンが変わる異種移行では、まずスキーマを変換します。手元の PC に入れる AWS Schema Conversion Tool(SCT)か、DMS の機能の DMS Schema Conversion を使います。
流れは「スキーマを変換して移行先に適用 → DMS でデータを移す」です。同じエンジンどうしの移行なら、エンジン間の変換は要りません。
| やりたいこと | まず思い出すもの |
|---|---|
| DB エンジン間でスキーマやコードを変換 | AWS Schema Conversion Tool・DMS Schema Conversion |
| データを移し、変更を同期し続ける | AWS Database Migration Service |
| サーバーを丸ごと移す | AWS Transform MGN(旧称 AWS Application Migration Service) |
出典: AWS Database Migration Service とは/AWS Schema Conversion Tool とは/What is AWS Transform MGN?
VPC の構成要素(サブネット・ゲートウェイ)
VPC の部品:サブネット・ルートテーブル・ゲートウェイ
Amazon VPC は、AWS アカウント専用の論理的に分けられた仮想ネットワークです。IP アドレスの範囲を決め、サブネットやゲートウェイを加えて使います。
サブネットは VPC の IP アドレス範囲の一部で、EC2 などはサブネットの中で起動します。通信の行き先はルートテーブルのルートで決まります。
インターネットゲートウェイを VPC に付け、ルートテーブルでそこへ通信を送るとパブリックサブネットになります。プライベートサブネットから外へ出るだけなら NAT ゲートウェイを使います。
VPC どうしは VPC ピアリングで 1 対 1 につなげます。数が増えたら AWS Transit Gateway をハブにして、VPC と拠点をまとめてつなぎます。
| 部品 | 役割 |
|---|---|
| サブネット | VPC の IP アドレス範囲の一部。リソースを置く場所 |
| ルートテーブル | 通信をどこへ送るかを決める |
| インターネットゲートウェイ | VPC とインターネットの出入り口 |
| NAT ゲートウェイ | 内側から外への通信だけを通す |
| AWS Transit Gateway | 多数の VPC と拠点をつなぐハブ |
VPC のセキュリティ(セキュリティグループ・ネットワーク ACL)
VPC のセキュリティ:セキュリティグループとネットワーク ACL
セキュリティグループはインスタンス単位、ネットワーク ACLはサブネット単位で働きます。公式は、セキュリティグループを主な仕組みとし、ネットワーク ACL を追加の防御として使うことを勧めています。
セキュリティグループは許可ルールだけで、ステートフルです。ネットワーク ACL は許可と拒否のルールを持ち、ステートレスなので戻りの通信も明示的に許可します。
Amazon Inspector は、EC2・ECR のコンテナイメージ・Lambda 関数を自動で見つけ、ソフトウェアの脆弱性と意図しないネットワークの露出を継続的に調べます。
| 特性 | セキュリティグループ | ネットワーク ACL |
|---|---|---|
| 働く単位 | インスタンス | サブネット |
| ルール | 許可だけ | 許可と拒否 |
| ルールの評価 | すべてのルールを見て決める | 番号の小さい順に、一致した時点で決める |
| 戻りの通信 | 自動で許可(ステートフル) | 明示的な許可が必要(ステートレス) |
Route 53 と AWS への接続(VPN・Direct Connect)
Route 53 と AWS への接続方法
Amazon Route 53 は DNS のサービスで、名前を IP アドレスに変換します。ヘルスチェックで正常な宛先にだけ通信を向けられ、ドメイン名の登録もできます。
拠点と AWS をつなぐ方法は 3 つを区別します。AWS Site-to-Site VPN は拠点と VPC の間に暗号化したトンネルを作ります。AWS Client VPN は個々の利用者の端末をつなぎます。この 2 つをまとめて AWS VPN と呼びます。
AWS Direct Connect は拠点から AWS への専用のネットワーク接続です。インターネット経由より安定した通信を得やすく、帯域のスループットも上げられます。
VPC から AWS のサービスへ、インターネットを通らずにプライベートにつなぐなら AWS PrivateLink です。
| 要件 | 選ぶもの |
|---|---|
| 拠点のネットワークと VPC を暗号化してつなぐ | AWS Site-to-Site VPN |
| 社員の端末から VPC につなぐ | AWS Client VPN |
| インターネットを通らない専用接続 | AWS Direct Connect |
| 名前解決・正常な宛先への振り分け | Amazon Route 53 |
S3 とストレージクラス・ライフサイクル
S3:ストレージクラスとライフサイクル
Amazon S3 はオブジェクトストレージです。指定しなければ S3 Standard に保存されます。S3 ストレージクラスは、アクセスの頻度と取り出しの速さで選び分けます。
アクセスが読めないデータは S3 Intelligent-Tiering が向きます。取り出し料金はなく、使われ方に合わせて自動で安い階層へ移ります。
Standard-IA と One Zone-IA は、月 1 回ほどしか読まないデータ向けで、最小保存期間は 30 日です。One Zone-IA は 1 つの AZ にだけ保存するため、AZ を失うとデータは戻りません。
S3 ライフサイクルには、別のクラスへ移す移行アクションと、期限で削除する有効期限アクションがあります。組み合わせると、移動と削除を自動にできます。
| クラス | 向くデータ | 最小保存期間 |
|---|---|---|
| S3 Standard | よくアクセスするデータ(既定) | なし |
| S3 Intelligent-Tiering | アクセスの様子が読めないデータ | なし |
| S3 Standard-IA・One Zone-IA | 月 1 回ほどのデータ | 30 日 |
| S3 Glacier Instant Retrieval | 四半期に 1 回・すぐ取り出したい | 90 日 |
| S3 Glacier Flexible Retrieval | 年 1 回・数分〜数時間で取り出す | 90 日 |
| S3 Glacier Deep Archive | 年 1 回未満・数時間で取り出す | 180 日 |
ブロックとファイル(EBS・インスタンスストア・EFS・FSx)
ブロックとファイル:EBS・インスタンスストア・EFS・FSx
Amazon Elastic Block Store(EBS)は EC2 に付ける永続的なブロックストレージです。データは 1 つの AZ の中で自動で複製され、EBS スナップショットでバックアップできます。
インスタンスストアはホストに付いたディスクの一時領域です。再起動ではデータが残りますが、停止・休止・終了で消えます。キャッシュなどの一時データに向きます。
Amazon Elastic File System(EFS)は Linux 向けのファイルシステムで、数千台の EC2 から同時に使え、容量は自動で増減します。Windows の SMB 共有には Amazon FSx の Windows File Server を使います。
io1・io2 の EBS はマルチアタッチで同じ AZ の最大 16 台に付けられますが、容量は自動で増減しません。多数の EC2 でファイルを共有するなら EFS が基本です。
| サービス | 種類 | 特徴 |
|---|---|---|
| Amazon Elastic Block Store | ブロック | 永続的。1 つの AZ の中で複製 |
| インスタンスストア | ブロック | 一時的。停止や終了で消える |
| Amazon Elastic File System | ファイル | Linux 向け。多数の EC2 で共有 |
| Amazon FSx | ファイル | Windows・Lustre・ONTAP・OpenZFS |
出典: Amazon Elastic Block Store とは/Amazon EC2 インスタンスストアボリュームのデータの永続性/AWS の概要(ホワイトペーパー): ストレージ/マルチアタッチを使用して EBS ボリュームを複数の EC2 インスタンスへアタッチ
Storage Gateway と AWS Backup
Storage Gateway と AWS Backup
AWS Storage Gateway は、オンプレミスのアプリが AWS のストレージを使えるようにするハイブリッドのサービスです。NFS・SMB・iSCSI などでつなぎ、よく使うデータはローカルキャッシュで速く読めます。
S3 ファイルゲートウェイはファイルを S3 のオブジェクトとして保存します。ボリュームゲートウェイには、一部だけを手元に持つキャッシュ型と、全データを手元に置く保管型があります。テープゲートウェイは仮想テープでアーカイブします。
AWS Backup は、サービスをまたいでバックアップを一元化・自動化します。バックアッププランという方針を作って当て、リージョン間やアカウント間へのコピーもできます。
| 要件 | 選ぶもの |
|---|---|
| ファイル共有の中身を S3 に置く | S3 ファイルゲートウェイ |
| 全データを手元に置き、S3 へスナップショット | ボリュームゲートウェイ(保管型) |
| テープのバックアップをクラウドへ | テープゲートウェイ |
| AWS のリソースのバックアップを一元管理 | AWS Backup |
出典: Amazon S3 ファイルゲートウェイとは/ボリュームゲートウェイについて(AWS Storage Gateway)/AWS Backup とは
AI/ML サービス
AI/ML:タスクとサービスを対で覚える
学習済みの AI サービスは、入力と出力で覚えると選び分けやすくなります。音声から文字は Amazon Transcribe、文字から音声は Amazon Polly、翻訳は Amazon Translate です。
文章の感情やキーフレーズは Amazon Comprehend、画像と動画の分析は Amazon Rekognition、文書のフォームや表の抽出は Amazon Textract、会話型のボットは Amazon Lex です。
自社データで独自のモデルを作るなら Amazon SageMaker AI です。構築・学習・デプロイをフルマネージドのインフラとツールで行えます。Amazon Q は業務や開発を手伝う生成 AI のアシスタントです。 なお Amazon Q Business は新規の受付を終えており、公式は似た機能として Amazon Quick を案内しています。
| やりたいこと | サービス |
|---|---|
| 音声を文字に起こす | Amazon Transcribe |
| 文章を読み上げる | Amazon Polly |
| 文章の感情・キーフレーズ | Amazon Comprehend |
| 画像・動画の分析 | Amazon Rekognition |
| 文書のフォームや表を抽出 | Amazon Textract |
| 独自モデルの構築と学習 | Amazon SageMaker AI |
出典: AWS の概要(ホワイトペーパー): 機械学習と人工知能/Amazon Q Business availability change
分析サービス
分析:取り込む・整える・問い合わせる・見せる
分析のサービスは役割の順に並べると覚えやすくなります。流れ続けるデータの取り込みは Amazon Kinesis、データの発見と変換は AWS Glue です。
S3 のデータに SQL で問い合わせるなら Amazon Athena で、サーバーレスなので実行したクエリの分だけ払います。大量のデータをためて分析するデータウェアハウスは Amazon Redshift です。
結果を見せる BI は Amazon Quick Sight です。公式は、Amazon QuickSight から発展した Amazon Quick の機能として Quick Sight を位置づけています。Spark などで大量データを処理するなら Amazon EMR です。ログの検索・分析には Amazon OpenSearch Service を使います。
| 役割 | サービス |
|---|---|
| ストリーミングの取り込み | Amazon Kinesis |
| データの発見・カタログ化・変換 | AWS Glue |
| S3 に SQL で問い合わせ | Amazon Athena |
| データウェアハウス | Amazon Redshift |
| ダッシュボードで可視化 | Amazon Quick Sight |
出典: AWS の概要(ホワイトペーパー): 分析/Amazon Quick とは(Amazon Quick Sight を含む)
アプリケーション統合(EventBridge・SNS・SQS)
アプリケーション統合:SQS・SNS・EventBridge の選び分け
Amazon Simple Queue Service(SQS)はメッセージをためるキューで、受け手が自分のペースで取り出します。標準キューと、送信順に 1 回だけ処理する SQS FIFO キューがあります。
Amazon Simple Notification Service(SNS)はトピックに届いたメッセージを多数の購読者に配ります。SQS・Lambda・HTTP のほか、E メールや SMS で人に知らせることもできます。 ただし SNS のメール配信は社内向けのシステム通知用で、マーケティングメールは SES を使います。
Amazon EventBridge はイベントをルールで振り分けるサーバーレスのサービスで、イベント駆動型アーキテクチャを作るのに使います。スケジューラで決まった時刻に処理を起動することもできます。
| やりたいこと | サービス |
|---|---|
| ためて、自分のペースで処理 | Amazon Simple Queue Service |
| 送った順に 1 回だけ処理 | SQS FIFO キュー |
| 1 つの知らせを多数へ配る・メールや SMS | Amazon Simple Notification Service |
| イベントの振り分け・時刻での起動 | Amazon EventBridge |
出典: AWS の概要(ホワイトペーパー): アプリケーション統合/Amazon SNS とは/Amazon EventBridge とは/Amazon SNS email subscription setup and management
ビジネスアプリケーションとカスタマーイネーブルメント(Connect・SES・サポート)
Connect・SES とサポートの選び方
Amazon Connect はクラウドのコンタクトセンターで、音声やチャットの問い合わせを担当者につなぎます。公式は従来の製品を Amazon Connect Customer とも呼んでいます。
Amazon Simple Email Service(SES)は、自社のアドレスとドメインでメールを送受信するサービスです。注文確認などの取引メールやマーケティングメールに使えます。
AWS サポートのベーシックサポートは全員に提供され、カスタマーサービスや AWS re:Post などが含まれます。技術サポートのケースは AWS ビジネスサポート+ 以上で使えます。 旧来の開発者サポートとビジネスサポートは 2027-01-01 に終了すると公式ドキュメントに書かれています。
出典: Connect Customer とは(Amazon Connect)/Amazon SES とは/AWS サポートプランの比較/AWS Support プラン(AWS サポートユーザーガイド)
デベロッパーツール(CodeBuild・CodePipeline・X-Ray)
デベロッパーツール:作る・流す・調べる
AWS CodeBuild はコンパイル・テスト・パッケージ作成を行うビルドサービスで、ビルドサーバーの管理が要りません。
AWS CodePipeline はリリースの流れを自動化し、コードの変更ごとにビルド・テスト・デプロイの段階を進めます。インスタンスへのデプロイの自動化は AWS CodeDeploy が受け持ちます。
AWS X-Ray はリクエストの流れを端から端まで追い、分散アプリの性能の問題やエラーの原因を探します。API の操作の記録を残す AWS CloudTrail とは目的が違います。
| 段階 | サービス |
|---|---|
| ビルドとテスト | AWS CodeBuild |
| リリースの流れの自動化 | AWS CodePipeline |
| デプロイの自動化 | AWS CodeDeploy |
| 遅さやエラーの原因の調査 | AWS X-Ray |
エンドユーザーコンピューティング・Amplify・IoT
エンドユーザーコンピューティング・Amplify・IoT
Amazon WorkSpaces は Windows や Linux のクラウドデスクトップです。Amazon WorkSpaces Applications(旧称 Amazon AppStream 2.0)はデスクトップアプリをストリーミングで届けます。
Amazon WorkSpaces Secure Browser は、社内サイトや SaaS をクラウド上のブラウザで使わせ、データを利用者の端末に残しにくくします。 公式ページによると、2026-10-29 から新規の利用受付を終えています。
AWS Amplify のホスティングは Git と連携し、ウェブアプリを継続的にデプロイして公開します。AWS IoT Core は MQTT や HTTPS で機器を AWS のサービスにつなぎます。
| 渡したいもの・つなぎたいもの | サービス |
|---|---|
| デスクトップ全体 | Amazon WorkSpaces |
| デスクトップアプリだけ | Amazon WorkSpaces Applications |
| ブラウザで使うウェブアプリ | Amazon WorkSpaces Secure Browser |
| 自社のウェブアプリの公開 | AWS Amplify |
| IoT の機器 | AWS IoT Core |
出典: AWS の概要(ホワイトペーパー): エンドユーザーコンピューティング/Amazon WorkSpaces Secure Browser/AWS Amplify ホスティングへようこそ/AWS IoT とは
演習(97 問)
結果はこのブラウザに保存され、ハブの「自分の成績」と弱点モードに使われます。
第 1 問 / 97 問
問題を読み込んでいます…
全問と解説の一覧
正解と解説は折りたたんであります。先に自分で考えてから開いてください。
全 97 問
AWS へのアクセス方法(コンソール・API・SDK・CLI)
プログラミングの経験がない担当者が、ウェブブラウザの画面だけで EC2 インスタンスの状態を確かめたい。使う手段として最も適切なものは?
A. AWS SDK を組み込んだ自作のプログラム B. AWS マネジメントコンソール C. AWS CLI のコマンド D. AWS CloudFormation のテンプレート
この問題へのリンク答えと解説
正解: B 【A(不正解)】 ? プログラミング言語から AWS を呼び出すためのライブラリです。 SDK はプログラムを書く人向けの道具で、画面だけで確かめたいという要件に合わない。 【B(正解)】 ? ブラウザで開く、AWS のウェブの管理画面です。 各サービスの画面に一元的にアクセスできるウェブアプリで、プログラミングなしで状態の確認や操作ができる。 【C(不正解)】 ? ターミナルにコマンドを打って AWS を操作するツールです。 コマンドの入力が必要で、ブラウザの画面だけで済ませたいという要件には合わない。 【D(不正解)】 ? 作りたいリソースの構成を書いておくファイルです。 リソースを作成・管理するための仕組みで、今の状態を画面で見るための手段ではない。
毎晩 20 時に開発用の EC2 インスタンスを止める処理を、社内サーバーのシェルスクリプトで自動化したい。スクリプトから AWS を操作する手段として最も適切なものは?
A. 担当者が毎晩コンソールにサインインして手で止める B. AWS Artifact から報告書を取り出す C. Amazon CloudFront の配信設定を変える D. AWS CLI のコマンドをスクリプトに書く
この問題へのリンク答えと解説
正解: D 【A(不正解)】 ? ブラウザの画面で 1 台ずつ操作する方法です。 毎晩人が操作する必要があり、自動化にならない。止め忘れも起きやすい。 【B(不正解)】 ? AWS のコンプライアンス報告書を入手するサービスです。 監査用の報告書を入手する場所で、インスタンスの起動や停止はできない。 【C(不正解)】 ? コンテンツを利用者の近くから配信するサービスです。 ウェブの配信を速くするサービスで、インスタンスを止める操作とは関係がない。 【D(正解)】 ? コマンドラインから AWS のサービスを操作するオープンソースのツールです。 CLI のコマンドはシェルスクリプトに書いて自動で実行できる。公式ガイドも、シェルスクリプトを作ってリソースを管理できると説明している。
会社の PC にはツールを入れられない。今すぐ AWS CLI のコマンドを試したいが、認証情報の設定も省きたい。最も適切な方法は?
A. コンソールから AWS CloudShell を起動する B. 自分の PC に AWS SDK を入れてプログラムを書く C. Amazon Lightsail でサーバーを作り、そこに CLI を入れる D. アクセスキー を作り、チャットで同僚に送ってもらう
この問題へのリンク答えと解説
正解: A 【A(正解)】 ? ブラウザから使える、AWS が用意したシェル環境です。 コンソールにサインインした認証情報がそのまま使え、AWS CLI もあらかじめ入っている。CloudShell 自体は追加料金なしで使える。 【B(不正解)】 ? 言語ごとの AWS 用ライブラリです。 PC へのインストールが必要で、ツールを入れられないという条件に反する。 【C(不正解)】 ? 低料金で使える仮想サーバーのサービスです。 サーバーの用意、CLI の導入、認証情報の設定が必要で、手間が多い。 【D(不正解)】 ? プログラムからのアクセスに使う長期の認証情報です。 認証情報の設定を省くという要件に反する。認証情報をチャットで送るのは安全面でも避けるべきだ。
在庫データを DynamoDB に書き込む機能を Python のアプリに組み込む。リクエストの署名の計算や再試行の処理は、自前で書かずに済ませたい。最も適切な方法は?
A. 担当者がコンソールで在庫データを手入力する B. クエリ API に HTTPS のリクエストを直接送るコードを書く C. AWS SDK(Python 用の SDK)を使う D. AWS CloudShell で毎回コマンドを手で打つ
この問題へのリンク答えと解説
正解: C 【A(不正解)】 ? ブラウザの画面で操作する方法です。 人の手作業になり、アプリの機能として組み込むことにならない。 【B(不正解)】 ? 低レベルの API を直接呼び出す方法です。 最も直接的な方法だが、リクエストの署名やエラー処理をアプリ側で書く必要がある。 【C(正解)】 ? 言語ごとに用意された、AWS のサービスを呼び出すためのライブラリです。 SDK は言語ごとの API を提供し、署名の計算、再試行、エラー処理など接続の細かい部分を引き受ける。 【D(不正解)】 ? ブラウザから使えるシェル環境です。 コマンドを打つのは人で、アプリに機能を組み込むことにはならない。
出典: Amazon EC2 Auto Scaling とは(AWS SDK とクエリ API の説明)/Elastic Load Balancing とは?(AWS SDK とクエリ API の説明)
IaC と 1 回限り/反復可能な作業
インフラの構成をテンプレートやコードに書き、同じ環境を何度でも自動で作れるようにする考え方を何と呼ぶか。
A. AWS クラウド導入フレームワーク B. Infrastructure as Code C. AWS Well-Architected フレームワーク D. ディザスタリカバリ
この問題へのリンク答えと解説
正解: B 【A(不正解)】 ? 組織がクラウドの導入を進めるための枠組みです。 クラウド導入を組織として進めるための考え方で、インフラをコードで定義する手法の名前ではない。 【B(正解)】 ? インフラをアプリのコードと同じように扱う考え方です。 設定を宣言的に定義してソース管理し、繰り返し同じ環境を作れるようにする。AWS では CloudFormation や AWS CDK などで実践できる。 【C(不正解)】 ? よいシステムを作るための考え方とベストプラクティスの集まりです。 設計の良し悪しを見直すための考え方で、構成をコードで書く手法そのものではない。 【D(不正解)】 ? 災害などの後にシステムを復旧するための備えです。 復旧の備えを指す言葉で、構成をコードで書く考え方の名前ではない。
開発・検証・本番の 3 つの環境に、同じ構成の VPC・EC2・RDS をそろえて作りたい。手作業による設定の漏れを防ぐ方法として最も適切なものは?
A. 手順書を作り、各環境でコンソールから同じ手順を繰り返す B. Amazon EC2 Auto Scaling を設定する C. AWS CloudFormation のテンプレートで 3 環境を作る D. AWS Backup で本番のバックアップを取る
この問題へのリンク答えと解説
正解: C 【A(不正解)】 ? 人が手順書を見ながら作る方法です。 手順書を書く人と実行する人が違い、更新も遅れがちで、環境が一致しないことがあると公式資料は指摘している。 【B(不正解)】 ? 負荷に応じて EC2 インスタンスの数を増減する機能です。 インスタンスの数を調整する機能で、VPC や RDS を含む環境全体を作る仕組みではない。 【C(正解)】 ? テンプレートに書いたとおりにリソースを作るサービスです。 テンプレートを再利用すれば、一貫性のある繰り返し可能な方法で同じリソースを作れる。依存関係の処理も任せられる。 【D(不正解)】 ? バックアップを一元的に管理するサービスです。 データを守るためのサービスで、新しい環境を同じ構成で作る道具ではない。
出典: CloudFormation とは/Infrastructure as Code(AWS での DevOps の概要)
開発チームは、YAML より普段使う TypeScript でインフラを定義したい。作ったものは CloudFormation を通じてデプロイしたい。最も適切なものは?
A. AWS Cloud Development Kit B. AWS SDK C. AWS Elastic Beanstalk D. Amazon Elastic Container Registry
この問題へのリンク答えと解説
正解: A 【A(正解)】 ? プログラミング言語でクラウドの構成を定義するフレームワークです。 TypeScript や Python などでインフラを定義し、CloudFormation を通じてリソースを用意するオープンソースの開発フレームワークだ。 【B(不正解)】 ? アプリから AWS の API を呼び出すライブラリです。 API を呼ぶ道具で、インフラ全体をコードとして定義し CloudFormation でデプロイする仕組みではない。 【C(不正解)】 ? アプリをアップロードすると実行環境を用意してくれるサービスです。 アプリをデプロイすると環境を自動で用意するサービスで、TypeScript でインフラを定義する仕組みではない。 【D(不正解)】 ? コンテナイメージを保存するサービスです。 イメージの保存場所で、インフラの定義やデプロイには使わない。
出典: AWS CDK とは
検証のため S3 バケットを 1 つだけ作り、翌日に消す。別に、同じ監視設定を全国 40 店舗分の AWS アカウントへ展開する予定もある。進め方として最も適切なものは?
A. どちらもコンソールで、その都度手作業で作る B. どちらも CloudFormation StackSets で一括展開する C. 1 回限りは StackSets、店舗分はコンソールの手作業 D. 1 回限りは手作業、店舗分は CloudFormation StackSets
この問題へのリンク答えと解説
正解: D 【A(不正解)】 ? 人が画面で 1 つずつ作る方法です。 1 回限りの作業には向くが、40 アカウント分を手で作ると漏れや差が生じやすい。 【B(不正解)】 ? 複数のアカウントとリージョンへ一括で展開する仕組みです。 翌日に消す 1 つだけのバケットにまで一括展開の仕組みを用意するのは、手間に見合いにくい。 【C(不正解)】 ? 1 回限りは一括展開、店舗分は手作業にする方法です。 繰り返しが必要な 40 アカウント分を手作業にしており、使い分けが逆になっている。 【D(正解)】 ? 1 回限りは手作業、店舗分は一括展開にする方法です。 StackSets は、複数のアカウントとリージョンにスタックを 1 回の操作で作成・更新・削除できる。繰り返す作業ほどコード化の効果が大きい。
出典: StackSets を使用したアカウントとリージョン全体でのスタックの管理/Infrastructure as Code(AWS での DevOps の概要)
本番の CloudFormation スタックを更新する前に、どのリソースが置き換えや削除になるかを確かめたい。最も適切な機能は?
A. CloudFormation StackSets B. 変更セット C. スタックをいったん削除して作り直す D. AWS CloudShell を開く
この問題へのリンク答えと解説
正解: B 【A(不正解)】 ? 複数のアカウントとリージョンへスタックを一括展開する機能です。 一括で展開・更新するための機能で、更新の影響を事前に一覧で確かめる機能ではない。 【B(正解)】 ? スタックへの変更案を、実行前に確かめるための仕組みです。 変更が実行中のリソースに与える影響を事前に確認できる。実行を決めるまで、スタックは変更されない。 【C(不正解)】 ? リソースをすべて消してから新しく作る方法です。 動いているリソースが消えてしまい、事前の確認にはならない。 【D(不正解)】 ? ブラウザで使えるシェル環境です。 コマンドを打つ場所で、変更の影響を示す機能そのものではない。
デプロイモデル(クラウド・ハイブリッド・オンプレミス)
アプリケーションのすべての部分をクラウド上で動かすデプロイモデルはどれか。
A. ハイブリッド B. オンプレミス(プライベートクラウド) C. クラウド D. AWS Outposts を自社に置く形
この問題へのリンク答えと解説
正解: C 【A(不正解)】 ? クラウドと既存の設備をつないで使う形です。 クラウドとクラウド外の既存の資源を接続する形で、すべてをクラウドで動かす形ではない。 【B(不正解)】 ? 自社の設備に仮想化などの仕組みを入れて使う形です。 資源を自社の設備に置く形で、クラウドの利点の多くは得られない。 【C(正解)】 ? アプリをクラウドの上だけで動かす形です。 AWS の資料では、クラウドベースのアプリはすべての部分がクラウドで動くと説明している。 【D(不正解)】 ? AWS の設備を自社の拠点に置くサービスです。 AWS のサービスを自社施設で動かす仕組みで、すべてをクラウドで動かす形ではない。
工場の生産管理システムは社内に残し、新しい分析基盤を AWS に作る。両者は AWS Direct Connect でつなぐ。このデプロイモデルはどれか。
A. ハイブリッド B. クラウド C. オンプレミス D. サーバーレス
この問題へのリンク答えと解説
正解: A 【A(正解)】 ? クラウドと既存の設備をつないで使う形です。 クラウドの資源と社内の既存システムを接続して使っており、ハイブリッドにあたる。 【B(不正解)】 ? すべてをクラウドの上で動かす形です。 生産管理システムが社内に残るため、すべてをクラウドで動かす形ではない。 【C(不正解)】 ? 資源を自社の設備に置く形です。 分析基盤を AWS に作るため、自社の設備だけで完結する形ではない。 【D(不正解)】 ? サーバーの管理をせずにアプリを動かす実行の形です。 サーバーを管理しない実行方式のことで、資源の置き場所を表すデプロイモデルではない。
工場の機械の制御には低レイテンシーとデータのローカル処理が必要で、システムを工場内に置く必要がある。それでも AWS と同じ API やツールで開発したい。最も適切なものは?
A. AWS Local Zones B. 遠くの別のリージョンに移す C. Amazon CloudFront で配信する D. AWS Outposts
この問題へのリンク答えと解説
正解: D 【A(不正解)】 ? 大都市の近くに AWS が設ける、リージョンの拡張です。 利用者の近くに置かれるが、AWS の拠点であり、お客様の工場の中に置くものではない。 【B(不正解)】 ? データセンターの場所を変える方法です。 距離が離れるほど遅延は大きくなり、ローカル処理の要件も満たせない。 【C(不正解)】 ? ウェブのコンテンツを利用者の近くから配信するサービスです。 コンテンツ配信を速くするサービスで、工場内で処理を動かす仕組みではない。 【D(正解)】 ? AWS が用意する設備を、AWS のデータセンター以外の場所に置くサービスです。 リージョンと同じ API やツールを使いながら、手元の計算資源で低レイテンシーとローカル処理の要件に応えられる。
リージョン・アベイラビリティーゾーン・エッジロケーション
アベイラビリティーゾーンの説明として最も適切なものは?
A. 世界各地に置かれ、コンテンツの写しを保持して配信する拠点 B. リージョン内にあり、独立した電源・ネットワークを持つデータセンター群 C. 世界の別々の地理的エリアで、互いに完全に分離されたもの D. 通信事業者の 5G ネットワークの端に AWS のサービスを置いた場所
この問題へのリンク答えと解説
正解: B 【A(不正解)】 ? 利用者の近くでコンテンツを配る場所の説明です。 これはエッジロケーションの説明で、CloudFront などが使う。 【B(正解)】 ? リージョンの中の区画の説明です。 AZ はリージョン内の互いに独立した場所で、複数使うと 1 か所の障害からアプリを守れる。 【C(不正解)】 ? 地理的に大きな単位の説明です。 これはリージョンの説明で、リージョンの中に複数の AZ がある。 【D(不正解)】 ? モバイル向けの超低レイテンシーの拠点の説明です。 これは AWS Wavelength の Wavelength Zone の説明だ。
海外の利用者が多い動画サイトで、画像や動画の表示を速くしたい。利用者に近い場所から配信する仕組みとして最も適切なものは?
A. 同じリージョン内で使う AZ を増やす B. データベースのリードレプリカを同じリージョンに作る C. Amazon EC2 Auto Scaling で台数を増やす D. Amazon CloudFront を使い、エッジロケーションから配信する
この問題へのリンク答えと解説
正解: D 【A(不正解)】 ? 1 つのリージョンの中で配置を広げる方法です。 可用性は上がるが、配信元は同じリージョンのままで、海外の利用者との距離は縮まない。 【B(不正解)】 ? 読み取り用の DB の複製です。 DB の読み取りを分散する方法で、画像や動画を利用者の近くから届ける仕組みではない。 【C(不正解)】 ? 負荷に応じてサーバーの数を変える機能です。 処理能力は増えるが、利用者までの距離による遅延は減らない。 【D(正解)】 ? CloudFront の拠点にコンテンツのキャッシュを置く方法です。 CloudFront はリクエストを遅延の最も少ないエッジロケーションへ送り、キャッシュがあればすぐに届ける。
東京リージョンで作った EC2 インスタンスが、大阪リージョンを選んだコンソールに表示されない。理由として最も適切なものは?
A. リージョンは互いに分離されており、リソースはリージョン間で自動では複製されないため B. インスタンスは AZ ではなくエッジロケーションで動いているため C. 大阪リージョンには AZ が 1 つしかないため D. 東京リージョンのインスタンスは作成から 1 日たたないと他で見えないため
この問題へのリンク答えと解説
正解: A 【A(正解)】 ? リージョン同士の関係を述べたものです。 コンソールには選んだリージョンのリソースだけが表示される。リージョン間で自動の複製は行われない。 【B(不正解)】 ? インスタンスの置き場所を述べたものです。 EC2 インスタンスはリージョン内の AZ のサブネットで動く。エッジロケーションは CloudFront などが使う拠点だ。 【C(不正解)】 ? AZ の数を述べたものです。 AZ の数の問題ではない。そもそもリソースは作ったリージョンにだけ表示される。 【D(不正解)】 ? 時間がたてば表示されるという考え方です。 時間がたっても他のリージョンには表示されない。リージョンは互いに独立している。
ロサンゼルスの映像制作会社が、近くの AWS の拠点で仮想ワークステーションを動かし、低レイテンシーで使いたい。最も適切なものは?
A. AWS Wavelength B. エッジロケーションで EC2 を起動する C. AWS Local Zones D. 地球の反対側のリージョンを選ぶ
この問題へのリンク答えと解説
正解: C 【A(不正解)】 ? 5G ネットワークの端に AWS のサービスを置く仕組みです。 5G のモバイル端末向けの超低レイテンシーの仕組みで、事務所の制作環境が主な対象ではない。 【B(不正解)】 ? CloudFront などがコンテンツを配る拠点です。 エッジロケーションはコンテンツ配信の拠点で、ワークステーション用の EC2 を起動する場所ではない。 【C(正解)】 ? 大都市の近くにコンピューティングなどを置く、リージョンの拡張です。 利用者の近くで低レイテンシーのアプリを動かせる。公式は仮想ワークステーションを使い道の例に挙げている。 【D(不正解)】 ? 遠いデータセンターを使う方法です。 距離が遠くなるほど遅延は大きくなり、要件と逆になる。
複数 AZ による高可用性
同じリージョン内のアベイラビリティーゾーンどうしの関係として最も適切なものは?
A. 同じ建物の別の階にあり、発電機を共有している B. 大陸ごとに 1 つだけあり、互いの通信は一般のインターネットを通る C. 電源は共有するが、ネットワークは別々になっている D. 発電機や冷却装置などの障害点を共有せず、低レイテンシーの専用回線で結ばれている
この問題へのリンク答えと解説
正解: D 【A(不正解)】 ? 1 つの建物の中で分かれている形です。 AZ は意味のある距離だけ離れており、発電機などの障害点を共有しないように作られている。 【B(不正解)】 ? 広い地域に 1 つずつある形です。 1 つのリージョンに複数の AZ があり、専用の高速・低レイテンシーの回線で結ばれている。 【C(不正解)】 ? 一部の設備だけを分けた形です。 電源も独立している。AZ ごとに別の配電所から受電するよう設計されている。 【D(正解)】 ? 互いに独立しつつ近くにある形です。 AZ は広域の災害で同時に影響を受けないよう離れ、同期レプリケーションができる程度に近い。
ウェブサーバー 2 台を同じ AZ に置いている。AZ 全体が止まってもサイトを続けたい。最も適切な対策は?
A. 同じ AZ のまま、インスタンスのサイズを大きくする B. 2 つの AZ に分けて置き、ロードバランサーで振り分ける C. 同じ AZ のまま、台数を 4 台に増やして負荷を分ける D. 別のリージョンに週 1 回バックアップを取るだけにする
この問題へのリンク答えと解説
正解: B 【A(不正解)】 ? 1 台ごとの処理能力を上げる方法です。 性能は上がるが、AZ が止まればすべて止まる。障害の範囲は変わらない。 【B(正解)】 ? 置き場所と通信の振り分けを組み合わせる方法です。 1 つの AZ が止まっても、別の AZ のインスタンスがリクエストを受けられる。ELB は正常なターゲットにだけ通信を送る。 【C(不正解)】 ? 同じ場所でサーバーの数を増やす方法です。 台数を増やしても同じ AZ にあるため、AZ の障害ではまとめて止まる。 【D(不正解)】 ? データの写しを遠くに保管する方法です。 データは守れるが、復元するまでサイトは止まる。止めないための対策ではない。
出典: リージョンとゾーン(Amazon EC2 ユーザーガイド)/Elastic Load Balancing とは?
Amazon RDS の本番データベースを、AZ の障害時にも自動で切り替わるようにしたい。最も適切な設定は?
A. マルチ AZ 配置を有効にする B. 同じ AZ にリードレプリカを 1 つ作る C. 毎日 1 回、手動でスナップショットを取る D. DB インスタンスクラスを大きくする
この問題へのリンク答えと解説
正解: A 【A(正解)】 ? 別の AZ にスタンバイを置く RDS の構成です。 RDS が別の AZ に同期スタンバイを自動で用意して維持し、障害時のフェイルオーバーに使う。 【B(不正解)】 ? 読み取り用の複製を作る方法です。 主に読み取りを分散するためのもので、同じ AZ では AZ の障害から守れない。 【C(不正解)】 ? その時点の DB の写しを保存する方法です。 データは戻せるが、復元するまで止まり、自動の切り替えにはならない。 【D(不正解)】 ? DB サーバーの性能を上げる方法です。 性能は上がるが、AZ の障害時に別の AZ へ切り替える仕組みにはならない。
RDS をマルチ AZ DB インスタンス配置(スタンバイ 1 つ)にした。参照の処理が増えたため、スタンバイにも読み取りを振り分けたい。正しい理解はどれか。
A. スタンバイの接続先を使えば、そのまま読み取りを振り分けられる B. マルチ AZ にしたので、読み取り性能は自動で 2 倍になる C. 読み取りの分散には、リードレプリカかマルチ AZ DB クラスターを使う D. 別のリージョンに DB を作り直さないと読み取りは増やせない
この問題へのリンク答えと解説
正解: C 【A(不正解)】 ? スタンバイを読み取りに使う考え方です。 この構成のスタンバイは読み取りの処理に使えない。フェイルオーバーのための待機用だ。 【B(不正解)】 ? 冗長化と性能を結びつけた考え方です。 高可用性のための構成で、読み取りのスケーリングの仕組みではないと公式は明記している。 【C(正解)】 ? 別の構成を組み合わせる考え方です。 公式は、読み取り専用の処理にはマルチ AZ DB クラスターかリードレプリカを使うよう案内している。 【D(不正解)】 ? リージョンを変える考え方です。 同じリージョン内でもリードレプリカなどで読み取りを分散できる。
複数リージョンを使うケース
目標復旧時間(RTO)の説明として最も適切なものは?
A. 最後にデータを復旧できる時点から、どれだけ前までのデータ損失を許せるか B. サービスが止まってから、復旧するまでに許される最大の時間 C. バックアップを保存しておく期間 D. 災害対策に使ってよい費用の上限
この問題へのリンク答えと解説
正解: B 【A(不正解)】 ? 失ってもよいデータの量を時間で表したものです。 これは目標復旧時点(RPO)の説明だ。 【B(正解)】 ? 止まっている時間の上限を表したものです。 公式の定義では、サービスの中断から復旧までの最大許容遅延時間を RTO と呼ぶ。 【C(不正解)】 ? データの写しを残す日数のことです。 保存期間は別の設定で、復旧にかけてよい時間の目標とは違う。 【D(不正解)】 ? 予算の目安のことです。 費用は戦略を選ぶときの判断材料だが、RTO の定義ではない。
法令により、顧客の個人データを国内に保存する必要がある。AWS で最初に決めるべきこととして最も適切なものは?
A. Amazon CloudFront で全世界に配信する B. 同じリージョンで使う AZ の数を増やす C. 性能の高いインスタンスタイプに変える D. データを保存するリージョンを国内のリージョンに限る
この問題へのリンク答えと解説
正解: D 【A(不正解)】 ? コンテンツを世界の拠点から配る方法です。 配信を速くする仕組みで、データを国内に保存するという要件を満たす手段ではない。 【B(不正解)】 ? リージョン内で冗長化を進める方法です。 可用性は上がるが、どの国にデータを置くかとは別の話だ。 【C(不正解)】 ? サーバーの性能を上げる方法です。 性能の選択で、データの保存場所の要件とは関係がない。 【D(正解)】 ? データを置く地理的な場所を選ぶ考え方です。 リージョンは法的な要件などを満たすように選ぶ。リソースはリージョン間で自動では複製されず、データ主権を考える出発点になる。
別のリージョンに、本番の縮小版を常に動かしておく。災害時はそのまま通信を受け、すぐに規模を広げる。この災害対策の戦略はどれか。
A. ウォームスタンバイ B. パイロットライト C. バックアップと復元 D. マルチサイトアクティブ/アクティブ
この問題へのリンク答えと解説
正解: A 【A(正解)】 ? 縮小した本番の写しを、常に動く状態で持つ戦略です。 縮小版が既に動いており、すぐに通信を処理できる。災害時は規模を広げるだけでよい。 【B(不正解)】 ? データの複製と中核部分だけを用意しておく戦略です。 アプリのサーバーなどは止めてあり、使う前に起動が必要になる。すぐには通信を処理できない。 【C(不正解)】 ? バックアップから環境を作り直す戦略です。 災害後にインフラの再作成とデータの復元が必要で、4 つの戦略のうち費用は低いが復旧に時間がかかる。 【D(不正解)】 ? 複数のリージョンで同時に本番を動かす戦略です。 縮小版ではなく、すべてのリージョンが本番として通信を処理する。
出典: クラウド内での災害対策オプション
世界中の利用者が近くのリージョンで読み書きでき、1 つのリージョンが止まっても他で続けられる DB にしたい。最も適切なものは?
A. 1 つのリージョンの RDS をマルチ AZ 配置にする B. Amazon ElastiCache を 1 つのリージョンに置く C. DynamoDB グローバルテーブルを使う D. AWS Backup で別のリージョンへバックアップをコピーする
この問題へのリンク答えと解説
正解: C 【A(不正解)】 ? 1 つのリージョン内で冗長化する構成です。 AZ の障害には強いが、リージョン全体が止まる場合や世界からの近い読み書きには対応しない。 【B(不正解)】 ? メモリ上のキャッシュのサービスです。 応答を速くする仕組みで、複数のリージョンで読み書きできるデータベースではない。 【C(正解)】 ? 選んだ複数のリージョンにテーブルを複製する DynamoDB の機能です。 マルチアクティブで主のテーブルがなく、各リージョンで読み書きできる。リージョン間の切り替えも複雑にならない。 【D(不正解)】 ? バックアップを別の場所へ写す方法です。 データは守れるが、使うには復元が必要で、各リージョンで同時に読み書きはできない。
EC2 とインスタンスタイプ
インスタンスタイプ名「c7gn.xlarge」のうち「xlarge」が表すものは?
A. 世代 B. シリーズ C. インスタンスサイズ D. オプション
この問題へのリンク答えと解説
正解: C 【A(不正解)】 ? 何代目の設計かを表す部分です。 世代は 2 番目の位置の数字(この例では 7)で表す。 【B(不正解)】 ? どの用途向けの系統かを表す部分です。 シリーズは最初の文字(この例では c)で表す。 【C(正解)】 ? 同じ系統の中での大きさを表す部分です。 ピリオドの後ろはインスタンスサイズを表す。small や 4xlarge などがある。 【D(不正解)】 ? プロセッサや追加の性能などを表す部分です。 オプションは世代の後ろの文字(この例では gn)で表す。
動画の変換やバッチ処理など、高性能なプロセッサを生かす計算中心の処理を EC2 で動かす。向いているインスタンスの系統は?
A. コンピューティング最適化 B. メモリ最適化 C. ストレージ最適化 D. バーストパフォーマンスインスタンス
この問題へのリンク答えと解説
正解: A 【A(正解)】 ? CPU の処理能力を重視した系統です。 高性能なプロセッサが生きる計算中心のアプリ向けで、バッチ処理やメディアの変換が使い道の例だ。 【B(不正解)】 ? 大量のデータをメモリで扱う系統です。 インメモリの DB や分析など、メモリを多く使う処理向けだ。 【C(不正解)】 ? ローカルのストレージへの読み書きを重視した系統です。 大量の低レイテンシーなランダム I/O が必要な処理向けだ。 【D(不正解)】 ? 普段は基準の性能で動き、必要なときだけ一時的に高くなる系統です。 CPU を常に高く使い続ける処理には、固定パフォーマンスのインスタンスが勧められている。
大量のデータをメモリに載せて処理するインメモリのデータベースを EC2 で動かす。向いているインスタンスの系統は?
A. 汎用 B. コンピューティング最適化 C. 高速コンピューティング D. メモリ最適化
この問題へのリンク答えと解説
正解: D 【A(不正解)】 ? 計算・メモリ・ネットワークのつり合いを取った系統です。 ウェブサーバーなど幅広い用途向けで、大量のデータをメモリで扱う処理に特化してはいない。 【B(不正解)】 ? CPU の処理能力を重視した系統です。 計算中心の処理向けで、メモリの多さを重視した系統ではない。 【C(不正解)】 ? GPU などのアクセラレーターを使う系統です。 画像処理や浮動小数点の計算などをハードウェアで速くする系統だ。 【D(正解)】 ? 大量のデータをメモリで処理する用途向けの系統です。 メモリ上で大きなデータセットを処理する作業で速い性能を出すよう設計され、インメモリ DB が使い道の例だ。
スループットの高いデータベースを EC2 で動かす。毎秒非常に多くの低レイテンシーなランダム I/O が必要だ。向いているインスタンスの系統は?
A. HPC 最適化 B. ストレージ最適化 C. メモリ最適化 D. バーストパフォーマンスインスタンス
この問題へのリンク答えと解説
正解: B 【A(不正解)】 ? 大規模な科学技術計算向けの系統です。 複雑なシミュレーションなどの計算を大規模に動かす向けで、ストレージ I/O 重視の系統ではない。 【B(正解)】 ? ローカルのストレージへの大量の読み書きを重視した系統です。 毎秒数百万回の低レイテンシーなランダム I/O を出せるよう設計され、高スループットの DB が使い道の例だ。 【C(不正解)】 ? 大量のデータをメモリで処理する系統です。 メモリ上の処理向けで、ストレージへの大量のランダム I/O を主な目的にした系統ではない。 【D(不正解)】 ? 普段は基準の CPU 性能で動く系統です。 負荷が低めの汎用の処理向けで、大量の I/O を常に求める DB には向かない。
社内の小さなウェブサーバーは、普段の CPU 使用率が低く、たまに短い時間だけ高くなる。費用効率がよい系統として最も適切なものは?
A. 高速コンピューティング(P 系・G 系など) B. HPC 最適化(Hpc 系) C. バーストパフォーマンス(T 系) D. ストレージ最適化(I 系・D 系など)
この問題へのリンク答えと解説
正解: C 【A(不正解)】 ? GPU などのアクセラレーターを使う系統です。 GPU が必要な処理向けで、負荷の低いウェブサーバーには過剰になる。 【B(不正解)】 ? 大規模な科学技術計算向けの系統です。 大規模な計算を前提にした系統で、小さなウェブサーバーには合わない。 【C(正解)】 ? 基準の性能で動き、必要なときだけ一時的に性能を上げる系統です。 T 系のインスタンスは基準の CPU 性能を持ち、クレジットを使って基準を超えて動ける。ウェブサーバーが使い道の例だ。 【D(不正解)】 ? ローカルのストレージへの大量の読み書きを重視した系統です。 大量のランダム I/O が必要な処理向けで、この用途には合わない。
コンテナ(ECS・EKS)
Kubernetes を使ったコンテナの運用で、コントロールプレーンの管理を AWS に任せたい。最も適切なサービスは?
A. Amazon Elastic Kubernetes Service B. Amazon Elastic Container Registry C. AWS Batch D. Amazon Lightsail
この問題へのリンク答えと解説
正解: A 【A(正解)】 ? Kubernetes のクラスターを動かすためのマネージドサービスです。 EKS ではコントロールプレーンを AWS が管理する。Kubernetes 準拠の認定を受けている。 【B(不正解)】 ? コンテナイメージを保存するサービスです。 イメージの保存場所で、Kubernetes のクラスターを動かすサービスではない。 【C(不正解)】 ? 大量のバッチ処理ジョブを実行するサービスです。 バッチ処理を効率よく動かすサービスで、Kubernetes の管理を任せる用途ではない。 【D(不正解)】 ? 低料金で使える仮想サーバーのサービスです。 手軽な仮想サーバーで、Kubernetes のコントロールプレーンを管理するサービスではない。
出典: Amazon EKS とは
Kubernetes の経験者はいない。AWS の他のサービスと連携しやすい、フルマネージドのコンテナオーケストレーションを使いたい。最も適切なものは?
A. Amazon Elastic Kubernetes Service B. Amazon Elastic Container Registry C. AWS Lambda D. Amazon Elastic Container Service
この問題へのリンク答えと解説
正解: D 【A(不正解)】 ? Kubernetes のクラスターを動かすマネージドサービスです。 Kubernetes の知識や道具を前提とするため、経験者がいない場合の第一候補にはなりにくい。 【B(不正解)】 ? コンテナイメージを保存するサービスです。 イメージを置く場所で、コンテナを配置・管理するオーケストレーションは行わない。 【C(不正解)】 ? 関数としてコードを動かすサーバーレスのサービスです。 関数を動かすサービスで、コンテナのオーケストレーションのサービスではない。 【D(正解)】 ? AWS 独自のコンテナ管理のサービスです。 ECS は AWS の運用のベストプラクティスを組み込み、ECR などの AWS のツールとも統合されている。
自分たちで作ったコンテナイメージを保存・共有し、ECS や EKS から取り出して使いたい。最も適切なサービスは?
A. Amazon S3 Glacier B. Amazon Elastic Container Registry C. Amazon Elastic Container Service D. Amazon Elastic File System
この問題へのリンク答えと解説
正解: B 【A(不正解)】 ? 長期保存向けの低コストなアーカイブ用ストレージです。 めったに使わないデータを安く保管する場所で、コンテナイメージの配布には向かない。 【B(正解)】 ? コンテナイメージを保存・共有するレジストリです。 コンテナイメージを保存・管理するフルマネージドのレジストリで、ECS や EKS と連携する。 【C(不正解)】 ? コンテナを配置・管理するオーケストレーションのサービスです。 コンテナを動かして管理するサービスで、イメージを保存するレジストリではない。イメージの保存には ECR を組み合わせる。 【D(不正解)】 ? 複数のインスタンスで共有するファイルストレージです。 ファイルを共有する仕組みで、コンテナイメージのレジストリではない。
AWS 上の Kubernetes に加え、自社データセンターのサーバーでも同じ Kubernetes の運用でコンテナを動かしたい。最も適切なサービスは?
A. Amazon Elastic Container Registry B. AWS Fargate C. Amazon Elastic Kubernetes Service D. AWS Lambda
この問題へのリンク答えと解説
正解: C 【A(不正解)】 ? コンテナイメージを保存するサービスです。 イメージの保存場所で、自社の設備で Kubernetes クラスターを動かす仕組みではない。 【B(不正解)】 ? AWS 上でサーバー管理なしにコンテナを動かすエンジンです。 AWS のクラウドで動く実行環境で、自社データセンターのサーバーを使う形ではない。 【C(正解)】 ? Kubernetes のクラスターを動かすマネージドサービスです。 EKS は AWS クラウドでも自社データセンターでも Kubernetes クラスターを動かせる。EKS Anywhere や EKS Hybrid Nodes がある。 【D(不正解)】 ? イベントに応じて関数を動かすサービスです。 関数の実行サービスで、Kubernetes の運用をそろえる用途ではない。
出典: Amazon EKS とは
サーバーレス(Lambda・Fargate)
AWS Lambda の関数の料金の考え方として最も適切なものは?
A. 起動しておいたサーバーの台数と時間で払う B. リクエスト数と、実行した時間(GB 秒)の分を払う C. 年額の固定料金を前払いする D. 確保した最大の同時実行数で月額が決まる
この問題へのリンク答えと解説
正解: B 【A(不正解)】 ? 常に動かしているサーバーの分を払う考え方です。 Lambda ではサーバーを用意しない。使っていない時間の分を払う形ではない。 【B(正解)】 ? 使った分だけを払う考え方です。 Lambda 関数はリクエストごとと実行時間の GB 秒で課金され、前払いは不要だ。 【C(不正解)】 ? 使用量に関係なく決まった額を払う考え方です。 Lambda には前払いの約束は必要なく、使ったリソースの分だけ請求される。 【D(不正解)】 ? 上限の設定値で料金が決まる考え方です。 基本の料金は実際のリクエストと実行時間で決まる。
出典: AWS Lambda とは
S3 に画像がアップロードされるたびに、縮小画像を作る短い処理を動かしたい。サーバーの管理はしたくない。最も適切なものは?
A. EC2 インスタンスを 1 台、常に起動しておく B. Amazon EC2 Auto Scaling でインスタンスの数を変える C. Amazon Lightsail で仮想サーバーを作る D. AWS Lambda の関数を S3 のイベントで動かす
この問題へのリンク答えと解説
正解: D 【A(不正解)】 ? サーバーを用意して動かし続ける方法です。 動作はするが、サーバーの管理が必要で、画像が来ない間も料金がかかる。 【B(不正解)】 ? 負荷に応じて EC2 の台数を増減する機能です。 台数は調整できるが、EC2 の管理は残り、サーバーを持たない要件に合わない。 【C(不正解)】 ? 低料金で使える仮想サーバーのサービスです。 手軽だがサーバーそのもので、OS などの管理が必要になる。 【D(正解)】 ? イベントに応じてコードを動かすサーバーレスのサービスです。 Lambda は S3 などのイベントをきっかけにコードを動かし、スケーリングやパッチ適用も AWS が管理する。
出典: AWS Lambda とは
Amazon ECS でコンテナを動かしたい。ただし EC2 インスタンスのクラスターの管理や、サーバーの種類選びはしたくない。最も適切なものは?
A. AWS Fargate B. EC2 起動のキャパシティを使う C. AWS Outposts D. Amazon Elastic Container Registry
この問題へのリンク答えと解説
正解: A 【A(正解)】 ? サーバーを管理せずにコンテナを動かすエンジンです。 Fargate を使うと、クラスターの用意や拡張、サーバーの種類選びが要らない。タスクごとに独自の分離境界を持つ。 【B(不正解)】 ? 自分で選んだ EC2 インスタンスでコンテナを動かす形です。 インスタンスタイプや台数を自分で選び、キャパシティを管理する必要がある。 【C(不正解)】 ? AWS の設備を自社の拠点に置くサービスです。 オンプレミスで AWS を使う仕組みで、サーバー管理をなくす目的のものではない。 【D(不正解)】 ? コンテナイメージを保存するサービスです。 イメージの保存場所で、コンテナを動かす実行環境ではない。
出典: Amazon ECS の AWS Fargate 用のアーキテクト/Amazon Elastic Container Service とは
1 回の処理に約 2 時間かかる動画の変換を、コンテナにまとめて動かしたい。サーバーの管理はしたくない。最も適切な方法は?
A. AWS Lambda の関数で、1 回の呼び出しで処理する B. Lambda のタイムアウトを 2 時間に延ばす C. AWS Fargate で ECS のタスクとして動かす D. EC2 インスタンスを自分で用意して動かす
この問題へのリンク答えと解説
正解: C 【A(不正解)】 ? 関数として短い処理を動かす方法です。 Lambda 関数は 1 回の呼び出しで原則最大 15 分までしか動かせず、2 時間の処理には足りない。 【B(不正解)】 ? 制限時間の設定を変える考え方です。 関数のタイムアウトの上限は 900 秒(15 分)だ。Lambda マネージドインスタンスの非同期呼び出しなどでも最大 90 分で、2 時間には届かない。 【C(正解)】 ? サーバーを管理せずにコンテナを動かす方法です。 Fargate なら EC2 の管理なしにコンテナを動かせる。Lambda 関数の実行時間の上限も受けない。 【D(不正解)】 ? サーバーを自分で管理する方法です。 処理はできるが、サーバーの管理をしたくないという要件に反する。
自動スケーリングとロードバランサー
ロードバランサー(Elastic Load Balancing)の役割として最も適切なものは?
A. ドメイン名を IP アドレスに変える B. 通信を複数の AZ のターゲットに分け、正常なものだけに送る C. 負荷に応じて EC2 インスタンスの数を増減する D. 画像などの写しを利用者の近くの拠点に置いて配る
この問題へのリンク答えと解説
正解: B 【A(不正解)】 ? 名前とアドレスを対応させる仕組みです。 これは DNS の役割で、Amazon Route 53 が担う。 【B(正解)】 ? 通信を分散し、状態を見ながら送り先を選ぶ仕組みです。 ELB は受けた通信を複数の AZ の EC2 インスタンスやコンテナに自動で分散し、正常なターゲットにだけ送る。 【C(不正解)】 ? サーバーの台数を調整する仕組みです。 これは Amazon EC2 Auto Scaling の役割だ。 【D(不正解)】 ? コンテンツをキャッシュして配信する仕組みです。 これは Amazon CloudFront の役割だ。
Auto Scaling グループを、最小 2・希望 4・最大 8 に設定した。動いている 1 台が故障したときの動きとして最も適切なものは?
A. 異常と判断して新しいインスタンスに置き換え、4 台を保つ B. 最小の 2 台を下回っていないので、3 台のまま動き続ける C. 故障をきっかけに、最大の 8 台まで一気に増やす D. グループ全体を止め、担当者の操作を待つ
この問題へのリンク答えと解説
正解: A 【A(正解)】 ? 異常な台を交換して数を維持する動きです。 EC2 Auto Scaling はヘルスチェックでインスタンスの状態を監視し、障害が起きたものを置き換えて希望する容量を保つ。 【B(不正解)】 ? 下限だけを守る動きです。 希望する容量の 4 台を保つように置き換えが行われる。 【C(不正解)】 ? 上限まで増やす動きです。 故障しただけで最大まで増やすことはない。希望する容量に戻すのが基本だ。 【D(不正解)】 ? 人の判断を待つ動きです。 異常なインスタンスは自動で置き換えられ、グループ全体が止まることはない。
出典: Amazon EC2 Auto Scaling とは/スケーリング方法を選択する(Amazon EC2 Auto Scaling)
12 月 1 日 10 時に新商品の販売を始めるため、その直前にウェブサーバーの台数を増やしておきたい。最も適切なスケーリング方法は?
A. 動的スケーリング B. 予測スケーリング C. スケジュールに基づくスケーリング D. 固定数のインスタンスを維持する
この問題へのリンク答えと解説
正解: C 【A(不正解)】 ? 負荷の変化に反応して台数を変える方法です。 負荷が上がってから反応するため、販売開始の直前に前もって増やす目的には合わない。 【B(不正解)】 ? 過去の日ごと・週ごとの通信の傾向から先回りして増やす方法です。 繰り返す傾向をもとにするため、1 回限りの販売開始の日時に合わせる用途には向かない。 【C(正解)】 ? 日付と時刻を指定して台数を変える方法です。 台数を変える時刻がはっきりわかっているときに便利な方法で、販売開始の直前に増やせる。 【D(不正解)】 ? 台数を変えずに保つ方法です。 異常な台の交換はするが、台数を前もって増やす動きはしない。
アクセスがいつ増えるかは読めない。グループの CPU 使用率が約 50% になるよう、台数を自動で増減したい。最も適切な方法は?
A. スケジュールに基づくスケーリング B. 予測スケーリングだけを使う C. 手動で希望する容量を変える D. 動的スケーリングのポリシーを設定する
この問題へのリンク答えと解説
正解: D 【A(不正解)】 ? 日付と時刻を決めて台数を変える方法です。 増える時刻がわからない今回の条件では、いつ増やすかを決められない。 【B(不正解)】 ? 過去の傾向から先回りして増やす方法です。 繰り返す傾向に先回りする方法で、読めない変化への反応を単独で担う方法ではない。 【C(不正解)】 ? 担当者が台数を変える方法です。 人の対応が必要で、急な変化に間に合わないことがある。 【D(正解)】 ? 負荷の変化に応じて自動で台数を変える方法です。 公式は、CPU 使用率を約 50% に保つ例を挙げている。通信がいつ変わるかわからない場合に向く方法だ。
ゲームの通信を TCP と UDP で受ける。非常に高い性能と、固定の IP アドレスが必要だ。ロードバランサーの種類として最も適切なものは?
A. Application Load Balancer B. Network Load Balancer C. Gateway Load Balancer D. Classic Load Balancer
この問題へのリンク答えと解説
正解: B 【A(不正解)】 ? HTTP や HTTPS の通信をレイヤー 7 で振り分ける種類です。 ヘッダーに基づく振り分けなど、ウェブの通信の細かな制御に向く。TCP や UDP をそのまま扱う種類ではない。 【B(正解)】 ? TCP・UDP・TLS の通信をレイヤー 4 で振り分ける種類です。 非常に高い性能と固定の IP アドレスが必要なときに向くと公式は案内している。 【C(不正解)】 ? セキュリティ機器などのアプライアンスに通信を配る種類です。 アプライアンスへの通信の分散に使う種類で、ゲームの通信を受ける用途ではない。 【D(不正解)】 ? 前の世代のロードバランサーです。 公式は現行世代のロードバランサーへの移行を勧めており、新しく選ぶ対象ではない。
出典: Elastic Load Balancing features/Elastic Load Balancing とは?/Gateway Load Balancer とは?
マネージド DB とリレーショナル DB(RDS・Aurora)
Amazon RDS を使うと AWS に任せられる作業として最も適切なものは?
A. 遅い SQL クエリのチューニング B. アプリケーションの最適化 C. バックアップ、パッチ適用、障害の検出と復旧 D. どの表にどんなデータを持つかの設計
この問題へのリンク答えと解説
正解: C 【A(不正解)】 ? SQL を書き直して速くする作業です。 公式の責任共有の説明では、クエリのチューニングは利用者の責任とされている。 【B(不正解)】 ? アプリの作りを改善する作業です。 公式の比較表では、オンプレミス・EC2・RDS のどれでも利用者の担当だ。 【C(正解)】 ? データベースの日々の運用作業です。 RDS はバックアップ、ソフトウェアのパッチ適用、自動の障害検出と復旧を管理する。 【D(不正解)】 ? データの持ち方を決める作業です。 データベースの設計は利用者が決めることで、AWS が代わりに決める作業ではない。
RDS が対応していない商用 DB ソフトを、そのまま使い続ける必要がある。OS とソフトの管理は自社で行う。最も適切な置き場所は?
A. Amazon EC2 のインスタンスに DB ソフトを自分で入れる B. Amazon RDS で DB インスタンスを作る C. Amazon DynamoDB にそのまま移す D. Amazon ElastiCache にそのまま移す
この問題へのリンク答えと解説
正解: A 【A(正解)】 ? 仮想サーバーに DB を自分で導入する方法です。 EC2 なら必要なソフトを導入できる。ハードウェアは AWS が管理し、OS や DB の更新は利用者が行う。 【B(不正解)】 ? マネージドのリレーショナル DB サービスです。 RDS で使えるのは対応する DB エンジンだけで、対応していないソフトは動かせない。 【C(不正解)】 ? サーバーレスの NoSQL データベースです。 NoSQL で JOIN 演算子に対応しないため、既存の商用 DB をそのまま動かす場所にはならない。 【D(不正解)】 ? メモリ上のキャッシュのサービスです。 キャッシュのサービスで、商用 DB ソフトを動かす環境ではない。
出典: Amazon Relational Database Service (Amazon RDS) とは/AWS で組織に適したデータベースを選択する
MySQL と互換性があり、データが増えるとストレージが自動で拡張されるマネージドなリレーショナル DB を使いたい。最も適切なものは?
A. Amazon DynamoDB B. Amazon ElastiCache C. Amazon DocumentDB D. Amazon Aurora
この問題へのリンク答えと解説
正解: D 【A(不正解)】 ? サーバーレスの NoSQL データベースです。 キーバリューとドキュメントの NoSQL で、MySQL と互換のあるリレーショナル DB ではない。 【B(不正解)】 ? メモリ上のキャッシュのサービスです。 Valkey などと互換のあるキャッシュで、MySQL 互換の DB ではない。 【C(不正解)】 ? MongoDB 互換のドキュメントデータベースです。 ドキュメント型の DB で、MySQL と互換性はない。 【D(正解)】 ? MySQL・PostgreSQL と互換性のあるリレーショナル DB です。 Aurora のクラスターボリュームは、データの量が増えると自動で大きくなる。既存の MySQL 用のコードやツールも使える。
Amazon Aurora のデータの保存のしかた(クラスターボリューム)として最も適切なものは?
A. 1 つの AZ にだけ保存し、別の AZ にはスナップショットを送る B. 1 つのリージョンの 3 つの AZ にデータの写しを持ち、AZ 間で自動で複製する C. DB インスタンスを追加するたびに、データを丸ごと新しく写す D. 容量を最初に決め、足りなくなったら手で拡張する
この問題へのリンク答えと解説
正解: B 【A(不正解)】 ? データを 1 か所にだけ置く形です。 Aurora のクラスターボリュームは 3 つの AZ にデータの写しを持ち、1 か所だけに置く形ではない。 【B(正解)】 ? 複数の AZ にまたがってデータを持つ形です。 公式は、写しが 3 つの AZ にあり、DB インスタンスの数とは関係なく複製されると説明している。 【C(不正解)】 ? インスタンスごとにデータを持つ形です。 Aurora はデータを共有ストレージに置くため、インスタンスを足してもデータの写しを新しく作らない。 【D(不正解)】 ? 容量を事前に確保する形です。 クラスターボリュームはデータの増加に合わせて自動で大きくなる。
NoSQL とインメモリ DB(DynamoDB・ElastiCache)
Amazon DynamoDB の説明として最も適切なものは?
A. サーバーレスで、1 桁ミリ秒の性能を出す NoSQL DB B. MySQL と PostgreSQL に互換性のあるリレーショナル DB C. Valkey や Memcached と互換性があるインメモリのキャッシュ D. データ同士のつながりを扱うグラフ DB
この問題へのリンク答えと解説
正解: A 【A(正解)】 ? キーバリューとドキュメントを扱うデータベースの説明です。 DynamoDB はサーバーの用意やパッチ適用が要らず、キーバリューとドキュメントのデータモデルに対応する。 【B(不正解)】 ? 表と SQL で扱うデータベースの説明です。 これは Amazon Aurora の説明だ。 【C(不正解)】 ? メモリ上でデータを扱う仕組みの説明です。 これは Amazon ElastiCache の説明だ。 【D(不正解)】 ? 関係を中心にデータを持つ仕組みの説明です。 これは Amazon Neptune の説明だ。
RDS に同じ商品情報を読む問い合わせが集中し、応答が遅い。読み取りを速くし、DB の負荷も減らしたい。最も適切なものは?
A. データをすべて Amazon Redshift に移す B. Amazon Neptune を追加する C. よく読むデータを ElastiCache にキャッシュする D. RDS の自動バックアップの保存期間を延ばす
この問題へのリンク答えと解説
正解: C 【A(不正解)】 ? 大量のデータを分析するデータウェアハウスです。 分析向けのサービスで、アプリの頻繁な読み取りを速くする用途ではない。 【B(不正解)】 ? データ同士のつながりを扱うグラフ DB です。 つながりの分析向けの DB で、読み取りの集中をさばくキャッシュではない。 【C(正解)】 ? よく使うデータをメモリに置いて速く返す方法です。 Amazon ElastiCache はフルマネージドのインメモリのキャッシュで、よく読むデータを置くと応答が速くなり、DB への問い合わせも減る。 【D(不正解)】 ? バックアップを長く残す設定です。 データの保護に関する設定で、読み取りの速さや負荷には効かない。
DynamoDB の読み取りの応答時間を、ミリ秒からマイクロ秒にしたい。既存のアプリの変更は最小限にしたい。最も適切なものは?
A. DynamoDB でマルチ AZ 配置を有効にする B. DynamoDB Accelerator を使う C. データを Amazon Aurora に移す D. DynamoDB グローバルテーブルを有効にする
この問題へのリンク答えと解説
正解: B 【A(不正解)】 ? RDS で別の AZ にスタンバイを置く構成です。 RDS の高可用性の機能で、DynamoDB の読み取りを速くする設定ではない。 【B(正解)】 ? DynamoDB 用のインメモリのキャッシュです。 DAX は DynamoDB と API の互換性があり、少ない変更で読み取りの応答をマイクロ秒まで速くできる。 【C(不正解)】 ? リレーショナルの DB へ移す方法です。 DB の種類を変える大きな作業で、アプリの変更を最小限にする要件に合わない。 【D(不正解)】 ? テーブルを複数のリージョンに複製する機能です。 リージョンをまたぐ複製の機能で、読み取りをマイクロ秒にする目的のものではない。
スマホゲームのプレイヤーの状態を保存する。利用者は 10 人から 1 億人まで大きく変わる。JOIN は使わず、サーバーの管理なしで一定の低レイテンシーを保ちたい。最も適切なものは?
A. EC2 に MySQL を入れて自分で運用する B. Amazon Redshift に保存する C. Amazon Neptune に保存する D. Amazon DynamoDB に保存する
この問題へのリンク答えと解説
正解: D 【A(不正解)】 ? 仮想サーバーに DB を自分で入れる方法です。 利用者の増減に合わせた拡張やパッチ適用を自分で行う必要があり、管理なしの要件に合わない。 【B(不正解)】 ? 大量のデータを分析するデータウェアハウスです。 分析向けで、ゲームの状態を頻繁に読み書きする用途ではない。 【C(不正解)】 ? データ同士のつながりを扱うグラフ DB です。 関係の探索に強い DB で、この用途の第一候補ではない。 【D(正解)】 ? サーバーレスの NoSQL データベースです。 DynamoDB は 10 人でも 1 億人でも一貫した 1 桁ミリ秒の性能を出すよう作られ、公式はゲームの状態の保存を使い道の例に挙げている。
データベース移行(DMS・SCT)
オンプレミスの Oracle Database を Amazon Aurora PostgreSQL 互換に移す。テーブル定義などのスキーマを、移行先の形式に変換するツールは?
A. AWS Transform MGN B. AWS Schema Conversion Tool C. AWS Storage Gateway D. AWS Elastic Disaster Recovery
この問題へのリンク答えと解説
正解: B 【A(不正解)】 ? サーバーをそのまま AWS へ移すサービスです(旧称 AWS Application Migration Service)。 AWS Transform MGN(旧称 AWS Application Migration Service)はサーバーを丸ごと移すリホスト向けで、DB エンジンを変えるためのスキーマ変換はしない。 【B(正解)】 ? 手元の PC に入れて使うデスクトップのツールです。 AWS SCT は、DB エンジン間で既存のスキーマを変換する。自動で変換できない部分は、同等のものを作る手引きを示す。 【C(不正解)】 ? オンプレミスとクラウドのストレージをつなぐサービスです。 ファイルやボリュームを AWS のストレージにつなぐもので、DB のスキーマは扱わない。 【D(不正解)】 ? サーバーを複製し、障害時に素早く復旧するサービスです。 サーバーを複製して障害時に復旧させるためのもので、DB のスキーマを別のエンジン向けに変換する機能はない。
出典: AWS Schema Conversion Tool とは/AWS Database Migration Service とは/What is AWS Transform MGN?/AWS の概要(ホワイトペーパー): ストレージ
稼働中の MySQL を Amazon RDS for MySQL へ移したい。移行中も元の DB を使い続け、発生した変更を移行先に反映し続けたい。使うサービスは?
A. AWS Schema Conversion Tool B. AWS Migration Hub C. AWS Application Discovery Service D. AWS Database Migration Service
この問題へのリンク答えと解説
正解: D 【A(不正解)】 ? DB エンジン間でスキーマを変換するツールです。 同じ MySQL どうしならエンジンの変換は要らない。データの変更を同期し続けるのは DMS の役割である。 【B(不正解)】 ? 移行の進み具合を 1 か所で追うサービスです。 移行の状況を見える化するもので、データそのものを移したり同期したりはしない。なお 2025-11-07 から新規の受付を終えている。 【C(不正解)】 ? 移行の計画のために、オンプレミスのサーバーの情報を集めるサービスです。 移行の計画づくりを助けるもので、データを移したり変更を同期したりはしない。なお新規の受付を終えている。 【D(正解)】 ? データベースの移行のためのマネージドサービスです。 DMS は 1 回限りの移行に加え、変更を継続的に複製して移行元と移行先を同期できる。
出典: AWS Database Migration Service とは/What Is AWS Migration Hub?/What is AWS Application Discovery Service?
Microsoft SQL Server から Amazon Aurora MySQL 互換へ移す計画を立てている。エンジンが変わる異種移行の進め方として最も適切なものは?
A. スキーマを SCT などで変換し、データを DMS で移す B. DMS でデータだけを移し、スキーマの変換は省く C. Storage Gateway のファイル共有に DB のファイルを置く D. SCT だけで、データの継続的な同期まで済ませる
この問題へのリンク答えと解説
正解: A 【A(正解)】 ? スキーマとデータを別の道具で扱う流れです。 公式の流れは、SCT か DMS Schema Conversion でスキーマを変換して適用し、その後 DMS でデータを移すというものである。 【B(不正解)】 ? データの移動だけで済ませる考え方です。 エンジンが変わる場合は、スキーマやコードを移行先の形式に変換する作業が必要になる。 【C(不正解)】 ? ファイル共有を経由する考え方です。 Storage Gateway はファイルやボリュームを扱うもので、DB エンジン間の変換と移行は行わない。 【D(不正解)】 ? 変換ツール 1 つで済ませる考え方です。 SCT は主にスキーマを変換する道具である。データの移行と継続的な複製は DMS が受け持つ。
出典: AWS Database Migration Service とは/AWS Schema Conversion Tool とは
VPC の構成要素(サブネット・ゲートウェイ)
Amazon VPC の中を IP アドレスの範囲で区切った区画で、EC2 インスタンスを起動する場所になるものは?
A. アベイラビリティーゾーン B. セキュリティグループ C. サブネット D. ルートテーブル
この問題へのリンク答えと解説
正解: C 【A(不正解)】 ? リージョンの中にある、独立したデータセンター群です。 AZ は物理的な場所の単位であり、VPC の IP アドレス範囲を区切ったものではない。 【B(不正解)】 ? インスタンスへの通信を制御する仕組みです。 通信の許可を決める仮想のファイアウォールで、アドレス範囲の区画ではない。 【C(正解)】 ? VPC の中に作るネットワークの単位です。 サブネットは VPC の IP アドレスの範囲で、EC2 などのリソースはサブネットの中で起動する。 【D(不正解)】 ? 通信の行き先を決めるルールの集まりです。 トラフィックの経路を決める表であり、インスタンスを置く区画そのものではない。
出典: Amazon VPC の仕組み
プライベートサブネットの DB サーバーが、更新ファイルを取るためにインターネットへ出たい。インターネット側から始まる接続は受けたくない。使うものは?
A. インスタンスにパブリック IP を付け、インターネットゲートウェイへ直接出す B. NAT ゲートウェイを置き、そこを経由させる C. AWS Direct Connect で専用接続を作る D. Elastic Load Balancing をサーバーの前に置く
この問題へのリンク答えと解説
正解: B 【A(不正解)】 ? サーバーを外から見える場所に置く方法です。 これでは外からの接続も届き得る形になる。DB をプライベートに保つという条件に合わない。 【B(正解)】 ? 複数のプライベート IP アドレスを 1 つの公開アドレスに対応づける仕組みです。 NAT デバイスは、VPC 内からの外向きの接続を許し、外から始まる求めていない接続は拒否する。 【C(不正解)】 ? 自社の拠点と AWS を専用線で結ぶサービスです。 オンプレミスとの専用接続であり、VPC 内のサーバーをインターネットに出すためのものではない。 【D(不正解)】 ? 受けた通信を複数のターゲットに振り分ける仕組みです。 入ってくる通信を分散するもので、プライベートなサーバーの外向き通信を実現するものではない。
新しく作った VPC のサブネットを、インターネットと直接やり取りできるパブリックサブネットにしたい。必要な設定の組み合わせは?
A. サブネットに NAT ゲートウェイを置くだけにする B. セキュリティグループですべての通信を許可する C. 別の VPC との VPC ピアリングの接続を作る D. インターネットゲートウェイを付け、そこへの経路を足す
この問題へのリンク答えと解説
正解: D 【A(不正解)】 ? 外向きの通信を肩代わりする仕組みを置く方法です。 NAT は内側から外へ出る通信のためのもので、それだけではサブネットはパブリックにならない。 【B(不正解)】 ? インスタンス側の通信の許可を広げる方法です。 セキュリティグループを広げても、外への経路が無ければインターネットとは通信できない。 【C(不正解)】 ? 2 つの VPC をつなぐ方法です。 VPC どうしをプライベートにつなぐもので、インターネットへの出入り口にはならない。 【D(正解)】 ? VPC の出入り口を作り、そこへ向かう道を登録する方法です。 インターネットゲートウェイを付け、ルートテーブルで通信をそこへ送るとパブリックサブネットになる。インスタンスにはパブリック IP も要る。
出典: Amazon VPC の仕組み
会社の VPC が数百に増え、オンプレミスの拠点ともつなぐ必要がある。1 対 1 の接続の管理が限界に近い。接続を一元的にまとめる方法は?
A. すべての VPC の組み合わせに VPC ピアリングを作り直す B. AWS Transit Gateway をハブにして、各 VPC と拠点をそこにつなぐ C. 各 VPC に インターネットゲートウェイを付け、インターネット経由で通信させる D. 各 VPC に NAT ゲートウェイを置いて相互に通信させる
この問題へのリンク答えと解説
正解: B 【A(不正解)】 ? VPC を 1 対 1 で結ぶ方法を増やす考え方です。 1 対 1 の接続が増えるほど管理は重くなる。数百の VPC では問題が大きくなる。 【B(正解)】 ? リージョンの仮想ルーターとして働くゲートウェイを使う方法です。 Transit Gateway はハブとして働き、各ネットワークはそこにつなぐだけで済む。管理が大きく簡単になる。 【C(不正解)】 ? それぞれの VPC を公開の経路でつなぐ考え方です。 VPC 間や拠点との接続をまとめる仕組みではなく、通信を公開の経路に出すことになる。 【D(不正解)】 ? 外向き通信用の仕組みを使う考え方です。 NAT は内側から外へ出るためのもので、多数の VPC と拠点を相互につなぐハブにはならない。
VPC のセキュリティ(セキュリティグループ・ネットワーク ACL)
インスタンス単位で付けて、許可のルールだけを書く。戻りの通信は自動で許可される。この VPC の仕組みは?
A. ネットワーク ACL B. AWS WAF C. セキュリティグループ D. ルートテーブル
この問題へのリンク答えと解説
正解: C 【A(不正解)】 ? サブネットの単位で通信を制御する仕組みです。 ネットワーク ACL はサブネット単位で働き、拒否のルールも書ける。戻りの通信も明示的な許可が要る。 【B(不正解)】 ? ウェブアプリへのリクエストをふるい分けるサービスです。 HTTP などのリクエストを検査するもので、VPC のインスタンス単位の通信制御とは別のものである。 【C(正解)】 ? VPC で使う仮想のファイアウォールの一つです。 セキュリティグループはインスタンス単位で働き、許可ルールだけを持つ。ステートフルなので戻りの通信は自動で許可される。 【D(不正解)】 ? 通信の行き先を決めるルールの集まりです。 経路を決めるもので、通信の許可や拒否を決める仕組みではない。
特定の IP アドレス範囲から届く通信を、サブネットにあるすべてのインスタンスについて明示的に拒否したい。使うものは?
A. ネットワーク ACLに拒否のルールを加える B. セキュリティグループに拒否のルールを加える C. Amazon Inspector でスキャンを始める D. ルートテーブルからその範囲を消す
この問題へのリンク答えと解説
正解: A 【A(正解)】 ? サブネットに関連付けて使う通信のルールです。 ネットワーク ACL はサブネット単位で働き、拒否ルールを書ける。特定の通信を止める用途に向く。 【B(不正解)】 ? インスタンス単位の通信のルールです。 セキュリティグループに書けるのは許可ルールだけで、拒否ルールは作れない。 【C(不正解)】 ? ソフトウェアの脆弱性などを調べるサービスです。 脆弱性や意図しないネットワークの露出を見つけるもので、通信を止める仕組みではない。 【D(不正解)】 ? 通信の行き先を決める表を書き換える方法です。 ルートテーブルは送り先の経路を決めるもので、届く通信を送信元で拒否する機能ではない。
EC2 インスタンスと Amazon ECR のコンテナイメージに、ソフトウェアの脆弱性がないかを調べたい。予定を組まず、自動で続けて確認したい。使うサービスは?
A. Amazon Macie B. Amazon GuardDuty C. AWS Trusted Advisor D. Amazon Inspector
この問題へのリンク答えと解説
正解: D 【A(不正解)】 ? S3 の機密データを見つけるサービスです。 Macie は機密データの発見と保護のためのもので、ソフトウェアの脆弱性は調べない。 【B(不正解)】 ? 脅威の兆しを見張るサービスです。 GuardDuty は不審な動きなどの脅威を検出するもので、ソフトウェアの脆弱性を調べるサービスではない。 【C(不正解)】 ? ベストプラクティスに沿っているかを点検するサービスです。 コストやセキュリティの設定の推奨を示すもので、イメージ内のソフトウェアの脆弱性は調べない。 【D(正解)】 ? AWS のセキュリティサービスの一つです。 Inspector は EC2・ECR のコンテナイメージ・Lambda 関数を自動で見つけ、脆弱性を継続的にスキャンする。
サブネットのネットワーク ACLで受信の HTTPS を許可したのに、利用者に応答が返らない。セキュリティグループの設定は正しい。考えられる原因は?
A. セキュリティグループはステートレスなので、送信ルールが足りない B. ネットワーク ACL はステートレスで、戻りの通信を送信ルールで許可していない C. ネットワーク ACL はインスタンスごとに付けるので、付け忘れがある D. HTTPS の通信にはインターネットゲートウェイが要らないため、経路が無い
この問題へのリンク答えと解説
正解: B 【A(不正解)】 ? インスタンス単位の仕組みの性質に原因を求める考え方です。 セキュリティグループはステートフルで、戻りの通信は自動で許可される。原因はそこではない。 【B(正解)】 ? サブネット単位の仕組みの性質に原因を求める考え方です。 ネットワーク ACL では戻りの通信も明示的な許可が要る。送信側のルールが無いと応答は出ていけない。 【C(不正解)】 ? 付け方の単位に原因を求める考え方です。 ネットワーク ACL はサブネットの単位で働き、そのサブネットのすべてのインスタンスに効く。 【D(不正解)】 ? 出入り口の要否に原因を求める考え方です。 インターネットと通信するには、通信の種類にかかわらずインターネットゲートウェイへの経路が要る。
Route 53 と AWS への接続(VPN・Direct Connect)
`www.example.com` のような名前を IP アドレスに変換する DNS のサービスで、ドメイン名の登録もできるのは?
A. Amazon CloudFront B. Amazon Route 53 C. AWS Global Accelerator D. Amazon API Gateway
この問題へのリンク答えと解説
正解: B 【A(不正解)】 ? コンテンツを利用者の近くから配信するサービスです。 CloudFront は CDN であり、名前を IP アドレスに変換する DNS サービスではない。 【B(正解)】 ? 利用者のリクエストを宛先へルーティングするサービスです。 Route 53 は名前を IP アドレスに変換する DNS で、ドメイン名の購入と管理もできる。 【C(不正解)】 ? 固定の IP アドレスを入口にして通信を速くするサービスです。 AWS のネットワークを使って通信を届けるもので、DNS やドメイン登録のサービスではない。 【D(不正解)】 ? API を公開・管理するためのサービスです。 API の入口を作るもので、名前解決やドメイン名の登録は行わない。
本社のデータセンターと AWS を、インターネットを通らないプライベートな専用接続で結びたい。インターネットより安定した通信が欲しい。使うものは?
A. AWS Site-to-Site VPN B. AWS Client VPN C. Amazon CloudFront D. AWS Direct Connect
この問題へのリンク答えと解説
正解: D 【A(不正解)】 ? 拠点と VPC の間に暗号化したトンネルを作るサービスです。 安全な接続は作れるが、インターネットの回線上に作るトンネルであり、専用の接続ではない。 【B(不正解)】 ? 利用者の端末から AWS につなぐ VPN です。 個々の端末向けのリモート接続であり、データセンターと AWS を専用線で結ぶものではない。 【C(不正解)】 ? 世界中にコンテンツを配信する CDN です。 利用者への配信を速くするもので、拠点と AWS の専用接続ではない。 【D(正解)】 ? Direct Connect ロケーションを経由して AWS とつなぐサービスです。 Direct Connect はプライベートな専用接続を作り、インターネットより安定した通信を得やすい。
在宅勤務の社員が、自分のノート PC から VPC 内の社内システムに安全につなぎたい。社員ごとに接続できる方法は?
A. AWS Client VPN B. AWS Site-to-Site VPN C. AWS Direct Connect D. Amazon Route 53
この問題へのリンク答えと解説
正解: A 【A(正解)】 ? VPN クライアントのソフトを使う VPN サービスです。 Client VPN は VPN クライアントを使って、利用者を AWS やオンプレミスのリソースにつなぐ。 【B(不正解)】 ? 拠点のネットワークと VPC を結ぶサービスです。 拠点どうしをつなぐもので、社員一人ひとりの端末をつなぐ用途には合わない。 【C(不正解)】 ? 拠点と AWS を専用線でつなぐサービスです。 データセンターなどの拠点向けの専用接続で、自宅の個人端末からの接続には使わない。 【D(不正解)】 ? 名前を IP アドレスに変換する DNS サービスです。 名前解決のサービスで、端末と VPC の間に安全な接続を作る機能はない。
2 つのリージョンに同じサイトを置いた。片方が止まったら、利用者を自動で正常な方へ向けたい。DNS の仕組みで実現する方法は?
A. Amazon CloudFront でページを長くキャッシュする B. ネットワーク ACLで止まった側への通信を拒否する C. Amazon Route 53 のヘルスチェックと DNS フェイルオーバーを使う D. AWS Direct Connect を 2 本引く
この問題へのリンク答えと解説
正解: C 【A(不正解)】 ? 利用者の近くに写しを置く方法です。 配信を速くする仕組みで、DNS の応答を切り替えて正常な側へ向ける方法ではない。 【B(不正解)】 ? サブネットの通信を止める方法です。 通信を止めても、利用者を正常なリージョンへ向け直すことはできない。 【C(正解)】 ? Route 53 の機能を組み合わせる方法です。 Route 53 はヘルスチェックで正常なエンドポイントにだけ通信を向けられ、DNS フェイルオーバーと組み合わせられる。 【D(不正解)】 ? 専用接続を二重にする方法です。 拠点と AWS の接続を冗長にするもので、一般の利用者の行き先を切り替える仕組みではない。
S3 とストレージクラス・ライフサイクル
Amazon S3 にオブジェクトをアップロードするとき、S3 ストレージクラスを指定しないと、どのクラスに保存される?
A. S3 Intelligent-Tiering B. S3 Standard-IA C. S3 Glacier Flexible Retrieval D. S3 Standard
この問題へのリンク答えと解説
正解: D 【A(不正解)】 ? アクセスの様子に合わせて階層を自動で移すクラスです。 自動で階層を移すクラスだが、指定しなかったときに使われる既定のクラスではない。 【B(不正解)】 ? アクセスの少ないデータ向けのクラスです。 取り出し料金がかかる低頻度アクセス向けのクラスで、既定のクラスではない。 【C(不正解)】 ? アーカイブ向けのクラスです。 アーカイブ用で、使う前に復元が要る。指定なしで選ばれることはない。 【D(正解)】 ? よくアクセスするデータ向けのクラスです。 S3 Standard が既定のストレージクラスで、指定しなければこのクラスになる。
どれくらい読まれるか予測できず、時期によって変わるデータを S3 に置く。取り出し料金なしで、保存料金を自動で下げたい。選ぶクラスは?
A. S3 One Zone-IA B. S3 Intelligent-Tiering C. S3 Glacier Deep Archive D. S3 Standard-IA
この問題へのリンク答えと解説
正解: B 【A(不正解)】 ? 1 つの AZ だけに保存する低頻度アクセス向けのクラスです。 取り出し料金がかかり、AZ を失うとデータの回復性がない。自動で階層を移す機能もない。 【B(正解)】 ? 複数のアクセス階層を持つストレージクラスです。 アクセスパターンが不明・変化するデータ向けで、取り出し料金はかからない。少額の監視料金がかかる。 【C(不正解)】 ? 長期保存とデジタル保存向けのクラスです。 取り出しに数時間かかり、取り出し料金もかかる。よく読まれる時期があるデータには合わない。 【D(不正解)】 ? 月 1 回ほどしか読まないデータ向けのクラスです。 取り出し料金がかかるため、読まれる頻度が変わるデータでは費用が読みにくい。
規則で長期の保存が必要な監査記録がある。ほとんど読まず、読むときも取り出しに数時間かかってよい。保存料金を最も安くしたい。選ぶクラスは?
A. S3 Glacier Deep Archive B. S3 Standard C. S3 Glacier Instant Retrieval D. S3 One Zone-IA
この問題へのリンク答えと解説
正解: A 【A(正解)】 ? S3 Glacier の名が付くアーカイブ用クラスの一つです。 年 1 回未満しか読まず、数時間の取り出しを許せるデータ向けで、クラウドで最も低コストのストレージとされる。 【B(不正解)】 ? よくアクセスするデータ向けの既定のクラスです。 すぐ読める代わりに保存料金は高めで、ほとんど読まない記録には向かない。 【C(不正解)】 ? S3 Glacier の名が付く、ミリ秒で読めるクラスです。 ミリ秒で取り出せることが必要なアーカイブ向けである。数時間待てるならより安いクラスがある。 【D(不正解)】 ? 1 つの AZ に保存する低頻度アクセス向けのクラスです。 AZ を失うとデータの回復性がなく、再作成できないデータの長期保存には向かない。
アプリのログを S3 に置く。作成から 30 日はよく見るが、その後はほぼ見ず、1 年たったら消してよい。手作業を減らす方法として最も適切なものは?
A. バージョニングを有効にして、古い版を残す B. S3 Intelligent-Tiering に入れ、1 年後に担当者が手で消す C. S3 ライフサイクルで 30 日後に移行、365 日後に削除する D. 毎日すべてのログを S3 Glacier Deep Archive にコピーする
この問題へのリンク答えと解説
正解: C 【A(不正解)】 ? 上書き前の版を保存しておく機能です。 古い版が残るだけで、安いクラスへの移行や期限での削除は行われない。 【B(不正解)】 ? 自動の階層移動と手作業を組み合わせる方法です。 階層は自動で移るが、削除が手作業のまま残るため、手作業を減らすという目的に十分ではない。 【C(正解)】 ? バケットに規則を設定しておく方法です。 30 日後に Standard-IA へ移す移行アクションと、365 日後の有効期限アクションを組み合わせると、移動も削除も自動になる。 【D(不正解)】 ? すぐにアーカイブへ写す方法です。 よく見る最初の 30 日も取り出しに時間がかかり、元のログの削除も残る。
ブロックとファイル(EBS・インスタンスストア・EFS・FSx)
EC2 インスタンスに付けて使うブロックストレージで、インスタンスを停止してもデータが残るものは?
A. インスタンスストア B. Amazon Elastic Block Store C. Amazon Elastic File System D. Amazon S3
この問題へのリンク答えと解説
正解: B 【A(不正解)】 ? ホストのコンピュータに物理的に付いたディスクです。 インスタンスを停止・休止・終了するとデータは消える。 【B(正解)】 ? EC2 にアタッチして使うブロックストレージのサービスです。 EBS はブロックストレージのボリュームで、インスタンスの停止とは独立してデータを保持する。 【C(不正解)】 ? 複数のインスタンスで共有するファイルシステムです。 EFS は永続的だが、ブロックストレージではなくファイルストレージである。 【D(不正解)】 ? オブジェクトを保存するストレージです。 S3 はオブジェクトストレージで、EC2 にブロックデバイスとしてアタッチするものではない。
出典: Amazon Elastic Block Store とは/Amazon EC2 インスタンスストアボリュームのデータの永続性
EC2 のインスタンスストアに置いたキャッシュのデータが、そのまま残るのはどの操作をしたとき?
A. インスタンスを停止したとき B. インスタンスを終了したとき C. インスタンスを再起動したとき D. インスタンスを休止したとき
この問題へのリンク答えと解説
正解: C 【A(不正解)】 ? インスタンスを止めて、後で起動し直す操作です。 停止するとインスタンスストアのブロックは暗号的に消去され、データは残らない。 【B(不正解)】 ? インスタンスを削除する操作です。 終了するとインスタンスストアのデータは消える。 【C(正解)】 ? インスタンスを止めずに起動し直す操作です。 再起動ではインスタンスストアのデータは保持される。 【D(不正解)】 ? メモリの内容を保存して止める操作です。 休止でもインスタンスストアのデータは消える。
Linux の EC2 インスタンス数十台から、同じファイルを同時に読み書きしたい。容量はファイルの増減に合わせて自動で伸び縮みしてほしい。使うものは?
A. Amazon Elastic Block Store B. インスタンスストア C. Amazon S3 Glacier D. Amazon Elastic File System
この問題へのリンク答えと解説
正解: D 【A(不正解)】 ? EC2 にアタッチして使うブロックストレージのボリュームです。 EBS は EC2 に付けるボリュームで、複数台へのマルチアタッチは io1・io2 を同じ AZ の最大 16 台までに限る。容量もファイルの増減では自動で伸び縮みしない。 【B(不正解)】 ? インスタンスに付いた一時的なストレージです。 そのインスタンスだけの一時領域で、停止すると消え、台数をまたいで共有できない。 【C(不正解)】 ? 長期保存向けのアーカイブです。 アーカイブ用のストレージクラスで、ファイルを同時に読み書きする共有には向かない。 【D(正解)】 ? Linux 向けのマネージドなファイルシステムです。 EFS は数千台の EC2 から同時にアクセスでき、ファイルの追加や削除に合わせて自動で増減する。
出典: AWS の概要(ホワイトペーパー): ストレージ/マルチアタッチを使用して EBS ボリュームを複数の EC2 インスタンスへアタッチ
Windows の業務アプリを AWS に移す。Active Directory と連携した SMB の共有フォルダが必要で、ファイルサーバーの管理は減らしたい。選ぶものは?
A. Amazon FSx for Windows File Server B. Amazon Elastic File System C. Amazon Elastic Block Store を EC2 に付けて自分で共有を作る D. AWS Storage Gateway のボリュームゲートウェイを使う
この問題へのリンク答えと解説
正解: A 【A(正解)】 ? Windows Server 上に作られたマネージドな共有ファイルストレージです。 SMB と NTFS、Active Directory との連携に対応し、Windows のファイルサーバー管理の手間を減らせる。 【B(不正解)】 ? Linux 向けのファイルシステムです。 EFS は Linux ベースのワークロード向けで、Windows の SMB 共有の要件には合わない。 【C(不正解)】 ? ボリュームの上に自分でファイルサーバーを組む方法です。 共有はできても、ファイルサーバーの運用を自分で抱えることになり、管理を減らす目的に合わない。 【D(不正解)】 ? iSCSI でマウントするクラウドのボリュームです。 オンプレミスのサーバーにブロックのボリュームを渡すもので、AWS 上の SMB 共有の答えではない。
Storage Gateway と AWS Backup
オンプレミスのファイルサーバーを置き換えたい。社内からは NFS や SMB で使い、中身は S3 にオブジェクトとして置く。よく使うデータは手元のキャッシュで速く読みたい。使うものは?
A. Amazon Elastic Block Store B. AWS Backup C. S3 ファイルゲートウェイ D. Amazon CloudFront
この問題へのリンク答えと解説
正解: C 【A(不正解)】 ? EC2 に付けるブロックストレージです。 AWS 上の EC2 のためのボリュームで、オンプレミスのファイル共有を S3 につなぐものではない。 【B(不正解)】 ? バックアップを一元管理するサービスです。 バックアップの取得と保管を自動化するもので、日常のファイル共有の置き場にはならない。 【C(正解)】 ? Storage Gateway の種類の一つです。 AWS Storage Gateway の S3 ファイルゲートウェイは NFS・SMB でファイルを扱い、S3 にオブジェクトとして保存する。ローカルキャッシュで速く読める。 【D(不正解)】 ? コンテンツを世界に配信する CDN です。 利用者への配信を速くするもので、社内のファイル共有を置き換える仕組みではない。
EC2・EBS・RDS・DynamoDB のバックアップを、サービスごとのスクリプトではなく 1 か所の方針として決め、自動で取りたい。使うサービスは?
A. AWS Elastic Disaster Recovery B. AWS Backup C. S3 ライフサイクル D. AWS Storage Gateway
この問題へのリンク答えと解説
正解: B 【A(不正解)】 ? サーバーを複製し、障害時に素早く復旧するサービスです。 サーバーの複製と復旧のためのもので、多くのサービスのバックアップを方針で一元管理するものではない。 【B(正解)】 ? バックアップのためのフルマネージドサービスです。 AWS Backup はバックアッププランという方針を作り、複数のサービスのリソースに当てて自動化できる。 【C(不正解)】 ? S3 のオブジェクトを移したり消したりする規則です。 S3 のオブジェクトを管理する規則で、EC2 や RDS のバックアップは取らない。 【D(不正解)】 ? オンプレミスとクラウドのストレージをつなぐサービスです。 オンプレミスのアプリが AWS のストレージを使うためのもので、AWS のリソースのバックアップを一元管理しない。
出典: AWS Backup とは
オンプレミスのアプリが、全データに手元で低遅延にアクセスしたい。そのうえで、データは S3 にスナップショットとして非同期にバックアップしたい。合う構成は?
A. ボリュームゲートウェイのキャッシュ型ボリューム B. テープゲートウェイ C. ボリュームゲートウェイの保管型ボリューム D. S3 ファイルゲートウェイ
この問題へのリンク答えと解説
正解: C 【A(不正解)】 ? S3 を主な保存先にするボリュームの構成です。 手元に持つのは一部だけで、全データへの低遅延アクセスという条件に合わない。 【B(不正解)】 ? 仮想のテープでクラウドにアーカイブする構成です。 テープを使うバックアップとアーカイブ向けで、アプリが日常的に全データを読む用途ではない。 【C(正解)】 ? オンプレミス側を主な保存先にするボリュームの構成です。 保管型ボリュームは全データをローカルに保存し、スナップショットを非同期で S3 にバックアップする。 【D(不正解)】 ? ファイルを S3 にオブジェクトとして置く構成です。 ファイル共有の形で S3 を使うもので、ブロックのボリュームとスナップショットの要件とは違う。
AI/ML サービス
アンケートの自由記述が数万件ある。それぞれが肯定的か否定的かを自動で判定し、キーフレーズも取り出したい。使うサービスは?
A. Amazon Polly B. Amazon Comprehend C. Amazon Rekognition D. Amazon Textract
この問題へのリンク答えと解説
正解: B 【A(不正解)】 ? 文章を自然な音声に変えるサービスです。 テキスト読み上げのサービスで、文章の感情を判定する機能は持たない。 【B(正解)】 ? 自然言語処理で文章から洞察を取り出すサービスです。 Comprehend は言語の識別、キーフレーズの抽出、文章がどれほど肯定的か否定的かの理解などができる。 【C(不正解)】 ? 画像や動画を分析するサービスです。 画像と動画の分析が中心で、大量の自由記述の感情分析には使わない。 【D(不正解)】 ? スキャンした文書からテキストとデータを取り出すサービスです。 文書から文字や表を抜き出すもので、文章が肯定的か否定的かは判定しない。
問い合わせ窓口に、音声とテキストの両方で会話できるチャットボットを置きたい。深層学習の専門知識なしで作りたい。使うサービスは?
A. Amazon Transcribe B. Amazon Translate C. Amazon Polly D. Amazon Lex
この問題へのリンク答えと解説
正解: D 【A(不正解)】 ? 音声を文字に起こすサービスです。 音声をテキストにするだけで、利用者と会話するボットの仕組みは持たない。 【B(不正解)】 ? 文章を別の言語に翻訳するサービスです。 翻訳のサービスで、会話の流れを管理するボットは作れない。 【C(不正解)】 ? 文章を音声に変えるサービスです。 読み上げのサービスで、利用者の意図を理解して会話する機能は持たない。 【D(正解)】 ? Amazon Alexa と同じ深層学習の技術を使う AI サービスです。 Lex は音声認識と自然言語理解を備え、専門知識なしでチャットボットを作れる。
紙の申込書をスキャンした画像が大量にある。手書きの文字に加え、フォームの項目の値や表の中身を取り出してシステムに入れたい。使うサービスは?
A. Amazon Textract B. Amazon Comprehend C. Amazon Transcribe D. Amazon Polly
この問題へのリンク答えと解説
正解: A 【A(正解)】 ? 機械学習で文書を読み取る AI サービスです。 Textract は OCR を超えて、フォームの項目の入力内容や表の情報も識別し、手書きも抽出できる。 【B(不正解)】 ? 文章の意味や感情を分析するサービスです。 テキストを分析するもので、スキャン画像から表やフォームの値を抜き出す役ではない。 【C(不正解)】 ? 音声を文字に起こすサービスです。 入力は音声であり、スキャンした紙の文書は扱わない。 【D(不正解)】 ? 文章を音声に変えるサービスです。 テキストを読み上げるもので、画像から文字を取り出す機能はない。
社内に ML の専門家がいる。自社データで独自のモデルを作り、学習させ、本番で予測に使いたい。インフラの管理は減らしたい。使うサービスは?
A. Amazon Rekognition B. Amazon Polly C. Amazon SageMaker AI D. Amazon Translate
この問題へのリンク答えと解説
正解: C 【A(不正解)】 ? 学習済みの仕組みで画像や動画を分析するサービスです。 すぐ使える画像分析のサービスで、あらゆる用途の独自モデルを作る基盤ではない。 【B(不正解)】 ? 文章を自然な音声に変えるサービスです。 テキスト読み上げの AI サービスで、自社データで独自の ML モデルを学習させる基盤ではない。 【C(正解)】 ? 機械学習の開発に使うツールと基盤をそろえたサービスです。 SageMaker AI は、フルマネージドのインフラとツールで、あらゆる用途の ML モデルを構築・学習・デプロイできる。 【D(不正解)】 ? ニューラル機械翻訳のサービスです。 翻訳に特化した AI サービスで、自社データで独自モデルを作る用途には合わない。
分析サービス
S3 に置いた CSV のログに、標準 SQL で直接問い合わせたい。サーバーの管理はせず、実行したクエリの分だけ払いたい。使うサービスは?
A. Amazon Redshift B. Amazon Athena C. AWS Glue D. Amazon Quick Sight
この問題へのリンク答えと解説
正解: B 【A(不正解)】 ? クラウドのデータウェアハウスです。 大量のデータを分析できるが、S3 のデータを指して即座にクエリする用途なら別のサービスが手軽である。 【B(正解)】 ? サーバーレスの対話型クエリサービスです。 Athena はサーバーレスで管理するインフラがなく、実行したクエリの分だけ料金を払う。 【C(不正解)】 ? データの抽出・変換・ロードを行うサービスです。 データの準備やカタログ化をするもので、それだけで対話的に SQL を投げるサービスではない。 【D(不正解)】 ? ダッシュボードを作る BI のサービスです。 可視化のためのサービスで、S3 のデータに直接 SQL を実行する役ではない。
ウェブサイトのクリックの流れを、何十万もの発生元から絶えず集めたい。データはミリ秒で使えるようにし、リアルタイムの監視画面に流したい。使うサービスは?
A. Amazon Athena B. AWS Glue C. Amazon EMR D. Amazon Kinesis
この問題へのリンク答えと解説
正解: D 【A(不正解)】 ? S3 のデータに SQL で問い合わせるサービスです。 保存済みのデータを問い合わせるもので、流れ続けるデータをリアルタイムに取り込む役ではない。 【B(不正解)】 ? データを抽出・変換・ロードするサービスです。 分析のためにデータを準備するもので、リアルタイムのストリーミングの取り込みが主な役割ではない。 【C(不正解)】 ? オープンソースのツールで大量データを処理する基盤です。 Spark や Flink などのオープンソースのツールで大量データを処理する基盤である。多数の発生元からのデータを受け続ける取り込み口のサービスではない。 【D(正解)】 ? Kinesis に含まれるデータストリーミングのサービスです。 Kinesis Data Streams は何十万もの発生元からクリックストリームなどを絶えず取り込み、データはミリ秒単位で使えるようになる。
経営層が、ブラウザやスマートフォンから売上の対話型ダッシュボードを見られるようにしたい。サーバーは用意したくない。使うサービスは?
A. Amazon Quick Sight B. AWS Glue C. Amazon Kinesis D. Amazon Redshift
この問題へのリンク答えと解説
正解: A 【A(正解)】 ? データを可視化する BI の機能です。 Quick Sight はデータソースにつないでダッシュボードを作り、ブラウザやモバイルで共有できる。 【B(不正解)】 ? データの抽出・変換・ロードを行うサービスです。 データの準備役で、利用者が見るダッシュボードは作らない。 【C(不正解)】 ? ストリーミングデータを扱うサービスです。 リアルタイムのデータを取り込むもので、経営層向けの可視化の画面は提供しない。 【D(不正解)】 ? クラウドのデータウェアハウスです。 分析用にデータをためてクエリする場所で、可視化には別の BI ツールを組み合わせる。
出典: Amazon Quick とは(Amazon Quick Sight を含む)/AWS の概要(ホワイトペーパー): 分析
複数の DB と S3 のデータをまとめて分析したい。まず各データを見つけてスキーマなどのメタデータを記録し、変換して分析用に読み込みたい。中心になるサービスは?
A. Amazon Athena B. Amazon Quick Sight C. AWS Glue D. Amazon Kinesis
この問題へのリンク答えと解説
正解: C 【A(不正解)】 ? S3 のデータに SQL で問い合わせるサービスです。 準備が済んだデータに問い合わせる役で、データの発見と変換の中心となるサービスではない。 【B(不正解)】 ? ダッシュボードで可視化する BI の機能です。 分析結果を見せる役で、データの抽出と変換は行わない。 【C(正解)】 ? フルマネージドの抽出・変換・ロードのサービスです。 Glue はデータを見つけてテーブル定義などのメタデータを Data Catalog に保存し、ETL ジョブで変換・ロードする。 【D(不正解)】 ? ストリーミングデータを集めるサービスです。 リアルタイムのデータの取り込みが中心で、複数のデータのカタログ化と変換の中心ではない。
アプリケーション統合(EventBridge・SNS・SQS)
受け付けた処理をいったんメッセージとしてためておき、処理側のサーバーが自分のペースで取り出して進めたい。使うサービスは?
A. Amazon Simple Notification Service B. Amazon EventBridge C. Amazon Simple Queue Service D. AWS Step Functions
この問題へのリンク答えと解説
正解: C 【A(不正解)】 ? トピックに送った通知を多数の購読者に配るサービスです。 SNS はプッシュ型の配信で、メッセージをためて処理側が取りに行く仕組みではない。 【B(不正解)】 ? イベントをルールで振り分けて届けるサービスです。 イベントのルーティングが中心で、メッセージを順番待ちでためておく基本の仕組みではない。 【C(正解)】 ? フルマネージドのメッセージキューのサービスです。 SQS はメッセージを失わずに送受信・保存でき、部品どうしを切り離して処理できる。 【D(不正解)】 ? 処理の手順をワークフローとしてつなぐサービスです。 複数の手順を順に進める仕組みで、メッセージをためるキューそのものではない。
注文が 1 件入るたびに、在庫・配送・分析の 3 つの仕組みへ同じ知らせを同時に届けたい。1 回の送信で済ませたい。使うサービスは?
A. Amazon Simple Notification Service のトピック B. Amazon Simple Queue Service のキューを 1 つだけ使う C. Amazon Simple Email Service D. AWS X-Ray
この問題へのリンク答えと解説
正解: A 【A(正解)】 ? パブリッシュ/サブスクライブ型のメッセージングの仕組みです。 SNS はトピックに届いたメッセージを複数の購読者へファンアウトし、並行して処理させられる。 【B(不正解)】 ? メッセージを 1 か所にためる仕組みです。 キュー 1 つでは、同じメッセージを 3 つの仕組みに同時に配ることはできない。 【C(不正解)】 ? メールを送受信するサービスです。 人へのメール送信が中心で、システムどうしに同じ知らせを配る仕組みではない。 【D(不正解)】 ? リクエストの流れを追跡するサービスです。 アプリの分析とデバッグのためのもので、メッセージを配る役ではない。
毎朝 9 時に Lambda 関数を起動して集計を始めたい。サーバーを置かずに、決まった時刻で処理を呼び出したい。使うものは?
A. Amazon Simple Queue Service B. Amazon Simple Notification Service C. AWS CodePipeline D. Amazon EventBridge のスケジューラ
この問題へのリンク答えと解説
正解: D 【A(不正解)】 ? メッセージをためるキューのサービスです。 キューはメッセージをためるもので、時刻を決めて処理を起動する機能ではない。 【B(不正解)】 ? 通知を購読者に配るサービスです。 発行されたメッセージを配るもので、決まった時刻に自ら起動する仕組みではない。 【C(不正解)】 ? リリースの流れを自動化するサービスです。 コードの変更をきっかけに動くもので、毎朝の集計を起動する用途ではない。 【D(正解)】 ? EventBridge に含まれる機能の一つです。 EventBridge スケジューラは cron やレート式でスケジュールを作り、タスクを実行できる。
決済の処理で、注文のメッセージを送った順番どおりに、1 回だけ処理したい。順番の入れ替わりや二重処理を避けたい。選ぶものは?
A. Amazon Simple Queue Service の標準キュー B. SQS FIFO キュー C. Amazon Simple Notification Service のトピック D. Amazon EventBridge のイベントバス
この問題へのリンク答えと解説
正解: B 【A(不正解)】 ? スループットを重視するキューです。 標準キューの順序はベストエフォートで、少なくとも 1 回の配信である。順番どおり・1 回だけは保証されない。 【B(正解)】 ? 先入れ先出し型の SQS のキューです。 FIFO キューは、メッセージが送信された正確な順番で 1 回だけ処理されるように作られている。 【C(不正解)】 ? 多数の購読者に通知を配る仕組みです。 多数への配信が目的で、注文を順番どおりに 1 回だけ処理する仕組みではない。 【D(不正解)】 ? イベントをルールで振り分ける仕組みです。 イベントを届け先へ振り分ける仕組みで、メッセージを送信順に 1 回だけ処理するように作られたキューではない。
ビジネスアプリケーションとカスタマーイネーブルメント(Connect・SES・サポート)
電話やチャットの問い合わせを受け、担当者につなぐコンタクトセンターをクラウドで作りたい。使った分だけ払いたい。使うサービスは?
A. Amazon Simple Email Service B. Amazon Lex C. Amazon Connect D. Amazon WorkSpaces
この問題へのリンク答えと解説
正解: C 【A(不正解)】 ? メールを送受信するサービスです。 メールの送受信のサービスで、電話やチャットを担当者につなぐ機能は持たない。 【B(不正解)】 ? 会話型のボットを作るサービスです。 ボットを作る部品であり、担当者へのルーティングを含むコンタクトセンター全体ではない。 【C(正解)】 ? AI を活用した顧客対応のサービスです。 Amazon Connect は顧客を担当者につなぎ、ルーティングや実績の確認ができる。使った分だけ料金がかかる。 【D(不正解)】 ? クラウドのデスクトップのサービスです。 社員に仮想デスクトップを渡すもので、問い合わせを受けて振り分ける仕組みではない。
注文確認のメールやニュースレターを、自社のドメインのアドレスから大量に送りたい。メールサーバーの運用はしたくない。使うサービスは?
A. Amazon Simple Queue Service B. Amazon Connect C. Amazon Simple Notification Service D. Amazon Simple Email Service
この問題へのリンク答えと解説
正解: D 【A(不正解)】 ? メッセージをためるキューのサービスです。 システム間でメッセージを受け渡すもので、メールを送る機能はない。 【B(不正解)】 ? クラウドのコンタクトセンターです。 顧客と担当者をつなぐもので、大量のメール配信の基盤ではない。 【C(不正解)】 ? トピックの購読者に通知を配るサービスです。 SNS もメールで通知できるが、本文は自由に作れず、公式は社内向けのシステム通知用でマーケティング用ではないとしている。 【D(正解)】 ? メールの送受信のためのサービスです。 SES はマーケティングメールや注文確認などの取引メールの送信に使え、受信も扱える。
出典: Amazon SES とは/Amazon SNS email subscription setup and management
本番システムの不具合について、AWS の技術者に技術サポートのケースを出したい。今はベーシックサポートだけを使っている。まず必要なことは?
A. AWS ビジネスサポート+ 以上の有料プランに入る B. ベーシックサポートのまま技術サポートのケースを出す C. AWS Trusted Advisor の点検結果をそのまま送る D. AWS Health Dashboard で障害の情報を待つ
この問題へのリンク答えと解説
正解: A 【A(正解)】 ? 有料のサポートプランに切り替える方法です。 現在選べるプランはベーシック・ビジネスサポート+・エンタープライズ・Unified Operations で、技術サポートのケースはビジネスサポート+ 以上で使える。 【B(不正解)】 ? 今のプランのまま相談する考え方です。 ベーシックサポートはアカウントと請求の質問への回答などが中心で、技術サポートのケースは含まれない。 【C(不正解)】 ? ベストプラクティスの点検を使う考え方です。 点検で推奨は得られるが、技術者にケースを出す手段ではない。 【D(不正解)】 ? AWS のサービスの状態を確かめる画面です。 サービス側の状態は分かるが、自社システムの不具合を技術者に相談する手段ではない。
デベロッパーツール(CodeBuild・CodePipeline・X-Ray)
ソースコードのコンパイル、テストの実行、デプロイできるパッケージの作成を、ビルドサーバーを持たずに行いたい。使うサービスは?
A. AWS X-Ray B. AWS CodePipeline C. AWS CodeDeploy D. AWS CodeBuild
この問題へのリンク答えと解説
正解: D 【A(不正解)】 ? リクエストの流れを追って分析するサービスです。 動いているアプリの分析とデバッグのためのもので、コードのビルドはしない。 【B(不正解)】 ? リリースの流れを自動化するサービスです。 ビルド・テスト・デプロイの段階をつなぐもので、コンパイルそのものを行うサービスではない。 【C(不正解)】 ? インスタンスへのデプロイを自動化するサービスです。 できたものを配置する役で、ソースのコンパイルやテストの実行はしない。 【D(正解)】 ? フルマネージドのビルドサービスです。 CodeBuild はコンパイル、テスト、パッケージ作成を行い、ビルドサーバーの用意や管理を不要にする。
コードが変わるたびに、ビルド・テスト・デプロイの各段階を決めた順で自動で進めたい。リリースの流れ全体を自動化するサービスは?
A. AWS CodePipeline B. AWS CodeBuild C. AWS X-Ray D. AWS CloudFormation
この問題へのリンク答えと解説
正解: A 【A(正解)】 ? フルマネージドの継続的デリバリーのサービスです。 CodePipeline はリリースの流れを自動化し、コードの変更ごとにビルド・テスト・デプロイの段階を進める。 【B(不正解)】 ? コードのビルドとテストを行うサービスです。 ビルドの段階を受け持つもので、リリースの流れ全体の順番を管理するものではない。 【C(不正解)】 ? 分散アプリを分析するサービスです。 アプリの振る舞いを調べるもので、リリースの段階を進める役ではない。 【D(不正解)】 ? テンプレートでリソースを用意するサービスです。 インフラをコードで作るもので、ビルドからデプロイまでの流れ全体を管理する役ではない。
多数のマイクロサービスでできたアプリの応答が遅い。どのサービスで時間がかかっているかを、リクエストの通り道を追って突き止めたい。使うサービスは?
A. AWS CloudTrail B. AWS CodeBuild C. AWS X-Ray D. Amazon Inspector
この問題へのリンク答えと解説
正解: C 【A(不正解)】 ? AWS の API の操作を記録するサービスです。 誰がどの操作をしたかを残す監査用のもので、リクエストごとの処理時間の内訳は追わない。 【B(不正解)】 ? コードのビルドとテストを行うサービスです。 開発の途中でコードを組み立てるもので、動いているアプリの遅さの原因は調べない。 【C(正解)】 ? 分散アプリの分析とデバッグを助けるサービスです。 X-Ray はリクエストの全体の流れと部品の地図を示し、性能の問題やエラーの根本原因を見つけるのに役立つ。 【D(不正解)】 ? ソフトウェアの脆弱性を調べるサービスです。 セキュリティの弱点を見つけるもので、応答の遅さの場所は特定しない。
エンドユーザーコンピューティング・Amplify・IoT
工場の数千台のセンサーを MQTT で AWS につなぎ、送られたデータを他の AWS サービスに渡したい。中心になるサービスは?
A. AWS Amplify B. AWS IoT Core C. Amazon Simple Queue Service D. Amazon Connect
この問題へのリンク答えと解説
正解: B 【A(不正解)】 ? ウェブアプリやモバイルアプリの構築とホスティングのサービスです。 フロントエンドの開発とホスティングのためのもので、機器を MQTT で接続する役ではない。 【B(正解)】 ? IoT の機器をクラウドにつなぐサービスです。 IoT Core は MQTT や HTTPS などに対応し、機器を他の機器や AWS のサービスにつなぐ。 【C(不正解)】 ? メッセージをためるキューのサービスです。 アプリの部品どうしの受け渡し用で、MQTT で機器を接続・管理する仕組みではない。 【D(不正解)】 ? クラウドのコンタクトセンターです。 顧客と担当者をつなぐもので、センサーの接続とは関係がない。
出典: AWS IoT とは
React で作ったウェブアプリを Git のリポジトリとつなぎ、プッシュするたびに自動でデプロイして公開したい。サーバーの管理はしたくない。使うものは?
A. AWS CodeBuild だけを使う B. AWS IoT Core C. AWS Amplify のホスティング D. Amazon WorkSpaces Applications
この問題へのリンク答えと解説
正解: C 【A(不正解)】 ? コードのビルドとテストを行うサービスです。 ビルドはできるが、それだけでウェブアプリを公開するホスティングは用意されない。 【B(不正解)】 ? IoT の機器をつなぐサービスです。 機器の接続のためのもので、ウェブアプリの公開には使わない。 【C(正解)】 ? フルスタックのウェブアプリをホストする仕組みです。 Amplify ホスティングは Git ベースの流れで継続的にデプロイし、AWS の CDN に配置する。React にも対応する。 【D(不正解)】 ? デスクトップアプリをストリーミングで届けるサービスです。 社内のデスクトップアプリを配るもので、ウェブアプリの公開とは目的が違う。
外部の協力会社に、設計用のデスクトップアプリを 1 つだけ使わせたい。各自の PC から使え、デスクトップ全体は渡したくない。最も合うサービスは?
A. Amazon WorkSpaces B. Amazon WorkSpaces Secure Browser C. AWS Amplify D. Amazon WorkSpaces Applications
この問題へのリンク答えと解説
正解: D 【A(不正解)】 ? Windows や Linux のクラウドデスクトップを渡すサービスです。 デスクトップ全体を渡すサービスで、アプリ 1 つだけを使わせたいという条件より範囲が広い。 【B(不正解)】 ? ブラウザで社内サイトや SaaS を安全に使わせるサービスです。 ウェブのアプリ向けで、デスクトップアプリを動かすものではない。なお 2026-10-29 から新規の利用受付を終えている。 【C(不正解)】 ? ウェブアプリとモバイルアプリの開発・公開のサービスです。 自社のアプリを作って公開するためのもので、既存のデスクトップアプリを配る役ではない。 【D(正解)】 ? フルマネージドのアプリケーションストリーミングのサービスです。 旧称は Amazon AppStream 2.0。デスクトップアプリを一元管理し、どのコンピュータにも安全に届けられる。アプリ単位で使わせる用途に合う。
出典: AWS の概要(ホワイトペーパー): エンドユーザーコンピューティング/Amazon WorkSpaces Secure Browser
この分野に出てくる用語(159 語)
Amazon API Gateway:API の作成・公開・保守・監視・保護をまとめて行うフルマネージドサービス。
Amazon Athena:Amazon S3 などに置いたデータを、サーバーを用意せず標準 SQL でそのまま分析できるサービス。
Amazon Aurora:クラウド向けに作られた、MySQL・PostgreSQL と互換性のあるリレーショナルデータベースサービス。
Amazon CloudFront:世界中のエッジロケーションからウェブコンテンツを低遅延で配信する CDN(コンテンツ配信ネットワーク)のサービス。
Amazon Comprehend:機械学習でテキストから意味や感情、キーフレーズなどを見つける自然言語処理(NLP)のサービス。
Amazon Connect:クラウドで顧客対応(コンタクトセンター)を行う AI 活用のサービス。使った分だけ支払う。
Amazon DocumentDB:MongoDB API と互換性のある、フルマネージドのドキュメントデータベースサービス。
Amazon DynamoDB:フルマネージドでサーバーレスの NoSQL データベース。キーバリューとドキュメントのデータモデルに対応する。
Amazon EC2:サイズを変更できる仮想サーバー(インスタンス)をクラウドで提供するサービス。
Amazon EC2 Auto Scaling:負荷に応じて EC2 インスタンスの数を自動で増減させ、アプリケーションの可用性を保つ機能。
Amazon Elastic Block Store:EC2 インスタンスにつないで使う、ブロックストレージ(仮想ディスク)のサービス。
Amazon Elastic Container Registry:コンテナイメージを保存・共有・デプロイするフルマネージドのコンテナレジストリ。
Amazon Elastic Container Service:コンテナ化したアプリケーションを実行・管理するフルマネージドのコンテナサービス。
Amazon Elastic File System:複数のインスタンスから同時に使える、伸縮するフルマネージドの共有ファイルストレージ(NFS)。
Amazon Elastic Kubernetes Service:Kubernetes を AWS 上やオンプレミスで動かすためのマネージドサービス。
Amazon ElastiCache:Valkey・Memcached・Redis OSS と互換性があるフルマネージドのインメモリキャッシュサービス。応答を速くする。
Amazon EMR:Apache Spark などのオープンソースの分析フレームワークで、大規模なデータ処理を行うビッグデータ基盤。
Amazon EventBridge:アプリケーションや AWS のサービスから届くイベントを受け取り、ルールに沿って送り先へ振り分けるサーバーレスのイベントバス。
Amazon FSx:Windows File Server など、よく使われる高機能ファイルシステムをフルマネージドで提供するサービス。
Amazon GuardDuty:悪意のある活動や異常な動きを監視し、AWS のアカウント・ワークロード・データへの脅威を検出するサービス。
Amazon Inspector:EC2 インスタンス、コンテナ、Lambda 関数などを自動で見つけ、ソフトウェアの脆弱性や意図しないネットワークの露出をスキャンするサービス。
Amazon Kinesis:動画やログなどのストリーミングデータを集め、リアルタイムに処理・分析するサービス群。
Amazon Lex:音声やテキストで会話するチャットボットなどの会話型インターフェイスを作る AI サービス。
Amazon Lightsail:予測しやすい低料金で簡単に使える仮想プライベートサーバー(VPS)のサービス。
Amazon Macie:機械学習とパターンマッチングで、Amazon S3 などにある個人情報などの機密データを見つけて保護するサービス。
Amazon Neptune:ナレッジグラフや不正検出など、データ同士のつながりを扱うグラフデータベースのマネージドサービス。
Amazon OpenSearch Service:検索、ログ分析、可観測性などに使うマネージドの検索・分析エンジン。
Amazon Polly:文章を自然な音声に変換する(音声合成)サービス。
Amazon Q:社内の情報やコードなどをもとに質問に答えたり、コンテンツを作ったりする、AWS の生成 AI アシスタント。
Amazon Quick Sight:データを可視化してダッシュボードやレポートを作り、共有できる BI(ビジネスインテリジェンス)サービス。
Amazon RDS:MySQL や PostgreSQL などのリレーショナルデータベースを、運用を任せて使えるマネージドサービス。
Amazon Redshift:大量のデータを高速に分析するフルマネージドのクラウドデータウェアハウス。
Amazon Rekognition:画像や動画の中の物体・人物・文字などを認識・分析するサービス。機械学習の経験がなくても使える。
Amazon Route 53:可用性が高くスケーラブルな DNS(ドメイン名と IP アドレスを対応付ける仕組み)のサービス。ドメイン登録もできる。
Amazon S3:データをオブジェクトとして保存する、拡張性と耐久性の高いオブジェクトストレージ。バックアップやデータレイクなどに使う。
Amazon S3 Glacier:長期保存するデータのアーカイブ向けの、低コストな Amazon S3 のストレージクラス群。
Amazon SageMaker AI:機械学習モデルの構築・トレーニング・デプロイを、フルマネージドのインフラとツールで行うサービス。
Amazon Simple Email Service:アプリケーションからメールを送信できる、拡張性のあるメール送信サービス。
Amazon Simple Notification Service:1 つのメッセージを複数の送り先へ一斉に届ける(発行・購読型)通知サービス。メール・SMS・アプリ間の通知に使う。
Amazon Simple Queue Service:メッセージを順番待ちの列(キュー)に入れて受け渡し、システム同士を疎結合にするフルマネージドのメッセージキュー。
Amazon Textract:スキャンした書類やフォーム、表から、文字・手書き文字・データを自動で取り出すサービス。
Amazon Transcribe:音声をテキストに変換する(自動音声認識)サービス。
Amazon Translate:深層学習を使って文章を別の言語に翻訳する機械翻訳サービス。
Amazon VPC:AWS 上に、自分で定義した論理的に分離された仮想ネットワークを作るサービス。
Amazon WorkSpaces:Windows や Linux の仮想デスクトップ(VDI)をクラウドで提供するマネージドサービス。
Amazon WorkSpaces Applications:Windows や Linux のアプリケーションを、端末に入れずにブラウザなどへストリーミング配信するサービス。
Amazon WorkSpaces Secure Browser:社内サイトや SaaS へ、安全なブラウザ環境からアクセスさせるフルマネージドのサービス。
Amazon マシンイメージ:EC2 インスタンスを用意して起動するのに必要なソフトウェアをまとめたイメージ。1 つの AMI から同じ設定のインスタンスを複数起動でき、別のリージョンへコピーもできる。
API:プログラム同士がやり取りするための窓口。AWS の操作はすべて API 呼び出しで行われ、コンソール・CLI・SDK もこれを使う。
Aurora グローバルデータベース:Amazon Aurora のデータを、専用の仕組みで別のリージョンへ通常 1 秒未満の遅れで複製する機能。主のリージョンが止まったとき、別のリージョンを昇格できる。
AWS Amplify:ウェブアプリやモバイルアプリのフロントエンドとバックエンドを素早く作ってデプロイできるサービス。
AWS Application Discovery Service:オンプレミスのサーバーやデータベースの使用状況と構成のデータを集め、移行計画を助けるサービス。2025 年 11 月 7 日に新規受付を終了した。
AWS Application Migration Service:サーバーをほぼそのまま AWS へ移す(リホスト)ための移行サービス。2026 年時点の正式名は AWS Transform MGN(試験ガイドは旧称で記載)。
AWS Artifact:AWS のセキュリティ・コンプライアンスのレポートや、AWS との契約書をオンデマンドで入手できるサービス。
AWS Auto Scaling:アプリケーションを監視し、複数のサービスのリソース容量を自動で調整してパフォーマンスとコストを保つサービス。
AWS Backup:AWS のサービスなどのバックアップを一元的に管理・自動化するサービス。
AWS Batch:大量のバッチ処理ジョブを AWS 上で効率よく実行するサービス。
AWS CLI:コマンドラインから AWS の複数のサービスを操作し、スクリプトで自動化できる統合ツール。
AWS Client VPN:在宅勤務など離れた場所の利用者が、自分の端末から AWS やオンプレミスのネットワークへ安全に接続するための VPN サービス。
AWS Cloud Development Kit:TypeScript・Python・Java などのプログラミング言語でクラウドのインフラを定義し、AWS CloudFormation を通じて用意するオープンソースの開発フレームワーク。
AWS CloudFormation:テンプレートに書いた内容どおりに AWS リソースを作成・管理する Infrastructure as Code のサービス。
AWS CloudShell:AWS マネジメントコンソールから起動できる、ブラウザで使うシェル環境。サインインした認証情報がそのまま使え、AWS CLI があらかじめ入っている。
AWS CloudTrail:AWS アカウントで「誰が・いつ・何の操作(API 呼び出し)をしたか」を記録するサービス。監査やセキュリティ調査に使う。
AWS CodeBuild:ソースコードのビルドとテストを行うフルマネージドのサービス。使ったビルド時間分だけ支払う。
AWS CodeDeploy:EC2 インスタンスやオンプレミスのサーバーなどへの、コードのデプロイを自動化するサービス。
AWS CodePipeline:コードの変更をきっかけに、ビルド・テスト・デプロイのリリース工程を自動で流す CI/CD のサービス。
AWS Database Migration Service:データベースのデータを、別のデータベースや分析システムへ移行するサービス。移行中も元のデータベースを使い続けられる。
AWS Direct Connect:お客様のネットワークと AWS を、インターネットを通らない専用線で直接つなぐサービス。安定した低遅延の通信が得られる。
AWS Elastic Beanstalk:コードをアップロードするだけで、容量の用意や監視などを任せてウェブアプリケーションをデプロイ・管理できるサービス。
AWS Elastic Disaster Recovery:オンプレミスやクラウドのアプリケーションを素早く復旧し、ダウンタイムとデータ損失を抑えるディザスタリカバリのサービス。
AWS Fargate:サーバーを管理せずにコンテナを動かせるサーバーレスのコンピューティングエンジン。ECS と EKS の両方で使える。
AWS Global Accelerator:AWS のグローバルネットワークを通して利用者の通信をアプリケーションへ届け、パフォーマンスと可用性を高めるサービス。
AWS Glue:データの抽出・変換・ロード(ETL)を行う、サーバーレスのデータ統合サービス。
AWS Health Dashboard:AWS のサービスの稼働状況や、自分のアカウントのリソースに影響するイベントや予定された変更を確認できる画面。
AWS IoT Core:インターネットにつながった機器(IoT デバイス)と AWS のサービスの間で、安全な双方向通信を可能にするサービス。
AWS Lambda:サーバーを用意・管理せずにコードを実行できるサーバーレスのサービス。料金はリクエスト数と実行時間に応じて発生する。
AWS Local Zones:AWS リージョンを拡張し、大都市など利用者の近くにコンピューティングやストレージを置く仕組み。低い遅延が必要なアプリに使う。
AWS Migration Hub:サーバーの検出、移行の計画、アプリケーションごとの移行状況の追跡を 1 か所で行うサービス。2025 年 11 月 7 日に新規受付を終了した。
AWS Outposts:AWS のインフラとサービスをお客様のオンプレミス環境で動かし、ハイブリッドな環境を作るサービス。
AWS PrivateLink:VPC と AWS のサービスなどの間を、インターネットを通らないプライベートな接続でつなぐ仕組み。
AWS re:Post:AWS に関する質問をして、AWS の専門家やコミュニティから回答を得られる公式の Q&A サービス。
AWS Schema Conversion Tool:種類の異なるデータベースへ移すときに、スキーマ(表の構造など)を変換するツール。
AWS SDK:Python や Java などのプログラミング言語から AWS のサービスを呼び出すためのライブラリ群。
AWS Site-to-Site VPN:データセンターや支社のネットワークと AWS の VPC を、インターネット経由の暗号化した通信路でつなぐサービス。
AWS Step Functions:複数の AWS サービスを順番や分岐を決めて組み合わせ、ワークフローとして実行するサーバーレスのサービス。
AWS Storage Gateway:オンプレミスの環境とクラウドストレージをつなぎ、よく使うデータを手元にキャッシュしながらクラウドに保存できるサービス。
AWS Transit Gateway:多数の VPC とオンプレミスのネットワークを、中央のハブでまとめてつなぐサービス。
AWS Trusted Advisor:AWS 環境を点検し、コスト最適化、パフォーマンス、セキュリティなどを改善するための推奨事項を示すサービス。
AWS VPN:暗号化した通信路で AWS とつなぐサービスの総称。拠点間をつなぐ Site-to-Site VPN と、個人の端末からつなぐ Client VPN がある。
AWS WAF:SQL インジェクションなどの一般的なウェブ攻撃やボットから、ウェブアプリケーションを守るファイアウォール。
AWS Wavelength:AWS のコンピューティングとストレージを通信事業者の 5G 網の端に置き、モバイル端末に非常に低い遅延を届ける仕組み。
AWS Well-Architected フレームワーク:AWS 上で安全・高性能・高耐障害・効率的なシステムを作るための考え方とベストプラクティス集。6 つの柱で整理されている。
AWS X-Ray:アプリケーションが処理したリクエストを追跡(トレース)し、遅い箇所やエラーの原因を見つけるのを助けるサービス。
AWS クラウド導入フレームワーク:AWS の経験とベストプラクティスを使い、組織がクラウドを効果的に導入して変革を進めるのを助けるフレームワーク。
AWS サポート:AWS のお客様向けの技術支援。ベーシック、ビジネスサポート+、エンタープライズサポート、Unified Operations などのプランがある。
AWS ビジネスサポート+:本番環境のワークロード向けに AWS が推奨する最小のサポートプラン。
AWS マネジメントコンソール:ウェブブラウザの画面から AWS のリソースを操作・管理する仕組み。
AWS リージョン:AWS のデータセンターが集まる、世界各地の地理的な拠点。各リージョンは複数のアベイラビリティーゾーンで構成される。
CloudFormation StackSets:1 つの CloudFormation テンプレートをもとに、複数の AWS アカウントと複数のリージョンへスタックを 1 回の操作で作成・更新・削除できる機能。
DMS Schema Conversion:AWS DMS の機能の一つ。移行元のスキーマを評価し、移行先のエンジンと互換性のある形に変換して適用する。
DynamoDB Accelerator:DynamoDB 用のフルマネージドのインメモリキャッシュ。DynamoDB と API の互換性があり、読み取りの応答をミリ秒からマイクロ秒に速くする。
DynamoDB グローバルテーブル:選んだ複数のリージョンに DynamoDB のテーブルを複製し、どのリージョンでも読み書きできるようにする機能。主のテーブルを持たないマルチアクティブの構成。
EBS スナップショット:EBS ボリュームのある時点のバックアップ。ボリュームとは独立して残り、そこから新しいボリュームを復元できる。
Elastic Load Balancing:届いた通信を複数のターゲット(EC2 インスタンスなど)に自動で振り分けるロードバランサーのサービス。
Infrastructure as Code:サーバーやネットワークなどのインフラ構成をコード(テンプレート)で書き、繰り返し同じ環境を自動で作れるようにする手法。
Kubernetes:コンテナの配置や拡張、管理を自動で行うオープンソースのコンテナオーケストレーションの仕組み。AWS では Amazon EKS で使える。
MQTT:IoT の機器がメッセージを発行・購読するために使う軽量な通信プロトコル。AWS IoT Core のメッセージブローカーが対応する。
NAT ゲートウェイ:プライベートサブネットのリソースが、外部から接続されずにインターネットなどへ出ていけるようにする仕組み。
NoSQL:表形式に限らず、キーバリューやドキュメントなど柔軟な形でデータを扱うデータベースの総称。
S3 Intelligent-Tiering:アクセスの様子を見て、オブジェクトを安いアクセス階層へ自動で移す S3 のストレージクラス。取り出し料金はなく、少額の監視料金がかかる。
S3 ストレージクラス:アクセス頻度や必要な取り出し速度に応じて選ぶ S3 の保存区分。S3 Standard、S3 Intelligent-Tiering、低頻度アクセス、S3 Glacier 系などがある。
S3 ファイルゲートウェイ:Storage Gateway の一種。NFS や SMB でファイルを扱い、中身を S3 にオブジェクトとして保存する。手元のキャッシュで低遅延に読める。
S3 ライフサイクル:ルールを決めて、一定期間後にオブジェクトを安いストレージクラスへ移したり削除したりする S3 の機能。
SQS FIFO キュー:メッセージを送信された正確な順番で、1 回だけ処理するように作られた SQS のキュー。
VPC ピアリング:2 つの VPC の間をつなぎ、プライベートに通信を通す接続。双方のインスタンスが同じネットワークにいるように通信できる。
アクセスキー:CLI や SDK から AWS をプログラムで操作するための長期の認証情報。アクセスキー ID とシークレットアクセスキーの組。
アベイラビリティーゾーン:リージョン内にある、互いに離れて独立した 1 つ以上のデータセンターのまとまり。複数使うと障害に強くなる。
イベント駆動型アーキテクチャ:イベントの発信と応答で、ゆるやかに結合した部品どうしを連携させる設計のスタイル。EventBridge などで作る。
インスタンスストア:EC2 インスタンスのホストに物理的に付いた一時的なブロックストレージ。インスタンスを停止・休止・終了するとデータは消える(再起動では残る)。
インスタンスタイプ:EC2 インスタンスの CPU・メモリ・ストレージ・ネットワーク性能の組み合わせ。汎用、コンピューティング最適化、メモリ最適化、ストレージ最適化などの系統がある。
インターネットゲートウェイ:VPC とインターネットの間の通信を可能にする出入口。
ウォームスタンバイ:別のリージョンに、本番の縮小版を常に動く状態で用意しておく災害対策の戦略。すぐに通信を処理でき、災害時は規模を広げるだけでよい。
エッジロケーション:利用者に近い場所でコンテンツを配信するための拠点。Amazon CloudFront などが使い、遅延を減らす。
オブジェクトストレージ:データを、本体・メタデータ・一意の識別子をまとめた「オブジェクト」として保存する方式。Amazon S3 が代表例。
キャッシュ:よく使うデータを速く読める場所(メモリなど)に一時的に置き、応答を速くしたり元のデータベースの負荷を減らしたりする仕組み。
コンテナ:アプリケーションと動かすのに必要なものを 1 つにまとめ、どこでも同じように動かせるようにした実行単位。
サーバーレス:利用者がサーバーの用意・管理をせずにアプリケーションを動かせる形態。容量の調整は AWS が行う。
サブネット:VPC の IP アドレス範囲を分けた区画。1 つのサブネットは 1 つのアベイラビリティーゾーンに置かれる。
スケジュールに基づくスケーリング:日付と時刻を指定して、Auto Scaling グループの台数を自動で変える方法。増減すべき時刻がはっきりわかっている場合に便利。
ステートフル:行きの通信を許可すると、その戻りの通信も自動で許可される性質。VPC ではセキュリティグループがこの性質を持つ。
ステートレス:行きと戻りの通信をそれぞれ別に判断する性質。VPC ではネットワーク ACL がこの性質を持ち、戻りの通信も明示的な許可が要る。
セキュリティグループ:EC2 インスタンスなどのリソース単位で、許可する通信を決める仮想ファイアウォール。ステートフルで、許可ルールだけを書く。
タスク定義:Amazon ECS でアプリケーションを動かすための設計図(ブループリント)。Fargate で動かすときは、ここで CPU とメモリの要件も指定する。
ディザスタリカバリ:災害や大きな障害が起きたときに、システムとデータを復旧させるための備えと手順。
データ主権:データがどの国・地域に保存され、どの法律に従うかを管理する考え方。リージョンを選ぶ理由の 1 つになる。
テープゲートウェイ:Storage Gateway の一種。仮想のテープを使い、データを AWS クラウドにアーカイブする。
デプロイモデル:IT 資源をどこに置くかの形。すべてクラウド、クラウドとオンプレミスを組み合わせるハイブリッド、オンプレミスがある。
ネットワーク ACL:サブネット単位で通信を許可・拒否するファイアウォール。ステートレスで、許可と拒否の両方のルールを書ける。
バーストパフォーマンスインスタンス:普段は基準の CPU 性能で動き、CPU クレジットを使って一時的に基準を超えて動ける EC2 インスタンス(T 系)。ウェブサーバー、中小規模の DB、開発・テスト環境などに向く。
パイロットライト:別のリージョンにデータを複製し、中核のインフラだけを用意しておく災害対策の戦略。アプリのサーバーは止めておき、災害時に起動して規模を広げる。
バックアップと復元:データのバックアップを取っておき、災害後にインフラを作り直してデータを戻す災害対策の戦略。4 つの戦略のうち費用と複雑さが最も低い。
バックアッププラン:AWS Backup で作るバックアップの方針。取る頻度や保存期間などを決め、タグなどで対象のリソースに当てる。
ファンアウト:1 つのメッセージを複製して、複数の届け先へ同時に送ること。SNS のトピックから複数の SQS キューや Lambda 関数へ配る形が代表例。
ベーシックサポート:すべての AWS のお客様が追加料金なしで使えるサポート。アカウントと請求の質問への回答、ドキュメント、サービス状態の確認などが含まれる。
ヘルスチェック:インスタンスやターゲットが正常に動いているかを定期的に確かめる仕組み。ELB は正常なものにだけ通信を送り、EC2 Auto Scaling は異常なものを置き換える。
ボリュームゲートウェイ:Storage Gateway の一種。iSCSI でマウントするクラウドのボリュームを渡す。一部を手元に持つキャッシュ型と、全データを手元に置く保管型がある。
マルチ AZ 配置:Amazon RDS で、別のアベイラビリティーゾーンにスタンバイを置き、障害時に自動で切り替える構成。スタンバイ 1 つの DB インスタンス配置では読み取りに使えず、DB クラスター配置では読み取りも受けられる。
マルチサイトアクティブ/アクティブ:複数のリージョンで同時に本番を動かし、すべてのリージョンで通信を処理する災害対策の戦略。最も複雑で費用が高いが、復旧時間をほぼゼロにできる。
リードレプリカ:元の DB インスタンスから複製した、読み取り用の DB インスタンス。読み取りの負荷を分散でき、別のリージョンに作ることもできる。
リホスト:アプリケーションを変更せずにそのままクラウドへ移す移行戦略。「リフトアンドシフト」とも呼ぶ。
リレーショナルデータベース:データを行と列の表で管理し、表同士を関連付けて SQL で扱うデータベース。
ルートテーブル:VPC の通信をどこへ送るかを決めるルール(ルート)の集まり。宛先の IP アドレス範囲と、送り先のゲートウェイなどを指定する。
異種移行:Oracle から PostgreSQL のように、エンジンの違うデータベースへ移すこと。スキーマの変換が要る。
単一障害点:そこが 1 つ壊れるだけでシステム全体が止まってしまう部分。AZ は発電機や冷却装置などの障害点を互いに共有しないよう設計されている。
動的スケーリング:CPU 使用率などの負荷の変化に応じて、Auto Scaling グループの台数を自動で増減する方法。通信がいつ変わるかわからない場合に向く。
変更セット:CloudFormation のスタックを更新する前に、追加・変更・削除されるリソースを確かめるための仕組み。実行を決めるまでスタックは変わらない。
目標復旧時間:サービスが止まってから復旧するまでに許される最大の時間。災害対策の戦略を選ぶときの目標の 1 つ。
目標復旧時点:最後にデータを戻せる時点から、どれだけの時間分のデータ損失まで許せるかを表す目標。バックアップや複製の頻度を決める基準になる。
予測スケーリング:通信の日ごと・週ごとの傾向に先回りして、Auto Scaling グループの EC2 インスタンスを前もって増やす方法。動的スケーリングと組み合わせて使える。
独学の次に、講座で体系立てて学びたい人へ
この問題集は独学用です。クラウドや生成AI・DX を仕事で使えるところまで講師つきで学びたい人には、IT・生成AI/DX の講座がそろうスクールも選択肢になります。
本ページは広告・アフィリエイトプログラムを利用しており、リンク経由でのお申し込み・購入により当サイトに収益が発生することがあります。ただし、ランキング・評価・掲載内容は広告費や報酬の有無に関わらず編集部の独自基準で決定しており、広告主からの指示により内容を変更することはありません。
IT・Webデザイン・資格まで幅広い講座。生成AI/DX講座はリスキリング補助金の対象
まずは無料ではじめられます。リンク先は公式サイトです。
このサービスの解説記事を読む →