AWSの勉強を始めました。普段はWeb制作や、React・TypeScriptでのアプリ開発をしていますが、AWSはほぼ初めてです。

いきなり手を動かす前に、まずは「出てくる言葉の意味がわかる状態」を目指して、基本を座学でまとめました。同じようにAWSをこれから始める方の地図になればうれしいです。

この記事でわかること:

  • クラウドとAWSの基本的な考え方
  • リージョン(Region)・AZなど「場所」の考え方
  • IAMを中心にしたアカウントとセキュリティの基本
  • 料金の仕組みと、2025年7月から変わった無料プラン
  • Webサイトやアプリを動かすのに必要な主要サービス
  • 学習中に出てきた疑問とその答え(Q&A)

※料金や無料プランの情報は2026年10月時点のものです。最新の情報は記事末尾の公式ページで確認してください。

CONTENTS目次
  1. クラウドとAWSの基本
  2. AWSの「場所」:リージョンとAZ
  3. アカウントとセキュリティ
  4. 料金の基本
  5. 主要サービス早見表
  6. 構成で理解する:予約アプリの場合
  7. 用語集
  8. 学習中に出てきた疑問Q&A
  9. 理解度チェック
  10. まとめ

クラウドとAWSの基本

クラウドとは、サーバーやデータベースを自分で買わずに、インターネット経由で「必要な分だけ借りる」仕組みです。AWS(エーダブリューエス、Amazon Web Services)は、Amazonが提供する世界最大級のクラウドサービスです。

オンプレミスとクラウドの違い

自社でサーバーを購入して設置・管理する従来の方法を「オンプレミス」と呼びます。

項目 オンプレミス クラウド(AWS)
準備期間 機器の購入・設置で数週間〜数か月 数分で使い始められる
費用 最初にまとまった購入費 使った分だけ払う(従量課金)
規模の変更 機器の買い足しが必要 画面操作や設定で増減できる
故障対応 自分で修理・交換 物理的な機器はAWSが管理
オンプレミスとクラウドで、自分が管理する範囲の違いを比べた図
オンプレミスとクラウドの、管理する範囲の違い

同じクラウドでも、EC2はサーバーを借りるのでOSの管理は自分、LambdaやS3はアプリとデータだけを管理すれば済みます。自分で管理する層が少ないほど、運用は楽になります。

押さえておきたい4つの考え方

従量課金・マネージドサービス・サーバーレス・責任共有モデルの4つを図にしたもの
クラウドの4つの考え方
  1. 従量課金(Pay-as-you-go):使った時間や量に応じて料金がかかります。小さく始められる反面、消し忘れると課金が続きます。
  2. マネージドサービス(Managed Service):OSの更新、バックアップ、障害対応などをAWSが代わりに行ってくれるサービスです。運用の手間が大きく減ります。
  3. サーバーレス(Serverless):サーバーがないのではなく、「サーバーの存在を意識しなくていい」という意味です。コードを置くだけで動き、使われたときだけ課金されます。
  4. 責任共有モデル(Shared Responsibility Model):セキュリティの責任をAWSと利用者で分け合う考え方です。データセンターや機器の安全はAWSの責任、その上で動かすアプリの設定・データ・アクセス権限は利用者の責任です。「AWSを使えば全部安全」ではない点は覚えておきたいところです。

Web制作者にとってのメリット

レンタルサーバーより自由度が高く、小さなブログから大量アクセスのあるアプリまで同じ仕組みで扱えます。React・TypeScriptで作ったアプリも、ほぼそのままの形で公開できます。

個人ブログから予約アプリ、大量アクセスのサービスまで、同じAWSの仕組みで規模を広げられることを示した図
同じ仕組みのまま、規模を広げられる

AWSの「場所」:リージョンとAZ

AWSのサービスは、世界中にあるデータセンターのどこかで動いています。場所の単位は大きい順に「リージョン(Region)」「アベイラビリティゾーン(Availability Zone、AZ)」で、配信用に「エッジロケーション(Edge Location)」があります。

東京リージョンの中に複数のAZがあり、その中にデータセンターがある構造と、エッジロケーションを示した図
リージョン・AZ・エッジロケーションの関係

リージョンの中に複数のAZがあり、その中にデータセンターがある入れ子の構造です。エッジロケーションはリージョンとは別に世界中にあり、利用者に近い場所からファイルを届けます。

