【実務・中級編】インターフェイス型VPCエンドポイント(AWS PrivateLink)のDNS名前解決の仕組み – クラウドインフラと仮想化ネットワーク実践ガイド

AWS PrivateLinkの舞台裏: インターフェイス型VPCエンドポイントのDNS名前解決を解き明かす

皆さん、こんにちは！最前線のSREとして、日々クラウドの深淵でパケットと格闘している私です。今回は、AWSの強力なネットワークサービスである AWS PrivateLink、その中でも特に インターフェイス型VPCエンドポイント の「DNS名前解決の仕組み」に焦点を当てて、皆さんの実務に役立つ知見をお届けします。

Web APIの設計やインフラ運用に携わる皆さんなら、パブリックインターネットを経由せずに、セキュアかつ高速にAWSサービスに接続したいというニーズは常にありますよね。PrivateLinkはまさにそのためのソリューションですが、「なぜAWSサービスのパブリックなDNS名が、VPC内のプライベートIPアドレスに解決されるのか？」という、その裏側にある魔法のような仕組みを、パケットの動きから紐解いていきましょう。

はじめに: パブリックインターネットの喧騒を離れて

アプリケーションがS3やDynamoDB、SQSといったAWSサービスと通信する際、通常はインターネットゲートウェイを経由し、パブリックIPアドレスを介してアクセスします。これは手軽で便利ですが、セキュリティ、ネットワークパフォーマンス、そしてデータ転送料といった面で課題が生じることがあります。

セキュリティ: パブリックインターネットを通過する通信は、常に外部からの脅威に晒されるリスクを伴います。
パフォーマンス: インターネットを経由するため、経路が不安定になったり、レイテンシが増大したりする可能性があります。
データ転送料: インターネットゲートウェイを経由するデータ転送には、通常料金が発生します。

これらの課題を解決し、VPC内からAWSサービスへ「プライベートな経路」で接続するための切り札が、AWS PrivateLinkです。PrivateLinkは、皆さんのVPCとAWSサービス（または他のVPCでホストされているサービス）の間に、仮想的なプライベート接続を確立します。これにより、トラフィックはAWSのネットワークバックボーン内にとどまり、インターネットを経由することなく、セキュアにサービスにアクセスできるようになるのです。

今回は、このPrivateLinkの中でも、AWSマネージドサービスへの接続に利用する インターフェイス型VPCエンドポイント に焦点を当てます。

インターフェイス型VPCエンドポイントとは？その正体と役割

インターフェイス型VPCエンドポイント（以下、VPCエンドポイント）は、皆さんのVPC内に作成される特殊な「ネットワークインターフェイス (ENI)」のようなものだと考えてください。このENIは、皆さんの指定したサブネットに配置され、VPCのIPアドレス範囲からプライベートIPアドレスを割り当てられます。

このENIが何をしてくれるかというと、AWSサービスへのトラフィックを、まるでVPC内の他のインスタンスに接続するかのように、プライベートなIPアドレスとElastic Network Interface（ENI）を介してルーティングしてくれるのです。

これにより、以下のようなメリットが得られます。

完全なプライベート接続: インターネットゲートウェイ、NATゲートウェイ、VPN接続、Direct Connectなどを経由することなく、VPC内からAWSサービスに直接接続できます。
セキュリティの向上: ネットワークACLやセキュリティグループで、VPCエンドポイントへのアクセスを細かく制御できます。
シンプルなネットワークアーキテクチャ: 複雑なルーティング設定や、パブリックIPアドレス管理が不要になります。

しかし、ここで一つの疑問が浮かびませんか？ S3のようなAWSサービスにアクセスする場合、通常は s3.ap-northeast-1.amazonaws.com のようなパブリックなDNS名を使います。PrivateLinkがプライベートな接続を提供すると言っても、アプリケーションはこれまで通り、このパブリックなDNS名で解決しようとします。どうやってそれがプライベートIPアドレスに解決されるのでしょうか？その魔法の正体こそが、DNS名前解決の仕組み に隠されています。

DNS名前解決の肝: プライベートホストゾーンとPrivateDnsEnabled

PrivateLinkの真骨頂は、このDNS解決の仕組みにあります。皆さんのアプリケーションがAWSサービスのパブリックDNS名をクエリした際、その名前が自動的にVPCエンドポイントのプライベートIPアドレスに解決される――この一連の動作こそが、PrivateLinkを非常に強力かつ透過的なものにしている理由です。

