使い始めるために必要なこと

4-1用意するもの ── 意外と少ない

AWSのアカウント（利用者登録）を作るのに必要なものは、次の4つだけです。

1. メールアドレス：アカウントの「名前」になります。個人のアドレスではなく、会社の共有アドレス（例：aws-admin@会社ドメイン）を使うのが鉄則です。担当者が異動・退職してもアカウントが宙に浮かないようにするためです。
2. クレジットカード：登録時に必須です。法人カードがなければ、担当者の個人カードで登録して後から請求書払いに切り替える、またはパートナー経由で契約する方法があります。
3. 電話番号：本人確認のためのSMSまたは自動音声通話に使います。
4. 住所・会社名：請求書に記載される情報です。適格請求書を取得するためにも正確に入力します。

登録自体は10分程度で終わり、その日のうちに使い始められます。この「速さ」がクラウドの利点ですが、裏を返せば社内のルールがないまま、誰でもアカウントを作れてしまうということでもあります（第5章で扱います）。

4-2アカウントの構造 ── 金庫の鍵と、社員証

AWSのアカウントには、2種類の「利用者」がいます。この区別は、セキュリティの基本中の基本です。

ルートユーザー ── 金庫の鍵

アカウントを作ったときのメールアドレスでログインする、すべての権限を持つ最高管理者。契約の解約や支払い方法の変更など、ここでしかできない操作があります。

日常業務では使わない。多要素認証（MFA）を必ず設定し、パスワードは厳重に保管する。

IAMユーザー / IAMロール ── 社員証

日常の操作に使う、必要な権限だけを持った利用者。人ごと、役割ごとに作り、「経理は請求情報の閲覧のみ」「開発者はサーバーの作成まで」のように権限を絞ります。

退職・異動時はその人の社員証だけを無効にすればよい。

複数アカウントと一括請求

ある程度の規模になると、「本番用」「開発用」「部署ごと」のように複数のアカウントを分けて使うのが一般的です。AWS Organizationsという無料の機能でこれらをまとめて管理し、請求を1つに統合（一括請求）できます。請求書は1通にまとまりつつ、アカウント別（＝部署別・システム別）の内訳も見られるため、コストの部門配賦がしやすくなります。

4-3どこに置くか ── リージョンとアベイラビリティゾーン

AWSは世界各地にデータセンター群を持っていて、利用者はサービスを作るときに「どの地域に置くか」を選びます。この地域の単位をリージョンと呼びます。日本には東京リージョンと大阪リージョンがあります。

リージョン選びは、非エンジニアにも関係する判断です。

• データの所在地：個人情報や契約上の制約で「データは国内に置くこと」と決まっている場合、東京または大阪を選ぶ必要があります。
• 料金差：同じサービスでもリージョンによって単価が違います。東京は米国の主要リージョンより1〜2割程度高めです。
• 応答速度：利用者に近いリージョンほど表示が速くなります。日本の利用者向けなら日本のリージョンが基本です。
• 災害対策：東京と大阪の両方を使えば、大規模災害時にも業務を続けられる構成が組めます（費用は増えます）。

各リージョンの中はさらに、物理的に離れた複数の建物群（アベイラビリティゾーン、AZ）に分かれています。1つの建物が停電や火災で止まっても、別の建物で動き続けられるようにするためです。「マルチAZ構成」と聞いたら「建物をまたいで二重化している＝止まりにくいが費用は約2倍」と理解すれば十分です。

4-4責任共有モデル ── AWSが守る範囲、自社が守る範囲

第1章・第2章で触れた「AWSに置けば自動で安全、ではない」という話を、きちんと整理したものが責任共有モデルです。AWSはこれを「クラウド"の"セキュリティはAWS、クラウド"内の"セキュリティはお客様」と表現しています。

守る範囲	具体的には	責任
建物・設備	データセンターの入退室管理、電源、空調、物理的な破壊からの保護	AWS
機器とその土台	サーバー機器、ネットワーク機器、仮想化の仕組みの保守・修正	AWS
サービスそのもの	S3やRDSといったサービスが正しく動き続けること	AWS
借りたサーバーの中身	OSの更新、ウイルス対策、不要な通り道を閉じる設定	利用者
データ	暗号化するか、誰に見せるか、バックアップを取るか、いつ消すか	利用者
権限と認証	IAMの設定、MFA、パスワード管理、退職者のアカウント停止	利用者
法令・契約の遵守	個人情報保護法、業界規制、顧客との契約に沿った使い方	利用者

ニュースになる「クラウドからの情報漏えい」の多くは、AWS側の侵害ではなく、利用者がS3の公開設定を誤った、権限を広く与えすぎたといった利用者側の設定ミスです。この表の下半分が、自社の責任範囲だと覚えておいてください。

4-5最初にやっておく5つの設定

アカウントを作ったら、何かを動かす前に、次の5つを済ませておくのが定石です。エンジニアに依頼する立場でも、「この5つは終わっていますか？」と確認できると安心です。

01 ルートユーザーにMFAを設定し、普段使わない

金庫の鍵を厳重に保管する。日常の操作用にIAMユーザーを作って、そちらでログインする。

02 請求アラート（AWS Budgets）を設定する

「月の利用額が○ドルを超えそうになったらメールで知らせる」という予算を作る。2つまでは無料。会社で使うなら、経理の共有アドレスも通知先に加えると、月中に異常に気づける。

03 操作記録（CloudTrail）を有効にする

誰がいつ何をしたかの記録を残す。事故が起きたときの原因調査や、監査対応に必要。基本的な記録は無料。

04 タグ付けのルールを決める

作るものすべてに「部署名」「プロジェクト名」「担当者」のラベル（タグ）を付けるルールを決める。これがないと、後から費用を部門別に分けることができない。

05 使うリージョンを決め、使わないリージョンは閉じる

東京と決めたら、他の地域で勝手にサーバーが立てられないよう制限する。不正利用で海外リージョンに大量のサーバーを立てられる被害を防ぐ。

4-6サポートプラン ── 困ったときに誰に聞くか

AWSのサポートは、プランによって受けられる内容が変わります。請求・アカウントに関する問い合わせは、どのプランでも無料でできます。

プラン	月額の目安	内容	向いている組織
Basic	無料	請求・アカウントの問い合わせ、公式ドキュメント、コミュニティ	個人の学習、お試し
Developer	29ドル〜（利用額の3％）	技術的な質問をメールで（営業時間内、返答まで最大24時間程度）	開発・検証段階
Business	100ドル〜（利用額の3〜10％、段階制）	24時間365日、電話・チャット対応。障害時は1時間以内に初回返答	業務システムを本番で動かす企業
Enterprise	15,000ドル〜	専任の技術担当者が付く。大規模・ミッションクリティカルな用途	大企業、金融機関など

※ 金額は2026年時点の目安です。本番システムを動かすなら Business 以上が一般的で、サポート費用も予算に含めておく必要があります。

4-7自社で直接契約するか、パートナー経由にするか

AWSを使う方法には、AWSと直接契約する方法と、国内のAWSパートナー（リセラー・請求代行会社）を通す方法があります。多くの日本企業は後者を選んでいます。

	直接契約	パートナー経由
契約相手	AWSジャパン	国内のパートナー企業
請求	AWSの請求書（円建ても可）	パートナーの請求書（円建て、国内の商習慣に沿った支払いサイト）
サポート	AWSのサポートプランに別途加入	日本語の技術サポートがセットになっていることが多い
費用	AWSの定価	定価から数％割引、または手数料が上乗せ。会社によって異なる
向いている場合	社内に詳しい技術者がいる	技術者が少ない、円建て・請求書払いを早く整えたい、相談相手がほしい