**このページの改善にご協力ください**
このユーザーガイドに貢献するには、すべてのページの右側のペインにある「**GitHub でこのページを編集する**」リンクを選択してください。
# ハイブリッドノード用のネットワークを準備する
このトピックでは、Amazon EKS クラスターを作成してハイブリッドノードをアタッチする前に設定する必要があるネットワーク設定の概要を説明します。このガイドでは、[AWS Site-to-Site VPN](https://docs.aws.amazon.com/vpn/latest/s2svpn/SetUpVPNConnections.html)、[AWS Direct Connect](https://docs.aws.amazon.com/directconnect/latest/UserGuide/Welcome.html)、または独自の VPN ソリューションを使用したハイブリッドネットワーク接続の前提条件の要件を満たしていることを前提としています。
![\[ハイブリッドノードのネットワーク接続。\]](http://docs.aws.amazon.com/ja_jp/eks/latest/userguide/images/hybrid-prereq-diagram.png)
## オンプレミスネットワーク設定
### 最小ネットワーク要件
最適なエクスペリエンスを実現するには、ハイブリッドノードから AWS リージョンへの接続には、100 Mbps 以上の通信速度と 200 ミリ秒以下のラウンドトリップレイテンシーを持つ、信頼性の高いネットワーク接続が推奨されます。これはほとんどのユースケースに対応する一般的なガイダンスですが、厳格な要件ではありません。帯域幅とレイテンシーの要件は、アプリケーションのイメージサイズ、アプリケーションの伸縮性、モニタリングとログ記録の設定、他の AWS サービスに保存されているデータへのアクセスに関するアプリケーションの依存関係など、ハイブリッドノードの数とワークロードの特性によって異なります。本番環境にデプロイする前に、独自のアプリケーションと環境でテストして、ネットワーク設定がワークロードの要件を満たしているか確認することをお勧めします。
### オンプレミスノードとポッド CIDR
ハイブリッドノードに使用するノードとポッドの CIDR と、それらで実行されているワークロードを特定します。CNI にオーバーレイネットワークを使用している場合、ノード CIDR はオンプレミスネットワークから割り当てられ、ポッド CIDR は Container Network Interface (CNI) から割り当てられます。`RemoteNodeNetwork` および `RemotePodNetwork` フィールドで EKS クラスターを作成する際、オンプレミスノード CIDR およびポッド CIDR を入力として渡します。オンプレミスノード CIDR は、オンプレミスネットワークでルーティング可能である必要があります。オンプレミスポッド CIDR のルーティング可能性の詳細については、次のセクションを参照してください。
オンプレミスノードとポッド CIDR ブロックは、以下の要件を満たしている必要があります。
1. `IPv4` RFC-1918 のいずれかの範囲内にある (`10.0.0.0/8`、`172.16.0.0/12`、または `192.168.0.0/16`) か、RFC 6598 で定義される CGNAT 範囲内にある (`100.64.0.0/10`) こと。
1. EKS クラスターの VPC CIDR や Kubernetes サービスの `IPv4` CIDR と相互に重複しないこと。
### オンプレミスポッドのネットワークルーティング
EKS Hybrid Node を使用する際、クラウド環境とオンプレミス環境間で完全なクラスター通信および機能を有効にするため、オンプレミスネットワークでオンプレミスポッド CIDR をルーティング可能にすることが一般的に推奨されています。
**ルーティング可能なポッドネットワーク**
オンプレミスネットワークでポッドネットワークをルーティング可能にできる場合、以下のガイダンスに従ってください。
1. オンプレミスポッド CIDR で EKS クラスターの `RemotePodNetwork` フィールドを設定し、オンプレミスポッド CIDR で VPC ルートテーブルを設定し、オンプレミスポッド CIDR で EKS クラスターセキュリティグループを設定します。
1. オンプレミスネットワークでオンプレミスポッド CIDR をルーティング可能にするために使用できる手法がいくつかあります。具体的には、ボーダーゲートウェイプロトコル (BGP)、静的ルート、その他のカスタムルーティングソリューションなどです。BGP はカスタムまたは手動でルート設定する必要がある代替ソリューションよりもスケーラブルで管理しやすいため、推奨されるソリューションです。AWS は、ポッド CIDR をアドバタイズするための Cilium と Calico の BGP 機能をサポートしています。詳細については、「[ハイブリッドノードの CNI を設定する](hybrid-nodes-cni.md)」および「[ルーティング可能なリモートポッド CIDR](hybrid-nodes-concepts-kubernetes.md#hybrid-nodes-concepts-k8s-pod-cidrs)」を参照してください。
1. EKS コントロールプレーンはウェブフックに割り当てられたポッド IP アドレスと通信できるため、ウェブフックはハイブリッドノードで実行できます。
1. クラウドノードで実行されているワークロードは、同じ EKS クラスター内のハイブリッドノードで実行されているワークロードと直接通信することができます。
1. 他の AWS サービス (AWS Application Load Balancer や Amazon Managed Service for Prometheus など) はハイブリッドノードで実行されているワークロードと通信し、ネットワークトラフィックのバランスを取ってポッドメトリクスをスクレイピングすることができます。
**ルーティング不可能なポッドネットワーク**
オンプレミスネットワークでポッドネットワークをルーティング*できない*場合、以下のガイダンスに従ってください。
1. ウェブフックは EKS コントロールプレーンからウェブフックに割り当てられたポッド IP アドレスへの接続が必要なため、ウェブフックはハイブリッドノードで実行することはできません。この場合、ハイブリッドノードと同じ EKS クラスター内のクラウドノードでウェブフックを実行することが推奨されます。詳細については、「[ハイブリッドノード用のウェブフックを設定する](hybrid-nodes-webhooks.md)」を参照してください。
1. クラウドノードで実行されているワークロードは、クラウドノードに VPC CNI を使用する際、またはハイブリッドノードに Cilium または Calico を使用する際、ハイブリッドノードで実行されているワークロードと直接通信することはできません。
1. サービストラフィック分散を使用し、トラフィックを発信元のゾーン内に留めます。サービストラフィック分散の詳細については、「[サービストラフィック分散の設定](hybrid-nodes-webhooks.md#hybrid-nodes-mixed-service-traffic-distribution)」を参照してください。
1. ポッドトラフィックがオンプレミスホストから出る際、出力マスカレードまたはネットワークアドレス変換 (NAT) を使用するように CNI を設定します。Cilium ではデフォルトで有効になっています。Calico では `natOutgoing` を `true` に設定する必要があります。
1. AWS Application Load Balancer や Amazon Managed Service for Prometheus などの他の AWS サービスは、ハイブリッドノードで実行されているワークロードと通信できません。
### ハイブリッドノードのインストールとアップグレードに必要なアクセス
ホストにハイブリッドノードの依存関係をインストールするインストールプロセス中は、以下のドメインにアクセスできる必要があります。このプロセスは、オペレーティングシステムイメージを構築するときに 1 回実行することも、ランタイム時に各ホストで実行することもできます。これには、初期インストールと、ハイブリッドノードの Kubernetes バージョンをアップグレードするときが含まれます。
パッケージの中には、OS のデフォルトパッケージマネージャーを使用してインストールされるものがあります。AL2023 および RHEL の場合、`yum` コマンドを使用して `containerd`、`ca-certificates`、`iptables`、`amazon-ssm-agent` をインストールします。Ubuntu の場合、`apt` を使用して `containerd`、`ca-certificates`、`iptables` をインストールし、`snap` を使用して `amazon-ssm-agent` をインストールします。
| コンポーネント | [URL] | プロトコル | ポート |
| --- | --- | --- | --- |
| EKS ノードアーティファクト (S3) | https://hybrid-assets.eks.amazonaws.com | HTTPS | 443 |
| [VPC サービスエンドポイント](https://docs.aws.amazon.com/general/latest/gr/eks.html) | https://eks.*region*.amazonaws.com | HTTPS | 443 |
| [ECR サービスエンドポイント](https://docs.aws.amazon.com/general/latest/gr/ecr.html) | https://api.ecr.*region*.amazonaws.com | HTTPS | 443 |
| EKS ECR エンドポイント | リージョンのエンドポイントについては、「[Amazon EKS アドオンの Amazon コンテナイメージレジストリを表示する](add-ons-images.md)」を参照してください。 | HTTPS | 443 |
| SSM バイナリエンドポイント 1 | https://amazon-ssm-*region*.s3.*region*.amazonaws.com | HTTPS | 443 |
| [SSM サービスエンドポイント](https://docs.aws.amazon.com/general/latest/gr/ssm.html) 1 | https://ssm.*region*.amazonaws.com | HTTPS | 443 |
| IAM Anywhere バイナリエンドポイント 2 | https://rolesanywhere.amazonaws.com | HTTPS | 443 |
| [IAM Anywhere サービスエンドポイント](https://docs.aws.amazon.com/general/latest/gr/rolesanywhere.html) 2 | https://rolesanywhere.*region*.amazonaws.com | HTTPS | 443 |
| オペレーティングシステムパッケージマネージャーのエンドポイント | パッケージリポジトリのエンドポイントは OS に固有であり、地理的リージョンによって異なる場合があります。 | HTTPS | 443 |
**注記**
1 AWS SSM エンドポイントへのアクセスは、オンプレミスの IAM 認証情報プロバイダーに AWS SSM ハイブリッドアクティベーションを使用している場合のみ必要です。
2 AWS IAM エンドポイントへのアクセスは、オンプレミスの IAM 認証情報プロバイダーに AWS IAM Roles Anywhere を使用している場合のみ必要です。
### 継続的なクラスター運用に必要なアクセス
クラスターの継続的な運用には、オンプレミスのファイアウォールに以下のネットワークアクセスが必要です。
**重要**
CNI の選択に応じて、CNI ポートに追加のネットワークアクセスルールを設定する必要があります。詳細については、「[Cilium のドキュメント](https://docs.cilium.io/en/stable/operations/system_requirements/#firewall-rules)」および「[Calico のドキュメント](https://docs.tigera.io/calico/latest/getting-started/kubernetes/requirements#network-requirements)」を参照してください。
| タイプ | プロトコル | 方向 | ポート | 送信元 | 目的地 | 使用方法 |
| --- | --- | --- | --- | --- | --- | --- |
| HTTPS | TCP | アウトバウンド | 443 | リモートノード CIDR | EKS クラスター IP 1 | Kubelet から Kubernetes API サーバーへ |
| HTTPS | TCP | アウトバウンド | 443 | リモートポッド CIDR | EKS クラスター IP 1 | Pod から Kubernetes API サーバーへ |
| HTTPS | TCP | アウトバウンド | 443 | リモートノード CIDR | [SSM サービスエンドポイント](https://docs.aws.amazon.com/general/latest/gr/ssm.html) | SSM ハイブリッドアクティベーション認証情報の更新と 5 分ごとの SSM ハートビート |
| HTTPS | TCP | アウトバウンド | 443 | リモートノード CIDR | [IAM Anywhere サービスエンドポイント](https://docs.aws.amazon.com/general/latest/gr/rolesanywhere.html) | IAM Roles Anywhere 認証情報の更新 |
| HTTPS | TCP | アウトバウンド | 443 | リモートポッド CIDR | [STS リージョナルエンドポイント](https://docs.aws.amazon.com/general/latest/gr/sts.html) | Pod から STS エンドポイントへ、IRSA のみ必要 |
| HTTPS | TCP | アウトバウンド | 443 | リモートノード CIDR | [Amazon EKS Auth サービスエンドポイント](https://docs.aws.amazon.com/general/latest/gr/eks.html) | Amazon EKS Pod Identity のみに必要な Amazon EKS 認証エンドポイントへのノード |
| HTTPS | TCP | インバウンド | 10250 | EKS クラスター IP 1 | リモートノード CIDR | Kubernetes API サーバーから kubelet へ |
| HTTPS | TCP | インバウンド | ウェブフックポート | EKS クラスター IP 1 | リモートポッド CIDR | Kubernetes API サーバーからウェブフックへ |
| HTTPS | TCP、UDP | インバウンド、アウトバウンド | 53 | リモートポッド CIDR | リモートポッド CIDR | Pod から CoreDNS へ。クラウドで CoreDNS のレプリカを少なくとも 1 つ実行する場合は、CoreDNS が実行されている VPC への DNS トラフィックを許可する必要があります。 |
| ユーザー定義 | ユーザー定義 | インバウンド、アウトバウンド | アプリポート | リモートポッド CIDR | リモートポッド CIDR | Pod から Pod へ |
**注記**
1 EKS クラスターの IP。Amazon EKS Elastic Network Interface については、次のセクションを参照してください。
### Amazon EKS ネットワークインターフェイス
Amazon EKS は、クラスターの作成時に渡す VPC 内のサブネットにネットワークインターフェイスをアタッチして、EKS コントロールプレーンと VPC 間の通信を有効にします。Amazon EKS が作成するネットワークインターフェイスは、クラスターの作成後に、Amazon EC2 コンソールまたは AWS CLI で確認できます。Kubernetes バージョンのアップグレードなど、EKS クラスターに変更が適用されると、元のネットワークインターフェイスが削除され、新しいネットワークインターフェイスが作成されます。クラスターの作成時に渡すサブネットに制約付きサブネットサイズを使用することで、Amazon EKS ネットワークインターフェイスの IP 範囲を制限できます。これにより、この既知の制約付き IP セットへのインバウンド/アウトバウンド接続を許可するようにオンプレミスファイアウォールを設定することが容易になります。ネットワークインターフェイスが作成されるサブネットを制御するためには、クラスター作成時に指定するサブネットの数を制限するか、クラスター作成後にサブネットを更新することができます。
Amazon EKS によってプロビジョニングされるネットワークインターフェイスには、`Amazon EKS your-cluster-name ` の形式の説明が付けられています。Amazon EKS がプロビジョニングするネットワークインターフェイスの IP アドレスを見つけるために使用できる AWS CLI コマンドについては、以下の例を参照してください。`VPC_ID` を、クラスターの作成時に渡す VPC の ID に置き換えます。
```
aws ec2 describe-network-interfaces \
--query 'NetworkInterfaces[?(VpcId == VPC_ID && contains(Description,Amazon EKS))].PrivateIpAddress'
```
## AWS VPC とサブネットの設定
ハイブリッドノードを持つクラスターには、Amazon EKS の既存の [VPC とサブネットの要件](network-reqs.md)が適用されます。さらに、VPC CIDR はオンプレミスノードおよびポッド CIDR と重複することはできません。オンプレミスノードの VPC ルートテーブルにルートを設定し、オプションでポッド CIDR を設定する必要があります。これらのルートは、ハイブリッドネットワーク接続に使用しているゲートウェイにトラフィックをルーティングするように設定する必要があります。通常、これは仮想プライベートゲートウェイ (VGW) またはトランジットゲートウェイ (TGW) です。TGW または VGW を使用して VPC をオンプレミス環境に接続する場合は、VPC の TGW または VGW アタッチメントを作成する必要があります。VPC は、DNS ホスト名と DNS 解決がサポートされている必要があります。
AWS CLI を使用する手順は以下のとおりです。これらのリソースは AWS マネジメントコンソール で、または AWS CloudFormation、AWS CDK、Terraform などの他のインターフェイスでも作成することができます。
### ステップ 1: VPC を作成する
1. 次のコマンドを実行して VPC を作成します。VPC\$1CIDR を、RFC 1918 (プライベート)、CGNAT (RFC 6598)、または非 RFC 1918/非 CGNAT (パブリック) のいずれかの IPv4 CIDR 範囲に置き換えます (例えば、10.0.0.0/16 など)。注: EKS の要件である DNS 解決は、VPC に対しデフォルトで有効になっています。
```
aws ec2 create-vpc --cidr-block VPC_CIDR
```
1. VPC の DNS ホスト名を有効にします。DNS 解決は、VPC に対しデフォルトで有効になっています。`VPC_ID` を、前のステップで作成した VPC の ID に置き換えます。
```
aws ec2 modify-vpc-attribute --vpc-id VPC_ID --enable-dns-hostnames
```
### ステップ 2: サブネットを作成する
少なくとも 2 つのサブネットを作成します。Amazon EKS は、これらのサブネットをクラスターのネットワークインターフェイスに使用します。詳細については、「[サブネットの要件と考慮事項](network-reqs.md#network-requirements-subnets)」を参照してください。
1. AWS リージョンのアベイラビリティーゾーンは、以下のコマンドで確認できます。`us-west-2` を実際のリージョンに置き換えます。
```
aws ec2 describe-availability-zones \
--query 'AvailabilityZones[?(RegionName == us-west-2)].ZoneName'
```
1. サブネットを作成します。`VPC_ID` を VPC の ID に置き換えます。`SUBNET_CIDR` を、サブネットの CIDR ブロック (10.0.1.0/24 など) に置き換えます。`AZ` を、サブネットが作成されるアベイラビリティーゾーン (us-west-2a など) に置き換えます。作成するサブネットは、少なくとも 2 つの異なるアベイラビリティーゾーンに存在している必要があります。
```
aws ec2 create-subnet \
--vpc-id VPC_ID \
--cidr-block SUBNET_CIDR \
--availability-zone AZ
```
### (オプション) ステップ 3: Amazon VPC Transit Gateway (TGW) または AWS Direct Connect 仮想プライベートゲートウェイ (VGW) を使用して VPC をアタッチする
TGW または VGW を使用している場合は、VPC を TGW または VGW にアタッチします。詳細については、「[Amazon VPC attachments in Amazon VPC Transit Gateways](https://docs.aws.amazon.com/vpc/latest/tgw/tgw-vpc-attachments.html)」または「[AWS Direct Connect virtual private gateway associations](https://docs.aws.amazon.com/vpn/latest/s2svpn/how_it_works.html#VPNGateway)」を参照してください。
**Transit Gateway**
以下のコマンドを実行して、トランジットゲートウェイをアタッチします。`VPC_ID` を VPC の ID に置き換えます。`SUBNET_ID1` と `SUBNET_ID2` を、前のステップで作成したサブネットの ID に置き換えます。`TGW_ID` を TGW の ID に置き換えます。
```
aws ec2 create-transit-gateway-vpc-attachment \
--vpc-id VPC_ID \
--subnet-ids SUBNET_ID1 SUBNET_ID2 \
--transit-gateway-id TGW_ID
```
**仮想プライベートゲートウェイ**
以下のコマンドを実行して、トランジットゲートウェイをアタッチします。`VPN_ID` をVGW の ID に置き換えます。`VPC_ID` を VPC の ID に置き換えます。
```
aws ec2 attach-vpn-gateway \
--vpn-gateway-id VPN_ID \
--vpc-id VPC_ID
```
### (オプション) ステップ 4: ルートテーブルを作成する
VPC のメインルートテーブルを変更するか、カスタムルートテーブルを作成できます。以下の手順では、オンプレミスノードとポッド CIDR へのルートを含むカスタムルートテーブルを作成します。詳細については、「[サブネットルートテーブル](https://docs.aws.amazon.com/vpc/latest/userguide/subnet-route-tables.html)」を参照してください。`VPC_ID` を VPC の ID に置き換えます。
```
aws ec2 create-route-table --vpc-id VPC_ID
```
### ステップ 5: オンプレミスノードとポッドのルートを作成する
オンプレミスの各リモートノードのルートテーブルにルートを作成します。VPC のメインルートテーブルを変更するか、前のステップで作成したカスタムルートテーブルを使用できます。
以下の例は、オンプレミスノードとポッド CIDR のルートを作成する方法を示します。この例では、トランジットゲートウェイ (TGW) を使用して VPC をオンプレミス環境に接続します。複数のオンプレミスノードとポッド CIDR がある場合は、CIDR ごとにステップを繰り返します。
+ インターネットゲートウェイまたは仮想プライベートゲートウェイ (VGW) を使用している場合は、`--transit-gateway-id` を `--gateway-id` に置き換えます。
+ `RT_ID` を、前のステップで作成したルートテーブルの ID に置き換えます。
+ `REMOTE_NODE_CIDR` を、ハイブリッドノードに使用する CIDR 範囲に置き換えます。
+ `REMOTE_POD_CIDR` を、ハイブリッドノードで稼働しているポッドに使用する CIDR 範囲に置き換えます。ポッド CIDR 範囲は、オンプレミスのオーバーレイネットワークを最も一般的に使用するコンテナネットワークインターフェイス (CNI) 設定に対応しています。詳細については、「[ハイブリッドノードの CNI を設定する](hybrid-nodes-cni.md)」を参照してください。
+ `TGW_ID` を TGW の ID に置き換えます。
**リモートノードネットワーク**
```
aws ec2 create-route \
--route-table-id RT_ID \
--destination-cidr-block REMOTE_NODE_CIDR \
--transit-gateway-id TGW_ID
```
**リモートポッドネットワーク**
```
aws ec2 create-route \
--route-table-id RT_ID \
--destination-cidr-block REMOTE_POD_CIDR \
--transit-gateway-id TGW_ID
```
### (オプション) ステップ 6: サブネットをルートテーブルに関連付ける
前のステップでカスタムルートテーブルを作成した場合は、前のステップで作成した各サブネットをカスタムルートテーブルに関連付けます。VPC メインルートテーブルを変更する場合、サブネットは VPC のメインルートテーブルに自動的に関連付けられるため、このステップをスキップできます。
前のステップで作成したサブネットごとに、以下のコマンドを実行します。`RT_ID` を、前のステップで作成したルートテーブルに置き換えます。`SUBNET_ID` をサブネットの ID に置き換えます。
```
aws ec2 associate-route-table --route-table-id RT_ID --subnet-id SUBNET_ID
```
## クラスターセキュリティグループの設定
クラスターの継続的な運用には、EKS クラスターセキュリティグループの以下のアクセスが必要です。Amazon EKS は、リモートノードとポッドネットワークが設定されたクラスターを作成または更新するときに、ハイブリッドノードに必要な**インバウンド**セキュリティグループルールを自動的に作成します。セキュリティグループがデフォルトですべての**アウトバウンド**トラフィックを許可するため、Amazon EKS はハイブリッドノードのクラスターセキュリティグループの**アウトバウンド**ルールを自動的には変更しません。クラスターセキュリティグループをカスタマイズする場合は、以下の表に示したルールにトラフィックを制限できます。
| タイプ | プロトコル | 方向 | ポート | 送信元 | 目的地 | 使用方法 |
| --- | --- | --- | --- | --- | --- | --- |
| HTTPS | TCP | インバウンド | 443 | リモートノード CIDR | 該当なし | Kubelet から Kubernetes API サーバーへ |
| HTTPS | TCP | インバウンド | 443 | リモートポッド CIDR | 該当なし | CNI がポッドトラフィックに NAT を使用していない場合で、ポッドが K8s API サーバーへのアクセスを必要とする場合。 |
| HTTPS | TCP | アウトバウンド | 10250 | 該当なし | リモートノード CIDR | Kubernetes API サーバーから Kubelet へ |
| HTTPS | TCP | アウトバウンド | ウェブフックポート | 該当なし | リモートポッド CIDR | Kubernetes API サーバーからウェブフックへ (ハイブリッドノードでウェブフックを実行している場合) |
**重要**
**セキュリティグループルールの制限**: Amazon EC2 セキュリティグループに保持できるインバウンドルールはデフォルトで最大 60 個です。クラスターセキュリティグループがこの制限に近づいた場合、セキュリティグループのインバウンドルールが適用されないことがあります。この場合、欠落しているインバウンドルールを手動で追加しなければならないことがあります。
**CIDR クリーンアップの責任**: EKS クラスターからリモートノードまたはポッドネットワークを削除した場合、EKS は対応するセキュリティグループルールを自動的に削除しません。セキュリティグループルールから未使用のリモートノードまたはポッドネットワークを手動で削除する責任はお客様にあります。
Amazon EKS が作成するクラスターセキュリティグループの詳細については「[クラスターの Amazon EKS セキュリティグループ要件を表示する](sec-group-reqs.md)」を参照してください。
### (オプション) セキュリティグループの手動設定
追加のセキュリティグループを作成したり、自動的に作成されたルールを変更したりする必要がある場合は、次のコマンドを参照として使用できます。デフォルトでは、以下のコマンドは、すべてのアウトバウンドアクセスを許可するセキュリティグループを作成します。アウトバウンドアクセスを上記のルールのみに制限することができます。アウトバウンドルールの制限を検討している場合、変更したルールを本番稼働用のクラスターに適用する前に、すべてのアプリケーションとポッドの接続を徹底的にテストすることをお勧めします。
+ 最初のコマンドで、`SG_NAME` をセキュリティグループの名前に置き換えます
+ 最初のコマンドで、`VPC_ID` を前のステップで作成した VPC の ID に置き換えます
+ 2 番目のコマンドで、`SG_ID` を最初のコマンドで作成したセキュリティグループの ID に置き換えます
+ 2 番目のコマンドで、`REMOTE_NODE_CIDR` と `REMOTE_POD_CIDR` をハイブリッドノードとオンプレミスネットワークの値にそれぞれ置き換えます。
```
aws ec2 create-security-group \
--group-name SG_NAME \
--description "security group for hybrid nodes" \
--vpc-id VPC_ID
```
```
aws ec2 authorize-security-group-ingress \
--group-id SG_ID \
--ip-permissions '[{"IpProtocol": "tcp", "FromPort": 443, "ToPort": 443, "IpRanges": [{"CidrIp": "REMOTE_NODE_CIDR"}, {"CidrIp": "REMOTE_POD_CIDR"}]}]'
```