Developer Blog

2026年10月15日

【AWS SAA備忘録】サービス名じゃないのに意味があやふやなIT用語まとめ

Written by

はじめに

SAAの問題文は、サービス名よりも「一般的なIT用語」の理解で正解が決まることが多いです。「低レイテンシー」「インバウンドトラフィック」「疎結合」などを、前後の文脈でなんとなく読んでいた自分への備忘録として、意味とSAAでの使われ方をセットでまとめます。

各用語は「ひとことで言うと」「SAAでの出方」「関連サービス」の3点で整理しています。

性能・速度系の用語

「速い」にも種類があります。レイテンシーは1回の応答の待ち時間、スループットは単位時間あたりの処理量、と分けて覚えるのがコツです。

用語ひとことで言うとSAAでの出方関連サービス
レイテンシー（Latency）リクエストしてから応答が返るまでの待ち時間。小さいほど良い「低レイテンシーでユーザーに配信」「ミリ秒未満のレイテンシー」CloudFront、ElastiCache、DynamoDB DAX、Global Accelerator
スループット（Throughput）一定時間に処理・転送できるデータ量「高スループットが必要なワークロード」EBS（st1）、FSx for Lustre、Kinesis
帯域幅（Bandwidth）通信路の太さ。一度に流せるデータ量の上限「帯域幅が限られているため転送に数週間かかる」Snowball、Direct Connect
IOPSストレージが1秒間にこなせる読み書き回数「高IOPSが必要なデータベース」EBS（io1/io2、gp3）
キャッシュよく使うデータを手前に置いて再利用する仕組み「データベースの読み取り負荷を軽減」ElastiCache、CloudFront、DAX
ボトルネック全体の性能を落としている一番遅い箇所「パフォーマンスのボトルネックを解消」原因に応じて変わる
リアルタイム / ニアリアルタイム即時に処理 / ほぼ即時（数秒〜数分の遅れは許容）「ニアリアルタイムで分析」Kinesis Data Streams / Amazon Data Firehose

通信・ネットワーク系の用語

インバウンドは「外から中へ入ってくる」、アウトバウンドは「中から外へ出ていく」通信です。セキュリティグループの設定やデータ転送料金の問題で頻出します。

用語ひとことで言うとSAAでの出方関連サービス
インバウンド（Inbound）外部からAWS環境・サーバーへ入ってくる通信「ポート443のインバウンドトラフィックを許可」セキュリティグループ、ネットワークACL
アウトバウンド（Outbound）AWS環境・サーバーから外部へ出ていく通信「プライベートサブネットからのアウトバウンド通信」NATゲートウェイ、データ転送料金
トラフィック（Traffic）ネットワーク上を流れる通信（データ）の量や流れそのもの「トラフィックが急増する」「トラフィックを分散」ELB、Route 53、CloudFront
エンドポイント（Endpoint）サービスへアクセスするための接続先（入口）「インターネットを経由せずS3にアクセス」VPCエンドポイント（ゲートウェイ型／インターフェイス型）
ステートフル / ステートレス（通信）戻りの通信を自動で許可する / 往復それぞれ許可が必要セキュリティグループとNACLの違いSG＝ステートフル、NACL＝ステートレス
オリジン（Origin）CDNがコンテンツを取りに行く元のサーバー「オリジンへの負荷を軽減」CloudFront＋S3、ALB
エッジロケーションユーザーの近くに置かれたAWSの配信拠点「世界中のユーザーに低レイテンシーで配信」CloudFront、Global Accelerator
パブリック / プライベートサブネットインターネットと直接通信できる / できないネットワーク区画「DBはプライベートサブネットに配置」VPC、インターネットゲートウェイ
オンプレミス接続（ハイブリッド）自社データセンターとAWSをつなぐこと「一貫したネットワーク性能」「専用線」Direct Connect、Site-to-Site VPN

可用性・耐障害性系の用語

「止まらない」「壊れても戻せる」を表す用語群です。SAAの「回復性の高いアーキテクチャ」分野の中心で、マルチAZとバックアップの選択肢を見分ける鍵になります。

