AWSの勉強を始めました。普段はWeb制作や、React・TypeScriptでのアプリ開発をしていますが、AWSはほぼ初めてです。
いきなり手を動かす前に、まずは「出てくる言葉の意味がわかる状態」を目指して、基本を座学でまとめました。同じようにAWSをこれから始める方の地図になればうれしいです。
この記事でわかること:
- クラウドとAWSの基本的な考え方
- リージョン(Region)・AZなど「場所」の考え方
- IAMを中心にしたアカウントとセキュリティの基本
- 料金の仕組みと、2025年7月から変わった無料プラン
- Webサイトやアプリを動かすのに必要な主要サービス
- 学習中に出てきた疑問とその答え(Q&A)
※料金や無料プランの情報は2026年10月時点のものです。最新の情報は記事末尾の公式ページで確認してください。
CONTENTS目次
クラウドとAWSの基本
クラウドとは、サーバーやデータベースを自分で買わずに、インターネット経由で「必要な分だけ借りる」仕組みです。AWS(エーダブリューエス、Amazon Web Services)は、Amazonが提供する世界最大級のクラウドサービスです。
オンプレミスとクラウドの違い
自社でサーバーを購入して設置・管理する従来の方法を「オンプレミス」と呼びます。
| 項目 | オンプレミス | クラウド(AWS) |
|---|---|---|
| 準備期間 | 機器の購入・設置で数週間〜数か月 | 数分で使い始められる |
| 費用 | 最初にまとまった購入費 | 使った分だけ払う(従量課金) |
| 規模の変更 | 機器の買い足しが必要 | 画面操作や設定で増減できる |
| 故障対応 | 自分で修理・交換 | 物理的な機器はAWSが管理 |

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

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

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

リージョンの中に複数の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にロールを付け、そのロールに書き込みを許可するポリシーを設定します。

必ず守る3つのルール
- MFA(Multi-Factor Authentication、多要素認証)を設定する:パスワードに加えて、スマホアプリの確認コードでログインします。ルートユーザーには必須です。
- 最小権限の原則(Least Privilege):必要な操作だけを許可します。「とりあえず全部許可」は事故のもとです。
- アクセスキー(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:EC2は常に動いているサーバーで、自分でOSを管理します。Lambdaは呼ばれたときだけ動き、管理はAWS任せです。小規模なアプリならLambdaが安くて楽です。
- DynamoDBとRDS:表同士を結合して集計したいならRDS、シンプルな読み書きを安く速く行いたいならDynamoDBが向いています。
- CloudFrontとCloudWatch:名前は似ていますが、Frontは「配信」、Watchは「監視」です。
構成で理解する:予約アプリの場合
サービスは単体ではなく、組み合わせて使います。予約アプリを例にすると、画面の表示とデータのやり取りはまったく別の道を通ります。

上の段は画面(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つ知っておくと安心です。
- 「クレジットを使い切る」より先に「6か月」が来ることが多い:学習程度では200 USDを使い切ることはまずないので、実際は6か月の期限が先に来ることがほとんど。期限までに切り替えないとアカウントが閉鎖されるので、カレンダーに期限を入れておく
- 早めに有料へ切り替えても、クレジットは無駄にならない:切り替え後も、残ったクレジットは初回登録日から最大12か月間、対象サービスで使える
- 公開するサイトは、本番運用前に有料へ切り替える:無料プランのまま公開していると、期限切れでアカウントが閉鎖されたときにサイトが止まる
そのほか、無料プランでは一部の企業向けサービスが使えないこと、クレジットが使えるのは対象のサービスだけ(ドメインの登録料などは対象外の場合がある)ことも押さえておきましょう。
理解度チェック
全10問です。8問以上正解なら、基本はばっちりです。
- 自社でサーバーを購入・設置して運用する方法を何と呼びますか。
- 日本向けのアプリを作るとき、基本的に選ぶリージョンはどこですか。
- 作成したはずのリソースが一覧に表示されないとき、最初に確認すべきことは何ですか。
- ルートユーザーに必ず設定すべきセキュリティ対策は何ですか。
- Lambdaに「DynamoDBへの書き込み」を許可するとき、Lambdaに付けるIAMの要素は何ですか。
- 責任共有モデルで、アプリのアクセス権限の設定は誰の責任ですか。
- 請求額が予算を超えそうなときに通知してくれるサービスは何ですか。
- Reactのビルド結果を置き、Webサイトとして配信するときに組み合わせる2つのサービスは何ですか。
- アプリの利用者向けにログイン機能を提供するサービスは何ですか。
- 独自ドメインのDNSを管理するサービスは何ですか。
解答を見る
- オンプレミス
- 東京リージョン(ap-northeast-1)
- 画面右上のリージョンが正しいか
- MFA(多要素認証)
- IAMロール(とそれに付けるポリシー)
- 利用者(自分)
- AWS Budgets
- S3とCloudFront
- Cognito
- Route 53
まとめ
AWSは用語やサービスの数が多くて圧倒されますが、Webサイトやアプリを動かすのに最初に必要なものは意外と限られています。まずは「場所(リージョン)」「権限(IAM)」「料金(無料プランとBudgets)」の3つを押さえ、主要サービスは「何をするものか」だけわかれば十分だと感じました。
次は実際にアカウントを作り、初期設定(MFA・管理者ユーザー・Budgets)を済ませたうえで、練習用の小さなサイトをS3とCloudFrontで公開してみる予定です(このブログやホームページを移すわけではなく、学習用のサブドメインで試します)。その様子もまたブログにまとめます。
参考にした公式情報:


