情シスに異動してきた当初、先輩からそう聞かれて私は固まってしまいました。「Linuxって一種類じゃないの？」というのが正直な感想でした。

サーバーの調達や構築をベンダーに依頼するとき、「OSは何にしますか？」と聞かれて「えっと……Linuxで」と答えたら「どのディストリビューションですか？」と返されて頭が真っ白になった、という経験はありませんか？

Linuxの種類が多い理由を知らないと、サーバー選定のたびに迷い続けることになります。

この記事では、なぜLinuxにこんなに種類があるのかを、OSの歴史をたどりながら情シス目線でわかりやすく整理します。難しい技術の話ではなく、「なぜそうなったのか」という背景を理解することで、現場での判断がぐっと楽になりますよ。

なぜLinuxは種類が多いのか？問題の本質

多くの情シス担当者がやってしまいがちなのが、「Ubuntu vs CentOS、どっちが優れているか」という比較から入ることです。しかしこれは本質ではありません。

大切なのは「なぜこんなに種類が生まれたのか」という歴史的な背景を理解することです。背景がわかれば、自然と「この用途にはこのディストリビューション」という判断ができるようになります。

種類が多い理由は主に3つあります。

原因① Linuxがオープンソースだから

Linuxは誰でも自由に使え、改造して再配布できるオープンソースのOSです。レシピを公開している料理のようなもので、誰でもそのレシピをベースに自分流にアレンジして配布できます。その結果、世界中の開発者やコミュニティが独自のLinuxを作り始めました。

原因② 用途・目的に合わせて派生が進んだから

「サーバー用途に特化したもの」「デスクトップ向けに使いやすくしたもの」「組み込み機器向けに軽量化したもの」など、用途に合わせて派生バージョンが生まれました。同じ「自動車」でも、トラック・バス・スポーツカーと種類があるのと同じ発想です。

原因③ 企業・コミュニティがそれぞれ独自に発展させたから

Red Hat（レッドハット）やCanonical（カノニカル）のような企業、または世界中の有志コミュニティが、それぞれの判断で機能を追加・改良してきました。その結果、同じLinuxをベースにしながらも、性格の異なるディストリビューションが数多く生まれています。

「Linuxが多い」のは混乱の証拠ではなく、自由と多様性の産物なのです。

LinuxのルーツをたどるとOSの歴史が見えてくる

Linuxの多様性を理解するには、その生い立ちを知ることが一番の近道です。歴史の教科書のように難しくはないので、気軽に読み進めてください。

UNIX（1969年）：すべての祖先

現代のOSのほぼすべての祖先が、1969年にAT&Tベル研究所で生まれた「UNIX（ユニックス）」です。「複数の人が同時に使える」「プログラムを部品のように組み合わせて使える」という革新的な設計で、研究機関や大学に広まりました。

ただしUNIXは有償で、使うには高いライセンス料が必要でした。「会社の金庫に鍵がかかっていて、お金を払わないと中を見られない」状態です。

GNU計画（1983年）：「誰でも使えるOSを作ろう」

1983年、リチャード・ストールマンというプログラマーが「GNU（グヌー）計画」を立ち上げます。「誰でも自由に使えるUNIX互換のOSを作る」という壮大なプロジェクトです。

GNU計画によって、テキストエディタやコンパイラなど多くのソフトウェアが無料で公開されました。しかし肝心の「OSの中核部分（カーネル）」だけが完成しませんでした。

Linuxカーネル誕生（1991年）：フィンランドの学生が世界を変えた

1991年、フィンランドのヘルシンキ大学の学生だったリーナス・トーバルズが、自作のカーネルをインターネットに公開します。「趣味で作っているOSがあるんだけど、使ってみる人いる？」という軽いメッセージとともに。

このカーネルがGNUのソフトウェアと組み合わさることで、「GNU/Linux」という完全な無償OSが生まれました。これが現在私たちが「Linux」と呼んでいるものの誕生です。

1人の学生の「趣味」が、現在の世界のサーバーの90%以上を支えるOSになるとは、誰も予想していませんでした。

ディストリビューションの誕生：Linuxを「使いやすく」パッケージング

Linuxカーネルだけでは、普通の人には使いにくいものでした。そこで「カーネル＋各種ソフトウェア＋インストーラー」をセットにしてパッケージ化したものが登場します。これが「ディストリビューション（distribution＝配布物）」です。

レストランで言えば、「食材（カーネル）」だけでなく「調理済みの料理としてテーブルに出す（ディストリビューション）」イメージです。

主要ディストリビューションの分岐

現在のLinuxは大きく2つの系統に分かれています。

Debian系：Debian Linuxを祖先に持つグループ。Ubuntuが代表格で、個人・開発者・クラウド環境で広く使われています。パッケージ管理に「apt」コマンドを使います。

Red Hat系：Red Hat Linuxを祖先に持つグループ。RHEL（Red Hat Enterprise Linux）・CentOS・Rocky Linuxが代表格で、企業のサーバー環境で長く使われてきました。パッケージ管理に「yum」または「dnf」コマンドを使います。

情シス担当者は結局どれを使えばいいのか

歴史がわかったところで、実務的な話をします。情シスの現場では、用途に応じて以下のように選ぶのが定石です。

迷ったら「AWSならAmazon Linux、それ以外はUbuntu LTS」と覚えておけば、情シスの現場でまず困りません。