用語ひとことで言うとSAAでの出方関連サービス
可用性（Availability）システムが使える状態を保っている割合「高可用性を実現する」マルチAZ、ELB、Auto Scaling
耐障害性（Fault Tolerance）一部が壊れてもサービスを止めずに動き続ける性質「AZ障害に耐えられる構成」マルチAZ配置、S3
冗長化同じ役割のものを複数用意して、1つ壊れても困らないようにすること「単一障害点を排除」複数AZへのEC2配置
単一障害点（SPOF）そこが壊れると全体が止まる1か所「SPOFを取り除く」1台構成のEC2・NATゲートウェイなど
フェイルオーバー障害時に予備（スタンバイ）へ自動で切り替えること「自動フェイルオーバー」RDS マルチAZ、Route 53 フェイルオーバールーティング
災害対策（DR）リージョン規模の障害から復旧するための備え「別リージョンで復旧」バックアップ＆リストア、パイロットライト、ウォームスタンバイ、マルチサイト
RPO（目標復旧時点）どの時点までのデータを取り戻せればよいか（失ってよいデータ量）「RPOは15分」スナップショット頻度、レプリケーション
RTO（目標復旧時間）障害からどれくらいの時間で復旧すべきか「RTOは1時間以内」DR戦略の選択
耐久性（Durability）保存したデータが失われない確率「イレブンナイン（99.999999999%）」S3
レプリケーションデータを別の場所へ複製すること「クロスリージョンレプリケーション」S3 CRR、RDS リードレプリカ、Aurora Global Database

ポイント: 可用性は「使えるか」、耐久性は「データが消えないか」です。名前が似ていて混同しやすいので注意。

拡張性・構成系の用語

アウトは「台数を増やす」、アップは「1台を強くする」です。SAAでは基本的にスケールアウト＋疎結合が「正解寄り」の選択肢になります。

用語ひとことで言うとSAAでの出方関連サービス
スケーラビリティ（拡張性）負荷の増減に合わせて処理能力を変えられる性質「スケーラブルなアーキテクチャ」Auto Scaling、サーバーレス全般
スケールアウト / スケールインサーバーの台数を増やす / 減らす（水平スケーリング）「需要に応じて自動でスケール」EC2 Auto Scaling
スケールアップ / スケールダウン1台の性能（CPU・メモリ）を上げる / 下げる（垂直スケーリング）「インスタンスタイプを変更」EC2、RDSのインスタンスサイズ変更
弾力性（Elasticity）需要に合わせて自動で伸び縮みすること「需要の変動に対応」Auto Scaling、DynamoDB オンデマンド
疎結合（Loose Coupling）コンポーネント同士の依存を弱め、片方が止まっても影響しにくくすること「アプリケーションを疎結合にする」SQS、SNS、EventBridge
密結合コンポーネント同士が直接強く依存している状態（疎結合の反対）問題文の「現状の課題」として登場―
ステートレスサーバーがセッション情報などの状態を持たないこと「セッション情報を外部に保存」ElastiCache、DynamoDB にセッションを保存
デカップリング密結合な構成を疎結合に切り離すこと「注文処理をデカップリング」SQS
サーバーレスサーバーの管理（OS・台数）を意識せずに使える形態「運用オーバーヘッドを最小限に」Lambda、Fargate、DynamoDB、API Gateway
マネージドサービス運用・保守の多くをAWSが代行してくれるサービス「管理の手間を減らす」RDS、Aurora、ECS on Fargate
マイクロサービス機能ごとに小さなサービスへ分割して開発・運用する設計「モノリシックなアプリを分割」ECS、EKS、Lambda、API Gateway

ポイント: 問題文の「運用上のオーバーヘッドが最も少ない」は、マネージドやサーバーレスを選べという強いヒントです。

ビジネス・シナリオ系の用語

問題文の冒頭に出てくる「どんな会社の、どんなシステムか」を表す言葉です。ここから要件（急なアクセス増、データの重要度など）を読み取ります。

