AWS ParallelCluster で使う場合のある VPC エンドポイントを洗い出してみた

はじめに

AWS ParallelCluster の構築でインターネットへは閉域網経由で出てかつ、可能な限り VPC のエンドポイントを利用する方針の要件がありました。そこで AWS ParallelCluster v3.15.1 で小規模なクラスターを作成し、VPC エンドポイント経由にできる通信先を洗い出しました。そちらを共有します。

確認結果

AWS ParallelCluster v3.15.1 で、IAM ロールと CloudFormation リソースの 2 つの観点で洗い出した結果、必要なエンドポイントは次のとおりです。必須の 5 つは公式ドキュメントの一覧と一致しました。オプションの項目は、特定の機能を有効化したときに追加で必要になります。

洗い出しの方針

ParallelCluster がどの AWS サービスと通信するかは、作成されるリソースからある程度逆算できます。今回は 2 つの観点で特定しました。1 つは CloudFormation の作成リソースです。スタックのリソース一覧から通信先サービスを特定します。もう 1 つは IAM ロールの許可アクションです。作成される 許可のポリシーから、操作対象サービスのプレフィックス（ec2:、dynamodb: 等）を確認します。

公式ドキュメントにも、単一サブネットでインターネットアクセスのない構成の必要エンドポイント一覧があります。

https://docs.aws.amazon.com/parallelcluster/latest/ug/aws-parallelcluster-in-a-single-public-subnet-no-internet-v3.html

ただし有効化する機能ごとの追加分までは網羅していません。たとえば Slurm Accounting の構成次第では必要になる Secrets Manager は公式の一覧には含まれていませんでした。そのため、実環境のリソースから洗い出すことにしました。

検証用のクラスターを作成する

検証用に、Slurm スケジューラの最小クラスターを作成します。主な構成は次のとおりです。

クラスター設定ファイル cluster-config.yaml を次の内容で用意します。

Region: ap-northeast-1
Image:
  Os: ubuntu2404
Tags:
  - Key: Name
    Value: pc-vpce-survey
# ----------------------------------------------------------------
# Head Node Settings
# ----------------------------------------------------------------
HeadNode:
  InstanceType: t3a.small
  Networking:
    ElasticIp: false
    SubnetId: subnet-029f0fb0acc64043d
  LocalStorage:
    RootVolume:
      Size: 45
      Encrypted: true
      VolumeType: gp3
      Iops: 3000
      Throughput: 125
  Iam:
    AdditionalIamPolicies:
      - Policy: arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore
# ----------------------------------------------------------------
# Compute Node Settings
# ----------------------------------------------------------------
Scheduling:
  Scheduler: slurm
  SlurmSettings:
    ScaledownIdletime: 5
  SlurmQueues:
    - Name: queue1
      ComputeResources:
        - Name: compute1
          Instances:
            - InstanceType: t3a.micro
          MinCount: 0
          MaxCount: 1
      ComputeSettings:
        LocalStorage:
          RootVolume:
            Size: 45
            Encrypted: true
            VolumeType: gp3
            Iops: 3000
            Throughput: 125
      CapacityType: SPOT
      AllocationStrategy: price-capacity-optimized
      Networking:
        SubnetIds:
          - subnet-029f0fb0acc64043d
      Iam:
        AdditionalIamPolicies:
          - Policy: arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore
# ----------------------------------------------------------------
# Monitoring Settings
# ----------------------------------------------------------------
Monitoring:
  Logs:
    CloudWatch:
      Enabled: true
      RetentionInDays: 180
      DeletionPolicy: "Delete"
  Dashboards:
    CloudWatch:
      Enabled: false

用意した cluster-config.yaml を使い、pcluster CLI でクラスター名 pc-vpce-survey のクラスターを作成します。作成コマンドや CLI のセットアップは、参考の入門記事を参照してください。

CloudFormation の作成リソースから洗い出す

ParallelCluster はクラスター作成時に CloudFormation スタックを作成します。v3 ではクラスター名がそのままスタック名になるため、先ほど作成した pc-vpce-survey をスタック名に指定します。スタックのリソースタイプを確認すると、クラスター一式の構成リソースがわかります。