今日からできる具体的なアクション

1. WSL2でUbuntuを触ってみる：Windows 11なら「wsl –install」コマンド1つでUbuntuが使えます。まずlsコマンドとcdコマンドだけ覚えれば十分です
2. AWSの無料枠でEC2を起動してみる：Amazon Linux 2023のインスタンスを1台立ち上げてSSH接続するだけで、実感が大きく変わります
3. ディストリビューションの系統図を1枚印刷する：「Ubuntu＝Debian系」「CentOS＝Red Hat系」という関係図を手元に置くだけで、会議中に迷わなくなります

Linuxは「難しいOS」ではなく、「歴史ある自由なOS」です。背景を知るだけで一気に親しみやすくなります。

まとめ

Linuxの種類が多い理由を、OSの歴史から整理しました。

• Linuxはオープンソースのため、誰でも自由に改造・配布できる
• 1969年のUNIX → 1983年のGNU計画 → 1991年のLinuxカーネル誕生という流れ
• 現在はDebian系（Ubuntu）とRed Hat系（RHEL/Rocky Linux）の2大系統が主流
• 情シスの現場では「AWSはAmazon Linux、それ以外はUbuntu LTS」が基本の選び方

「種類が多くて何が何だかわからない」というモヤモヤが、少し晴れたでしょうか。次のステップとして、実際にWSL2やEC2でLinuxを触ってみることをおすすめします。

関連記事：情シスがAWSを学ぶべき理由はこちら

関連記事：LambdaでEC2・RDS夜間停止を自動化する方法はこちら

私自身、AWS Cloud Practitioner（CLF）を取得してSAAの勉強を始めたとき、最初の壁が「用語の多さ」でした。VPC、サブネット、IAM、Route 53……。略語とカタカナの嵐で、正直最初の1週間は参考書を眺めているだけで終わった、なんて経験があります。

情シスの現場でも似たようなことがよくあります。ベンダーとの打ち合わせで「ELBをフロントに置いて、バックエンドはECSで」なんて言われても、初めて聞く人にはまったく意味がわかりません。

用語を知らないと、会議でうなずくだけの人になってしまいます。

この記事では、AWS SAA試験に頻出する用語を30個、情シス目線でわかりやすく解説します。難しい言葉は日常のたとえ話に置き換えながら説明しますので、IT初心者の方でも安心して読み進めてください。

なぜAWSの用語はわかりにくいのか？

AWSの用語が難しく感じる理由は主に3つあります。

原因① カタカナが多すぎる

「インスタンス」「スナップショット」「レプリケーション」……。日本語に訳すと意味が伝わるのに、カタカナのまま使われるため余計に難しく感じます。

原因② サービス名が覚えにくい

「Amazon Elastic Compute Cloud（EC2）」のように、正式名称が長すぎて略称で呼ばれることがほとんどです。略称だけ見ても何のサービスかわかりにくいのが悩みどころです。

原因③ 似たようなサービスが多い

RDSとAurora、SQSとSNS、CloudWatchとCloudTrail……。名前が似ているうえに用途も近いため、混乱しやすいのです。

「なんとなく知っている」ではなく「たとえ話で説明できる」レベルを目指しましょう。

たとえ話で覚えるのが最強の方法

用語を丸暗記しても、試験で問われる「この場合どのサービスを使うべきか」という応用問題には対応できません。大切なのは「このサービスは何をするものか」をイメージで理解することです。たとえば、S3は「クラウド上の巨大な引き出し」、EC2は「クラウド上のパソコン」と覚えると、応用が利くようになります。

【ネットワーク】7つの頻出用語

① VPC（Amazon Virtual Private Cloud）

AWSクラウド内に作る「自分専用のプライベートネットワーク」です。会社の社内ネットワークをクラウド上に再現したものとイメージしてください。

② サブネット（Subnet）

VPCをさらに小さく区切ったネットワークの区画です。「社内ネットワークの中にある、部署ごとのフロア」のイメージです。外部公開の「パブリックサブネット」と社内専用の「プライベートサブネット」があります。

③ Route 53

AWSのDNSサービスです。「salaryman-senki.com」と入力したとき、どのサーバーに案内するかを管理する「電話帳」のようなサービスです。

④ CloudFront

世界中にコンテンツを高速配信するCDNです。「世界各地に荷物の中継倉庫を置いて、最寄りの倉庫から配送する」イメージです。

⑤ Direct Connect

社内ネットワークとAWSを専用線でつなぐサービスです。インターネット経由ではなく、専用の高速道路を使うイメージです。

⑥ NAT Gateway

プライベートサブネット内のサーバーがインターネットに出るための「出口専用の関所」です。外からは入れないが、中からは出られる仕組みです。

⑦ セキュリティグループ（Security Group）

EC2などへの通信を制御する「個別のファイアウォール」です。「このIPからのアクセスだけ許可する」といったルールを設定します。

【ストレージ】6つの頻出用語

⑧ S3（Amazon Simple Storage Service）

AWSの代表的なオブジェクトストレージです。「容量無制限のクラウド上の引き出し」と覚えてください。

⑨ EBS（Amazon Elastic Block Store）

EC2インスタンスに取り付けるストレージです。「パソコンのハードディスク」のようなものです。

⑩ EFS（Amazon Elastic File System）

複数のEC2インスタンスから同時にアクセスできる共有ファイルシステムです。「社内の共有ドライブ」のイメージです。