この「魔法」を可能にするためには、いくつかの重要な設定が裏で連携しています。

1. VPCのDNSサポート設定:

enableDnsSupport: VPCでDNS解決を有効にするか。trueである必要があります。
enableDnsHostnames: VPC内のEC2インスタンスがDNSホスト名を取得するか。これもtrueである必要があります。
これらの設定は、VPCが内部のDNSリゾルバ（VPCのCIDR + .2 のIPアドレス、例: 10.0.0.2）を使ってDNSクエリを処理し、プライベートホストゾーンと連携するために不可欠です。

2. VPCエンドポイントの PrivateDnsEnabled オプション:

VPCエンドポイントを作成する際に、--private-dns-enabled オプションをtrueに設定します。
この設定が真価を発揮すると、AWSは裏で皆さんのVPCの内部DNSリゾルバと連携し、VPCエンドポイントのための特殊な プライベートホストゾーン を自動的に設定します。

具体的には、PrivateDnsEnabled をtrueにしてVPCエンドポイントを作成すると、AWSは以下の設定を自動的に行います。

VPCエンドポイントに割り当てられたENIに、そのVPCエンドポイントに特有のDNS名（例: vpce-xxxxxxxxxxxx-xxxxxxxx.s3.ap-northeast-1.vpce.amazonaws.com）を付与します。
皆さんのVPCの内部DNSリゾルバに対して、AWSサービスのパブリックDNS名（例: s3.ap-northeast-1.amazonaws.com）に対するクエリが来た場合、それを上記のVPCエンドポイント固有のDNS名への CNAMEレコード として解決するように指示します。
最終的に、このCNAMEレコードがVPCエンドポイントのプライベートIPアドレスに解決されます。

これにより、アプリケーション側はS3にアクセスする際、これまでと全く同じ s3.ap-northeast-1.amazonaws.com というURLを使っていながら、裏ではプライベートな経路で接続が確立されるわけです。アプリケーションコードを変更する必要がない、という点は非常に強力です。

DNS解決のシーケンスを追う: パケットが駆け巡る道筋

では、具体的にDNSクエリがどのように処理され、パケットがVPCエンドポイントに到達するのか、そのシーケンスを追ってみましょう。

1. アプリケーションからのDNSクエリ発行:

VPC内のEC2インスタンスで動作するアプリケーションが、例えばS3バケットにアクセスしようと、https://s3.ap-northeast-1.amazonaws.com/your-bucket/your-object のようなURLにアクセスを試みます。
この際、OSのDNSリゾルバ（通常は /etc/resolv.conf に設定されているVPCの内部DNSリゾルバ VPC_CIDR_RANGE.2）に対して、s3.ap-northeast-1.amazonaws.com のIPアドレスを問い合わせるDNSクエリを発行します。

2. VPC内部DNSリゾルバの挙動:

VPCの内部DNSリゾルバは、受け取ったクエリ s3.ap-northeast-1.amazonaws.com を処理します。
PrivateDnsEnabled がtrueでVPCエンドポイントが作成されている場合、VPC内部DNSリゾルバは、このクエリをVPCエンドポイントのために自動生成されたCNAMEレコード（例: s3.ap-northeast-1.amazonaws.com -> vpce-xxxxxxxxxxxx-xxxxxxxx.s3.ap-northeast-1.vpce.amazonaws.com）に変換します。
次に、VPC内部DNSリゾルバは、このエンドポイント固有のDNS名 vpce-xxxxxxxxxxxx-xxxxxxxx.s3.ap-northeast-1.vpce.amazonaws.com を解決します。
最終的に、この名前はVPCエンドポイントに割り当てられたプライベートIPアドレス（例: 10.0.1.15, 10.0.2.20 など、複数のENIがある場合は複数のIP）に解決され、アプリケーションに返されます。

3. アプリケーションによる接続:

アプリケーションは、DNSリゾルバから返されたプライベートIPアドレスを使って、VPCエンドポイントのENIに直接TCP接続（通常はHTTPSなのでポート443）を試みます。
このトラフィックはVPC内を流れ、インターネットゲートウェイを一切経由しません。
VPCエンドポイントのENIは、そのVPCエンドポイントが接続しているAWSサービス（この例ではS3）へのトラフィックを、AWSの内部ネットワークバックボーンを通じてルーティングします。

