はじめに
こちらではAWS機能について書いていきたいと思います。
公式ドキュメントやAWS認定試験（ソリューションアーキテクトやDevOpsなど）の勉強教材など細かい内容をかかず、ざっくりとした内容で。
試験などに興味はないし！公式ドキュメントなど長ったらしくて読めん！
という方に向けに作っていきたいと思います。
(私の備忘録も兼ねて)
今回はネットワークな内容です。
写真はつけられればつけます。(Qiitaの制限の範囲内で)
環境
AWS
ドキュメント
Virtual Private Cloud(VPC)とは
AWSクラウド内に倫理的に分離されたセクションを作り、ユーザーが定義した仮想ネットワークを構築するサービス
端的にいうと仮想のネットワークサービス
・任意のIPアドレス範囲を選択して仮想ネットワークを構築(IPアドレスはCIDR方式)
AWSで予約されているIPアドレスなどもあるので使用するさいは注意！
・サブネットの作成、ルートテーブルやネットワークゲートウェイの設定など仮想ネットワーキング環境を制御
・必要に応じてクラウド内のネットワーク同士をつなげることもできる
・複数の接続オプションが利用できる
インターネット経由
VPN
・設定を跨がせて設定することもできる
・サブネットが使えるのでVPC内で分割することも可能
サブネット
ネットワークをやってると聞くがAWSでも存在する
CIDR/16、サブネットに/24の設定が推奨らしい
パブリックネットワーク
外部インターネットに公開するネットワーク
プライベートネットワーク
内部のネットワーク
外部ににつなぎたい場合NATゲートウェイを使用するらしい
NAT Gateway
https://docs.aws.amazon.com/ja_jp/vpc/latest/userguide/vpc-nat-gateway.html
そとのリソースにつにつなぎたい場合はAWSネットワークを使うかエンドポイントを使っての接続ができる。
インターネットの設定
・ルートテーブルでパケットの行先を設定
・VPC作成時にデフォルトで一つだけ作れられている。
・VPC内はCIDRアドレスでルーティングされている。
VPCトラフィック設定
・セキュリティグループ
・ネットワークACLs
要はAWSの設定にしてしまうかACLで設定してしまうか
セキュリティグループ
・ステートフルで戻りのトラフィックの考慮が入らない
・サーバ単位で適応可能
・許可のみをIn/Outで設定
・デフォルトでは同じセキュリティグループ内の通信のみ許可
・必要な通信は許可設定が必要
・全てのルールを適応
ネットワークACLs
・ステートフルで戻りのトラフィックの考慮がいる
・サブネット単位で適応
・許可と拒否をIn/Outで指定
・デフォルトでは全ての送信元IPを許可
・番号の順序通りに適応
VPCとのオンプレ接続
・VPN接続
・Direct Connect
Direct Connect
AZ以外にDirect Connectがあり
そこにDirect Connectデバイスで接続してそこから
AWSにいくという流れになる
・安価なアウトバウンドトラフィック料金
・ネットワーク信頼性の向上
・ネットワーク帯域幅の向上
・Direct Connect
Direct Connect gateway
Direct Connect gatewayにより同一アカウントに所属する複数のリージョンの複数AZから複数リージョン複数VPCに接続可能
例 東京リージョン>Direct Connect gateway>米国北部リージョン
VPNとDirect Connect
VPNとDirect Connectの特徴の差を簡単にまとめてみたいと思います
VPNと専用線比較
| VPN | 専用線 | |
|---|---|---|
| コスト | 安価 | 専用キャリア契約もあり高価 |
| リードタイム | クラウド上で接続設定で可能なため即時 | 物理的な対応が必要なため数週間 |
| 帯域幅 | 暗号化のオーバーヘッドにより限界がある | ポートあたり1G/10Gbps |
| 品質 | インターネットの影響を受ける | キャリアにより高品質 |
| 障害切り分け | インターネットベースのため切り分けが難しい | 物理的に確保されているため容易 |
VPCエンドポイント
インターネットゲートウェイを経由せずにAWSにアクセスできる。
ルートテーブルにて設定できる。
主に二種類の方法で接続
Gateway型
サブネットにルーティングを設定してVPC内部から外のサービスにアクセスする
特徴
PrivateLink型
サブネットにエンドポイント用のプライベートIPアドレスを設定、DNSが名前解決でルーティングを行う
比較
| Gateway型 | Private型 | |
|---|---|---|
| アクセス制御 | エンドポイントポリシーを設定 | セキュリティーグループで設定 |
| 料金 | 無料 | 有料 |
| 冗長性 | AWS側が管理 | マルチAZ設計 |
NATゲートウェイ
プライベートサブネットのリソースがインターネットまたはAWSクラウドと通信が可能になる
・AWSによるマネージドNATサービス
・EIPの割り当て可能
・最大10Gbps
・ビルドインで冗長化されている高価陽性
・アベイラビリティゾーン毎に設置
VPC Flow logs
ネットワークトラフィックを取得し
CloudWatchでモニタリングができる機能
・ネットワークインターフェースを送信元/送信先といるトラフィックが対象
・セキュリティグループとネットワークACLのルールでaccepted/rejectされたトラフィックログを取得
・キャプチャウィンドウと言われる時間枠(10分間)で収集・プロセッシング・保存する
・RDS、Redshift、ElasticCache、WorkSpacesのネットワークインターフェーストラフィックも取得可能
・追加料金なし
| リソース | 上限数 |
|---|---|
| リージョンあたりのVPCの数 | ５ |
| VPCあたりのサブネットの数 | 200 |
| ルートテーブルあたりのルート数 | 100 |
| AWSアカウントあたりの１リージョン内のElasticIPの数 | 5 |
| VPCあtりのセキュリティグループ数 | 500 |
| セキュリティグループあたりのルール数 | 50 |
VPC Peering
二つのVPC間でのトラフィックルーティングが可能
・異なるAWSアカウント間のVPC間をピア接続できる
・一部リージョン間んp異なるVPC間のピア接続も可能
・単一障害点や帯域幅のボトルネックは存在しない
基本的に1対1の関係となるため
A->B->C
と繋いでも
A->Cと繋いでいることにはならない
新たにそれの設定をする必要がある
VPCについて
ここらへんはUdemyであったものを参照したいとおもいます。(他に良さげなものが見つかりませんでした....)
VPCを分割するケース
・アプリケーション
・監視スコープごと
・リスクレベルごと
・本番/検証/開発などのフェーズごと
・部署ごと
などなど
VPC設計ポイント
・設計時には将来の拡張も見据えたアドレッシングや他ネットワークとの接続性も考慮する
・CIDR（IPアドレス）は既存のVPC、社内のDCやオフィスと被らないアドレス帯を設定し、組織構成やシステム構成の将来像も考えながら前もって計画する
・VPC構成は自社業務に合わせたVPC単体ではなくVPC全体の関係性も視野に入れる
・組織とシステム境界からVPCをどのように分割するか将来構成も考慮して検討する
・複数のAZを利用して可溶性の高いシステムを構成
・サブネットは大きいサブネットを使い、パブリック/プライベートサブネットへのリソースの配慮をインターネットアクセス可否から検討する
・セキュリティグループを使ってリソース感のトラフィックを適切に制御する
・実装や運用を保持するツールも有効利用し、VPC Flow Logsを使ってモニタリングできるようにする。