⑪ S3 Glacier

アクセス頻度の低いデータの長期保存に向いた低コストストレージです。「めったに開けない倉庫の奥の棚」のイメージです。

⑫ Storage Gateway

社内システムとAWSのストレージをつなぐ橋渡し役のサービスです。

⑬ AWS Backup

複数のAWSサービスのバックアップを一元管理するサービスです。

【コンピューティング】6つの頻出用語

⑭ EC2（Amazon Elastic Compute Cloud）

AWSの仮想サーバーです。「クラウド上のパソコン」と覚えてください。必要なときだけ起動し、使った分だけ料金が発生します。

⑮ Lambda

サーバーを管理せずにプログラムを実行できるサービスです。「イベントが発生したときだけ処理が動く自販機」のイメージです。

⑯ Auto Scaling

アクセス量に応じてEC2の台数を自動で増減するサービスです。「ランチタイムだけアルバイトを増やして、閑散時は減らす」シフト管理のようなイメージです。

⑰ ECS（Amazon Elastic Container Service）

Dockerコンテナを管理するサービスです。アプリを軽量な「コンテナ」という箱に入れて効率よく動かす仕組みです。

⑱ Elastic Beanstalk

アプリのデプロイを自動化するサービスです。「コードを渡すと、あとは全部やっておいてくれる便利屋さん」のイメージです。

⑲ AMI（Amazon Machine Image）

EC2インスタンスの設定を丸ごとコピーしたテンプレートです。「PCの環境をそのままコピーして量産する」イメージです。

【セキュリティ】6つの頻出用語

⑳ IAM（AWS Identity and Access Management）

AWSのユーザーや権限を管理するサービスです。「誰が・何を・どこまでできるか」を細かく設定できます。情シスで言うActive Directoryに近い役割です。

㉑ WAF（AWS Web Application Firewall）

Webアプリへの不正アクセスを遮断するファイアウォールです。SQLインジェクションやXSSなどの攻撃を検知・防御します。

㉒ KMS（AWS Key Management Service）

データの暗号化に使う「鍵」を管理するサービスです。「金庫の鍵を安全に保管してくれる鍵専門業者」のようなイメージです。

㉓ Shield

DDoS攻撃からAWSリソースを守るサービスです。標準版は無料で自動的に有効になっています。

㉔ Cognito

アプリのユーザー認証を管理するサービスです。「ログイン機能をゼロから作らなくても安全なログイン画面ができる」サービスです。

㉕ CloudTrail

AWSアカウント内の操作履歴を記録するサービスです。「誰がいつ何をしたか」を記録する監査ログです。

【データベース】5つの頻出用語

㉖ RDS（Amazon Relational Database Service）

MySQLやPostgreSQLなどのリレーショナルデータベースをマネージドで使えるサービスです。「データベースの管理をAWSに丸投げできる」サービスです。

㉗ Aurora

AWSが独自開発した高性能データベースです。RDSより高速・高可用で、「RDSの上位版」とイメージしてください。

㉘ DynamoDB

AWSのNoSQLデータベースです。大量のデータを高速処理するのが得意です。「ExcelではなくJSONのような柔軟な形式でデータを保存する」イメージです。

㉙ ElastiCache

データをメモリ上に一時保存してRDSへの負荷を減らすキャッシュサービスです。「よく使うデータを手元のメモに控えておいて、いちいち引き出しを開けなくて済む」仕組みです。

㉚ Redshift

大量データの分析に特化したデータウェアハウスです。「業務データを分析して経営レポートを作るときに使う巨大な分析エンジン」のイメージです。

今日からできる具体的なアクション

1. 用語を声に出して読む：黙読より音読の方が記憶に残ります
2. たとえ話を自分の言葉で言い換える：人に説明できるレベルまで理解を深める
3. 問題集で実践練習する：試験形式の問題を解いて定着させる
4. わからない用語が出たらすぐ調べてメモ：自分だけの用語集を作る

用語を覚えることはゴールではなく、スタートラインです。

私自身、この30用語を押さえてから問題集の正解率がぐっと上がりました。まずは声に出して読むところから始めてみてください。

まとめ

今回はAWS SAA頻出用語30選を、情シス目線でわかりやすく解説しました。用語は「たとえ話で理解する」ことで、試験でも実務でも応用できるようになります。ぜひこの記事をブックマークして、勉強の合間に見返してみてください。

関連記事：Route 53 Resolverの設定方法はこちら

関連記事：情シスがAWSを学ぶべき理由はこちら

本番環境：月額 約3万円
検証環境：月額 約4万5千円

……え？逆じゃない？

私が所属する情シス部門では、昨年度から業務システムをオンプレミス（社内サーバー）からAWSへ移行しました。本番環境と検証環境をそれぞれ構築して、「さあ運用開始！」となったタイミングでこの事態に気づいたのです。

「AWSはコスト削減になる」と社内で説明して移行を進めた手前、このままでは立場がありません。原因を徹底的に調べ、3つの対策を打った結果、検証環境のコストを本番環境以下に抑えることができました。同じような状況に悩んでいる情シス担当者の方に向けて、実体験をそのままお伝えします。

なぜ検証環境がコスト過多になりやすいのか

検証環境は「後回し」にされがちな、コストの伏魔殿です。

