仮の宿 学習室 資格 クラウド・AI・Python 合格ラボ AWSの主要サービス クラウド・AI・Python CLOUD / AI / PYTHON
AWSの主要サービス
講義 4 本・確認問題 40 問 ｜ 本試験では「AWS認定」（0問）の一部 ｜ 最終更新 2026-09-24
この章で学ぶこと 仮想サーバーのEC2、コードだけを預けるLambda、コンテナを束ねるECSとEKS、そして基盤の管理を手放すFargate。どれに何をやらせるのかが分かります。 オブジェクト・ブロック・ファイルという3つのデータの持ち方の違いと、アーカイブ向けのS3 Glacierの選び方が分かります。 リレーショナルのRDSとAurora、NoSQLのDynamoDB、インメモリのElastiCache、データウェアハウスのRedshift。5つの役割の違いが分かります。 SQSのキューとSNSのトピック、EventBridge、Step Functions、API Gateway。部品どうしをどうつなぐと壊れにくいのかが分かります。 1. コンピューティング EC2とLambdaとコンテナ
仮想サーバーのEC2、コードだけを預けるLambda、コンテナを束ねるECSとEKS、そして基盤の管理を手放すFargate。どれに何をやらせるのかが分かります。
AWSでいうコンピューティングとは、要するに「計算をする場所を借りる」ことです。ただし借り方が一通りではありません。サーバーを1台まるごと借りて中身を全部自分で決めるやり方、コードだけを預けて動かしてもらうやり方、コンテナの集まりを預けて配置と台数だけ面倒を見てもらうやり方。この3つの借り方の違いが、そのままEC2・Lambda・コンテナサービスの違いになっています。
Amazon EC2（Amazon Elastic Compute Cloud）は、クラウド上で安全かつサイズ変更可能なコンピューティング能力を提供するWebサービスです。公式の説明で大事なのは2点で、使った分だけ支払うことと、コンピューティングリソースを完全に制御できることです。完全に制御できるということは、裏返せばOSの面倒も自分で見るということでもあります。台数も止め時も自分で決めるので、動かしている間はずっと費用が発生します。
AWS Lambdaは、サーバーのプロビジョニングや管理をせずにコードを実行できるサービスです。課金は消費したコンピューティング時間に対してだけで、コードが実行されていない間は料金が発生しません。ここがEC2との決定的な差です。1日に数回しか呼ばれない処理をEC2で待ち受けると、待っている大半の時間にも費用がかかりますが、Lambdaなら呼ばれた分しかかかりません。逆に、四六時中フルに動き続ける処理なら、この特徴は効きません。
コンテナは、アプリケーションと必要なライブラリをひとまとめにして、どこでも同じように動かせる形にしたものです。数が増えるとどのサーバーにどれを何個置くかという管理が要り、それを引き受けるのがオーケストレーションです。Amazon ECS（Amazon Elastic Container Service）はAWSのフルマネージドなコンテナオーケストレーションサービスで、コンテナ化したアプリケーションのデプロイ・管理・スケールを容易にします。Amazon EKS（Amazon Elastic Kubernetes Service）は、自前でKubernetesクラスターをインストール・運用することなくAWS上でKubernetesを実行できるマネージドサービスで、Kubernetes準拠の認定を受けています。すでにKubernetesの資産があるならEKS、AWSの流儀でまとめたいならECS、という分かれ方になります。
AWS Fargateは、コンテナ向けのサーバーレスな従量課金コンピューティングエンジンです。サーバーやクラスターのプロビジョニング・設定・スケールが不要で、ECSやEKSの起動タイプとして使います。ここを取り違えないでください。Fargateは「コンテナをどこで走らせるか」の答えであって、「コンテナをどう配置し管理するか」の答えではありません。後者はECSやEKSの仕事なので、Fargateを使ってもECSやEKSが不要になるわけではありません。
ECSでタスクを動かす基盤、つまりキャパシティの選択肢は、基本が2つです。Fargateを選べばAWSが基盤を管理し、利用者はインスタンスの存在を意識しません。EC2を選べばインスタンスタイプと台数を利用者が選び、自分で管理します。ほかにECS Managed Instances、オンプレミス向けのECS Anywhereもあります。どちらを選んでもコンテナの配置とスケールはECSが行い、変わるのは基盤の面倒を誰が見るかです。
つまずきどころは「サーバーレス」という言葉です。これは物理サーバーが存在しないという意味ではありません。サーバーはAWS側にあり、利用者がその調達・設定・スケールをしなくてよい、という意味です。Lambdaが「サーバーのプロビジョニングや管理なしに」と説明され、Fargateが「サーバーやクラスターのプロビジョニング・設定・スケールが不要」と説明されるのは、どちらもこの意味においてです。
コンピューティングの借り方と、利用者に残る仕事 サービス 預けるもの 利用者に残る仕事 向く場面 EC2 ハードウェアと仮想化 OSの管理、台数と稼働時間の判断 常時動かす、環境を細かく決めたい Lambda サーバーの一切 コードとイベントの設計 呼び出しがまばら、待ち時間に払いたくない ECS コンテナの配置とスケール コンテナの中身と基盤の選択 AWSの流儀でコンテナを束ねたい EKS Kubernetesの運用 Kubernetesの設定とコンテナの中身 Kubernetesの資産をそのまま活かしたい Fargate 基盤のサーバーとクラスター コンテナに与える資源の指定 インスタンスを一切持ちたくない
ECS でキャパシティを決めるときの順番 1. インスタンスに固有の設定を入れる必要があるか -> あるなら EC2 起動タイプ（自分で管理する） -> ないなら 2 へ 2. インスタンスの運用を引き受ける担当がいるか -> いないなら Fargate（AWS が基盤を管理） どちらを選んでも、コンテナの配置とスケールは ECS が行う 用語 Amazon EC2 Amazon Elastic Compute Cloud。サイズ変更可能なコンピューティング能力（仮想サーバー）を提供する。使った分だけ支払い、コンピューティングリソースを完全に制御できる。 AWS Lambda サーバーのプロビジョニングや管理なしにコードを実行できるサービス。消費したコンピューティング時間にのみ課金され、実行されていない間は料金が発生しない。 Amazon ECS Amazon Elastic Container Service。フルマネージドのコンテナオーケストレーションサービスで、コンテナ化アプリケーションのデプロイ・管理・スケールを容易にする。 Amazon EKS Amazon Elastic Kubernetes Service。自前でKubernetesクラスターをインストール・運用することなくAWS上でKubernetesを実行できる。Kubernetes準拠認定済み。 AWS Fargate コンテナ向けのサーバーレス従量課金コンピューティングエンジン。サーバーやクラスターのプロビジョニング・設定・スケールが不要で、ECSやEKSの起動タイプとして使う。 サーバーレス 物理サーバーが無いという意味ではなく、サーバーの調達・設定・スケールを利用者が行わなくてよいという意味。LambdaやFargateの説明に使われる。 オーケストレーション 多数のコンテナを、どのサーバーにいくつ置き、落ちたらどう入れ替えるかまで含めて自動で束ねること。ECSやEKSが担う役割。 キャパシティの選択肢 ECSでタスクを動かす基盤の選び方。基本はFargate（AWSが管理）とEC2（利用者がインスタンスタイプと台数を選び管理）の2つ。ほかにECS Managed InstancesとECS Anywhereがある。 起動タイプ コンテナを実際に走らせる基盤の種類。FargateとEC2があり、配置と管理を行うECSやEKSとは役割が別。 イベント駆動 何かが起きたときにだけ処理を動かす作り。Lambdaはこの形に向き、待っている時間に費用がかからない。 例題
例題：例題：社内で常に一定の負荷がかかり続けるアプリケーションサーバーと、月末に一度だけ動く集計処理がある。それぞれどのコンピューティングが向くか。
答えと考え方 常時動かすものはEC2が向きます。使った分だけ支払う形ですが、そもそも止める時間がないので、環境を完全に制御できる利点のほうが効きます。月末に一度だけの集計はLambdaが向きます。消費したコンピューティング時間にのみ課金され、動いていない残りの日には料金が発生しないからです。同じ「計算する場所」でも、動いていない時間が長いほどLambda側の利点が大きくなります。
例題：例題：「Fargateを使えばECSもEKSも要らない」という説明は正しいか。
答えと考え方 正しくありません。Fargateはコンテナ向けのサーバーレス従量課金コンピューティングエンジンで、ECSやEKSの起動タイプとして使うものです。つまり「どこで走らせるか」を引き受ける役で、「どのコンテナを何個どこに置き、どう入れ替えるか」というオーケストレーションはECSやEKSの仕事のまま残ります。両者は置き換えではなく組み合わせです。
出典・根拠：Amazon Web Services, Inc. AWS ホワイトペーパー「Amazon Web Services の概要」コンピューティング（2026年8月確認）
2. ストレージ S3とEBSとEFSの使い分け
オブジェクト・ブロック・ファイルという3つのデータの持ち方の違いと、アーカイブ向けのS3 Glacierの選び方が分かります。
AWSのストレージは「容量がいくら」ではなく「データをどういう単位で持つか」で分かれます。ここを押さえないと、S3・EBS・EFSがどれも同じ入れ物に見えてしまいます。オブジェクト・ブロック・ファイルという3つの持ち方があり、それぞれS3・EBS・EFSが対応します。試験でも実務でも、まずこの対応を体に入れるところから始まります。
Amazon S3（Amazon Simple Storage Service）はオブジェクトストレージです。任意の量のデータを保存・保護でき、スケーラビリティ・可用性・セキュリティ・パフォーマンスに優れると公式に説明されています。データはHTTPのAPIエンドポイント経由で丸ごと出し入れするもので、OSからディスクとして見えるわけではありません。用途としてはWeb、モバイル、バックアップ、アーカイブ、IoT、ビッグデータ分析が挙げられています。
Amazon EBS（Amazon Elastic Block Store）はブロックストレージです。EC2インスタンスで使う永続的なボリュームで、OSからはディスクとして見えます。アベイラビリティゾーン内で自動的にレプリケートされ、一貫した低レイテンシ性能を提供します。ここで効いてくるのが単一AZという性質と、原則として1つのインスタンスにアタッチして使うという性質です。OSの起動ディスクやデータベースのデータ領域には向きますが、多数のサーバーで同じ場所を共有する用途には向きません。
Amazon EFS（Amazon Elastic File System）はファイルストレージです。Linuxワークロード向けのシンプルでスケーラブル、エラスティックなファイルシステムで、ファイルの増減に応じて容量が自動で伸縮します。そして数千台のEC2インスタンスからの並列共有アクセスに対応します。「複数のサーバーが同じディレクトリを同時に読み書きしたい」という要件が出たら、EFSを思い出す場面です。容量を先に決めなくてよいのも、ブロックストレージとの分かりやすい違いです。
3つの使い分けは、要件の言い回しから逆算できます。「複数のEC2から同時にマウントして共有したい」ならEFS。「1台のEC2のOSやデータベースのディスクが要る」ならEBS。「静的コンテンツやバックアップをオブジェクトとして置きたい」ならS3。実際のシステムでは3つを同時に使うのが普通で、どれか1つを選ぶ問題ではなく、役割ごとに割り振る問題だと考えてください。
長期保管にはS3 Glacierというアーカイブ用のストレージクラス群があります。即時の取り出しが必要なデータ向けのS3 Glacier Instant Retrieval、めったにアクセスしない長期データ向けのS3 Glacier Flexible Retrieval、最低コストで数時間かけて取り出すS3 Glacier Deep Archiveの3つです。選ぶときにまず決めるのは容量でも料金でもなく、取り出しにどれだけ待てるかです。待てないなら費用は上がり、数時間待てるなら最も安く保管できる、という交換になっています。
つまずきどころは、EBSとEFSの取り違えです。名前がどちらもElastic ... Storeで似ていますが、EBSのBはBlock、EFSのFはFileです。ブロックは1台に接続してディスクとして使うもの、ファイルは多数のホストからマウントして共有できるもの、と覚えると迷いません。
3つのストレージとアーカイブ向けクラスの比較 サービス データの単位 同時に使える範囲 典型的な置き物 S3 オブジェクト APIから誰でも（権限次第） 静的コンテンツ、バックアップ、分析用データ EBS ブロック 原則1つのEC2インスタンス OSの起動ディスク、データベースのデータ領域 EFS ファイル 多数のEC2から並列に共有 複数サーバーで共有する作業領域や配信素材 S3 Glacier オブジェクト（アーカイブ） 取り出してから利用 監査ログ、法定保存の記録、古い成果物
用語 Amazon S3 Amazon Simple Storage Service。任意の量のデータを保存・保護できるオブジェクトストレージ。Web、モバイル、バックアップ、アーカイブ、IoT、ビッグデータ分析などに使う。 Amazon EBS Amazon Elastic Block Store。EC2インスタンスで使う永続的なブロックストレージボリューム。AZ内で自動的にレプリケートされ、一貫した低レイテンシ性能を提供する。 Amazon EFS Amazon Elastic File System。Linuxワークロード向けのファイルシステム。容量が自動で伸縮し、数千台のEC2インスタンスからの並列共有アクセスに対応する。 オブジェクトストレージ データを丸ごと1つの塊として保存し、APIで出し入れする方式。OSからディスクとしては見えない。S3がこれにあたる。 ブロックストレージ OSからディスクとして見える方式。ファイルシステムを載せて使う。EBSがこれにあたり、原則1つのインスタンスにアタッチする。 ファイルストレージ ディレクトリとファイルの形で、複数のホストからマウントして共有できる方式。EFSがこれにあたる。 S3 Glacier アーカイブ用のストレージクラス群。取り出しの速さと費用の兼ね合いでInstant Retrieval、Flexible Retrieval、Deep Archiveから選ぶ。 S3 Glacier Deep Archive 最低コストで保管し、取り出しに数時間かける長期保管向けのクラス。めったに読まない記録の置き場に向く。 エラスティック 使う量に応じて自動で伸び縮みする性質。EFSはファイルの増減に応じて容量が自動で伸縮するため、事前の容量設計が要らない。 単一AZ EBSのボリュームが1つのアベイラビリティゾーン内で自動レプリケートされる性質。AZをまたぐ可用性は別の仕組みで確保する。 例題
例題：例題：Webサーバーを3台に増やしたところ、利用者がアップロードした画像が、アップロードを受けた1台にしか無いという不具合が出た。どこに置けばよいか。
答えと考え方 各サーバーのEBSに置いたままだと、EBSは原則1つのインスタンスにアタッチするブロックストレージなので、ほかの2台からは見えません。3台が同じディレクトリを見る必要があるならEFSを共有のファイルシステムとしてマウントします。画像を配信するだけならS3にオブジェクトとして置き、アプリケーションはURLで参照する形も定番です。どちらも「1台に閉じない置き場に移す」という点は同じです。
例題：例題：S3 Glacierのどのクラスにするかを決めるとき、最初に確かめるべきことは何か。
答えと考え方 取り出しにどれだけ待てるかです。すぐ読み出す必要があるならS3 Glacier Instant Retrieval、めったにアクセスしない長期データならS3 Glacier Flexible Retrieval、数時間待てるなら最低コストのS3 Glacier Deep Archiveになります。容量から考えると迷いますが、取り出しの速さから考えると一本道です。
出典・根拠：Amazon Web Services, Inc. AWS ホワイトペーパー「Amazon Web Services の概要」ストレージ（2026年8月確認）
3. データベース RDSとAuroraとDynamoDB
リレーショナルのRDSとAurora、NoSQLのDynamoDB、インメモリのElastiCache、データウェアハウスのRedshift。5つの役割の違いが分かります。
データベースも、ストレージと同じで「どれが優れているか」ではなく「何をさせたいか」で選びます。表と行の形で厳密に扱いたいのか、キーを指定して1件ずつ高速に出し入れしたいのか、大量のデータをまとめて集計したいのか、それとも同じ問合せを何度も繰り返すので手前で受け止めたいのか。この問いに対する答えが、それぞれRDS、DynamoDB、Redshift、ElastiCacheです。
Amazon RDS（Amazon Relational Database Service）は、クラウドでのリレーショナルデータベースのセットアップ・運用・スケールを容易にするマネージドサービスです。ハードウェアのプロビジョニング、データベースのセットアップ、パッチ適用、バックアップといった管理作業を自動化します。裏返すと、自動化されるのは運用の手間であって、表と列の設計や索引をどこに張るかといった設計の判断は利用者に残ります。ここを混同すると「マネージドなら何もしなくてよい」という誤解になります。
Amazon Auroraは、MySQL・PostgreSQL互換のフルマネージドなリレーショナルデータベースエンジンです。重要なのは、AuroraがRDSの一部だということです。別サービスではなく、同じマネジメントコンソール、CLI、API操作でプロビジョニング、パッチ適用、バックアップ、復旧、障害検知を行います。違いは管理の単位で、標準のRDSが個々のDBインスタンスを管理するのに対し、Auroraはレプリケーションで同期されたDBサーバーのクラスター全体を管理します。Aurora固有の性質としては、高性能な分散共有ストレージサブシステムを持ち、ストレージが必要に応じて自動で拡張されること、同等ハードウェア上の標準のMySQLやPostgreSQLに比べて高いスループットを狙う設計であることが挙げられます。
Amazon DynamoDBは、キーバリュー型／ドキュメント型のNoSQLデータベースです。あらゆる規模で1桁ミリ秒のパフォーマンスを提供する、フルマネージドかつマルチリージョン対応のデータベースと説明されています。キーを指定して1件ずつ読み書きする用途、たとえばセッション情報や利用者ごとの設定、大量の端末からの書き込みなどに向きます。表を結合して複雑な条件で絞り込むような使い方は、リレーショナル側の得意分野です。
Amazon ElastiCacheは、クラウドでインメモリキャッシュを簡単にデプロイ・運用・スケールできるサービスです。ディスクベースのデータベースに依存せず、高速なインメモリキャッシュから情報を取得することでWebアプリケーションの性能を改善します。データベースの置き換えではなく、その手前に置いて同じ読み出しを受け止める役です。何度も同じ結果を返している問合せがあるなら、そこがElastiCacheの出番になります。
Amazon Redshiftは、クラウド上のフルマネージド・ペタバイト規模のデータウェアハウスサービスです。データセットの大小によらず、既存のSQLベースのツールやBIアプリケーションから高速なクエリ性能を提供します。RDSとの違いは目的で、RDSが日々の取引を1件ずつ読み書きする業務システムを支えるのに対し、Redshiftは大量に貯まった実績データをまとめて集計し分析するためのものです。どちらもSQLで問い合わせるので、名前だけ見ると似て見えるのが厄介なところです。
つまずきどころは2つです。1つはAuroraをRDSと無関係の別物だと思ってしまうこと。もう1つは、RedshiftをRDSの上位版だと思ってしまうことです。前者は「RDSの一部で、管理の単位がクラスター」、後者は「同じSQLでも分析用と取引用で別物」と押さえてください。
5つのデータベース系サービスの役割 サービス 種別 得意なこと 選ぶ合図になる要件 RDS リレーショナル 日々の取引を関係モデルで読み書きする 既存の業務システムをそのまま移したい Aurora リレーショナル（RDSの一部） クラスター全体を管理し高い性能を出す MySQLやPostgreSQL互換のまま強くしたい DynamoDB NoSQL キーを指定した1件ずつの高速な読み書き 規模が読めず、応答を短く保ちたい ElastiCache インメモリ 同じ読み出しをメモリで受け止める 同一の問合せが繰り返され応答が遅い Redshift データウェアハウス 大量の実績データをまとめて集計する BIツールから分析したい
用語 Amazon RDS Amazon Relational Database Service。リレーショナルDBのセットアップ・運用・スケールを容易にし、ハードウェアの用意、パッチ適用、バックアップなどを自動化する。 Amazon Aurora MySQL・PostgreSQL互換のフルマネージドなリレーショナルDBエンジン。RDSの一部で、個々のインスタンスではなくクラスター全体を管理の単位とする。 分散共有ストレージ Auroraが持つ高性能なストレージのしくみ。DBサーバー群で共有され、必要に応じて容量が自動で拡張される。 Amazon DynamoDB キーバリュー型／ドキュメント型のNoSQLデータベース。あらゆる規模で1桁ミリ秒のパフォーマンスを提供し、マルチリージョンに対応する。 Amazon ElastiCache インメモリキャッシュをデプロイ・運用・スケールするサービス。ディスクベースDBに依存せず、メモリから情報を取得して応答を速くする。 Amazon Redshift フルマネージド・ペタバイト規模のデータウェアハウスサービス。既存のSQLベースのツールやBIアプリから高速なクエリ性能を得られる。 データウェアハウス 分析のために大量のデータを集めて置いておく基盤。1件ずつの取引を捌く業務データベースとは目的が違う。 NoSQL 表と行の関係モデルによらないデータベースの総称。DynamoDBはキーバリュー型とドキュメント型に対応する。 マネージドサービス 運用作業をAWSが引き受ける形のサービス。RDSではハードウェアの用意、セットアップ、パッチ適用、バックアップが自動化されるが、設計の判断は利用者に残る。 クラスター レプリケーションで同期された複数のDBサーバーのまとまり。Auroraはこの単位で管理する。 例題
例題：例題：利用者のプロフィール画面を開くたびに同じ問合せがRDSへ飛び、負荷が上がっている。作り変えずに応答を速くする手はあるか。
答えと考え方 ElastiCacheを手前に置く手があります。ElastiCacheはディスクベースのデータベースに依存せず、高速なインメモリキャッシュから情報を取得することでWebアプリケーションの性能を改善するサービスです。何度も同じ結果を返している読み出しであれば、2回目以降をメモリから返せるので、RDS側の負荷も同時に下がります。データベースそのものを置き換える話ではない点が要点です。
例題：例題：オンプレミスのMySQLで動く業務システムをAWSへ移す。互換性は保ちたいが、複数台構成をまとめて面倒を見てほしい。何を選ぶか。
答えと考え方 Auroraが候補になります。AuroraはMySQL・PostgreSQL互換のフルマネージドなリレーショナルDBエンジンで、RDSの一部として同じコンソールやAPIから運用できます。標準のRDSが個々のDBインスタンスを管理するのに対し、Auroraはレプリケーションで同期されたDBサーバーのクラスター全体を管理するので、「まとめて面倒を見てほしい」という要件に噛み合います。
出典・根拠：Amazon Web Services, Inc. AWS ホワイトペーパー「Amazon Web Services の概要」データベース（2026年8月確認）
4. アプリケーション統合とファンアウト
SQSのキューとSNSのトピック、EventBridge、Step Functions、API Gateway。部品どうしをどうつなぐと壊れにくいのかが分かります。
システムが大きくなると、部品どうしを直接呼び合わせる作りが重荷になります。呼ばれた側が遅ければ呼んだ側も止まり、呼ばれた側が落ちれば要求は消え、宛先が増えるたびに呼ぶ側を直すことになるからです。この重荷を減らすために、間にメッセージの仕組みを挟むのがアプリケーション統合です。要点は、直接つながずに「置き場」や「配り役」を挟むことにあります。
Amazon SQS（Amazon Simple Queue Service）は、分散したソフトウェアシステムやコンポーネントを統合して疎結合化する、セキュアで耐久性と可用性に優れたホスト型のキューサービスです。送り手はメッセージをキューに入れた時点で自分の仕事を終え、受け手は自分の速度でポーリングして取り出します。通常は1つのコンシューマが取り出すポイントツーポイントの形です。キューには標準キューとFIFOキューがあり、標準キューはat-least-once配信、FIFOキューはexactly-once処理と順序保証を備えます。
Amazon SNS（Amazon Simple Notification Service）は、パブリッシャーからサブスクライバーへメッセージを配信するフルマネージドのパブ／サブサービスです。パブリッシャーはトピック、すなわち論理的なアクセスポイントかつ通信チャネルへ非同期にメッセージを送り、そのトピックを購読している宛先へ同時にプッシュ配信されます。サブスクライバーの種別は、SQS・Lambda・HTTP(S)・Data Firehoseなどのアプリ間を指すA2Aと、Eメール・モバイルプッシュ・SMSなどの対人を指すA2Pに整理されます。
SQSとSNSは対で覚えます。SQSはキューで、メッセージを保持し、通常1つの受け手が取り出す1対1の形。SNSはトピックで、1つのメッセージを複数の購読者へ同時に押し出す1対多の形です。そして両者を組み合わせたのがファンアウトパターンで、SNSトピックの購読者として複数のSQSキューを並べる構成です。公式に定番として示されている形で、1件の出来事を集計用・通知用・監査用といった複数の処理へ配りつつ、それぞれの受け手はキューのおかげで自分の速度で処理できます。
Amazon EventBridgeは、イベントを使ってアプリケーションのコンポーネント同士を接続するサーバーレスサービスで、イベントの取り込み・フィルタリング・変換・配信を行います。中心にあるイベントバスは、多数のソースから多数のターゲットへイベントをルーティングするルーターです。またEventBridge Schedulerは、cron式やrate式による定期実行や単発実行を管理します。決まった時刻に何かを起動したい、という要件はここで扱います。
AWS Step Functionsは、ワークフローすなわちステートマシンを作成するサービスです。分散アプリケーションの構築、プロセスの自動化、マイクロサービスのオーケストレーション、データや機械学習のパイプライン作成に使い、各ステップをstate、実行中のインスタンスをexecutionと呼びます。「AのあとにBを実行し、失敗したらCへ」という手順そのものを外に出して図として持てるのが利点です。起動役のEventBridgeと、手順を進める役のStep Functionsは、組み合わせて使う関係にあります。
Amazon API Gatewayは、REST・HTTP・WebSocketのAPIをあらゆる規模で作成・公開・維持・監視・保護するサービスです。EC2上のワークロード、Lambda、任意のWebアプリケーションといったバックエンドへのアクセスのフロントドアとして機能します。外から来る要求の入口がAPI Gateway、内側で部品どうしをつなぐのがSQSやSNSやEventBridge、と場所で整理すると混ざりません。
つまずきどころは、SQSとSNSの向きの取り違えです。キューは受け側が取りに行く置き場、トピックは送り側が押し出す配り役、と方向で覚えてください。この向きが分かっていれば、ファンアウトが「トピックからキューへ」であって逆ではないことも自然に出てきます。
つなぎ役の比較。何を挟むと何が変わるか サービス つなぎ方 宛先の数 選ぶ合図になる要件 SQS キューに置き、受け手が取りに来る 通常は1つ 受け手を待たせたくない、取りこぼしたくない SNS トピックへ送り、購読者へ押し出す 複数 1件の出来事を同時に多数へ知らせたい EventBridge イベントバスが送り先へ振り分ける 複数 多数の発生元と送り先を規則で結びたい Step Functions 手順を状態として並べて進める 手順の数だけ 順序や失敗時の分岐を外に出して管理したい API Gateway 外からの要求をバックエンドへ中継 設定した経路 APIとして外部へ公開し保護したい
ファンアウトパターンの形 在庫更新イベント | SNS トピック / | \ SQS SQS SQS <- 購読者として3本のキューを並べる | | | 集計用 通知用 監査用 <- それぞれ自分の速度で取り出す 宛先を増やすときは購読を1つ足すだけで、送る側は直さない 用語 Amazon SQS Amazon Simple Queue Service。コンポーネントを疎結合化するホスト型のキューサービス。メッセージを保持し、通常1つのコンシューマがポーリングして取り出す。 標準キューとFIFOキュー SQSのキューの種類。標準キューはat-least-once配信で重複がありうる。FIFOキューはexactly-once処理と順序保証を備える。 Amazon SNS Amazon Simple Notification Service。パブリッシャーからサブスクライバーへ配信するフルマネージドのパブ／サブサービス。トピックへ非同期に送る。 トピック SNSでメッセージを受け取る論理的なアクセスポイントかつ通信チャネル。購読している宛先へ同時にプッシュ配信される。 A2AとA2P SNSのサブスクライバー種別。A2Aはアプリ間（SQS、Lambda、HTTP(S)、Data Firehoseなど）、A2Pは対人（Eメール、モバイルプッシュ、SMS）。 ファンアウトパターン 1つのSNSトピックから複数のSQSキューへ同時に配信する定番構成。1件の出来事を複数の処理へ配りつつ、受け手ごとに自分の速度で処理できる。 Amazon EventBridge イベントでコンポーネント同士を接続するサーバーレスサービス。イベントの取り込み・フィルタリング・変換・配信を行う。 イベントバス 多数のソースから多数のターゲットへイベントをルーティングするルーター。EventBridgeの中心となる仕組み。 EventBridge Scheduler cron式やrate式による定期実行と単発実行を管理する仕組み。決まった時刻の起動はここで扱う。 AWS Step Functions ワークフロー（ステートマシン）を作成するサービス。各ステップをstate、実行中のインスタンスをexecutionと呼ぶ。 Amazon API Gateway REST・HTTP・WebSocketのAPIを作成・公開・維持・監視・保護するサービス。バックエンドへのアクセスのフロントドアとして機能する。 疎結合 部品どうしが互いの都合に引きずられない状態。間にキューを挟むと、片方の遅れや停止がもう片方を止めにくくなる。 例題
例題：例題：SNSトピックにLambdaを直接購読させる構成と、SNSトピックからSQSキューを挟んでLambdaへ渡す構成では、何が変わるか。
答えと考え方 キューを挟むとメッセージがいったん保持され、受け手が自分の速度で取り出せるようになります。SQSは疎結合化のためのキューサービスで、送り手はキューに入れた時点で仕事を終えられます。したがって受け手側が一時的に遅れても、送り手や配り役はその影響を受けにくくなります。直接購読は経路が短くて済む代わりに、受け手側の都合がそのまま出やすい形です。
例題：例題：毎朝決まった時刻に、3段階の集計処理を順番に流したい。起動と進行はそれぞれどのサービスが担うか。
答えと考え方 起動はEventBridge Schedulerです。cron式やrate式による定期実行や単発実行を管理する仕組みなので、時刻による起動はここで扱います。3段階の順序と失敗時の分岐を持つのはStep Functionsで、ワークフローすなわちステートマシンとして各ステップをstateで並べます。「いつ始めるか」と「どういう順で進めるか」を別のサービスに持たせるのが、この2つの組み合わせ方です。
出典・根拠：Amazon Web Services, Inc.「Amazon Simple Queue Service デベロッパーガイド」（2026年8月確認）
確認問題（40問） 四肢択一。「正解と解説」を開くと、正解の理由と他の選択肢が違う理由を確認できます。
問1｜EC2とS3
Amazon EC2 と Amazon S3 の役割の組合せとして適切なものはどれか。
EC2は仮想サーバーを提供し、S3はオブジェクトを保存する EC2はオブジェクトを保存し、S3は仮想サーバーを提供する EC2はファイルを共有し、S3は関数のコードを実行する EC2は関数のコードを実行し、S3はファイルを共有する 正解と解説 正解：A. EC2は仮想サーバーを提供し、S3はオブジェクトを保存する EC2 は Amazon Elastic Compute Cloud で、サイズ変更可能なコンピューティング能力すなわち仮想サーバーを提供する。S3 は Amazon Simple Storage Service で、任意の量のデータをオブジェクトとして保存する。この2つを入れ替えた記述は昔から多い取り違えなので、名前の綴りから役割を思い出せるようにしておきたい。関数のコードを実行するのは Lambda、ファイルを共有するのは EFS である。
根拠：Amazon Web Services, Inc. AWS ホワイトペーパー「Amazon Web Services の概要」コンピューティング（2026年8月確認）
問2｜Lambdaの課金
AWS Lambda の課金の考え方として適切なものはどれか。
コードが実行されていない間も、確保した容量に応じて課金される 作成した関数の本数に応じて、月ごとに定額で課金される 消費したコンピューティング時間に対してのみ課金される アップロードしたコードの容量に対してのみ課金される 正解と解説 正解：C. 消費したコンピューティング時間に対してのみ課金される Lambda はサーバーのプロビジョニングや管理なしにコードを実行でき、消費したコンピューティング時間にのみ課金される。コードが実行されていない間は料金が発生しない点が、動かしている限り費用がかかる EC2 との大きな違いである。関数の本数やアップロードしたコードの容量そのものを課金の単位にしているわけではない。
根拠：Amazon Web Services, Inc. AWS ホワイトペーパー「Amazon Web Services の概要」コンピューティング（2026年8月確認）
問3｜サーバーレス
サーバーレスと呼ばれるサービスに共通する特徴はどれか。
処理を実行する物理的なサーバーがどこにも存在していない 利用者はサーバーのプロビジョニングや管理を行わなくてよい 利用者が用意した専用の物理サーバー上でだけ処理が動く 実行の前に利用者がOSの種類とパッチ適用方針を決める 正解と解説 正解：B. 利用者はサーバーのプロビジョニングや管理を行わなくてよい サーバーレスは物理サーバーが無いという意味ではなく、サーバーの調達・設定・スケールを利用者が行わなくてよいという意味である。Lambda は「サーバーのプロビジョニングや管理なしにコードを実行できる」と説明され、Fargate は「サーバーやクラスターのプロビジョニング・設定・スケールが不要」と説明される。物理サーバーはAWS側にあり、OSの種類やパッチ適用を利用者が決めるのは EC2 のような形態である。
根拠：Amazon Web Services, Inc. AWS ホワイトペーパー「Amazon Web Services の概要」コンピューティング（2026年8月確認）
問4｜Fargate
AWS Fargate の説明として適切なものはどれか。
Kubernetes のクラスターをAWS上で運用するマネージドサービス 仮想サーバーのインスタンスタイプと台数を利用者が選んで使う仕組み 分散した処理の手順をワークフローとして定義して実行する仕組み コンテナ向けの、サーバー管理が要らない従量課金の実行エンジン 正解と解説 正解：D. コンテナ向けの、サーバー管理が要らない従量課金の実行エンジン Fargate はコンテナ向けのサーバーレス従量課金コンピューティングエンジンで、サーバーやクラスターのプロビジョニング・設定・スケールが不要であり、ECS や EKS の起動タイプとして使う。Kubernetes のマネージド運用は EKS、インスタンスタイプと台数を自分で選ぶのは EC2 起動タイプ、手順をワークフローとして定義するのは Step Functions である。
根拠：Amazon Web Services, Inc. AWS ホワイトペーパー「Amazon Web Services の概要」コンピューティング（2026年8月確認）
問5｜ECSの容量
Amazon ECS でタスクを動かす基盤の選び方に関する記述のうち、適切なものはどれか。
EC2ではAWSが基盤を管理し、Fargate では利用者がインスタンスを管理する Fargate と EC2 のどちらを選んでも、利用者がインスタンスを管理する Fargate ではAWSが基盤を管理し、EC2では利用者がインスタンスを管理する Fargate と EC2 のどちらを選んでも、AWSがインスタンスを管理する 正解と解説 正解：C. Fargate ではAWSが基盤を管理し、EC2では利用者がインスタンスを管理する ECS のキャパシティ選択肢は、サーバーレスでAWSが基盤を管理する Fargate と、インスタンスタイプと台数を利用者が選んで管理する EC2 の2つが基本である。ほかに ECS Managed Instances、オンプレミス向けの ECS Anywhere がある。どちらを選んでもコンテナの配置とスケールを行うのは ECS であり、変わるのは基盤の面倒を誰が見るかという点だけである。
根拠：Amazon Web Services, Inc.「Amazon Elastic Container Service デベロッパーガイド」（2026年8月確認）
問6｜EKS
Amazon EKS を採用する理由として最も適切なものはどれか。
Kubernetes を自前で構築し運用する手間を省きたいから リレーショナルデータベースの定期的なバックアップを任せたいから 静的なWebコンテンツを利用者に近い場所から配信したいから 受信したトラフィックを複数のターゲットへ自動で振り分けたいから 正解と解説 正解：A. Kubernetes を自前で構築し運用する手間を省きたいから EKS は Amazon Elastic Kubernetes Service で、自前で Kubernetes クラスターをインストール・運用することなくAWS上で Kubernetes を実行できるマネージドサービスであり、Kubernetes 準拠の認定を受けている。データベースの運用自動化は RDS、コンテンツを近い場所から配信するのは CloudFront、トラフィックの振り分けは Elastic Load Balancing が担う。
根拠：Amazon Web Services, Inc.「Amazon EKS ユーザーガイド」（2026年8月確認）
問7｜実行の選択
1日に数回だけ届くファイルを、届いたときにだけ変換したい。費用を抑える構成として適切なものはどれか。
EC2 インスタンスを常時稼働させ、処理を一定間隔で行う EC2 インスタンスを常時稼働させ、処理を手作業で起動する EKS のクラスターを常時稼働させ、処理を一定間隔で行う Lambda に処理を書き、ファイルの到着を契機に実行する 正解と解説 正解：D. Lambda に処理を書き、ファイルの到着を契機に実行する Lambda はサーバーの管理なしにコードを実行でき、消費したコンピューティング時間にのみ課金され、実行されていない間は料金が発生しない。したがって呼び出しがまばらな処理では、待っている時間に費用がかからない Lambda が有利になる。EC2 や EKS のクラスターを常時稼働させる構成は、処理が動いていない大半の時間にも費用がかかり続ける。
根拠：Amazon Web Services, Inc. AWS ホワイトペーパー「Amazon Web Services の概要」コンピューティング（2026年8月確認）
問8｜EC2の制御
Amazon EC2 の特徴を述べたものとして適切なものはどれか。
コードの実行時間だけが課金され、利用者はOSに触れる必要がない コンピューティングリソースを完全に制御でき、使った分だけ支払う データをオブジェクト単位で保存し、HTTPのAPIから読み書きする ワークフローの各段階を状態として定義し、順序どおりに実行する 正解と解説 正解：B. コンピューティングリソースを完全に制御でき、使った分だけ支払う EC2 はクラウド上で安全かつサイズ変更可能なコンピューティング能力を提供するサービスで、使った分だけ支払い、コンピューティングリソースを完全に制御できると公式に説明されている。実行時間だけが課金されOSに触れないのは Lambda、オブジェクト単位で保存するのは S3、ワークフローを状態として定義するのは Step Functions の性質である。制御できる範囲が広いぶん、OSの管理が利用者に残る点も合わせて押さえたい。
根拠：Amazon Web Services, Inc. AWS ホワイトペーパー「Amazon Web Services の概要」コンピューティング（2026年8月確認）
問9｜ECS
Amazon ECS が担う役割として適切なものはどれか。
Kubernetes の API に準拠したクラスターをAWS上で提供する 仮想サーバーのイメージから任意の台数のインスタンスを起動する 関数の形で書いたコードをイベントの発生に応じて実行する コンテナ化したアプリケーションの配置と管理と規模の調整を行う 正解と解説 正解：D. コンテナ化したアプリケーションの配置と管理と規模の調整を行う ECS は Amazon Elastic Container Service で、フルマネージドのコンテナオーケストレーションサービスとして、コンテナ化したアプリケーションのデプロイ・管理・スケールを容易にする。Kubernetes に準拠したクラスターを提供するのは EKS、仮想サーバーの起動は EC2、イベントに応じたコードの実行は Lambda である。ECS と EKS はどちらもコンテナを束ねるが、Kubernetes を使うかどうかで分かれる。
根拠：Amazon Web Services, Inc.「Amazon Elastic Container Service デベロッパーガイド」（2026年8月確認）
問10｜ECSとEKS
Amazon ECS と Amazon EKS の違いを述べたものとして適切なものはどれか。
ECS が Kubernetes を実行し、EKS はAWS独自の方式でコンテナを束ねる EKS が Kubernetes を実行し、ECS はAWS独自の方式でコンテナを束ねる ECS はコンテナを扱い、EKS は仮想サーバーのイメージだけを扱う EKS はコンテナを扱い、ECS は仮想サーバーのイメージだけを扱う 正解と解説 正解：B. EKS が Kubernetes を実行し、ECS はAWS独自の方式でコンテナを束ねる EKS は自前で Kubernetes クラスターをインストール・運用することなくAWS上で Kubernetes を実行できるマネージドサービスで、Kubernetes 準拠の認定を受けている。一方 ECS はAWSのフルマネージドなコンテナオーケストレーションサービスで、Kubernetes を前提としない。どちらもコンテナを扱うサービスであり、仮想サーバーのイメージだけを扱うわけではない。起動先としてはどちらも Fargate を選べる。
根拠：Amazon Web Services, Inc.「Amazon EKS ユーザーガイド」（2026年8月確認）
問11｜EBSとEFS
Amazon EBS と Amazon EFS の性質の組合せとして適切なものはどれか。
EBS はファイルとして多数のEC2から共有し、EFS はブロックとして接続する EBS はブロックとして1台のEC2に接続し、EFS は多数のEC2から共有する EBS も EFS も、多数のEC2インスタンスからの並列共有を前提としている EBS も EFS も、1台のEC2インスタンスへの接続だけを前提としている 正解と解説 正解：B. EBS はブロックとして1台のEC2に接続し、EFS は多数のEC2から共有する EBS は EC2 インスタンスで使う永続的なブロックストレージボリュームで、アベイラビリティゾーン内で自動的にレプリケートされ、原則として1つのインスタンスにアタッチして使う。EFS は Linux ワークロード向けのファイルシステムで、容量が自動で伸縮し、数千台の EC2 インスタンスからの並列共有アクセスに対応する。共有できるのは EFS の側であり、両方が共有向け、あるいは両方が単独接続専用ということはない。
根拠：Amazon Web Services, Inc. AWS ホワイトペーパー「Amazon Web Services の概要」ストレージ（2026年8月確認）
問12｜S3の種別
Amazon S3 が扱うデータの持ち方として適切なものはどれか。
EC2 インスタンスに接続して使うブロックストレージである Linux 向けの共有ファイルシステムとして提供される インメモリのキャッシュとして高速な読み書きを提供する 任意の量のデータを保存できるオブジェクトストレージである 正解と解説 正解：D. 任意の量のデータを保存できるオブジェクトストレージである S3 は Amazon Simple Storage Service で、任意の量のデータを保存・保護できる、スケーラビリティや可用性に優れたオブジェクトストレージである。ブロックストレージは EBS、Linux 向けの共有ファイルシステムは EFS、インメモリのキャッシュは ElastiCache が担う。オブジェクト・ブロック・ファイルという3つの持ち方の違いが、AWSのストレージを選ぶときの出発点になる。
根拠：Amazon Web Services, Inc. AWS ホワイトペーパー「Amazon Web Services の概要」ストレージ（2026年8月確認）
問13｜共有の選択
数百台のEC2インスタンスから同じディレクトリを同時にマウントして読み書きしたい。適切なものはどれか。
Amazon EFS のファイルシステムを各インスタンスからマウントする Amazon EBS のボリュームを各インスタンスに1本ずつ接続する S3 Glacier Deep Archive に置いて各インスタンスから読み書きする Amazon ElastiCache のノードを各インスタンスから参照する 正解と解説 正解：A. Amazon EFS のファイルシステムを各インスタンスからマウントする EFS はファイルの増減に応じて容量が自動で伸縮し、数千台の EC2 インスタンスからの並列共有アクセスに対応するファイルストレージなので、同じディレクトリを多数のインスタンスから同時にマウントする用途に合う。EBS はアベイラビリティゾーン内のブロックストレージで、原則1つのインスタンスにアタッチするため各自の領域が別々になる。Glacier Deep Archive は取り出しに時間をかけるアーカイブ向けのクラス、ElastiCache はファイルシステムではなくインメモリキャッシュである。
根拠：Amazon Web Services, Inc. AWS ホワイトペーパー「Amazon Web Services の概要」ストレージ（2026年8月確認）
問14｜EBSのAZ
Amazon EBS のボリュームが自動的にレプリケートされる範囲として適切なものはどれか。
世界中のエッジロケーションに複製される 複数のリージョンにまたがって複製される 1つのアベイラビリティゾーンの中で複製される 契約したすべてのアカウントの間で複製される 正解と解説 正解：C. 1つのアベイラビリティゾーンの中で複製される EBS は EC2 インスタンス向けの永続的なブロックストレージで、アベイラビリティゾーン内で自動的にレプリケートされ、一貫した低レイテンシ性能を提供する。この単一AZという性質があるため、AZ をまたぐ可用性を求めるなら別の仕組みが必要になる。リージョンをまたぐ複製や、エッジロケーションでの配信は EBS の役割ではない。
根拠：Amazon Web Services, Inc. AWS ホワイトペーパー「Amazon Web Services の概要」ストレージ（2026年8月確認）
問15｜Glacier
S3 Glacier のストレージクラスに関する記述のうち、適切なものはどれか。
即時の取り出しに応じるクラスと、時間をかけて取り出すクラスがある アーカイブ用のクラスであり、取り出しに要する時間はどれも同じである 保存できるのはデータベースのバックアップファイルに限られている 保存したデータはブロックストレージとしてEC2に直接接続できる 正解と解説 正解：A. 即時の取り出しに応じるクラスと、時間をかけて取り出すクラスがある S3 Glacier はアーカイブ用のストレージクラス群で、即時の取り出しが必要なデータ向けの S3 Glacier Instant Retrieval、めったにアクセスしない長期データ向けの S3 Glacier Flexible Retrieval、最低コストで数時間かけて取り出す S3 Glacier Deep Archive がある。取り出しの速さと費用の兼ね合いでクラスを選ぶ設計であり、取り出し時間が一律ということはない。保存できるデータの種類に制限はなく、ブロックストレージとして接続する使い方でもない。
根拠：Amazon Web Services, Inc. AWS ホワイトペーパー「Amazon Web Services の概要」ストレージ（2026年8月確認）
問16｜3つの区分
S3・EBS・EFS を、扱うデータの単位で分類した組合せとして適切なものはどれか。
S3 がブロック、EBS がファイル、EFS がオブジェクト S3 がファイル、EBS がオブジェクト、EFS がブロック S3 がブロック、EBS がオブジェクト、EFS がファイル S3 がオブジェクト、EBS がブロック、EFS がファイル 正解と解説 正解：D. S3 がオブジェクト、EBS がブロック、EFS がファイル S3 はオブジェクトストレージ、EBS は EC2 に接続するブロックストレージ、EFS は Linux ワークロード向けのファイルストレージである。オブジェクトはAPI経由で丸ごと出し入れするもの、ブロックはOSからディスクとして見えるもの、ファイルは複数のホストからマウントして共有できるものと整理すると、要件から選ぶときに迷いにくい。
根拠：Amazon Web Services, Inc. AWS ホワイトペーパー「Amazon Web Services の概要」ストレージ（2026年8月確認）
問17｜OSディスク
1台のEC2インスタンスで動かすデータベースの、データ格納用ディスクとして使うものはどれか。
Amazon S3 のバケットをディスクとして接続する S3 Glacier Flexible Retrieval のアーカイブを使う Amazon EBS のボリュームをインスタンスに接続する Amazon CloudFront のキャッシュをディスクとして使う 正解と解説 正解：C. Amazon EBS のボリュームをインスタンスに接続する EBS は EC2 インスタンスで使う永続的なブロックストレージボリュームで、一貫した低レイテンシ性能を提供するため、OS やデータベースのディスクとして使うのに向く。S3 はオブジェクトストレージで、バケットをブロックデバイスとして接続する仕組みではない。Glacier は取り出しに時間をかけるアーカイブ向けのクラス、CloudFront は配信を高速化する CDN である。
根拠：Amazon Web Services, Inc. AWS ホワイトペーパー「Amazon Web Services の概要」ストレージ（2026年8月確認）
問18｜S3の用途
静的なWebコンテンツやバックアップの置き場として S3 が選ばれる理由はどれか。
OSからディスクとして見えるので、そのまま業務システムに接続できるから 任意の量のデータを保存でき、拡張性と可用性と安全性に優れているから 接続できるインスタンスが1台に限られ、書き換えの競合が起きないから メモリ上にデータを置くため、ディスクを介さずに読み書きできるから 正解と解説 正解：B. 任意の量のデータを保存でき、拡張性と可用性と安全性に優れているから S3 は任意の量のデータを保存・保護できる、スケーラビリティ・可用性・セキュリティ・パフォーマンスに優れたオブジェクトストレージで、Web、モバイル、バックアップ、アーカイブ、IoT、ビッグデータ分析といった用途が公式に挙げられている。OSからディスクとして見えるのは EBS、1インスタンスへの接続を原則とするのも EBS、メモリ上にデータを置くのは ElastiCache の性質である。
根拠：Amazon Web Services, Inc. AWS ホワイトペーパー「Amazon Web Services の概要」ストレージ（2026年8月確認）
問19｜EFSの伸縮
Amazon EFS の容量に関する記述として適切なものはどれか。
ファイルの増減に応じて、容量が自動で伸び縮みする 作成時に決めた容量が固定され、後から変更できない 容量を増やすときは、いったん切り離して作り直す必要がある 保存できる容量はインスタンスのメモリ量で決まる 正解と解説 正解：A. ファイルの増減に応じて、容量が自動で伸び縮みする EFS はシンプルでスケーラブル、エラスティックなファイルシステムで、ファイルを追加・削除すると容量が自動で伸縮し、事前の容量設計が要らない。容量を先に決めて固定したり、広げるために作り直したりするのはブロックストレージの発想であり、接続先インスタンスのメモリ量が容量を決めるわけでもない。この伸縮性が、共有の作業領域として使いやすい理由になっている。
根拠：Amazon Web Services, Inc. AWS ホワイトペーパー「Amazon Web Services の概要」ストレージ（2026年8月確認）
問20｜保管の選択
めったに参照しない監査ログを、数時間かけて取り出せればよい前提で最も安く長期保管したい。適切なものはどれか。
Amazon EBS のボリュームを作り、そこへ書き出して保管する Amazon EFS のファイルシステムに置いたまま保管する S3 Glacier Deep Archive のクラスに保管する Amazon ElastiCache のノードに載せたまま保管する 正解と解説 正解：C. S3 Glacier Deep Archive のクラスに保管する S3 Glacier Deep Archive は、めったにアクセスしないデータを最低コストで保管し、取り出しに数時間かけるアーカイブ向けのストレージクラスなので、この条件に合う。EBS と EFS は取り出しの速さを保つ設計で、長期の休眠データの置き場としては割高になりやすい。ElastiCache はインメモリのキャッシュであり、そもそも長期保管のための仕組みではない。取り出しにどれだけ待てるかを先に決めるのが、クラス選びの筋道である。
根拠：Amazon Web Services, Inc. AWS ホワイトペーパー「Amazon Web Services の概要」ストレージ（2026年8月確認）
問21｜RDS
Amazon RDS が自動化する管理作業として適切なものはどれか。
表と列の設計、および索引をどこに張るかの決定 業務アプリケーションの画面遷移と入力チェック ハードウェアの用意、パッチ適用、バックアップ 保存されたデータの内容が正しいかどうかの検証 正解と解説 正解：C. ハードウェアの用意、パッチ適用、バックアップ RDS はクラウドでのリレーショナルデータベースのセットアップ・運用・スケールを容易にするマネージドサービスで、ハードウェアのプロビジョニング、データベースのセットアップ、パッチ適用、バックアップといった管理作業を自動化する。一方、表と列の設計や索引の判断、アプリケーションの作り、データの中身の妥当性は、いずれも利用者側の仕事として残る。マネージドとは運用の手間を預けることであって、設計まで預けることではない。
根拠：Amazon Web Services, Inc. AWS ホワイトペーパー「Amazon Web Services の概要」データベース（2026年8月確認）
問22｜AuroraとRDS
Amazon Aurora と標準の Amazon RDS の関係を述べたものとして適切なものはどれか。
Aurora は RDS の一部で、個々のインスタンスではなくクラスター全体を管理する Aurora は RDS とは別のサービスで、専用のコンソールとAPIからだけ操作する Aurora は RDS の一部だが、パッチ適用とバックアップは利用者が自分で行う Aurora は RDS の一部で、扱えるのはキーバリュー型のデータに限られる 正解と解説 正解：A. Aurora は RDS の一部で、個々のインスタンスではなくクラスター全体を管理する Aurora はマネージドデータベースサービスである Amazon RDS の一部で、同じマネジメントコンソール、CLI、API 操作でプロビジョニング、パッチ適用、バックアップ、復旧、障害検知を行う。違いは管理の単位にあり、標準の RDS が個々の DB インスタンスを管理するのに対し、Aurora はレプリケーションで同期された DB サーバーのクラスター全体を管理する。Aurora は MySQL・PostgreSQL 互換のリレーショナルデータベースであって、キーバリュー型ではない。
根拠：Amazon Web Services, Inc.「Amazon Aurora ユーザーガイド」（2026年8月確認）
問23｜DynamoDB
Amazon DynamoDB の説明として適切なものはどれか。
ペタバイト規模のデータウェアハウスとして分析の問合せに応じる MySQL と PostgreSQL に互換性のあるリレーショナルデータベース メモリ上にデータを置き、ディスクを介さずに読み書きを速くする キーバリュー型とドキュメント型に対応した NoSQL データベース 正解と解説 正解：D. キーバリュー型とドキュメント型に対応した NoSQL データベース DynamoDB はキーバリュー型とドキュメント型の NoSQL データベースで、あらゆる規模で1桁ミリ秒のパフォーマンスを提供する、フルマネージドかつマルチリージョン対応のデータベースである。データウェアハウスは Redshift、MySQL・PostgreSQL 互換のリレーショナルデータベースは Aurora、メモリ上での読み書きは ElastiCache が担う。
根拠：Amazon Web Services, Inc. AWS ホワイトペーパー「Amazon Web Services の概要」データベース（2026年8月確認）
問24｜Redshift
数年分の実績データをまとめて集計し、BIツールから分析したい。基盤として適切なものはどれか。
Amazon ElastiCache のクラスターに載せたまま集計する Amazon Redshift のデータウェアハウスに置いて集計する Amazon EFS のファイルシステムに置いたまま集計する Amazon SQS のキューに入れて順に取り出しながら集計する 正解と解説 正解：B. Amazon Redshift のデータウェアハウスに置いて集計する Redshift はクラウド上のフルマネージド・ペタバイト規模のデータウェアハウスサービスで、データセットの大小によらず、既存の SQL ベースのツールや BI アプリケーションから高速なクエリ性能を得られる。ElastiCache はインメモリのキャッシュ、EFS は共有ファイルシステム、SQS はメッセージのキューであり、いずれも大量データの集計と分析を担う基盤ではない。
根拠：Amazon Web Services, Inc. AWS ホワイトペーパー「Amazon Web Services の概要」データベース（2026年8月確認）
問25｜キャッシュ
Amazon ElastiCache を導入して得られる効果として適切なものはどれか。
表の結合や集計を含む分析用の問合せを、まとめて速くできる 長期に保管するバックアップの費用を、大きく下げられる 複数のEC2インスタンスから同じディレクトリを共有できる ディスクを介さずメモリから取得することで応答を速くできる 正解と解説 正解：D. ディスクを介さずメモリから取得することで応答を速くできる ElastiCache はクラウドでインメモリキャッシュを簡単にデプロイ・運用・スケールできるサービスで、ディスクベースのデータベースに依存せず高速なインメモリキャッシュから情報を取得することで、Web アプリケーションの性能を改善する。分析用の問合せを速くするのは Redshift、長期保管の費用低減は S3 Glacier のクラス、ディレクトリの共有は EFS の担当である。
根拠：Amazon Web Services, Inc. AWS ホワイトペーパー「Amazon Web Services の概要」データベース（2026年8月確認）
問26｜Auroraの特徴
Amazon Aurora の特徴として適切なものはどれか。
利用者が容量を先に決め、足りなくなるたび手作業で広げていく 分散共有ストレージを持ち、必要に応じて容量が自動で広がる データをキーと値の組として保存し、SQL を使わずに読み書きする 取り出しに数時間かかる代わりに、保管の費用を最も安く抑える 正解と解説 正解：B. 分散共有ストレージを持ち、必要に応じて容量が自動で広がる Aurora は MySQL・PostgreSQL 互換のフルマネージドなリレーショナルデータベースエンジンで、高性能な分散共有ストレージサブシステムを持ち、ストレージは必要に応じて自動で拡張される。容量を先に決めて手作業で広げる必要はない。キーと値の組で保存するのは DynamoDB、時間をかけて取り出す代わりに安く保管するのは S3 Glacier のアーカイブ向けクラスである。
根拠：Amazon Web Services, Inc.「Amazon Aurora ユーザーガイド」（2026年8月確認）
問27｜分析と取引
Amazon Redshift と Amazon RDS の使い分けとして適切なものはどれか。
分析のための集計は Redshift、日々の取引の記録は RDS が向く 日々の取引の記録は Redshift、分析のための集計は RDS が向く どちらもデータウェアハウスで、扱えるデータ量だけが違っている どちらも NoSQL で、問合せに使える言語だけが違っている 正解と解説 正解：A. 分析のための集計は Redshift、日々の取引の記録は RDS が向く Redshift はフルマネージドでペタバイト規模のデータウェアハウスサービスで、SQL ベースのツールや BI アプリケーションから大量のデータを集計・分析する用途に向く。RDS はリレーショナルデータベースのセットアップ・運用・スケールを容易にするサービスで、業務システムが日々の取引を読み書きする用途に向く。どちらも SQL で問い合わせるため似て見えるが、NoSQL ではないし、量の違いだけでもない。
根拠：Amazon Web Services, Inc. AWS ホワイトペーパー「Amazon Web Services の概要」データベース（2026年8月確認）
問28｜DBの選択
1桁ミリ秒の応答で、キーを指定して1件ずつ読み書きしたい。基盤として適切なものはどれか。
Amazon Redshift のデータウェアハウス Amazon RDS のリレーショナルデータベース Amazon DynamoDB のNoSQLデータベース Amazon EFS の共有ファイルシステム 正解と解説 正解：C. Amazon DynamoDB のNoSQLデータベース DynamoDB はキーバリュー型とドキュメント型の NoSQL データベースで、あらゆる規模で1桁ミリ秒のパフォーマンスを提供すると公式に説明されている。Redshift は大量データの集計と分析に向くデータウェアハウス、RDS は関係モデルでの読み書きを担うサービス、EFS はファイルの共有を担うストレージであり、いずれもこの条件を第一に狙った基盤ではない。
根拠：Amazon Web Services, Inc. AWS ホワイトペーパー「Amazon Web Services の概要」データベース（2026年8月確認）
問29｜RDSの位置
Amazon RDS の説明として適切なものはどれか。
キーと値の組で保存し、SQL を使わずに読み書きするデータベース リレーショナルデータベースの構築と運用を容易にするサービス メモリ上のキャッシュを置いて読み出しを速くするサービス 大量のデータを取り込んで集計するデータウェアハウス 正解と解説 正解：B. リレーショナルデータベースの構築と運用を容易にするサービス RDS は Amazon Relational Database Service で、クラウドでのリレーショナルデータベースのセットアップ・運用・スケールを容易にするマネージドサービスである。キーと値の組で保存するのは DynamoDB、インメモリのキャッシュは ElastiCache、大量データの集計はデータウェアハウスである Redshift が担う。なお Aurora は RDS の一部として提供されるエンジンである。
根拠：Amazon Web Services, Inc. AWS ホワイトペーパー「Amazon Web Services の概要」データベース（2026年8月確認）
問30｜Auroraの管理
Aurora のクラスターに対する日常の運用について、適切な記述はどれか。
RDS と同じコンソールやAPIから、パッチ適用やバックアップを行える Aurora 専用の管理用インスタンスを別に立てて、そこから操作を行う バックアップと復旧の手順は、利用者が自分で作り込む必要がある クラスターではなく、個々のインスタンス単位でしか操作ができない 正解と解説 正解：A. RDS と同じコンソールやAPIから、パッチ適用やバックアップを行える Aurora は RDS の一部として提供され、同じマネジメントコンソール、CLI、API 操作でプロビジョニング、パッチ適用、バックアップ、復旧、障害検知を行える。管理用のインスタンスを別に立てる必要はなく、これらの手順を利用者が作り込む必要もない。標準の RDS が個々の DB インスタンスを管理するのに対し、Aurora はクラスター全体を管理の単位とする点が違いである。
根拠：Amazon Web Services, Inc.「Amazon Aurora ユーザーガイド」（2026年8月確認）
問31｜SQSとSNS
Amazon SQS と Amazon SNS の性質の組合せとして適切なものはどれか。
SQS はトピックへの配信、SNS はキューへの蓄積を担う仕組みである SQS も SNS も、1件を多数の宛先へ同時に届けるための仕組みである SQS も SNS も、保持したメッセージを1つの宛先が取り出す仕組みである SQS はキューへの蓄積、SNS はトピックへの配信を担う仕組みである 正解と解説 正解：D. SQS はキューへの蓄積、SNS はトピックへの配信を担う仕組みである SQS はメッセージをキューに保持し、通常は1つのコンシューマがポーリングして取り出すポイントツーポイントのサービスである。SNS はパブリッシャーがトピックへメッセージを送り、複数のサブスクライバーへ同時にプッシュ配信するパブサブのサービスである。両者を入れ替えた記述は典型的な取り違えで、どちらも同じ配り方をするわけでもない。キューは受け手が取りに行く置き場、トピックは送り手が押し出す配り役、と方向で覚えるとよい。
根拠：Amazon Web Services, Inc.「Amazon Simple Queue Service デベロッパーガイド」（2026年8月確認）
問32｜FIFOキュー
Amazon SQS のFIFOキューの性質として適切なものはどれか。
送った順序は保たれないが、重複した配信だけは起こらない 送った順序が保たれ、メッセージが1回だけ処理される 送った順序は保たれるが、同じメッセージが複数回届く 送った順序も処理の回数も、どちらも保証の対象外である 正解と解説 正解：B. 送った順序が保たれ、メッセージが1回だけ処理される SQS には標準キューと FIFO キューがあり、標準キューは at-least-once 配信なので同じメッセージが複数回届くことがある。FIFO キューは exactly-once 処理と順序保証を備え、送った順序が保たれ、1回だけ処理される。順序や消失防止が重要なワークフローでは FIFO キューを選ぶことになる。
根拠：Amazon Web Services, Inc.「Amazon Simple Queue Service デベロッパーガイド」（2026年8月確認）
問33｜ファンアウト
ファンアウトパターンと呼ばれる構成の組立て方として適切なものはどれか。
1つのSQSキューを、複数のSNSトピックが順番に読み取る 1つのSQSキューから、複数のSQSキューへ直接転送する 1つのSNSトピックから、複数のSQSキューへ同時に配信する 1つのSNSトピックを、複数のSNSトピックが順番に読み取る 正解と解説 正解：C. 1つのSNSトピックから、複数のSQSキューへ同時に配信する SNS はトピックへ送られたメッセージを複数のサブスクライバーへ同時にプッシュ配信し、そのサブスクライバーには SQS キューを指定できる。この SNS トピックから複数の SQS キューへ配る形が、公式に定番として示されているファンアウトパターンである。キューは配信元ではなく受け側なので、キューがトピックを読み取る向きにはならない。
根拠：Amazon Web Services, Inc.「Amazon Simple Notification Service デベロッパーガイド」（2026年8月確認）
問34｜通知先
Amazon SNS のサブスクライバーとして指定できる宛先の説明として適切なものはどれか。
SQSやLambdaなどアプリ側の宛先と、Eメールなど対人の宛先を指定できる 指定できるのはEメールやSMSなど、人に届ける宛先だけに限られている 指定できるのはSQSやLambdaなど、アプリ側の宛先だけに限られている 指定できるのは同じアカウント内のEC2インスタンスだけに限られている 正解と解説 正解：A. SQSやLambdaなどアプリ側の宛先と、Eメールなど対人の宛先を指定できる SNS のサブスクライバー種別は、SQS、Lambda、HTTP(S)、Data Firehose などのアプリ間を指す A2A と、Eメール、モバイルプッシュ、SMS などの対人を指す A2P の2つに整理される。どちらか一方に限られるわけではなく、EC2 インスタンスだけを宛先にする仕組みでもない。この幅の広さが、対人の通知にもアプリ間の連携にも SNS が使われる理由になっている。
根拠：Amazon Web Services, Inc.「Amazon Simple Notification Service デベロッパーガイド」（2026年8月確認）
問35｜ワークフロー
AWS Step Functions が扱うものとして適切なものはどれか。
受信したリクエストを複数のターゲットへ振り分ける規則 複数の段階からなる処理の流れを表すステートマシン 保存したオブジェクトの版数と保管期間を決める規則 インメモリのキャッシュに置く鍵と値の組合せの一覧 正解と解説 正解：B. 複数の段階からなる処理の流れを表すステートマシン Step Functions はワークフローすなわちステートマシンを作成し、分散アプリケーションの構築、プロセスの自動化、マイクロサービスのオーケストレーション、データや機械学習のパイプライン作成を可能にするサービスである。各ステップを state、実行中のインスタンスを execution と呼ぶ。トラフィックの振り分けは Elastic Load Balancing、オブジェクトの保管は S3、鍵と値のキャッシュは ElastiCache の領分である。
根拠：Amazon Web Services, Inc.「AWS Step Functions デベロッパーガイド」（2026年8月確認）
問36｜APIGateway
Amazon API Gateway が果たす役割として適切なものはどれか。
バックエンドで動く処理そのものを、コンテナとして実行する 複数のアカウントに共通の保護規則を、まとめて適用する バックエンドへのアクセスを受け付けるフロントドアになる 静的なコンテンツをエッジロケーションにキャッシュする 正解と解説 正解：C. バックエンドへのアクセスを受け付けるフロントドアになる API Gateway は REST、HTTP、WebSocket の API をあらゆる規模で作成・公開・維持・監視・保護するサービスで、EC2 上のワークロード、Lambda、任意の Web アプリケーションといったバックエンドへのアクセスのフロントドアとして機能する。処理そのものを実行するのはバックエンド側、保護規則の一元適用は AWS Firewall Manager、エッジでのキャッシュは CloudFront の役割である。
根拠：Amazon Web Services, Inc.「Amazon API Gateway デベロッパーガイド」（2026年8月確認）
問37｜イベントバス
Amazon EventBridge のイベントバスの説明として適切なものはどれか。
多数のソースから多数のターゲットへイベントを振り分けるルーター メッセージを順序どおりに保持し、1つの宛先が取り出す待ち行列 処理の各段階を状態として定義し、順番に進めるステートマシン APIへの要求を受け付け、バックエンドへ中継するフロントドア 正解と解説 正解：A. 多数のソースから多数のターゲットへイベントを振り分けるルーター EventBridge はイベントを使ってアプリケーションのコンポーネント同士を接続するサーバーレスサービスで、イベントの取り込み・フィルタリング・変換・配信を行う。イベントバスは、多数のソースから多数のターゲットへイベントをルーティングするルーターである。待ち行列は SQS、ステートマシンは Step Functions、フロントドアは API Gateway の説明にあたる。
根拠：Amazon Web Services, Inc.「Amazon EventBridge ユーザーガイド」（2026年8月確認）
問38｜定期実行
決まった時刻に処理を起動する仕組みを、cron 式で管理したい。適切なものはどれか。
Amazon SQS の標準キューにメッセージを置いて待たせる Amazon SNS のトピックに購読者を登録して待ち受ける Amazon API Gateway に WebSocket の API を作成する Amazon EventBridge Scheduler にスケジュールを登録する 正解と解説 正解：D. Amazon EventBridge Scheduler にスケジュールを登録する EventBridge Scheduler は cron 式や rate 式による定期実行と単発実行を管理する仕組みなので、決まった時刻の起動はここで扱う。SQS はメッセージを保持して受け手に取り出させるキュー、SNS は購読者へ配信するパブサブ、API Gateway は API を公開して中継するサービスであり、いずれも時刻による起動を目的とした仕組みではない。
根拠：Amazon Web Services, Inc.「Amazon EventBridge ユーザーガイド」（2026年8月確認）
問39｜疎結合
注文の受付と、時間のかかる後続処理とを切り離し、受付側を待たせないようにしたい。適切なものはどれか。
受付側から後続処理を直接呼び出し、応答が返るまで待たせる 受付側と後続処理を1つのプログラムにまとめて順番に実行する 受付側がSQSのキューへ入れ、後続処理が取り出して進める 受付側の処理をEC2に載せ、後続処理も同じEC2で実行する 正解と解説 正解：C. 受付側がSQSのキューへ入れ、後続処理が取り出して進める SQS は分散したソフトウェアシステムやコンポーネントを統合して疎結合化する、セキュアで耐久性と可用性に優れたホスト型のキューサービスである。受付側はメッセージをキューへ入れた時点で応答でき、後続処理は自分の速度で取り出して進められるため、片方の遅れがもう片方を止めにくい。直接呼び出す構成や1本にまとめる構成では、後続処理の遅れがそのまま受付側の待ち時間になる。
根拠：Amazon Web Services, Inc.「Amazon Simple Queue Service デベロッパーガイド」（2026年8月確認）
問40｜配信の選択
1件の在庫更新を、集計用と通知用と監査用の3つの処理へ同時に届けたい。適切なものはどれか。
1本のSQSキューを作り、3つの処理が同じキューから取り出す 3本のSQSキューを作り、更新の発生元が順に3回ずつ送信する 1本のSQSキューを作り、取り出した処理が残り2つへ転送する 1本のSNSトピックに3本のSQSキューを購読させて配信する 正解と解説 正解：D. 1本のSNSトピックに3本のSQSキューを購読させて配信する SNS はトピックへ送ったメッセージを複数のサブスクライバーへ同時にプッシュ配信し、サブスクライバーとして SQS キューを指定できるため、1件の出来事を3つの処理へ配るには SNS トピックと複数の SQS キューによるファンアウトパターンを使う。1本のキューを3つの処理が共有すると、通常はどれか1つが取り出した時点で残りは受け取れない。発生元が3回送る構成や、受け取った処理が転送する構成は、宛先が増えるたびに送る側を直すことになり疎結合にならない。
根拠：Amazon Web Services, Inc.「Amazon Simple Notification Service デベロッパーガイド」（2026年8月確認）
演習：この章の問題を解く ランダム出題の演習ツールです（JavaScript が有効な場合に動きます）。上の「確認問題」はそのままでもすべて読めます。
← 前の章：クラウドの考え方と責任分界 次の章：ネットワーク・運用・料金 → ※ 解説は学習用の情報提供です。最新の出題範囲・制度は必ず公式発表をご確認ください。