この一連の流れにより、アプリケーションはインターネットへの出口を持つことなく、セキュアにAWSサービスと通信できるようになるのです。

実際の挙動を確認する: digとnslookupで覗き込む

実際にVPC内のEC2インスタンスから、DNS解決の挙動を確認してみましょう。

【事前準備】

VPC内にEC2インスタンスを起動し、SSH接続できるようにする。
S3用のインターフェイス型VPCエンドポイントを、--private-dns-enabled オプションをtrueにして作成しておく。
エンドポイントのセキュリティグループは、EC2インスタンスからのHTTPS (TCP 443) を許可するルールを設定する。
エンドポイントを配置するサブネットと、EC2インスタンスがあるサブネット間のルーティングが正しく行われていることを確認する。

EC2インスタンス内での確認:

# S3 VPCエンドポイント作成前のS3 DNS解決
# (PrivateDnsEnabled=falseの場合も同様)
# 通常、S3のパブリックIPアドレスが返されます。
# 例えば、EC2インスタンスをPrivateLink作成前に起動し、その後PrivateLinkを作成した場合、
# キャッシュがなければ自動的にPrivateLink経由の解決に切り替わります。
# 以下はPrivateLinkが有効になる前、またはPrivateDnsEnabled=falseの場合の例です。
$ dig s3.ap-northeast-1.amazonaws.com +short
# 実際の出力例:
# 52.219.148.16
# 52.219.148.80
# (複数のパブリックIPが表示されることがあります)

# --- ここからVPCエンドポイント作成後 (PrivateDnsEnabled=true) ---

# S3 VPCエンドポイント作成後（PrivateDnsEnabled=true）のS3 DNS解決
# プライベートIPアドレスが返ってくることを確認します。
$ dig s3.ap-northeast-1.amazonaws.com +short
# 実際の出力例:
# s3.ap-northeast-1.vpce.amazonaws.com.
# vpce-xxxxxxxxxxxx-xxxxxxxx.s3.ap-northeast-1.vpce.amazonaws.com.
# 10.0.1.15
# 10.0.2.20
# (VPCエンドポイントのENIに割り当てられたプライベートIPアドレスが表示されます)

# エンドポイントの内部DNS名も直接確認してみましょう。
# これはCNAMEのターゲットになっているDNS名です。
# (vpce-xxxxxxxxxxxx-xxxxxxxx の部分はご自身のVPCエンドポイントIDに依存します)
$ dig vpce-xxxxxxxxxxxx-xxxxxxxx.s3.ap-northeast-1.vpce.amazonaws.com +short
# 実際の出力例:
# 10.0.1.15
# 10.0.2.20
# (同様にプライベートIPアドレスが表示されます)

digコマンドの出力から、s3.ap-northeast-1.amazonaws.com が直接パブリックIPではなく、VPCエンドポイント固有のDNS名を経由して、最終的にVPC内のプライベートIPアドレスに解決されていることが明確にわかりますね。これが、PrivateLinkのDNS解決の「舞台裏」です。

コード例: アプリケーションからのアクセス

VPCエンドポイントが適切に設定されていれば、ほとんどのAWS SDKやツールは、特別な設定なしにPrivateLinkの恩恵を受けられます。DNS解決が透過的に行われるため、アプリケーションコードを変更する必要がないからです。

Python (boto3) の例

PythonのAWS SDKであるboto3を使ってS3にアクセスする例です。VPCエンドポイントの有無に関わらず、コードは同じです。

import boto3
import os

# S3クライアントを初期化
# PrivateLinkが設定されていれば、自動的にプライベート経路が使われるため、
# 通常のS3エンドポイントURLを指定するだけでOKです。
s3 = boto3.client('s3', region_name='ap-northeast-1')

try:
    print("S3バケット一覧を取得中...")
    response = s3.list_buckets()
    print("S3 Buckets:")
    for bucket in response['Buckets']:
        print(f"- {bucket['Name']}")
except Exception as e:
    print(f"S3へのアクセス中にエラーが発生しました: {e}")

# 特定のバケットからオブジェクトを取得する例
bucket_name = 'your-private-bucket-name' # ご自身のプライベートバケット名に置き換えてください
object_key = 'your-object-key.txt'      # 取得したいオブジェクトのキーに置き換えてください

try:
    print(f"\nバケット '{bucket_name}' からオブジェクト '{object_key}' を取得中...")
    response = s3.get_object(Bucket=bucket_name, Key=object_key)
    # オブジェクトの内容を読み込み、UTF-8でデコード
    body = response['Body'].read().decode('utf-8')
    print(f"'{object_key}' の内容 (冒頭200文字):\n{body[:200]}...") # 冒頭200文字を表示
except s3.exceptions.NoSuchKey:
    print(f"エラー: バケット '{bucket_name}' にオブジェクト '{object_key}' が見つかりません。")
except Exception as e:
    print(f"S3からオブジェクトを取得中にエラーが発生しました: {e}")

curlでのアクセス例 (S3)

curlコマンドでS3にアクセスする場合も、DNS解決がプライベートIPに向くため、特別な指定は不要です。ただし、S3へのGETリクエストは通常、認証のための署名が必要になるため、AWS CLIで署名付きURLを生成してアクセスするのが一般的です。

# S3への署名付きURLを生成する例 (AWS CLIを使用)
# これはVPC内のEC2インスタンスから実行することを想定しています。
# AWS CLIが適切に設定されており、S3へのアクセス権限を持つIAMロールがアタッチされている必要があります。
# 'your-private-bucket-name' と 'your-object-key.txt' はご自身の環境に合わせて変更してください。
BUCKET_NAME="your-private-bucket-name"
OBJECT_KEY="your-object-key.txt"

echo "S3オブジェクトへの署名付きURLを生成中..."
SIGNED_URL=$(aws s3 presign "s3://${BUCKET_NAME}/${OBJECT_KEY}" --expires-in 3600) # 1時間有効なURLを生成

if [ -z "$SIGNED_URL" ]; then
    echo "エラー: 署名付きURLの生成に失敗しました。AWS CLIの設定やS3アクセス権限を確認してください。"
else
    echo "生成された署名付きURL: ${SIGNED_URL}"
    echo "curlコマンドでアクセス中..."
    # 生成された署名付きURLを使ってcurlでアクセス
    # PrivateLinkが有効であれば、このリクエストはプライベートIP経由でS3にルーティングされます。
    curl -s "${SIGNED_URL}"
    echo "" # 改行
fi

Fetch API (API Gateway REST APIのVPCエンドポイント) の例

API GatewayのプライベートAPIにVPCエンドポイント経由でアクセスする場合、通常はAPI Gatewayにカスタムドメイン名を設定し、そのドメイン名をRoute 53プライベートホストゾーンでVPCエンドポイントのプライベートIPに解決させます。このケースはS3などのAWSマネージドサービスとは少し異なり、明示的なRoute 53プライベートホストゾーンの連携が必要になります。

以下は、api.your-company.com というカスタムドメイン名が、VPCエンドポイント経由でAPI GatewayのプライベートAPIを指すように設定されているという前提での例です。

// fetch-api-example.js
async function fetchDataFromPrivateApi() {
    // VPCエンドポイント経由でアクセスするAPI GatewayのカスタムドメインURL
    // このドメイン名がRoute 53プライベートホストゾーンによってプライベートIPに解決される
    const apiUrl = 'https://api.your-company.com/your-resource'; 

    // 必要に応じて認証ヘッダーなどを追加
    const headers = {
        'Content-Type': 'application/json',
        // 'Authorization': 'Bearer YOUR_AUTH_TOKEN' // 例えば、CognitoやIAMによる認証
    };

    try {
        console.log(`Private API (${apiUrl}) からデータを取得中...`);
        const response = await fetch(apiUrl, {
            method: 'GET',
            headers: headers
        });

        if (!response.ok) {
            // HTTPエラーレスポンスの場合、詳細なエラーメッセージを取得
            const errorBody = await response.text();
            throw new Error(`HTTPエラー! ステータス: ${response.status}, ボディ: ${errorBody}`);
        }

        const data = await response.json();
        console.log('Private APIからのデータ:', data);
    } catch (error) {
        console.error('データの取得中にエラーが発生しました:', error);
    }
}

// 関数を実行
fetchDataFromPrivateApi();