本番環境は障害が起きたら大変なので、みんな真剣に構成を考えます。冗長化の必要性・インスタンスのスペック・バックアップ……細かく精査します。ところが検証環境はどうでしょう？「本番と同じ構成で作っておけばいいか」という空気が漂いがちです。その結果、本番環境と同等のスペック・構成がそのままコピーされ、誰も最適化しないまま動き続けることになります。

AWS移行直後は特に要注意です。オンプレの感覚のまま「サーバーは常時稼働が当たり前」と思い込んでいると、AWSの従量課金の特性を活かせず、無駄なコストが積み上がっていきます。

私の検証環境が高くなった原因は3つだった

原因① EC2のインスタンスタイプが本番と同じだった

EC2（Amazon Elastic Compute Cloud）とは、AWSが提供する仮想サーバーのことです。私の環境では、本番・検証ともに m5.xlarge（vCPU 4個・メモリ16GB）を使っていました。本番環境ではこのスペックが必要ですが、検証環境でそこまでのパワーは必要ありません。スペックの選定は「本番の縮小版」ではなく、「検証に必要な最小限」で考えるべきでした。

原因② マルチAZ構成のまま使っていた

マルチAZ（Multi-AZ）とは、異なるデータセンターに同じシステムを冗長化して配置する構成です。本番環境では非常に重要な設定ですが、検証環境にここまでの可用性は必要ありません。にもかかわらず、RDS（AWSのデータベースサービス）でマルチAZ構成を有効にしたままでした。これだけでコストがほぼ2倍になります。本番と同じ「安心感」を検証環境にも求めてしまっていたのが原因でした。

原因③ 24時間365日、ずっと稼働していた

オンプレのサーバーは電源を入れたら基本的に動かし続けます。その感覚のままAWSを使っていたため、検証環境のEC2とRDSは土日も夜中も動き続けていました。1ヶ月720時間のうち業務時間外はおよそ500時間以上。全体の70%近くが「誰も使っていない稼働時間」になっていたのです。AWSの最大のメリットは「使った分だけ払う」こと。その利点をまったく活かせていませんでした。

実際にやった3つのコスト削減策

対策① EC2インスタンスタイプをダウンサイジング

m5.xlarge → t3.medium（vCPU 2個・メモリ4GB）に変更しました。t3シリーズは「バースト可能タイプ」と呼ばれ、普段は低スペックで動きつつ、負荷が高い瞬間だけCPUパワーを一時的に上げることができます。検証用途には十分な性能で、料金は約1/4程度になります。変更手順はEC2インスタンスを停止 → インスタンスタイプを変更 → 再起動の3ステップで完了します。「本番と同じスペックでないと不安」は思い込み。検証なら最小限で十分です。

対策② RDSのマルチAZ構成をシングルAZに変更

RDSの設定画面から「マルチAZ配置」を無効にするだけで完了です。この変更を行うと一時的にRDSが再起動するため、業務終了後に実施することをおすすめします。費用は変更直後から単純に半減します。冗長化は必要な場所にだけかける。検証環境は「止まっても困らない」が正解です。

対策③ EventBridge＋Lambdaで夜間・週末を自動停止

これが最もインパクトのある対策でした。Amazon EventBridgeでスケジュールを設定し、AWS Lambdaを使ってEC2とRDSを自動で起動・停止するようにしました。

これにより、稼働時間は月720時間 → 約220時間に削減。コストも約70%減を実現しました。

Cost Explorerで今すぐ確認できること

コスト削減の第一歩は「何にお金がかかっているか把握すること」です。AWSのCost Explorerを使えば、サービス別・リソース別にコストを可視化できます。

1. AWSマネジメントコンソールにログイン
2. 画面右上のアカウント名をクリック →「請求とコスト管理」を選択
3. 左メニューの「Cost Explorer」を開く
4. 「サービス別」でEC2・RDSの費用を確認
5. 「リソース別」に掘り下げて、どの環境が高いか特定する

「なんとなく高い」を「なぜ高いか」に変えるだけで、打ち手が見えてきます。

まとめ

AWSはオンプレと違い、「設定を見直すだけでコストが下がる」というのが大きな強みです。最初から完璧な構成を作るより、まず動かして改善していく。その繰り返しがAWSを使いこなす近道だと実感しました。もし「うちも検証環境のコストが妙に高い……」と感じている方がいれば、ぜひCost Explorerを開いてみてください。

関連記事：LambdaでEC2・RDS夜間停止自動化｜AWSコスト削減実装ガイド
関連記事：Aurora Serverlessで自動スケーリング｜予測不能な負荷への対応方法

こんな時、各EC2インスタンスについているEBS（Elastic Block Store）では、基本的に1対1の接続になるため、データの共有が困難です。

私は模擬試験で「何百ものEC2インスタンスから同時にアクセスでき、高い可用性を持つストレージは？」と問われ、「S3をマウントすればいいのかな？」と迷いました。しかし、POSIX準拠のファイルシステムとして標準的な操作ができ、自動でスケーリングしてくれる正解はAmazon EFS（Elastic File System）でした。

Amazon EFSが「共有ストレージ」に最適な理由

EFSは、ネットワーク経由で接続するマネージドなファイルシステム（NFS）です。

• 同時アクセス
  数千台のEC2インスタンスから同時にマウント（接続）して、同じファイルを読み書きできます。
• 高い可用性と耐久性
  データは複数のアベイラビリティゾーン（AZ）にまたがって保存されるため、1つのAZに障害が起きてもデータは守られ、アクセスも継続できます。
