--- title: "AWS環境構築の手順｜VPC・EC2・IAM・セキュリティグループの初期設計を解説" url: "https://www.issoh.co.jp/tech/details/15359/" published: 2026-07-19 updated: 2026-09-22 categories: ["AWS"] publisher: "株式会社一創" --- # AWS環境構築の手順｜VPC・EC2・IAM・セキュリティグループの初期設計を解説 AWSで環境を構築する順序は決まっています。アカウントの初期設定、VPCによるネットワーク、EC2などのコンピューティング、そしてセキュリティグループとIAMによる権限。この4段階です。本記事は、この順序に沿ってVPCのCIDR設計・サブネット分割・EC2のAMI選定・セキュリティグループの初期設計を、実装者が判断に迷う箇所に絞って解説します。マネジメントコンソールでの手動構築を前提にしつつ、IaCへ切り替える条件と構築を外部へ任せる場面の線引きまで扱う構成です。クラウドやAWSそのものの概念整理は[クラウドとは・AWSとは何かを事業者向けに解説した記事](https://www.issoh.co.jp/column/details/13421/)に譲り、本記事は構築の実装に絞ります。 ## まとめ：AWS環境構築は4段階の順序と初期設計の型で決まる AWS環境構築で先に押さえるべき結論は次のとおりです。作業は「アカウント初期設定→VPC→EC2→セキュリティグループ・IAM」の順で進め、後工程からの手戻りを防ぎます。VPCのCIDRは10.0.0.0/16のような広めのプライベート帯を確保し、オンプレミスや他VPCと重複させないこと。ここだけは後から取り返しがつきません。サブネットはパブリックとプライベートを分け、2つ以上のアベイラビリティゾーンへ配置します。 EC2はAmazon Linux 2023を既定に選び、メタデータ保護のIMDSv2必須を維持したまま起動します。EBSはgp3、SSH接続は22番ポートを開けずSSM Session Managerへ寄せ、アプリからAWSサービスへの権限はアクセスキーでなくIAMロールで付与する。この型に沿えば、小規模構成でもセキュリティの初期水準を保てます。手動構築で済むのはサーバー数台・単一環境までで、検証・本番の複数環境を持つならIaCへ移すべき段階です。それぞれの条件は独自章で言い切ります。 ## AWS環境構築の全体像と着手前に押さえる4段階の構築順序・前提知識 個別の設定に入る前に、全体の流れと前提を短く固めます。ここが曖昧なまま画面操作を始めると、CIDRの引き直しやサブネットの作り直しが発生しがちです。 ### アカウント初期設定からネットワーク・サーバー・権限までの4段階の流れ 構築は次の4段階で進めます。第1段階がアカウントの土台づくりで、ルートユーザーの保護・作業用の管理者権限・証跡と請求の監視を整えます。第2段階がVPCの構築で、CIDR設計・サブネット分割・インターネットゲートウェイとルートテーブルの設定まで。第3段階でEC2インスタンスをAMI・インスタンスタイプ・EBSの選定とともに起動し、第4段階でセキュリティグループの通信制御とIAMロールの権限を締めます。ネットワークより先にEC2を作れないため、順序の入れ替えは実質できません。各段階の成果物を確認してから次へ進むと、切り戻しの範囲が段階内に収まります。なお、どこまでをAWSに任せてどこからを自分で管理するかの整理は[IaaS・PaaS・SaaSの管理範囲を比較した記事](https://www.issoh.co.jp/column/details/13429/)が前提になります。 ### リージョンとアベイラビリティゾーンの選定基準と東京リージョンの構成 リージョンは利用者との物理距離で選びます。国内向けシステムなら東京リージョン（ap-northeast-1）が第一候補で、大阪リージョン（ap-northeast-3）は災害対策の待機系に使う構成が定番です。リージョン内には独立したデータセンター群であるアベイラビリティゾーン（AZ）が複数あり、東京リージョンでは3つ以上のAZを利用できます（2026年7月時点）。単一AZにサーバーを寄せると、そのAZの障害がそのまま全断につながります。本番環境は最低2AZへ分散させる前提で、この後のサブネット設計を進めてください。マネジメントコンソール右上のリージョン表示が「東京」になっているかは、作業開始時に毎回確かめる癖をつけます。別リージョンに作ったリソースは一覧に表示されず、消し忘れの温床になるためです。 AZ名とAZ IDの対応、アカウントによって`ap-northeast-1a`の指す物理ゾーンが変わる問題は[ap-northeast-1とは｜東京リージョンのAZ構成と指定方法・大阪との使い分け](https://www.issoh.co.jp/tech/details/17728/)で扱っています。 ## AWSアカウント開設直後に行うルートユーザー保護と管理者権限の初期設定 アカウント開設直後のルートユーザーは、契約情報まで含めて何でもできる状態です。日常作業に使わず、最初に保護します。 ### ルートユーザーのMFA設定とIAM Identity Centerによる管理者作成 最初にやることは2つです。ひとつはルートユーザーへの多要素認証（MFA）の設定で、AWSは2024年以降、管理アカウントのルートユーザーにMFAを段階的に必須化しています。認証アプリでもFIDO2セキュリティキーでも構いませんが、設定しない選択肢はありません。もうひとつは日常作業用の管理者の作成です。従来はIAMユーザーを作る手順が定番でしたが、現在のAWSの公式推奨はIAM Identity Centerで人のアクセスを管理し、一時的な認証情報でサインインする方式です（2026年7月時点）。長期のアクセスキーを持つIAMユーザーは漏えい時の被害が大きく、新規構築でわざわざ選ぶ理由がありません。ルートユーザーは請求設定の変更など限られた作業だけに残し、普段はIdentity Center経由の管理者で作業します。 ### CloudTrailの証跡有効化とAWS Budgetsによる請求アラート設定 操作の記録と請求の監視も、リソースを作り始める前に仕込みます。CloudTrailは管理操作のイベント履歴を過去90日分まで無料で参照でき、S3バケットへの証跡保存を有効化すれば90日を超える保管も可能です。誰がいつセキュリティグループを開けたかを後から追えるかどうかは、この設定ひとつで決まります。請求側はAWS Budgetsで月額の上限額を決め、超過見込みの時点でメール通知を受ける設定まで入れておく段取りです。使った分だけ課金されるAWSでは、消し忘れたNATゲートウェイや検証用インスタンスが静かに料金を積み上げるからです。金額の当たりを付けるには、構築前に[AWSの料金計算ツールの使い方を整理した記事](https://www.issoh.co.jp/column/details/13183/)で概算を出しておくと、アラートのしきい値も決めやすくなります。 ## VPC設計の実装手順｜CIDR設計とサブネット分割・マルチAZ配置の勘所 VPCはAWS内に作る自分専用の仮想ネットワークです。ここでの設計、特にCIDRだけは後から変えにくいため、先に考え方を固めます。 ### VPC CIDRの設計基準｜10.0.0.0/16と重複回避・サブネット分割の考え方 VPCにはプライベートIPアドレスの範囲（CIDR）を割り当てます。実務の基準は2つだけです。第一に、将来つなぐ可能性のあるネットワークと重複させないこと。オンプレミスとのVPN接続や他VPCとのピアリングは、CIDRが重複していると構成できません。社内LANが192.168.0.0系を使っているなら、VPCは10.0.0.0系から取るという住み分けが定石です。第二に、広めに確保すること。10.0.0.0/16なら約65,000個のIPを持て、後述のサブネット分割の自由度が保てます。VPC自体は無料のため、狭く取る節約に意味はありません。サブネットは/24（251個の利用可能IP）を単位に切り出すと、用途×AZの組み合わせで整理しやすくなります。AWSは各サブネットで5個のIPを予約するため、/28のような極端に狭い切り方は避けます。 ### パブリック・プライベートサブネットの分割とルートテーブル・IGWの設定 サブネットは外部公開の有無で2種類に分けます。インターネットから直接アクセスさせるロードバランサーや踏み台はパブリックサブネットへ、アプリケーションサーバーやデータベースはプライベートサブネットへ置く構成が基本形です。両者を分けるのはサブネット自体の属性ではなく、ルートテーブルの中身です。作業手順は次のようになります。 1. VPCを作成し、インターネットゲートウェイ（IGW）を作成してVPCへアタッチする 2. パブリック用・プライベート用のサブネットを、それぞれ2つのAZに作成する（計4つ） 3. パブリック用ルートテーブルを作り、0.0.0.0/0の宛先をIGWへ向けるルートを追加する 4. そのルートテーブルをパブリックサブネットへ関連付け、プライベート側には関連付けない IGWへのルートを持つサブネットがパブリック、持たないものがプライベート。この定義を押さえておくと、疎通しないときにどのルートテーブルを見ればよいかがすぐ分かります。 ### NATゲートウェイの配置数とマルチAZ構成のコストの釣り合い プライベートサブネットのサーバーにも、OSアップデートなどで外向きの通信は必要です。それを担うのがNATゲートウェイで、パブリックサブネットに配置し、プライベート側のルートテーブルから0.0.0.0/0を向けます。設計判断になるのは配置数です。可用性を厳密に取るならAZごとに1台ずつ置きますが、NATゲートウェイは時間課金と処理データ量課金の両方が発生し、2台構成では固定費が単純に2倍になります。検証環境や停止許容度の高いシステムなら1台に集約し、AZ障害時は片系が外向き通信を失う割り切りで十分です。逆に、外部APIへの通信が止まると業務が止まるシステムでは2台に分けます。全構成で一律にどちらかへ倒すのではなく、外向き通信の停止をどれだけ許容できるかで台数を決めてください。なお、AWSのマネージドサービスへの通信であればNATゲートウェイを介さず私設接続に寄せられます。詳しくは[AWS PrivateLinkとは](https://www.issoh.co.jp/tech/details/15473/)を参照してください。 ## EC2インスタンス構築の手順｜AMI選定・タイプ選択・EBSと接続方式 ネットワークができたらEC2を起動します。起動ウィザードで迷いやすいのはAMI・インスタンスタイプ・ストレージ・接続方式の4点です。 ### AMI選定の基準｜Amazon Linux 2023とIMDSv2デフォルト必須の注意点 AMIはOSイメージの選択です。Linuxで特段の制約がなければAmazon Linux 2023を選びます。前世代のAmazon Linux 2は2026年6月30日でサポートが終了しており、新規構築で選ぶ理由はもうありません。Amazon Linux 2023のAMIで起動したインスタンスは、メタデータ取得がIMDSv2のみに既定で制限されます。IMDSv2はインスタンス情報への問い合わせにセッショントークンを要求する方式で、SSRF攻撃経由の認証情報窃取への防御になります。古い監視エージェントなどがIMDSv1を前提にしていると起動後に情報取得で失敗しますが、その場合もIMDSv1へ戻すのではなく、エージェント側の更新で対応するのが筋です。2024年半ば以降にリリースされた新しいインスタンスタイプはIMDSv2のみをサポートするため、v1前提の構成はいずれ行き止まりになります。 ### インスタンスタイプの選び方｜tシリーズとm・cシリーズの命名規則と使い分け インスタンスタイプの名前は「ファミリー＋世代＋属性」の規則で読めます。`t3.micro`ならtファミリーの第3世代、`m8g.large`ならmファミリー第8世代のGraviton（gはArmベースのAWS製CPUを指す属性）です。主要ファミリーの使い分けを整理します。 | ファミリー | 特性 | 主な用途 | | ----------- | ----------- | ----------- | | t系（t3・t4g） | バースト型・低価格 | 検証・小規模Web | | m系（m7i・m8g） | CPUとメモリの均衡型 | 一般的なアプリサーバー | | c系（c7i・c8g） | コンピューティング寄り | バッチ・API処理 | | r系（r7i・r8g） | メモリ寄り | DB・キャッシュ | 迷ったらt3またはt4gの小さいサイズで始め、CPUクレジットの枯渇が見えたらm系へ上げる進め方が安全です。第8世代のGraviton4搭載タイプ（m8gは2024年9月に一般提供開始）は同性能帯のx86系より単価が低く、ソフトウェアがArm対応済みなら第一候補になります。サイズは後から変更できるため、最初に盛る必要はありません。 ### EBSはgp3を既定にする理由とSSM Session Managerによる接続 ルートボリュームはgp3を選びます。gp3はベースラインで3,000IOPS・125MB/秒を保証し、gp2よりGBあたり単価が約2割低い世代です。gp2はIOPSが容量に連動するため小容量で遅くなる欠点があり、新規で選ぶ理由がありません。接続方式は、キーペアを作ってSSHする従来手順より、SSM Session Managerを既定にします。EC2にAmazonSSMManagedInstanceCoreポリシーを持つIAMロールを付ければ、ブラウザやCLIからポート開放なしでシェルへ入れます。踏み台サーバーの構築も、秘密鍵ファイルの受け渡し管理も不要になり、操作ログはCloudTrail側に残る。初期構築のこの一手で、SSH鍵の漏えいという事故のカテゴリーごと消せます。 ## セキュリティグループとIAMロールの初期設計｜最小開放と権限分離の原則 最後の段階が通信と権限の制御です。ここでの手抜きが、公開後の侵害につながる典型ルートになります。 ### セキュリティグループ最小開放の設計と22番ポートを開けない接続手段 セキュリティグループはインスタンス単位の仮想ファイアウォールで、許可ルールだけを書くステートフル型です。戻りの通信は自動で許可されるため、インバウンドの穴だけを最小にします。原則は3つです。Webサーバーなら443番のみを0.0.0.0/0に開ける。22番はSSM Session Managerで代替し、そもそも開けない。アプリからDBへの通信は、IPアドレスでなく「アプリ側セキュリティグループからの3306番を許可」のようにグループ参照で書く。グループ参照にしておくと、サーバーが増減してもルールの書き換えが発生しません。似た機能のネットワークACLはサブネット単位・ステートレス型の別物で、既定の全許可のまま触らない運用で問題ありません。制御の主役はセキュリティグループ側に一本化します。 ### EC2へのIAMロール付与とアクセスキーを配置しない権限設計 EC2上のアプリがS3などのAWSサービスへアクセスする権限は、IAMロールで付与します。アクセスキーを発行してサーバー内の設定ファイルへ書く方式は、キーの漏えいがそのまま恒久的な認証情報の漏えいになるため、新規構築では採りません。ロール方式なら認証情報は自動的に短期のものが払い出され、ローテーションも不要です。IAMのユーザー・ロール・ポリシーの違いや権限評価の仕組みは[AWS IAMとは何かを実装者目線で解説した記事](https://www.issoh.co.jp/tech/details/15427/)で確認できます。ポリシーは「S3の特定バケットへの読み書きだけ」のように対象と操作を絞り、AdministratorAccessのような広い権限をインスタンスへ付けないこと。なお保存データ側の防御は既定で進んでおり、S3は2023年1月以降、新規オブジェクトが自動でSSE-S3暗号化されます。EBSのデフォルト暗号化もリージョン単位の設定ひとつで有効化できるため、初期構築の時点で入れておきます。 ## 手動構築で済ませる場面とIaC・構築外注へ切り替える判断基準 ここまでの手順はコンソールの手動操作を前提にしました。この章では、手動のままでよい条件と、切り替えるべき条件を言い切ります。 ### サーバー数台・単一環境の構成を手動構築で完結させてよい条件と記録の残し方 単一環境・サーバー数台・構成変更が四半期に一度あるかないか。この3条件が揃うなら、手動構築で完結させて構いません。この規模でTerraformやCloudFormationを導入しても、コードの学習と保守の手間が構成変更の頻度に見合わず、IaCのコードだけが実環境とずれていく「作りっぱなしのコード」が残りがちです。ただし手動で行く場合も、CIDR設計・セキュリティグループのルール一覧・IAMロールの内容は必ずドキュメントに残します。構築した本人が異動した後、設定の意図を実画面から逆算するコストは想像以上に大きいためです。逆に言えば、記録を残す運用すら回らない体制なら、手動構築の資格がない状態と判断してください。 ### 検証・本番の複数環境とIaC移行・構築外注を選ぶ判断の分かれ目 検証と本番で同じ構成を2面持つ、あるいは月次以上の頻度で構成が変わる。どちらかに当たった時点でIaCへ移します。同じ構成を手作業で2回作ると必ず差分が生まれ、「検証では動いたのに本番で動かない」の調査に費やす時間が、コード化の初期投資を超えていくからです。コンテナ運用まで進む場合は、[ECSデプロイをコードで管理するecspressoの導入手順](https://www.issoh.co.jp/tech/details/13182/)のように、デプロイ部分から段階的にコード化する進め方が現実的です。一方、社内に構築経験者がいない・本番稼働まで数か月の期限がある・セキュリティ要件の判断に自信がないという状況なら、初期構築を外部へ任せて運用を内製化する分担が結果的に早く安くつきます。外注する場合の依頼範囲・費用相場・ベンダー選定の基準は[AWS構築代行の依頼範囲と費用](https://www.issoh.co.jp/column/details/16406/)にまとめました。設計から移行・運用まで任せる場合の相談先としては[AWSを含むインフラ構築の支援サービス](https://www.issoh.co.jp/service/system/aws/)があります。 ## よくある質問 AWS環境構築の着手前に、実務でよく聞かれる疑問に答えます。 ### AWS環境構築にはどのくらいの期間がかかりますか？ 本記事の範囲（アカウント初期設定・VPC・EC2数台・セキュリティグループとIAM）であれば、要件が固まっている前提で実作業は2〜3日、設計の検討を含めて1〜2週間が目安です。期間が延びる要因はほぼ設計側にあり、CIDRの調整（社内ネットワークとの重複確認）と、セキュリティ要件の合意に時間がかかります。マルチAZのデータベースや冗長化構成まで含める場合は、その分の設計・試験期間を上乗せして見積もってください。 ### 無料利用枠だけでどこまで構築を試せますか？ AWSの無料利用枠は2025年に改定され、新規アカウントには登録時にクレジットが付与され、所定の設定作業の完了分と合わせて最大200USD相当まで拡張できる方式になっています（2026年7月時点）。本記事のVPC・小型EC2・gp3ボリューム程度の検証なら、この範囲で十分に収まります。ただしNATゲートウェイとElastic IPの放置は課金が積み上がりやすいため、検証を終えたら削除する運用だけは最初から徹底してください。 ### VPCは環境ごとに分けるべきですか？ 検証環境と本番環境は別VPCに分けることを推奨します。同一VPCに混在させると、セキュリティグループの誤参照や検証作業の負荷が本番へ波及する経路が残るためです。VPCを分ければ、CIDRさえ重複させていなければ後からピアリングでつなぐこともできます。さらに厳密にやるなら、環境ごとにAWSアカウント自体を分け、AWS Organizationsで束ねる構成が現在の標準的な分離方法です。 ### セキュリティグループとネットワークACLはどちらを設定すべきですか？ 日常の通信制御はセキュリティグループに一本化してください。セキュリティグループはインスタンス単位・ステートフルで、許可ルールだけを管理すればよく、運用の負担が小さい方式です。ネットワークACLはサブネット単位・ステートレスで、戻り通信の許可も明示する必要があり、二重管理になると障害調査が難しくなります。特定IPをサブネットごと遮断したいような例外時にだけネットワークACLを足す、という使い分けが実務的です。 ### 構築後の運用で最初に整えるべきことは何ですか？ 監視と更新の2つです。監視はCloudWatchでCPU使用率・ステータスチェック失敗・EBSの残容量にアラームを設定し、通知先をメールやチャットへつなぐところから始めます。更新はOSパッチの適用方針を決め、SSMのPatch Managerで自動化すると手が離れます。メトリクスやログの収集を本格化する段階になったら、計装の構成まで含めて設計する段階に進んでください。その先の構成は関連記事のオブザーバビリティ実装の記事で扱っています。 ## 関連記事 - [クラウドとは？AWSとは何かを仕組み・料金・移行の判断まで事業者向けに解説](https://www.issoh.co.jp/column/details/13421/)：本記事の親にあたる概念解説で、AWSの全体像をまず押さえたい方向けです。 - [クラウド移行の進め方｜計画から移行方式・費用・切り替えまでの手順を発注者視点で解説](https://www.issoh.co.jp/column/details/13424/)：既存システムをAWSへ移す場合の計画づくりを補えます。 - [AWSオブザーバビリティの実装｜ADOT・CloudWatch・Container Insightsで計装する構成](https://www.issoh.co.jp/tech/details/15297/)：構築後の監視を本格化する次の段階を実装視点で解説しています。 - [IaaS・PaaS・SaaSの違いとは？管理範囲と選び方を比較表で解説](https://www.issoh.co.jp/column/details/13429/)：AWSで自分が管理する範囲の整理に役立ちます。 - [AWSの見積もりとは？料金計算ツールの使い方と費用が変わる要因を発注視点で解説](https://www.issoh.co.jp/column/details/13183/)：構築前の費用概算とアラートのしきい値決めに使えます。 --- 出典: [AWS環境構築の手順｜VPC・EC2・IAM・セキュリティグループの初期設計を解説]()（株式会社一創）