基本的なAWSのサービスだが、自由度も高いのでどのように設計をすればよいのか、いつも頭を悩ませる。Designを読み込んでベストプラクティスを守るようにする。ベストプラクティスネットワーク設計を考える時に、まず一般的なネットワーク設計原則を確認する。プライベートネットワークにオーバーラップしないようにサブネットを実装するのが良い。将来への拡大に備えて、IPアドレススペースを余分に確保しておく事も良い考えだ。VPCは、次のような設計のベストプラクティスに従う必要がある。VPCのCIDRとサブネットを適切なサイズで用意するAWS上のアプリケーションVPCの設計を考える時、ユーザー、バックエンドシステム、ルーティングの観点からAWSをどのように活用するかを考えて、同様に現在と将来に必要なネットワークサイズを推定する必要がある。ベストプラクティスを守ってさえいれば、ある構成から別の構成に簡単に変える事も可能。VPCを作り出す事ができる。一度作成したVPCとサブネットはリサイズする事はできないという事を覚えておく必要がある。自分のユースケースに対して適切な構成を選択するには、以下のような条件をもとにデザインパターンを考える。それぞれ違った方法でルーティングをするホストが必要か?これらの条件をもとに以下のデザインパターンを採用する。VPCパブリックサブネットのみで構成されたVPC。VPC内のAWSリソースは自社が持つ内部システム及び内部ネットワークとの直接的の接続をできないようにする。Usecaseテスト、R&D、デモ、本番とその他の環境で使われるが、内部ネットワークからは完全に隔離されたネットワークとする。ネットワーク内のAWSリソースが内部へのプライベート通信を持たないようにするケースで適切である。AccessVPC内にあるAWSリソースにアクセスする際には、全ユーザー(内部・外部)はインターネット越しに利用する。AccessVPC内のAWSリソースはインターネット上の他のパブリックなシステムへのアクセスが許可される。RoutingAWSリソースはすべて同じルーティング要件を共有し、インターネットゲートウェイとAWSが提供するインターネット接続を利用する。VPCパブリックサブネットとプライベートサブネットで構成されたVPC。NATも使用する事も考える。Usecaseこのパターンは内部(ブライベート)と外部(パブリット)リソースの両方と通信する必要があるネットワーク構成を作るときに使用される。パブリックとブライベートルーティングの両方に対応する必要があるシステムで最適。データベース・バックエンドシステムで構築された多層構造Webアプリケーションで有効。Access状況によるが、VPC内にあるAWSリソースにアクセスする際には、全ユーザー(内部・外部)はインターネット越しでも内部からでもアクセスできるようにする。AccessVPC内のAWSリソースは内部・外部システムへのアクセスできるようにし、プライベートネットワーク、インターネット接続を利用できるようにする。RoutingパブリックサブネットかプライベートサブネットのどちらにAWSリソースを配置するかをグループ分けして、それぞれが適切にルーティングされるようにする。VPCパブリックサブネットとプライベートサブネットと内部システム(VPN接続)で構成されたVPC。Usecaseこのパターンはオンプレミス(ブライベート)と外部(パブリット)リソースの両方と通信する必要があるネットワーク構成を作るときに使用される。インターネット越しに内部の顧客システム等にアクセスするWebアプリケーションで等有効。AccessVPC内のAWSリソースは内部・外部システムへのアクセスできるようにし、プライベートネットワーク、インターネット接続を利用できるようにする。VPCプライベートサブネットと内部システム(VPN接続)で構成されたVPCUsecaseバックオフィスシステムのような内部ユーザーからのアクセスのみを想定したケースで有効。AccessVPC内のAWSリソースは顧客の内部システムにアクセスできるようにする。Connectを利用して顧客の内部システムと通信できるようにする。ネットマスク)まで取る事が可能。VPCのサイズはどの程度リソースが必要になるかに応じて、適切なサイズを決める。AWSで事前に予約されたIPアドレスは除外している例えば以下のWebサイトで192.168.0.0をSmallのVPCサイズで分割してみる。Zonesやパブリックサブネット、プライベートサブネットとして振り分けていく。SSR)でWebアプリを構築たまにゃん🇹🇭エンジニアバンコクで働くエンジニア。ex-日本経済新聞社。マーケティングテクノロジーの分野で仕事してます(CRM、データエンジニアリング)。