• 運用が楽
  容量を予め決める必要はありません。ファイルを追加すれば自動で増え、消せば減る。まさに「エアスティック（伸縮自在）」です。

【試験対策】EBS vs S3の使い分け

ここがSAA試験で最も重要です！要件にあわせて最適なストレージを選べるようになりましょう。

コストを抑える「ライフサイクル管理」

EFSには、コストを劇的に抑えるための「低頻度アクセス（IA）」ストレージクラスがあります。
「30日間アクセスがないファイルは、自動的に安価なIAクラスに移動する」といった設定が可能です。前回のS3ライフサイクルポリシーと似た考え方ですね！

試験で役立つ！キーワード判別法

ストレージ選定の問題で、以下の言葉があればAmazon EFS が正解です。

• 「複数のインスタンスから共有アクセスが必要」
• 「POSIX準拠のファイル・システム（NFS v4）」
• 「高可用性と耐久性を備えた共有ストレージ」
• 「オンプレミスのサーバーからもマウントしたい」

今回の学び：攻略の格言

「みんなで使う（共有する）ならEFS。AZをまたいでデータを守り、容量はAWSにお任せで自動伸縮！」

あとがき：一歩ずつ、合格へ

最後まで読んでいただき、ありがとうございました！

「共有ストレージ」と聞くと、昔は自分たちで専用のサーバー（NAS）を立てて苦労して管理していましたが、AWSなら数クリックで高可用な環境が手に入る。本当にいい時代になったなと感じます。

EFSも使いこなせば、オートスケーリングでサーバーがどんどん増減するような柔軟なWebシステムも、自身を持って設計できるようになりますね。

それでは、次回の記事でお会いしましょう！

データベースのパスワードや外部サービスのAPIキー、どう管理していますか？

「とりあえずコードに直書き（ハードコード）して、GitHubに上げないように気をつける」⋯⋯これ、実は非常に危険な運用です。もし設定ファイルが漏洩したら、全てのデータが危険にさらされます。

私は模擬試験で「DBの認証情報を安全に管理し、定期的に変更（ローテーション）するには？」という問いに出会い、正解がAWS Secrets Managerであることを学びました。しかも、これを使うと「パスワードを自分で変える手間」すらなくなるんです！

Secrets Managerができる「3つのすごいこと」

Secrets Managerは、単なる「パスワードの保管庫」ではありません。

• ハードコードの排除
  アプリケーションはコードの中にパスワードを書く代わりに、Secrets Managerに「パスワードを教えて」とリクエストを送ります。
• 自動ローテーション（定期更新）
  「30日ごとにパスワードを自動でランダムなものに変更する」といった設定が可能です。これが試験で最も狙われるポイントです！
• プログラムからの簡単呼び出し
  AWS SDKを使えば、数行のコードで安全に機密情報を取り出せます。

【試験対策】Secrets Manager vs Parameter Strore

AWSには「SSM Parameter Store」という似たサービスがあります。どちらを選ぶべきかの判断基準を整理しましょう。

「パスワードを定期的に変えたい！」という要件があれば、100% Secrets Managerが正解です。

自動ローテーションの仕組み

Secrets Managerがパスワードを更新する際、裏側ではAWS Lamdaが動いています。

1.Secrets ManagerがLamdaを起動。
2.Lamdaがデータベースのパスワードを新しいものに変更。
3.Secrets Manager内の値を更新。

この連携により、人間が一切介入することなく、常に「新鮮で安全なパスワード」を使い続けることができます。

試験で役立つ！キーワード判別法

セキュリティの問題で、以下の言葉があればAWS Secrets Managerが正解です。

• 「機密情報の自動ローテーション（更新）」
• 「ハードコードされた認証情報の削除」
• 「RDSのパスワードを安全に管理」
• 「プログラムからAPI経由でパスワードを取得」

今回の学び：攻略の格言

「秘密は覚えるな、Secrets Managerに預けろ。Lamdaが勝手にパスワードを磨き（更新）、漏洩リスクを最小化する！」

あとがき：一歩ずつ、合格へ

最後まで読んでいただき、ありがとうございました！

「パスワードを定期的に変える」というのは、理屈では分かっていても、手動でやるのは面倒だし事故の元ですよね。それをマネージドサービスで自動化できるのがAWSの良さです。

セキュリティを固めることは、自分たちのシステムだけでなく、ユーザーの信頼を守ること。この一歩が、プロのアーキテクトへの大きな一歩になります。

それでは、次回の記事でお会いしましょう！

私は最初、「読み取りが遅いなら、RDSのリードレプリカを増やせばいいんじゃない？」と考えていました。しかし、試験の要件は「ミリ秒単位の超低遅延」と「極度のコスト効率」。

これらを満たすための、RDSとElastiCacheの「黄金コンビ」について解説します！

データベースの前に「高速なメモ」を置く

ElastiCacheは、ハードディスクではなく「メモリ（RAM）」の上にデータを保存するデータベースです。

• 驚異のスピード
  ミリ秒（1000分の1秒）ではなく、マイクロ秒（100万分の1秒）単位の応答時間を実現します。
• RDSを休ませる
  一度DBから読み取ったデータをElastiCacheにキャッシュしておけば、次に同じリクエストが来た時はDBまで行かずに済みます。これで、高価なDBインスタンスの負荷を劇的に減らせます。

試験で狙われる「Redis」と「Memcached」の選び方

ElastiCacheには2つのエンジンがありますが、SAA試験で問われるのは「どっちを使うべきか」の判断です。

①Redis

• 多機能
  データのバックアップ（スナップショット）や、レプリケーションによる高可用性に対応。
• 高度なデータ構造
  リストやセットなど、複雑なデータを扱えます。
• 用途
  ランキング機能、セッション管理、高可用性が必要なシステム。

②Memcached

• シンプル
  機能は少ないですが、その分極めてシンプルで高速。
• マルチスレッド
  複数のCPUコアを効率よく使えます。
• 用途
  構造が単純なキャッシュ。

【比較表】RDS vs ElastiCache

試験で役立つ！キーワード判別法

パフォーマンス最適化の問題で、以下の言葉があればAmazon ElastiCacheが正解の鍵です！

• 「ミリ秒未満（Sub-millisecond）のレイテンシー」
• 「データベースの読み取り負荷を軽減」
• 「インメモリデータストア」
• 「リードレプリカよりも高いパフォーマンス」

今回の学び：攻略の格言

「重いDB、叩く前（読み取る前）にキャッシュを見ろ！ミリ秒未満の壁を超えるならElastiCacheの一択だ！」

あとがき：一歩ずつ、合格へ

最後まで読んでいただき、ありがとうございました。

今回の構成は、動画配信サービスなど、現代のWebアプリケーションでは欠かせないアーキテクチャです。RDSだけで無理に頑張るのではなく、キャッシュを組み合わせて「適材適所」で負荷を逃がす。この考え方ができるようになると、インフラ設計がぐっと楽しくなりますね。

「速さは正義」。ユーザー体験を向上させるための強力な武器を、また一つ手に入れました。

それでは、次回の記事でお会いしましょう！

そんな時、一般的なリレーショナルデータベース（RDS）だと、データ量が増えるにつれて検索スピードが落ちてしまい、限界を感じることがあります。

私は模擬試験で「何百万ものレコードに対する全文検索を、低遅延で実現するには？」と問われ、「RDSのインデックスを頑張ればいいのかな？」と悩みましたが、正解はもっと「検索」に特化した専用サービス、Amazon OpenSearch Serviceを使うことでした。

なぜ「検索」にはOpenSearchなのか？

OpenSearch Serviceは、大量のデータに対して「全文検索」や「リアルタイム分析」を行うためのマネージドサービスです。

• 全文検索が得意
  曖昧なキーワード検索や、複雑な条件での絞り込みを驚くほど早く処理できます。
• 可視化ツール「OpenSearch Dashboards」
  検索結果をグラフやチャートにまとめ、ダッシュボードで一目で状況を把握できます（ログ監視などに最適！）。
• スケーラビリティ
  データが増えても、クラスターのサイズを調整することで、常に安定したパフォーマンスを維持できます。

実務・試験でよく出る「データ投入」の黄金パターン

OpenSearchにどうやってデータを入れるか？ここがSAA試験の頻出ポイントです。

• Amazon Kinesis Data Firehoseとの連携
  ストリーミングデータ（ログやクリックストリームなど）を、Firehose経由でほぼリアルタイムにOpenSearchへ流し込む構成が鉄板です。
• Amazon S3からの取り込み
  S3に保存された過去のログを、Lamdaなどを使ってOpenSearchへインデックス（登録）する方法もよく使われます。

【比較表】RDS vs OpenSearch Service

「いつものDB」と「検索エンジン」の使い分けを整理しましょう。

試験で役立つ！キーワード判別法

問題文に以下のキーワードがあれば、Amazon OpenSearch Serviceが正解の最有力候補です。

• 「全文検索（Full-text search」
• 「低遅延な検索レスポンス」
• 「ログの可視化とリアルタイム分析」
• 「何百万ものドキュメントを迅速に検索」

今回の学び：攻略の格言

「探すのが仕事なら、専用の道具を使え。RDSで粘らず、Open Searchで爆速検索を実現しよう！」

あとがき：一歩ずつ、合格へ

最後まで読んでいただき、ありがとうございました！

「適材適所」という言葉がある通り、AWSには特定の目的に特化した強力なサービスがたくさんあります。これらをパズルのように組み合わせることで、ユーザーにとって最高に心地よいレスポンスを提供できるシステムが作れるんですね。

「検索といえばOpenSearch」という引き出しが一つ増えるだけで、アーキテクトとしての提案の幅がぐっと広がった気がします。

それでは、次回の記事でお会いしましょう！

「普通のVPN」と「加速されたVPN」の違い

通常、Site-to-Site VPNはインターネットの荒波を超えてAWSまで繋がります。しかし、今回の構成は一味違います。

• AWS Grobal Acceleratorの活用
  ユーザーに近い拠点（エッジロケーション）から、即座にAWSの高速なプライベートネットワークに通信を取り込みます。
• 高速道路を走るVPN
  インターネットの混雑を回避して、AWSの専用網を通ってVPN接続を行うため、安定性が劇的に向上します。

これが、専用線（Direct Connect）を使わずに、コストを抑えつつ高品質な通信を実現する「第3の選択肢」です。

実務で役立つ！もう一つの重要サービス「Transit Gateway」

拠点が複数ある場合や、VPCがたくさんある場合に登場するのがAWS Transit Gatewayです。

• ハブ・アンド・スポーク構成
  たくさんのVPCやオンプレミス拠点を、この「ハブ」にガチャンと繋ぐだけで、網の目のような複雑な接続をスッキリと一本化できます。
• 管理の簡素化
  新しいVPCが増えても、Transit Gatewayに繋ぐだけで既存のVPNや専用線を利用できるため、拡張性が非常に高いのが特徴です。

【比較表】オンプレミス接続、どれを選ぶ？

試験で「どの接続方法がベストか」を見極めるための表です。

試験で役立つ！キーワード判別法

ネットワーク構成の問題で、以下のフレーズがあればこの組み合わせが正解です！

• 「Direct Connectを使わずにパフォーマンスを向上させたい」
• 「グローバルな拠点から安定したVPN接続を行いたい」
• 「AWS Grobal AcceleratorをVPNのフロントに使用する」
• 「複数のVPCや拠点を一元管理したい」→AWS Transit Gateway

今回の学び：攻略の格言

「専用線が高いなら、VPNを加速しろ！Grobal AcceleratorでAWSの専用網（ハイウェイ）へ滑り込め！」

あとがき：一歩ずつ、合格へ！

最後まで読んでいいただき、ありがとうございました！

今回の構成を知った時、「専用線かVPNか」という二択ではなく、その中間を埋める「賢い折衷案」があることに驚きました。AWSのサービスをパズルのように組み合わせることで、予算という制約の中でも最高のパフォーマンスを引き出せる。これこそがアーキテクトの腕の見せ所ですね。

学びはまだまだ止まりません！次回はさらに踏み込んだテーマに挑戦します！

「データベースのパスワード、コードに直書きしちゃおうかな⋯⋯」
「オンプレミスで使っていたIPアドレス、AWSでもそのまま使いたいな⋯⋯」

そんな悩みをAWSの標準機能でスマートに解決する方法を、私の失敗談とともに整理しましょう！

データベース接続に「パスワード」はもういらない？

通常、RDSに接続する際にはユーザー名とパスワードが必要ですが、これだと「パスワードの管理」が大きなリスクになります。そこで登場するのがIAMデータベース認証です。

• パスワードの代わりに「トークン」
  一時的な署名付き認証トークンを使用してログインします。パスワードをアプリに保存する必要がありません。
• IAMロールで権限管理
  「このEC2インスタンスには、このDBへの接続を許可する」という設定をIAMロールで行なえます。
• メリット
  パスワードの漏洩リスクがゼロになり、運用が圧倒的に楽になります。

【試験のひっかけ！】
「SSL接続」は通信の暗号化であり、認証（誰がアクセスしていいか）ではありません。認証をセキュアにするなら、迷わず「IMAデータベース認証」を選びましょう。

独自のIPアドレスをAWSへ！「BYOIPの仕組み」

企業によっては、セキュリティ上の理由（ホワイトリスト登録など）で、オンプレミスで使っていた特定のパブリックIPアドレスをAWSでも使い続けたい場合があります。これを実現するのがBYOP（Bring Your Own IP）です。

ここで重要になるのがROA（Route Origin Authorrization）というキーワードです。

• ROAとは
  「このIPアドレスは私のものです。AWSがこれを使ってもいいですよ」ということを証明するための電子署名付きデータです。
• 手順
  RIR（地域インターネットレジストリ）を通じてROAを作成し、AWSアカウントに登録することで、持ち込んだIPアドレスをAWS上で利用可能（アドバタイズ）にします。

【比較表】セキュリティと移管のポイント

試験で役立つ！キーワード判別法

セキュリティや移行の問題で、以下の言葉があればこれらが正解の鍵です！

• 「パスワードのハードコードを避けたい」
  IAMデータベース認証
• 「インスタンスのプロファイル認証情報を使用する」
  IAMデータベース認証
• 「オンプレミスのIPアドレスをAWSへ移管」
  BYOIP / ROA (Route Origin Authorization)

今回の学び：攻略の格言

「DB接続はトークン（IAM）でスマートに。IPの引っ越しはROA（証明）で正当に！」

あとがき：一歩ずつ、合格へ

「SAA対策・想定問題集の振り返りシリーズ」ということで、早くも14回目を迎えました。

最初は「なんで間違えたんだろう⋯⋯」と落ち込むこともありましたが、こうして一つ一つの「なぜ」を深堀りし、ブログという形でアウトプットすることで、知識が血肉になっていくのを実感しました。

それでは、次回の記事でお会いしましょう！

「クラウドの時代」と言われても、何から始めればいいかわからないのが情シスの本音ではないでしょうか。

「AWSもAzureもGCPも名前は聞いたことがある。でも、うちの会社で何を使っているかよくわからないし、ベンダーに任せているから自分で勉強しなくてもいいか…」

正直、私自身もずっとそう思っていました。

情シスの仕事は幅広く、クラウドだけを勉強している余裕なんてない。日々のヘルプデスク対応、社内システムの管理、セキュリティ対応…やることは山積みです。

でも、ある日気づきました。「クラウドを知らない情シスは、気づかないうちに損をしている」と。

この記事では、私が実際にAWSを学び始めて感じた「情シス担当者がAWSを学ぶべき理由」を3つ、現場目線でお伝えします。

実はここが問題：クラウドを「知らない」と何が困るのか

知らないと、判断できない。判断できないと、ベンダー任せになる。

社内でSaaSツールを導入するとき、基幹システムをクラウドに移行するとき、情シスは意思決定に関わることが増えています。

でも、クラウドの仕組みを知らないまま会議に出ると、こんなことが起きます。

• ベンダーの説明が「なんとなくわかった気がする」で終わる
• 見積もりが適正かどうか判断できない
• セキュリティリスクを自分でチェックできない

これは情シスの怠慢ではなく、学ぶ機会がなかっただけです。だからこそ、今から少しずつ知識をつけていくことに意味があります。

情シスがAWSを学ぶべき理由3つ

理由① 国内企業でのシェアが圧倒的。現場でAWSに出会う確率が高い

クラウドサービスには、Amazon Web Services（AWS）、Microsoft Azure（アジュール）、Google Cloud Platform（GCP）の「3大クラウド」があります。

では、なぜAzureやGCPではなくAWSなのか。

答えはシンプルで、日本国内でAWSのシェアが最も高いからです。

クラウド市場の調査データでも、AWSは国内外で継続的にトップシェアを維持しています。つまり、取引先・委託先・グループ会社がAWSを使っている確率が高く、情シスとして関わる機会が最も多いのがAWSということです。

もちろん、AzureはMicrosoft 365 との親和性が高く、Office製品を使っている企業に向いています。GCPはデータ分析やAI領域で強みを持っています。それぞれに得意分野があります。

ただ、「まず1つだけ学ぶなら何か」という問いへの答えとしては、「現場で一番よく出てくるAWSから始めるのが合理的」です。

私自身、AWS Cloud Practitioner（クラウドプラクティショナー：AWSの入門資格）を取得してから、ベンダーとの会話の解像度が明らかに上がりました。

理由② ベンダーに「言いくるめられない」ようになる

「よくわからないけど、プロが言うなら大丈夫か」は、情シスにとって最大のリスクです。

クラウドの提案を受けるとき、ベンダーはたくさんの専門用語を使います。

• 「このリージョン（地域ごとのデータセンターの拠点）に配置すれば冗長性が確保できます」
• 「IAM（AWSのアクセス権限を管理するサービス）でロールを分けておけばセキュリティは問題ありません」
• 「S3（Amazon Simple Storage Service：クラウド上のファイル保管サービス）に静的コンテンツを置くとコストを最適化できます」

これらの言葉を聞いたとき、「それって本当に適切な提案なのか？」を判断できますか？

AWSの基礎を学ぶと、こうした専門用語の意味がわかり、「それは本当にうちの規模に必要ですか？」と自信を持って質問できるようになります。

過剰なスペックや不要なオプションを見抜けるようになるのは、コスト削減にも直結します。情シスの腕の見せ所です。

理由③ キャリアの選択肢が広がる

「情シスはコストセンター」という時代は、終わりつつあります。

クラウドを使いこなせる情シス人材は、社内でも市場でも価値が上がっています。

AWS Cloud Practitioner を皮切りに、AWS Solutions Architect Associate（SAA：AWSのシステム設計を問う中級資格）などの資格を取っていくと、転職市場での評価も変わります。私自身、現在SAAを勉強中ですが、社内での会話の幅が明らかに広がりました。

また、クラウドの知識があると、社内DX（デジタルトランスフォーメーション）の推進役を担うチャンスも増えます。「言われたことをやるだけの情シス」から、「会社のIT戦略に意見できる情シス」へ、少しずつ変わっていけます。

解決策：まず「概念を知るだけ」でも十分

AWSは、実際に触らなくても「知っているだけ」で役に立つことがたくさんあります。

「クラウドを学ぶ＝プログラミングが必要」と思っていませんか？そんなことはありません。

AWSには、入門レベルの資格として「AWS Cloud Practitioner（クラウドプラクティショナー）」があります。これは技術的な実装よりも、クラウドの概念・サービスの概要・コストの考え方を問う試験です。

つまり、「どんなサービスが存在して、何ができるか」を知るだけでいいのです。

ベンダーとの会話で困らない程度の知識は、この資格を目指して勉強するだけで十分に身につきます。私自身もこの資格から始めました。

今日からできる具体的なアクション

1. AWSの公式サイトで無料アカウントを作る
   AWS無料利用枠を使えば、お金をかけずにサービスを体験できます。まず触ってみることが大事です。
2. AWS Cloud Practitioner の試験範囲を確認する
   AWSの公式サイトや学習サービス「AWS Skill Builder（スキルビルダー）」では、無料の学習コンテンツが公開されています。まず試験の全体像を把握しましょう。
3. ベンダーとの次の打ち合わせで「1つだけ」確認してみる
   「このサービスはAWSのどの機能を使っていますか？」と聞くだけでいいです。答えを調べることで、学習が加速します。

難しく考えなくて大丈夫。知識は少しずつ積み上げるものです。

まとめ

情シス担当者がAWSを学ぶべき理由を3つお伝えしました。

• 理由①：国内シェアが高く、現場でAWSに出会う機会が多い
• 理由②：ベンダーの提案を自分で判断できるようになる
• 理由③：キャリアの選択肢が広がり、社内での立場も変わる

「クラウドは難しそう」と感じていた方も、まずは概念を知るところから始めれば大丈夫です。情シスの仕事にクラウドの知識は、これからの時代の「必須スキル」になっていきます。

一緒に、少しずつ学んでいきましょう。