【補足】API GatewayプライベートAPIとPrivateLink
API GatewayのプライベートAPIの場合、VPCエンドポイントを介してアクセスする際に、VPCエンドポイントのDNS名ではなく、API Gatewayに設定したカスタムドメイン名を使用することが推奨されます。このカスタムドメイン名が、Route 53プライベートホストゾーンによってVPCエンドポイントのプライベートIPアドレスに解決されるように設定する必要があります。これは、S3などの一部のAWSサービスのように PrivateDnsEnabled オプションだけでパブリックDNS名がVPCエンドポイントに解決されるケースとは少し異なるため、注意が必要です。

設定例: AWS CLIでのVPCエンドポイント作成

実際にAWS CLIを使ってVPCエンドポイントを作成するコマンド例を見てみましょう。S3へのVPCエンドポイントを作成する例です。

# VPCエンドポイント（S3用）を作成するAWS CLIコマンド例

# --- 事前準備: 必要なIDを環境変数に設定 ---
# ご自身の環境に合わせて、VPC ID, サブネットID, セキュリティグループIDは事前に取得しておいてください。
# 例: aws ec2 describe-vpcs --filters "Name=tag:Name,Values=MyProdVPC" --query "Vpcs[0].VpcId" --output text
# 例: aws ec2 describe-subnets --filters "Name=vpc-id,Values=${VPC_ID}" "Name=tag:Name,Values=MyPrivateSubnet*" --query "Subnets[].SubnetId" --output text
# 例: aws ec2 describe-security-groups --filters "Name=vpc-id,Values=${VPC_ID}" "Name=tag:Name,Values=VPC-Endpoint-SG" --query "SecurityGroups[0].GroupId" --output text

VPC_ID="vpc-xxxxxxxxxxxxxxxxx"             # ご自身のVPC IDに置き換えてください
SUBNET_ID_1="subnet-xxxxxxxxxxxxxxxxx"    # エンドポイントを配置するサブネットID (AZごとに1つ推奨)
SUBNET_ID_2="subnet-yyyyyyyyyyyyyyyyy"    # 別のAZのサブネットID (高可用性のため複数指定推奨)
SECURITY_GROUP_ID="sg-zzzzzzzzzzzzzzzzz"  # エンドポイントに関連付けるセキュリティグループID

# S3のサービス名はリージョンごとに異なる形式です。
# ap-northeast-1 (東京リージョン) のS3のサービス名
SERVICE_NAME="com.amazonaws.ap-northeast-1.s3" 

echo "S3用インターフェイス型VPCエンドポイントを作成中..."
VPC_ENDPOINT_ID=$(aws ec2 create-vpc-endpoint \
    --vpc-id "${VPC_ID}" \
    --vpc-endpoint-type Interface \
    --service-name "${SERVICE_NAME}" \
    --subnet-ids "${SUBNET_ID_1}" "${SUBNET_ID_2}" \
    --security-group-ids "${SECURITY_GROUP_ID}" \
    --private-dns-enabled \
    --tag-specifications 'ResourceType=vpc-endpoint,Tags=[{Key=Name,Value=s3-interface-endpoint}]' \
    --query 'VpcEndpoint.VpcEndpointId' \
    --output text)

if [ -z "$VPC_ENDPOINT_ID" ]; then
    echo "エラー: VPCエンドポイントの作成に失敗しました。"
    exit 1
fi

echo "VPCエンドポイントの作成を開始しました。ID: ${VPC_ENDPOINT_ID}"
echo "VPCエンドポイントのステータスが 'available' になるまで、数分かかる場合があります。"
echo "コンソールまたは以下のコマンドでステータスを確認してください。"

# 作成後の確認コマンド
echo "確認コマンド例: aws ec2 describe-vpc-endpoints --vpc-endpoint-ids ${VPC_ENDPOINT_ID}"
aws ec2 describe-vpc-endpoints --vpc-endpoint-ids "${VPC_ENDPOINT_ID}" --query "VpcEndpoints[0].State" --output text

このコマンドで最も重要なオプションは --private-dns-enabled です。これをtrueにすることで、前述のDNS名前解決の仕組みが自動的に設定され、VPC内のアプリケーションが特別な設定なしにPrivateLinkの恩恵を受けられるようになります。

トラブルシューティングのヒント: 泥臭い現場から

PrivateLinkは非常に便利ですが、やはりネットワーク。トラブルが発生することもあります。現場でよく遭遇する問題と、そのデバッグポイントをいくつかご紹介しましょう。