用語 読み方 意味 例
Region リージョン データセンターが集まる地域 東京(ap-northeast-1)、大阪(ap-northeast-3)
Availability Zone(AZ) アベイラビリティゾーン/エーゼット リージョン内にある、互いに独立したデータセンター群 東京リージョン内の複数のAZ
Edge Location エッジロケーション CloudFrontが利用者の近くからファイルを配信するための拠点 東京・大阪など世界各地

覚えておきたいポイント

  • リージョンは自分で選ぶ:画面右上でリージョンを切り替えます。日本向けのアプリは基本的に東京リージョンを選びます。
  • 「作ったはずのものが見えない」の原因の多くはリージョン違い:別のリージョンを表示していると、作成したリソースが一覧に出てきません。
  • AZを分けると止まりにくくなる:1つのAZで停電などが起きても、別のAZで動き続けられるように設計できます。
  • リージョンに属さないサービスもある:IAMやCloudFrontなどは「グローバルサービス」です。CloudFrontで使うSSL証明書はバージニア北部(us-east-1)で作る、というルールもあるので覚えておくと後で助かります。

アカウントとセキュリティ

AWSで最初に身につけたいのは「誰に、何を、どこまで許すか」の考え方です。設定ミスは情報漏えいや高額請求に直結します。

ルートユーザー(Root User)

アカウント作成時のメールアドレスでログインする、すべての操作ができる最強の管理者です。普段の作業には使わず、MFAをかけて金庫にしまうイメージで扱います。

IAM(アイアム)の4つの要素

要素 意味 たとえ
IAMユーザー(IAM User) AWSを操作する個人のアカウント 社員一人ひとりの社員証
IAMグループ(IAM Group) ユーザーをまとめる単位 部署
IAMロール(IAM Role) AWSのサービスやアプリに一時的に与える権限 業務ごとの入館許可証
IAMポリシー(IAM Policy) 「何をしてよいか」を書いたルール(JSON) 就業規則・権限表

たとえば「LambdaがDynamoDBに書き込める」ようにしたいときは、Lambdaにロールを付け、そのロールに書き込みを許可するポリシーを設定します。

人にはグループ、サービスにはロールを通してIAMポリシーで権限を渡す仕組みを示した図
IAMのユーザー・グループ・ロール・ポリシーの関係

必ず守る3つのルール

  1. MFA(Multi-Factor Authentication、多要素認証)を設定する:パスワードに加えて、スマホアプリの確認コードでログインします。ルートユーザーには必須です。
  2. 最小権限の原則(Least Privilege):必要な操作だけを許可します。「とりあえず全部許可」は事故のもとです。
  3. アクセスキー(Access Key)を公開しない:AWSを操作するための鍵(アクセスキー)をGitHubなどに載せると、すぐに悪用されます。.env ファイルは必ず .gitignore に入れます。

IAMとCognitoの違い

IAMは「AWSを操作する人やサービス」のための権限管理、Cognitoは「作ったアプリを使うお客さん」のためのログイン機能です。どちらも「ユーザー」を扱うので混同しやすいポイントです。

料金の基本

AWSは従量課金なので、学習中に一番怖いのは「知らないうちに請求が来ること」です。仕組みを知り、最初にアラートを設定すれば防げます。

新規アカウントの無料プラン(2025年7月15日以降に作成したアカウント)

  • アカウント作成時に「無料プラン」か「有料プラン」を選びます。
  • 初めての利用者は100 USDのクレジットを受け取り、指定のアクティビティを完了すると最大100 USDが追加されます(合計最大200 USD)。
  • 無料プランは、6か月が経つか、クレジットを使い切るか、早いほうで終わります。その間は有料プランにアップグレードしない限り料金は発生しません。
  • 期限後にアップグレードしないと、アカウントは閉鎖されます(90日以内ならアップグレードで復帰可能)。
  • 30以上のサービスには、毎月の「常時無料」枠もあります。
アカウント作成から無料プランを経て、有料プランへ切り替えるか閉鎖されるかの流れを示した図
無料プランの流れ

2025年7月15日より前に作ったアカウントは、従来の「12か月無料枠」のルールが適用されます。

課金事故の典型パターン

  • 試しに作ったサーバー(EC2)やデータベース(RDS)を消し忘れる
  • 違うリージョンで作ったリソースに気づかない
  • アクセスキーが漏れて、第三者に高性能なサーバーを大量に立てられる

