AWS VPC の構築

AWS VPCの作成

操作記録

  • VPC > VPCを作成
  • 作成するリソースを「VPCなど」とする
  • 名前タグの自動生成「Sandbox」を指定
  • IPv4 CIDR ブロックをデフォルト(10.0.0.0/16)
  • IPv6 CIDR ブロックを「Amazon 提供の IPv6 CIDR ブロック」
  • テナンシーを「デフォルト」
  • アベイラビリティゾーン (AZ) の数を「3」
  • パブリックサブネットの数を「3」
  • プライベートサブネットの数を「6」
  • NAT ゲートウェイを「なし」
    • NATはあるだけで時間当たり料金がかかる
    • 後で追加したり削除したりして制御可能なため
  • Egress only internet gatewayを「yes」
    • NATと大体同じ役割をIPv6で行う
    • NATが存在しない場合で使えるのか不明
  • VPC エンドポイントを「S3ゲートウェイ」
  • DNSオプション
    • DNS ホスト名を有効化
    • DNS 解決を有効化
  • VPCを作成

生成結果

以下が作成される

  • VPC
  • S3エンドポイント: サブネット内からS3にアクセスする為のエンドポイント
  • サブネット: パブリック3+プライベート6で9つ生成
  • インターネットゲートウェイ
  • ルートテーブル
    • Nameタグのないメインルートテーブルが1→名前を付与
    • publicのルートテーブルがaz共通で1
    • privateのサブネットごとに1
  • セキュリティグループ
    • インバウンドルールx1
    • アウトバウンドルールx1
    • ただし、どちらもIP制限などなくそのまま使うには不適当

マネージドプレフィックスリストはAWSデフォルトのリストがあるだけの状態から特に何も増えない。また、Egress only internet gatewayは作成されず。

生成されたリソースにはname属性タグのみ自動で付くか、または何もつかない。そのため該当のVPCで動かすサービス名などをタグ付けしておく。今回はタグのキーをUnitとし、値をSandboxとした。

Elastic IPは自動的に作成されず、インスタンスに属していない状態でElastic IPを保有する場合料金が発生する。したがってアクセス対象のインスタンスと同時に作成するのが適当か。

AWS セキュリティグループの構成

VPCに対して設定するような作り方になる。設定は簡単で使いまわすほどでもないのでVPC単位で作成する運用で問題なさそう。全く同じ構成のVPCを複製する時のためか。Unit=Sandboxのタグを付与する。

基本的なVPCの構築はこれだけで終了。以降は利用するインスタンスやサービスによってセキュリティグループの設定が変更されたり、エンドポイントを追加したりといった進め方になる。

参考: Docker SwarmをAWSに立てる

  • 構築したVPCからDocker Swarm環境を構築
Back to prev page