dig や nslookup でプライベートIPに解決されない:
VPCのDNSサポート設定: VPCの enableDnsSupport と enableDnsHostnames が両方とも true になっているか確認してください。これらが false だと、VPC内部DNSリゾルバが正しく機能しません。
エンドポイントの PrivateDnsEnabled 設定: VPCエンドポイント作成時に --private-dns-enabled を true にしているか確認してください。これが false だと、自動的なプライベートDNS解決は行われません。
DHCPオプションセット: VPCにカスタムのDHCPオプションセット（例えば、Route 53 Resolver for Hybrid DNS）が適用されている場合、それが原因でVPC内部DNSリゾルバの挙動が変わることがあります。
Route 53 Resolverのルール: Route 53 Resolverを使っている場合、誤ったフォワードルールやシステムルールが適用されていないか確認します。

DNSはプライベートIPに解決されるが、サービスへの接続がタイムアウトする:
VPCエンドポイントのステータス: aws ec2 describe-vpc-endpoints コマンドで、VPCエンドポイントのステータスが available になっているか確認してください。pending や failed の場合はまだ使えません。
セキュリティグループ: VPCエンドポイントに関連付けられたセキュリティグループのインバウンドルールを確認してください。VPC内のソース（EC2インスタンスのプライベートIP範囲やセキュリティグループ）からの、サービスが必要とするポート（例: HTTPSならTCP 443）へのアクセスを許可する必要があります。
NACL: サブネットのネットワークACLで、VPCエンドポイントのENIへのインバウンド/アウトバウンドトラフィックが許可されているか確認してください。
ルートテーブル: EC2インスタンスがVPCエンドポイントのENIと同じサブネットにいるか、またはEC2インスタンスがいるサブネットのルートテーブルに、VPCエンドポイントのENIが存在するサブネットへのルートが正しく設定されているか確認してください。通常、VPC内のルーティングは自動ですが、意図しない変更がないか確認しましょう。
サービス側の設定: 接続しようとしているAWSサービス自体が、VPCエンドポイントからのアクセスを許可するように設定されているか確認します。S3のバケットポリシーや、SQSのアクセスポリシーなどです。

複数のVPCエンドポイントが存在する場合の競合:
同じサービスに対して複数のVPCエンドポイントが存在し、それぞれ異なる設定になっている場合、どちらが優先されるかという問題が発生することがあります。通常は最も新しい、または特定の条件で選択されますが、意図しないVPCエンドポイントが使われる可能性も考慮しましょう。

これらのチェックリストは、私がこれまで数々のネットワーク障害を乗り越えてきた経験から得た、実践的なデバッグの出発点です。パケットは嘘をつきません。dig や nslookup、telnet や curl といった基本的なツールを駆使し、どこで通信が止まっているのか、何が解決されているのかを一つ一つ確認していくことが重要です。

まとめ: PrivateLinkでセキュアでシンプルなアーキテクチャを

今回は、AWS PrivateLinkのインターフェイス型VPCエンドポイントにおけるDNS名前解決の仕組みに深く踏み込みました。パブリックDNS名がVPCエンドポイントのプライベートIPアドレスに透過的に解決される裏側には、VPC内部DNSリゾルバと PrivateDnsEnabled オプションが連携して機能していることがお分かりいただけたかと思います。

この仕組みを理解することは、PrivateLinkを単なる「セキュアな接続」として使うだけでなく、以下のようなメリットをもたらします。

アーキテクチャの堅牢性向上: DNS解決のフローを理解することで、ネットワーク設計の選択肢が広がり、より堅牢なシステムを構築できます。
トラブルシューティング能力の向上: 問題発生時に、どこをチェックすべきかという見当がつきやすくなり、解決までの時間を短縮できます。
リソース管理の最適化: PrivateLinkによってデータ転送料の削減や、インターネットゲートウェイ経由のトラフィック量削減にも繋がります。

クラウドインフラが複雑化する現代において、このような「見えない部分」の挙動を深く理解していることは、皆さんのエンジニアとしての市場価値を間違いなく高めます。ぜひ、今回学んだ知識を日々の実務に活かし、セキュアで高性能なシステム構築に役立ててください。

それでは、また次の記事で！ AWSの奥深き世界でお会いしましょう！