事故を防ぐ3つの習慣

  • AWS Budgets(バジェット)で予算アラートを設定する:たとえば月1,000円を超えそうならメールで通知
  • 使い終わったリソースはすぐ削除する:学習用は「作ったら消すまでがセット」
  • 請求ダッシュボードを週1回見る:どのサービスにいくらかかっているかを確認

主要サービス早見表

AWSには200以上のサービスがありますが、Webサイトやアプリを動かすのに最初に必要なのは次の17個です。カテゴリごとに「何をするものか」だけ押さえれば十分です。

カテゴリ サービス 読み方 一言でいうと
コンピューティング EC2 イーシーツー 自分で管理するレンタルサーバー
コンピューティング Lambda ラムダ 関数を置くだけで動くサーバーレス実行環境
コンピューティング Lightsail ライトセイル WordPressなどがすぐ使える簡単なサーバー
ストレージ S3 エススリー ファイル置き場(画像・HTML・バックアップ)
データベース DynamoDB ダイナモディービー サーバー管理不要のNoSQLデータベース
データベース RDS アールディーエス MySQL・PostgreSQLなどの管理型データベース
ネットワーク・配信 CloudFront クラウドフロント 世界中から高速配信するCDN
ネットワーク・配信 Route 53 ルートフィフティースリー DNS(独自ドメインの管理)
ネットワーク・配信 API Gateway エーピーアイ ゲートウェイ APIの入り口。リクエストをLambdaへ渡す
ネットワーク・配信 VPC ブイピーシー AWS上に作る自分専用のネットワーク
セキュリティ・認証 IAM アイアム AWSを操作する人・サービスの権限管理
セキュリティ・認証 Cognito コグニート アプリ利用者のログイン・会員登録
セキュリティ・認証 ACM エーシーエム 無料のSSL証明書(HTTPS化)
監視・運用 CloudWatch クラウドウォッチ ログ・監視・アラーム
監視・運用 Budgets バジェット 予算と請求アラート
開発ツール Amplify アンプリファイ フロントエンドのホスティングと開発支援
開発ツール CDK シーディーケー インフラをTypeScriptなどのコードで定義する

迷いやすい組み合わせ

EC2とLambda、RDSとDynamoDB、CloudFrontとCloudWatchの違いを並べて比べた図
迷いやすい3組の見分け方
  • EC2とLambda:EC2は常に動いているサーバーで、自分でOSを管理します。Lambdaは呼ばれたときだけ動き、管理はAWS任せです。小規模なアプリならLambdaが安くて楽です。
  • DynamoDBとRDS:表同士を結合して集計したいならRDS、シンプルな読み書きを安く速く行いたいならDynamoDBが向いています。
  • CloudFrontとCloudWatch:名前は似ていますが、Frontは「配信」、Watchは「監視」です。

構成で理解する:予約アプリの場合

サービスは単体ではなく、組み合わせて使います。予約アプリを例にすると、画面の表示とデータのやり取りはまったく別の道を通ります。

予約アプリの構成図。画面はRoute 53・CloudFront・S3から、データはAPI Gateway・Lambda・DynamoDBを通り、Cognitoでログインを確認する
予約アプリをAWSで動かす基本構成

上の段は画面(HTML・JS・画像)を届ける道、中の段は予約データを読み書きする道です。下の段のCognitoでログインした利用者だけが、APIを使えるようにします。

作りたいもの 使うサービス 特徴
静的なホームページ S3、CloudFront、Route 53、ACM もっとも基本の構成。安くて表示が速い
ブログ(microCMS+Astro) Amplify Hosting、Route 53(記事はmicroCMSで管理) 記事を公開すると自動でサイトが再ビルドされる。サーバー保守が不要
WordPressのサイト Lightsail 今のWordPressをほぼそのまま移せる。更新やセキュリティ対策は自分で行う
予約・顧客管理アプリ 上図の構成(S3、CloudFront、API Gateway、Lambda、DynamoDB、Cognito) 使った分だけの課金で、小規模なら低コスト。CDKでまとめて管理できる

Amplify Hostingは、内部でS3やCloudFrontにあたる仕組みを自動で用意してくれるサービスです。最初の公開はAmplifyで体験し、仕組みを理解したくなったらS3とCloudFrontを自分で組む、という順番もおすすめです。

