【初心者向け】AWSで優先的に学ぶべきサービス10選
はじめに
こんにちは!
今回は 「AWSで優先的に学ぶべきサービス10選」 というテーマで紹介します。
AWSには実に200を超えるサービスが存在しており、初学者にとっては「何から学べばいいのか分からない…」と迷うことも多いのではないでしょうか。私自身も最初にAWSを学び始めた時、その壁にぶつかりました。
本記事では、これからAWSを学ぼうとしている方が最初に触れるべきサービスを10個に厳選して紹介します。あくまで私の個人的な意見になりますが、同じように悩んでいる方の参考になれば嬉しいです。
対象読者
- AWSをこれから学び始めたいと考えている方
- サービスが多すぎて、何から手を付ければよいか迷っている方
- ハンズオンや資格勉強を始める前に、全体像をつかみたい方
記事を読むメリット
- AWSでシステムを構築するうえで、最初に学ぶべきサービスが明確になる
- 限られた学習時間を効率よく使えるようになる
- 基礎を固めたうえで、ハンズオンや資格学習にスムーズに進める
10選
1. ネットワーク:VPC
これはAWS上で何かを作るなら避けて通れない重要サービスです。
VPC(Virtual Private Cloud)は、AWS上に自分専用のネットワーク空間を作るサービスであり、EC2やRDSなどの主要サービスはVPC内で動作します。
2. ロードバランサー:ELB
ELB(Elastic Load Balancing)は、AWSが提供するマネージドな負荷分散サービスで、主に以下の3種類があります。
-
ALB(Application Load Balancer):HTTP/HTTPSなどアプリケーション層向け。レイヤ7で動作する。
-
NLB(Network Load Balancer):高スループット・低レイテンシのTCP向け。レイヤ4で動作する。
-
CLB(Classic Load Balancer):旧世代(新規では基本非推奨)
中でも使用頻度が高く、優先度が高いのがALBです。
ALBを使うことで複数のEC2やコンテナにトラフィックを分散し、スケーラビリティや可用性を高めることができます。
また、AWSでは単一障害点を避けるため、基本的にはマルチAZ構成が採用されます。
例えば「複数AZに配置したEC2をALBでまとめて、障害時にも自動で正常なインスタンスにルーティング」といった構成が一般的です。
高可用性を実現する上で欠かせない存在なので、10選に入れました。
3. コンピューティング:EC2 (とEBS)
EC2(Elastic Compute Cloud)は、AWSが提供する仮想サーバーサービスです。
LinuxやWindowsなどのOSを選択し、自分で構成したサーバー環境をクラウド上に構築できます。
最近はFargateやECSなどのコンテナサービスの利用も増えていますが、現在もEC2を使ったシステムは多く、特にレガシーシステムや大規模なオンプレのシステムをクラウドへ移行する場面では、EC2が採用されやすい印象です。
この辺りなのですが、大規模・レガシーなシステムはどうしてもリファクタリングが難しく、EC2にリホストしてクラウド移行という形に落ち着くイメージです。
コンテナ系のサービスは初期の学習コストがかかるため、まずはEC2で仮想サーバーの立ち上げ・接続・基本的な設定を体験してみると、AWSに慣れる入り口として有効です。
また、EC2を使う上で切り離せないのが EBS(Elastic Block Store) です。
EBSはEC2にアタッチされる永続的なブロックストレージで、インスタンスのOSが格納されています。
私自身は、パソコンでいう「ローカルドライブ(Cドライブ)」のようなイメージを持っています。
EC2インスタンスを停止・再起動してもデータが保持されるのが特徴です。
その他にもインスタンスが保持するデータや、インスタンス上で動作するアプリケーションログをEBSに保存することもできます。
「EC2とEBSはセットで動く」という理解を持っておくと、ストレージ周りのトラブルや設計時の選択肢も把握しやすくなります。
4. データベース:RDS
RDS(Relational Database Service)は、AWSが提供するマネージド型のリレーショナルデータベースサービスです。
MySQLやPostgreSQL、MariaDB、Oracle、SQL Serverなど、主要なDBエンジンをマネージドで利用できます。
採用されるDBエンジンですが、多少コストがかかっても可用性・パフォーマンスが必要な場面ではAmazon Aurora(MySQL/PostgreSQL互換)が採用されやすいです。
コストを抑えたい場合はMySQLが採用されやすい印象です。
オンプレミス環境では、データベースの構築・バックアップ・パッチ適用・スケーリングなどを自分で行う必要がありますが、RDSではこれらの運用管理作業の多くをAWSが自動化してくれるのが大きな特徴です。
アプリケーションとデータベースはセットで構成されるのが一般的なため、RDSもAWS上でシステムを構築する際はほぼ必須のサービスと言えます。
5. オブジェクトストレージ:S3
S3(Simple Storage Service)は、AWSを代表するオブジェクトストレージサービスです。
ファイル(オブジェクト)を格納でき、高い耐久性・スケーラビリティ・低コストを兼ね備えているのが特徴です。
代表的な用途には以下のようなものがあります:
- CloudTrailやCloudWatch LogsなどのAWSサービスが生成するログ保存先として利用
- 保存されたログを Athena でクエリ分析 → QuickSight で可視化 といった、軽量な分析基盤の構築
- バックアップの保存先(S3ライフサイクル設定で、古いバックアップはより低コストなストレージへ移動させる事もできる)
- 静的Webサイトのホスティング(ランディングページや簡易なWebページを激安で公開可能)
S3は多くのAWSサービスと連携して使われる重要な存在です。
使いこなせるようになると、あらゆる用途に応用が効くため早め慣れておくと今後の学習もスムーズになります。
6. アクセス管理:IAM
IAM(Identity and Access Management)は、AWSリソースへのアクセスを制御するための認証・認可サービスです。
セキュリティ系サービスのひとつですが、AWSでシステムを構築・運用するうえで欠かせないため、本記事でも取り上げています。
IAMを正しく理解していないと、以下のような問題に直面することがあります:
- 意図しないアクセス制御ミス(重大なセキュリティ事故の発生)
- アクセス拒否や、意図した動作にならない(サービス同士が連携できない)
- 誰が何にアクセスできるか分からず、管理が煩雑になる
例えば、EC2インスタンスからS3へファイルを保存したい場合には、EC2に適切なIAMロールをアタッチする必要があります。
一方で、CloudTrailのログをS3に保存する場合は、CloudTrailにロールを割り当てるのではなく、S3バケット側のバケットポリシーで書き込みを許可する必要があります。
さらにこのIAMロールは人(IAMユーザー)に割り当てることもできますし、他のアカウントのIAMユーザーに割り当てる事もできます。
このように、「サービスがサービスにアクセスするケース」と「ユーザーがAWSリソースにアクセスするケース」では、IAMの使い方が変わるため混乱しやすいです。
IAMは奥が深いですが、早い段階で基本を理解しておくことで、後々のトラブルや沼を回避する助けになります。
7. 監視:CloudWatch
Amazon CloudWatch は、AWSリソースやアプリケーションの監視、ログ収集、可視化を行うマネージドサービスです。
主な用途:
- EC2などのリソースのメトリクス監視
例:CPU使用率、ディスクI/O、ネットワークトラフィックなどをリアルタイムで可視化。 - アプリケーションログの収集と分析
CloudWatch Logs にログを集約し、検索・抽出・可視化・保存などが可能です。 - 異常検知と通知
CloudWatch Alarm を設定することで、しきい値を超えた場合に SNS などを通じてリアルタイム通知を送信できます。
さらに標準のメトリクスだけでなく、CloudWatch エージェント を EC2 インスタンスにインストールする事で以下のような詳細なメトリクスも収集可能になります:
- メモリ使用率
- ディスク使用率
- カスタムメトリクス(任意の値をアプリケーションから送信)
また、CloudWatch Logs に収集されたログから特定の文字列を抽出し、ログベースのメトリクスを生成することも可能です。
例えば「ERROR」という文字列の出現回数をメトリクス化し、アラームのトリガーに使うといった運用ができます。
長期間のメトリクスデータを分析することで、リソースの使用状況の傾向を把握できます。
例えば、常にCPU使用率が低いEC2インスタンスを特定し、スペックを落とすことでコスト削減につなげるといった対応も可能です。
CloudWatch は、AWSの監視における中心的な存在です。
システムインフラだけでなく、アプリケーションの健全性を可視化し安定運用と迅速なトラブル対応を実現する事ができます。
機能が多いため難しいのですが、使いこなせば強力な武器になります。
8. 通知:SNS
SNS(Simple Notification Service)はAWSのイベント通知を行うためのメッセージ配信サービスで、通知フローを構築することができます。
代表的な使い方としては、下記の通りです。
- CloudWatch Alarm でEC2などのパフォーマンスの異常を検知し、管理者に通知する
- AWS Budgets でコストのしきい値を超えた際に、予算超過を通知する
- セキュリティ系サービス(GuardDuty、CloudTrailなど)で不審な操作を検出し、即時通知する
SNS単体ではメール通知ができます。
さらにSNSとChatbotを組み合わせると、SlackやMicrosoft Teamsに通知できるようになり、ある程度メッセージ内容もカスタマイズできます。
そして実装する手間はあるのですが、SNSとLambdaを組み合わせるとLINE通知が可能になったり、よりメッセージ内容を柔軟にカスタマイズすることができます。
このように異常やイベント発生時にリアルタイムで通知を送る仕組みを作っておくことで、運用担当者の負担軽減や対応の迅速化、システム障害の早期発見・復旧につながります。
一見シンプルなサービスですが、運用を支える重要な存在です。
9. DNS: Route53
Route 53は、AWSが提供するDNS(ドメインネームシステム)サービスです。
よくある使い方としては、AWS上に構築したWebサービスに独自ドメインを割り当ててインターネット上に公開するケースです。
Route53上でドメインを購入することもできますし、お名前.com など外部で安く取得したドメインをRoute53に移管・登録して使うことも可能です。
例えば前述のS3で静的Webサイトをホスティングする構成でも、Route53を使えば独自ドメインによるアクセスが実現できます。
さらに、次のようなユースケースにも対応しています:
- マルチリージョン構成において、各リージョンのエンドポイントに対してヘルスチェックを行い、リージョンレベルでの障害発生時に正常なリージョンへ自動でフェイルオーバーする
- オンプレミスとVPC間でDNS名を共通化し、ハイブリッド構成での名前解決を実現(Route53 Resolver)
ただし、そこまでの大規模構成に携わる機会は正直少ないと思われるのですが、実はVPC内部だけで完結するシンプルな構成でも、Route53は裏でしっかり使われています。
VPCを作成すると、EC2などのリソースには内部DNS名(例:ip-10-0-0-123.ec2.internal)が割り当てられ、Route53 Resolverという内部DNS機能が自動的に動作し、名前解決が行われます。
つまり、独自にRoute53を設定していなくても、気づかないうちにお世話になっている存在なのです。
このためRoute53の仕組みを知っておくことで、プライベートな名前解決がうまくいかない時のトラブルシューティング力が向上します。
また、将来的にハイブリッド構成やマルチリージョン構成を扱う際の理解がスムーズになるといったメリットがあります。
10. バックアップ:Backup
AWS Backupは、AWS上のさまざまなサービスのバックアップを一元管理・自動化できるマネージドサービスです。
少しややこしいのが、実は多くのAWSサービスには標準でバックアップ機能が備わっているという点です。
そのため日常的なバックアップ作業は個々のサービス側の機能だけで完結するケースも多く、「AWS Backupをわざわざ使わなくてもいいのでは?」と感じます。
各サービスの標準バックアップ機能の例:
- RDS:自動バックアップ(最大35日)や、手動スナップショットによるバックアップが可能
- EBS:手動でスナップショットを取得して保存可能
- EC2:AMI(Amazon Machine Image)を作成して、OSやアプリケーション構成を丸ごと保存可能
※AMIはどちらかといえば「バックアップ」よりも、「インスタンスをテンプレートとして再利用する」仕組みです
このように、基本的なバックアップはサービス単体でも十分に対応できます。
一方でAWS Backupの強みは、以下のようなより広い運用・ガバナンス・リスク対策にあります:
- 大規模災害対策(DR)
他リージョンへのバックアップコピーが可能です。リージョン全体に障害が発生しても、事前にコピーされたデータで復旧できます。 - クロスアカウントのバックアップ管理
例えば、開発アカウントで取得したバックアップを「バックアップ専用アカウント」に安全に集約可能。 - アカウント侵害対策
Vaultのロック機能(Backup Vault Lock)を使うことで、悪意ある削除からバックアップを保護可能。 - 監査・コンプライアンス対応
CloudTrailと連携することで、バックアップ・復元操作の記録を取得できます。
監査ポリシーなど組織の要件、DR対策やアカウント侵害など万が一の備えとして価値を発揮するサービスです。
AWS Backupの使い方や実際の復元手順なども事前に知っておくと、いざという時に役に立ちます。
番外編
こちらでは10選には入らなかったものの、個人的に重要だと感じるサービスについて紹介したいと思います。
ファイルサーバー:EFS, FSx for Windows File Server
EFS
EFS (Elastic File System)は、Linux向けの共有ファイルストレージです。
複数のEC2インスタンスやコンテナ(Fargate、ECS、EKS)から同時にマウントして共有利用が可能です。
主な用途:
- 複数のサーバー・コンテナ上で稼働するアプリケーションのログを1か所に集約する
- 共有ディレクトリとしての活用(Webアプリの共通データ置き場) など
FSx for Windows File Server
FSx for Windows File ServerはWindows向けのマネージドなファイルサーバーです。
Windows Serverのファイル共有(SMBプロトコル)に対応し、Active Directory連携も可能です。
主な用途:
- Windows EC2からのファイル共有
- 社内システムのファイルサーバー代替(オンプレのファイルサーバーからの移行)
- ハイブリッド構成での利用(オンプレからのマウントも可能)
AD連携・アクセス権限の設定ができるため、社内のファイルサーバーと同じような運用が可能です。
よくあるケースとしては、AWS上でファイルサーバーを構築し、バックアップ・リストアまでAWS側で完結させるといったところでしょうか。
社内システムとの連携や、レガシーで大規模なシステムがWindows環境だったりするため、そのような場面で採用されやすい印象です。
運用効率化:SSM
SSM(Systems Manager)は、AWS上やオンプレミスのサーバーを一元的に管理・運用できるサービスです。
SSMには、以下のように様々な機能が搭載されています。:
- Session Managerによって、EC2インスタンスに対して22番ポートを開けずにセキュアにリモート接続
- Run Commandで、複数のEC2に対して一括でコマンドを実行
- Patch ManagerでOSパッチ適用を自動化
- InventoryでEC2のソフトウェア情報・設定の収集と可視化
特に真価を発揮するのは、EC2インスタンスを大量に管理する場面です。
そのような時に運用効率を高め、管理者の負担を大きく軽減できるのが魅力です。
一方でコンテナ環境の場合は用途が限定されるため、EC2ほど多用されるケースは少ないです。
OSの管理が不要ですし、コンテナの管理はECS/EKSで行うためです。
どちらかというとレガシーな環境で(EC2が多いため)活躍しそうなサービスです。
コンテナを採用していたりモダンな環境では効果は限定的かなと。
CDN: CloudFront
CloudFront は、AWSが提供するグローバルなCDN(コンテンツ配信ネットワーク)サービスです。
世界中に配置されたサーバーを活用し、ユーザーに近い場所からコンテンツを配信することで、高速・低遅延な配信を実現します。
主な用途としては、下記の通りです:
- 静的Webサイトの配信(HTML, CSS, JS, 画像など)
- 動画・音声コンテンツの配信
- Webアプリの高速化とセキュリティ強化
- オリジンサーバーの負荷軽減とコスト削減
静的ファイルをCloudFrontがキャッシュすることで、ページの読み込みが高速化され、ユーザー体験が向上します。
リクエストの多くがCloudFrontのキャッシュで処理されるため、オリジンサーバー(例:S3, ALB, EC2)の負荷と転送量が減り、コスト削減につながります。
大量アクセスが発生してもCloudFrontが一部を吸収することで、バックエンドにかかる負荷を抑制できます。
さらにClouFrontはAWS WAF(Web Application Firewall)との統合ができます。
AWSが提供するマネージドルールを活用することで、簡単にDoS対策やIP制限、SQLインジェクション防止などが可能です。
AWS上でWebサイトやWebサービスを構築・公開する場合などに有用ですので、学んでおいて損はないサービスだと思います。
Discussion