ルートスタックのリソース一覧を取得します。

aws cloudformation list-stack-resources \
  --stack-name pc-vpce-survey \
  --region ap-northeast-1 \
  --query "StackResourceSummaries[].{ResourceType:ResourceType,LogicalResourceId:LogicalResourceId}"

出力にはリソースタイプが並びます。Route 53 ホストゾーンや DynamoDB テーブル、CloudWatch Logs ロググループ、WaitCondition、EC2 インスタンスなどです。

[
  { "ResourceType": "AWS::Route53::HostedZone",           "LogicalResourceId": "Route53HostedZone" },
  { "ResourceType": "AWS::DynamoDB::Table",               "LogicalResourceId": "DynamoDBTable" },
  { "ResourceType": "AWS::DynamoDB::Table",               "LogicalResourceId": "SlurmDynamoDBTable" },
  { "ResourceType": "AWS::Logs::LogGroup",                "LogicalResourceId": "CloudWatchLogGroup" },
  { "ResourceType": "AWS::CloudFormation::WaitCondition", "LogicalResourceId": "HeadNodeWaitCondition..." },
  { "ResourceType": "AWS::Lambda::Function",              "LogicalResourceId": "CleanupRoute53Function" },
  { "ResourceType": "AWS::EC2::Instance",                 "LogicalResourceId": "HeadNode" }
]

取得したリソースタイプを該当する AWS サービス名に置き換えます。

WaitCondition だけは 2 つのサービスにまたがります。これはヘッドノードのブートストラップ完了を待つ仕組みです。完了シグナルは、AWS が管理する S3 バケット（cloudformation-waitcondition-{リージョン}）への署名付き URL に PUT されます。そのため CloudFormation だけでなく S3 への通信も発生します。

コンピュートノードの IAM ロールと Launch Template は ComputeFleetQueues ネストスタックにあります。まずリソースタイプ AWS::CloudFormation::Stack の PhysicalResourceId（ARN）を取得します。

aws cloudformation list-stack-resources \
  --stack-name pc-vpce-survey \
  --region ap-northeast-1 \
  --query "StackResourceSummaries[?ResourceType=='AWS::CloudFormation::Stack'].PhysicalResourceId" \
  --output text

ネストスタックの ARN が返ります。

arn:aws:cloudformation:ap-northeast-1:123456789012:stack/pc-vpce-survey-ComputeFleetQueuesNestedStack.../...

この ARN を --stack-name に指定して同じ list-stack-resources を実行すると、ネストスタック内のリソースを確認できます。含まれるのは、コンピュートノードの IAM ロール、インスタンスプロファイル、IAM ポリシー、Launch Template です。コンピュートノードのロールの許可内容は次で確認します。

IAM ロールの許可アクションを確認する

スタックに含まれる IAM ロールのポリシーを取得し、各アクションのサービスプレフィックス（route53: のように : より前の部分）を確認します。

まずスタック内の IAM ロール名を取得します。

aws cloudformation list-stack-resources \
  --stack-name pc-vpce-survey \
  --region ap-northeast-1 \
  --query "StackResourceSummaries[?ResourceType=='AWS::IAM::Role'].PhysicalResourceId" \
  --output text

ルートスタックには、ヘッドノードのロールと Cleanup 用 Lambda の実行ロールが含まれます。コンピュートノードのロールは ComputeFleetQueues ネストスタック側にあるため、先ほど取得した ARN を --stack-name に指定して同じクエリを実行します。ルートとネストを合わせた 4 つのロール名が得られます。

pc-vpce-survey-RoleHeadNode-JI16YZ9YaDi1
pc-vpce-survey-CleanupResourcesFunctionExecutionRol-JOrMz4W53pOG
pc-vpce-survey-CleanupRoute53FunctionExecutionRole-hVSgCDAiTHw7
# ComputeFleetQueues ネストスタック側
pc-vpce-survey-ComputeFleetQue-Role15b342af42246b70-lJ46jQ1zq8mg