用語集

サービス名以外で、AWSの記事や画面によく出てくる言葉です。

用語 読み方 意味
ARN エーアールエヌ AWS上のリソースを一意に指す名前(住所のようなもの)
Access Key アクセスキー プログラムやCLIからAWSを操作するための鍵
AWS CLI エーダブリューエス シーエルアイ ターミナルからAWSを操作するコマンドツール
Endpoint エンドポイント サービスにアクセスするためのURL
Origin オリジン CloudFrontが配信するファイルの元の置き場所(S3など)
Console(AWS Management Console) コンソール ブラウザで操作するAWSの管理画面
Scaling スケーリング アクセス量に応じて処理能力を増減させること
Stack スタック CDKなどでまとめて作成・削除するリソースのひとかたまり
Bucket バケット S3でファイルを入れる入れ物(フォルダの最上位)
Hosted Zone ホストゾーン Route 53でドメインのDNS設定をまとめたもの
Managed Service マネージドサービス 運用管理をAWSが代わりに行うサービス
Resource リソース AWS上に作ったもの全般(サーバー、バケット、関数など)
IaC(Infrastructure as Code) アイエーシー Infrastructure as Code。インフラをコードで管理すること

学習中に出てきた疑問Q&A

Q. Budgetsは、予算を超えたら自動でストップさせられる?

A. 標準では通知するだけで、自動では止まりません。「予算アクション(Budget actions)」を設定すれば、予算を超えたときに一部を自動で止めることができます。

予算アクションでできること:

  • 指定したEC2やRDSのインスタンスを自動で停止する
  • IAMポリシーを自動で付けて、新しいリソースを作れないようにする
  • 実行前に自分の承認を挟むことも選べる

それでも完全には止まらない理由:

  • 「停止」や「権限の制限」であって削除はしないため、S3の保管料などはかかり続ける
  • 請求データの反映には数時間ほどの遅れがあり、気づいた時点で予算を少し超えていることがある
  • すべての課金をまとめて止める「上限設定」の機能はない

学習中の現実的な対策は、無料プランを使うことです。有料プランに切り替えない限り料金は発生しないので、これが実質的な上限になります。そのうえで、Budgetsで少額の通知を設定し、使い終わったリソースはすぐ削除する習慣を組み合わせます。

Q. EC2とLambdaは、どう使い分ける?

A. 「どちらが上か」ではなく、処理の性質で選びます。判断のポイントは次の5つです。

判断のポイント Lambdaが向く EC2が向く
1回の処理時間 短い処理(最大15分まで) 15分を超える長い処理
動き方 リクエストが来たときだけ動けばよい 常に動き続ける必要がある(常駐プロセス、常時接続)
アクセスの波 少ない・ムラがある(夜間はほぼゼロなど) 一日中ずっと高い負荷が続く
使いたいソフト 自分で書いたコード(Node.js・Pythonなど) WordPressや特定のミドルウェアなど、OSに入れるソフト
運用の手間 OSの更新や障害対応はAWS任せにしたい OSから自由に設定したい・管理できる

料金の考え方:Lambdaは「呼ばれた回数×動いた時間」で課金されるので、使われない時間はほぼ0円です。EC2は起動している時間で課金されるので、アクセスがなくても料金がかかります。ただし、24時間ずっと高負荷が続く処理では、EC2のほうが割安になることもあります。

Lambdaの注意点:

  • コールドスタート(Cold Start):しばらく呼ばれていないと、最初の1回だけ起動に時間がかかり、応答が少し遅くなることがある
  • 状態を持てない:処理が終わると中身は消えるので、データはDynamoDBやS3などに保存する

具体例:

  • 予約アプリのAPI(予約の登録・一覧取得) → Lambda
  • 予約確定メールの送信、毎朝のデータ集計 → Lambda
  • WordPressのサイト → EC2(手軽にやるならLightsail)
  • 長時間かかる動画の変換、常に接続を保つゲームサーバー → EC2

迷ったら、まずLambdaで作れないかを考え、「15分を超える」「常に動かしたい」「OSに入れるソフトが必要」のどれかに当てはまったらEC2を選びます。その中間としてコンテナで動かすECS(Fargate)もあります。

Q. ルートユーザーと管理者(admin)アカウントは分けたほうがいい?