用語ひとことで言うとSAAでの出方・読み取るべき要件
Eコマース（EC）インターネット上で商品を売買するサービス（通販サイト）セール時のトラフィック急増、注文データの確実な処理、決済の可用性
オンプレミス自社で用意・管理するサーバーやデータセンター「オンプレミスからAWSへ移行」→ DMS、DataSync、Snowball、Direct Connect
ワークロードシステム上で動かす処理やアプリケーションのまとまり「バッチ処理のワークロード」「中断可能なワークロード」→ スポットインスタンス
ミッションクリティカル止まると業務に重大な影響が出る重要なシステム高可用性・マルチAZ・DRが必要
バッチ処理データをまとめて一括処理すること（夜間集計など）AWS Batch、スポットインスタンス、Step Functions
ストリーミングデータ途切れなく流れ続けるデータ（IoT、クリックログなど）Kinesis、MSK
コンプライアンス法令や業界規制、社内ルールを守ること暗号化（KMS）、監査ログ（CloudTrail）、データの保管場所の制限
ガバナンス組織全体でルールを決め、統制・管理することOrganizations、SCP、Control Tower、Config
コスト効率 / 費用対効果必要な要件を最も安く満たすこと「最も費用対効果の高い」→ S3ストレージクラス、Savings Plans、スポット
リフト＆シフトアプリをほぼそのままの形でおクラウドへ移すこと「最小限の変更で移行」→ EC2へそのまま移行、Application Migration Service
静的コンテンツ / 動的コンテンツ誰が見ても同じ画像・HTML / 利用者ごとに変わる内容静的はS3＋CloudFront、動的はEC2・Lambdaなど
アクセスパターンデータがどの頻度・どの方法で読み書きされるか「アクセス頻度が予測できない」→ S3 Intelligent-Tiering

問題文によく出るキーワード→サービス対応表

問題文のフレーズを見たら、まず思い浮かべたい候補です。最終判断は他の条件（コスト、運用負荷）と合わせて行います。

問題文のフレーズまず疑う候補
世界中のユーザーに低レイテンシーで配信CloudFront、Global Accelerator
読み取り負荷が高い / 同じクエリが繰り返されるElastiCache、RDS リードレプリカ、DAX
トラフィックの急増・予測できない変動Auto Scaling、SQS でバッファリング、サーバーレス
コンポーネントを疎結合にするSQS、SNS、EventBridge
運用オーバーヘッドを最小限にマネージドサービス、サーバーレス
インターネットを経由せずにアクセスVPCエンドポイント、PrivateLink
プライベートサブネットからインターネットへ出るNATゲートウェイ
一貫したネットワーク性能・専用線Direct Connect
大量データを短期間で移行（帯域不足）Snowball
自動フェイルオーバー（DB）RDS マルチAZ、Aurora
中断しても問題ないワークロードを安くスポットインスタンス
アクセス頻度が不明・変化するS3 Intelligent-Tiering
リアルタイムのストリーミング処理Kinesis Data Streams

まとめ

SAAの問題文は「シナリオ（Eコマース、オンプレミス）→ 課題（レイテンシー、トラフィック急増、密結合）→ 制約（コスト、運用負荷）」の順に読むと、用語がそのまま選択肢の絞り込みに使えます。

対になる用語（インバウンド/アウトバウンド、スケールアウト/アップ、RPO/RTO、可用性/耐久性）はセットで覚えると、なんとなく読みから卒業できます。

ここまで読んでいただき、ありがとうございます。もしこの記事の技術や考え方に少しでも興味を持っていただけたら、ネクストのエンジニアと気軽に話してみませんか。

  • 選考ではありません
  • 履歴書不要
  • 技術の話が中心
  • 所要時間30分程度
  • オンラインOK

エンジニアと話してみる

関連リンク

AI・クラウド・データ分析のご相談はネクスト株式会社までお問い合わせください。
アバター画像

お会いできるのを楽しみにしています

カジュアル面談に申し込むエントリーする