洗い出しの主な対象は、ヘッドノードとコンピュートノードのインスタンスロールです。ヘッドノードのロールは 3 つのインラインポリシーを持っています。

• parallelcluster
• parallelcluster-slurm-head-node
• parallelcluster-slurm-route53

許可アクションの範囲が広いため、ヘッドノードのロールを中心に確認します。

ヘッドノードのロールの内容ですとサービスプレフィックスはこうなりました。コンピュートノードは route53: と iam: を持たない以外は、ほぼ同じ範囲でした。

このうち ec2:、cloudformation:、s3:、dynamodb:、logs: は、公式の必須エンドポイント 5 種で想定道理です。ただし、IAM ロールの許可はそれより広く、必須一覧にないサービスも含みます。

ssm:、ssmmessages:、ec2messages: は AmazonSSMManagedInstanceCore 由来です。今回クラスター設定で明示的に追加したため含まれています。Session Manager 接続が不要であれば、対応するエンドポイントは省略できます。

cloudwatch:（メトリクス）と xray: は CloudWatchAgentServerPolicy の許可範囲に含まれます。ただし公式の必須エンドポイント一覧には入っていません。確かにメトリクスは送信しているなと思いました。ここは確認しておいてよかったです。

コンピュートノードを起動して通信を確認してみる

静的な 2 つの観点（IAM と CloudFormation リソース）に加えて、実際の通信でも確かめました。気になったのは、CloudFormation をどのノードが呼ぶのかです。ヘッドノードにジョブを投入するとコンピュートノードが動的に起動します。この状態で CloudTrail の管理イベントを見て、どのノードがどのサービスと通信するかを確認しました。

コンピュートノードについては、v3.15.0 で cfn-hup が systemd タイマー（pcluster-check-update.timer）に置き換わりました。設定変更の同期は共有ストレージ（既定では NFS）経由になり、CloudFormation API コールはなくなったはずです。これも合わせて確認します。変更点は以下の記事を参照してください。

https://dev.classmethod.jp/articles/aws-parallelcluster-v3150-p6-b300-update/

CloudFormation を呼ぶのはヘッドノードだけ

まず CloudFormation への通信を見ます。EventSource を cloudformation.amazonaws.com で絞り込みます。

aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=EventSource,AttributeValue=cloudformation.amazonaws.com \
  --start-time 2026-06-27T05:56:00Z \
  --region ap-northeast-1

ヘッドノード（i-06938ab97575c8532）が DescribeStackResource を約 60 秒間隔で呼び続けていました。cfn-hup の定期ポーリングです。

DescribeStackResource  05:56:17Z  i-06938ab97575c8532
DescribeStackResource  05:57:18Z  i-06938ab97575c8532
DescribeStackResource  05:58:19Z  i-06938ab97575c8532
...（約 60 秒間隔で継続）...
DescribeStackResource  06:07:23Z  i-06938ab97575c8532

CloudFormation を呼ぶのはヘッドノードだけでした。CloudFormation エンドポイントが必須なのは、このためです。コンピュートノードの起動有無に関わらず、ヘッドノードが常時ポーリングします。

コンピュートノードは CloudFormation を呼ばない

次にコンピュートノード（i-0cfaed13f61b5c284）起因の通信を見ます。起動から約 10 分間監視しても、コンピュート起因の CloudFormation は 0 件でした。管理イベントに現れたのは ssm（エージェント登録）、logs（CreateLogStream）、kms（Decrypt）だけです。コンピュートノードの設定取得は DynamoDB と S3 経由で、CloudFormation API は使いません。

この kms（Decrypt）は、EBS ルートボリュームの暗号化（既定で Encrypted: true）に伴う呼び出しです。EC2 の identity-only ロールによる AWS 内部完結の呼び出しで、sourceIPAddress は AWS Internal でした。インスタンスのネットワークを経由しないため、EBS 暗号化のために KMS の VPC エンドポイントを用意する必要はありません。CloudTrail に出たからといって、エンドポイントが必要とは限りません。

VPC エンドポイント対応を整理

洗い出し結果を公式ドキュメントと突き合わせると、設定上の注意点は次の 3 点です。

Route 53 非対応への対処

Route 53 は VPC エンドポイントに対応していません。ParallelCluster はデフォルトで、コンピュートノードのカスタムホスト名を解決する Route 53 プライベートホストゾーンを作成します。ホスト名は {queue_name}-{st|dy}-{compute_resource}-{N} 形式です。閉域網構成では、この機能を無効にして EC2 デフォルトホスト名に切り替えます。

When creating a Slurm cluster, AWS ParallelCluster creates a private Route 53 hosted zone that is used to resolve the custom compute node hostnames, such as {queue_name}-{st|dy}-{compute_resource}-{N}. Because Route 53 doesn't support VPC endpoints, this feature must be disabled. Additionally, AWS ParallelCluster must be configured to use the default Amazon EC2 hostnames, such as ip-1-2-3-4.

出典: AWS ParallelCluster in a single subnet with no internet access - AWS ParallelCluster

クラスターコンフィグに以下の設定を追加します。DisableManagedDns と UseEc2Hostnames をともに true にすると、Slurm の NodeName が DNS 解決されなくなります。ジョブスクリプトやモニタリングで NodeName を参照している場合は、NodeHostName を使うよう切り替えてください。

Scheduling:
  SlurmSettings:
    Dns:
      DisableManagedDns: true
      UseEc2Hostnames: true

Interface エンドポイントの設定要件

Interface エンドポイントは Private DNS を有効にすると、サービスのデフォルト DNS 名への通信がエンドポイント経由になります。デフォルト DNS 名は ec2.ap-northeast-1.amazonaws.com のような形式です。あわせて、VPC の DNS Resolution と DNS Hostnames も有効にしておく必要があります。

なお Lambda は CloudFormation リソースとして作成されますが、CleanupRoute53Function などは VPC 外のマネージド環境で実行されます。クラスターノードからの通信は発生しないため、Lambda の VPC エンドポイントは不要です。

条件付きエンドポイント（オプション）

DirectoryService を有効にする場合、または Slurm Accounting で外部データベースを使う場合は、Secrets Manager エンドポイントが追加で必要です。いずれもヘッドノードが Secrets Manager のシークレットを取得するためです（Slurm Accounting では PasswordSecretArn で指定した DB パスワード）。

LoginNodes を有効にする場合は、Elastic Load Balancing と Amazon EC2 Auto Scaling のエンドポイントも追加します。

Session Manager でノードに接続する場合は、ssm、ssmmessages、ec2messages の 3 つの Interface エンドポイントが必要です。

まとめ

AWS ParallelCluster v3.15.1 の最小構成のクラスターを作成し、必要な VPC エンドポイントを洗い出しました。IAM ロールの許可アクションと、作成される CloudFormation リソースの両方を突き合わせて確認しました。最小構成で必須となる VPC エンドポイントは次の 5 つです。

Route 53 は通信先ですが VPC エンドポイントに非対応のため、DisableManagedDns でマネージド DNS を無効にして回避します。機能を追加するときのオプションは、確認結果のテーブルを参照してください。

おわりに

閉域で HPC クラスターを設計するなら、どのサービスと通信しているかの把握が第一歩です。動かしてから通信の詰まりに気づくより、設計段階でこの一覧を潰しておくほうが楽です。共有ストレージや DirectoryService を足すとエンドポイントも増えるので、これを基準に足していってください。洗い出した結果、個人的に気になったのは CloudWatch のメトリクスの件でした。

参考

• AWS ParallelCluster in a single subnet with no internet access - AWS ParallelCluster
• Slurm accounting with AWS ParallelCluster - AWS ParallelCluster
• AWS ParallelCluster クラスター作成時に自動作成するセキュリティグループのルールと FSx for Lustre をマウントするときに必要なルール設定を確認してみた
• AWS ParallelClusterでHPCクラスタをお手軽に構築してみる
• AWS ParallelCluster で Slurm Accounting の設定方法を解説
• AWS ParallelCluster v3.15.0 で P6-B300 サポートなど主要な変更点を確認してみた