A. 分けるのが基本です。AWSも、ルートユーザーは普段使わず、日常の作業は別の管理者ユーザーで行うことを推奨しています。

分けるべき理由:

  • ルートユーザーは制限をかけられない:IAMポリシーで権限をしぼれないため、パスワードが漏れるとアカウントのすべて(解約や連絡先の変更まで)を操作されてしまう
  • 漏れたときに止められる:管理者ユーザーなら、漏れてもルートユーザーから無効化・削除できる。ルートユーザー自体が漏れると、取り返すのがとても大変
  • 誰が何をしたか追える:ユーザーを分けておくと操作の記録が残り、トラブル時に原因を追いやすい
アカウント 使う場面 設定
ルートユーザー アカウントの解約、支払い・連絡先など一部の設定変更だけ MFA必須、アクセスキーは作らない、パスワードは安全に保管
管理者ユーザー(admin) 普段の作業すべて AdministratorAccessの権限、MFAを設定

管理者ユーザーの作り方は2通りあります。学習中は「IAMユーザー」を1つ作るのが手軽です。AWSが現在おすすめしているのは「IAM Identity Center(アイデンティティセンター)」でユーザーを作る方法で、複数人で使う場合や本格運用に向いています。

Q. 最初は無料プランで始めて、クレジットを使い切ったら有料に切り替えればいい?

A. 基本的にはその進め方で大丈夫です。ただし、切り替えのタイミングについて3つ知っておくと安心です。

  1. 「クレジットを使い切る」より先に「6か月」が来ることが多い:学習程度では200 USDを使い切ることはまずないので、実際は6か月の期限が先に来ることがほとんど。期限までに切り替えないとアカウントが閉鎖されるので、カレンダーに期限を入れておく
  2. 早めに有料へ切り替えても、クレジットは無駄にならない:切り替え後も、残ったクレジットは初回登録日から最大12か月間、対象サービスで使える
  3. 公開するサイトは、本番運用前に有料へ切り替える:無料プランのまま公開していると、期限切れでアカウントが閉鎖されたときにサイトが止まる

そのほか、無料プランでは一部の企業向けサービスが使えないこと、クレジットが使えるのは対象のサービスだけ(ドメインの登録料などは対象外の場合がある)ことも押さえておきましょう。

理解度チェック

全10問です。8問以上正解なら、基本はばっちりです。

  1. 自社でサーバーを購入・設置して運用する方法を何と呼びますか。
  2. 日本向けのアプリを作るとき、基本的に選ぶリージョンはどこですか。
  3. 作成したはずのリソースが一覧に表示されないとき、最初に確認すべきことは何ですか。
  4. ルートユーザーに必ず設定すべきセキュリティ対策は何ですか。
  5. Lambdaに「DynamoDBへの書き込み」を許可するとき、Lambdaに付けるIAMの要素は何ですか。
  6. 責任共有モデルで、アプリのアクセス権限の設定は誰の責任ですか。
  7. 請求額が予算を超えそうなときに通知してくれるサービスは何ですか。
  8. Reactのビルド結果を置き、Webサイトとして配信するときに組み合わせる2つのサービスは何ですか。
  9. アプリの利用者向けにログイン機能を提供するサービスは何ですか。
  10. 独自ドメインのDNSを管理するサービスは何ですか。
解答を見る
  1. オンプレミス
  2. 東京リージョン(ap-northeast-1)
  3. 画面右上のリージョンが正しいか
  4. MFA(多要素認証)
  5. IAMロール(とそれに付けるポリシー)
  6. 利用者(自分)
  7. AWS Budgets
  8. S3とCloudFront
  9. Cognito
  10. Route 53

まとめ

AWSは用語やサービスの数が多くて圧倒されますが、Webサイトやアプリを動かすのに最初に必要なものは意外と限られています。まずは「場所(リージョン)」「権限(IAM)」「料金(無料プランとBudgets)」の3つを押さえ、主要サービスは「何をするものか」だけわかれば十分だと感じました。

次は実際にアカウントを作り、初期設定(MFA・管理者ユーザー・Budgets)を済ませたうえで、練習用の小さなサイトをS3とCloudFrontで公開してみる予定です(このブログやホームページを移すわけではなく、学習用のサブドメインで試します)。その様子もまたブログにまとめます。

参考にした公式情報: