AWS PCS の Slurm 25.11 がリリース新機能で監査ログを S3、運用ログを CloudWatch Logs に分離してみた

大村保貴

2026.06.02

はじめに

2026 年 4 月 23 日、AWS Parallel Computing Service（AWS PCS）の Slurm 25.11 がリリースされました。

今回のアップデートで追加された主な機能は次の 4 つです。

Prometheus 互換の OpenMetrics エンドポイント（可観測性）
スケジューラ監査ログの分離（コスト削減）
迅速な再キュー（レジリエンス）
コンピュートノードグループ単位のスケールダウン制御（その他）

Slurm 25.11 の個人的な推しは、スケジューラ監査ログの分離です。AWS PCS はもともとスケジューラログ（運用ログ）を CloudWatch Logs, S3, Firehose に配信できましたが、監査ログ（AUDIT_RPCS）は運用ログに混在していました。25.11 ではこれを専用ログタイプ PCS_SCHEDULER_AUDIT_LOGS として分離し、運用ログとは別の配信先で扱えます。監査ログはスケジューラログ量の最大 90% を占めうるとのことで、切り離して安いストレージに保存してコストを抑えられます。というわけで、監査ログを S3、運用ログを CloudWatch Logs に振り分けが機能するか検証してみました。

AWS PCS の Slurm バージョン振り返り

サポートバージョンと EOL

AWS PCS は常時最大 3 世代の Slurm をサポートします。2026 年 6 月時点のサポートバージョンは以下の通りです。

Slurm バージョン	SchedMD リリース日	AWS PCS リリース日	AWS PCS EOL 日
25.11	2025/11/6	2026/4/9	2027/5/31
25.05	2025/5/29	2025/10/16	2026/11/30
24.11	2024/11/29	2025/5/14	2026/5/31

EOL を過ぎても既存クラスターは最大 12 か月間は継続稼働できますが、サポートは保証されません。

24.11 と 25.05 で何ができるようになったかは、それぞれ次の記事で紹介しています。24.11 は Slurm アカウンティング、25.05 はジョブの自動再キューイングが目玉でした。

アップデートチェック

OpenMetrics エンドポイント対応

OpenMetrics エンドポイントは、slurmctld（Slurm コントローラーデーモン）が Prometheus 互換のメトリクスを HTTP（ポート 6817）で公開する機能です。Slurm 25.11 から slurmctld 自身が直接サポートし、Prometheus などの既存の監視ツールでジョブ・ノード・スケジューラの状態を可視化できます。

AWS PCS ではデフォルトで無効です。CommunicationParameters=enable_http などの Slurm 設定を追加して有効化します。

スケジューラ監査ログの分離

AWS PCS はスケジューラログ（PCS_SCHEDULER_LOGS）を slurmctld・slurmdbd（24.11 以降）・slurmrestd（25.05 以降）から配信できます。配信先は S3 や CloudWatch Logs などです。25.11 では、このうち監査ログを分離できるようになりました。

スケジューラ監査ログは、slurmctld と slurmdbd が処理した RPC 操作を記録するログで、ログメッセージの AUDIT_RPCS: プレフィックスで識別されます。セキュリティ監査やコンプライアンス用途に使われます。監査ログには「誰が（uid）・どの操作（msg_type）を・どこから（client IP）」という情報が含まれるため、ジョブを投入したユーザーや操作時刻を後から追跡できる証跡になります。

Slurm 25.11 より前は、この監査ログが PCS_SCHEDULER_LOGS に混在していました。25.11 では専用のログタイプ PCS_SCHEDULER_AUDIT_LOGS に分離されました。

For clusters running Slurm 25.11 and later, AWS PCS delivers audit logs separately through the PCS_SCHEDULER_AUDIT_LOGS log type. This separation lets you control audit log ingestion and storage costs independently from your operational logs, because audit logs can make up to 90% of scheduler log volume.

出典: Scheduler audit logs in AWS PCS

監査ログがスケジューラログ量の最大 90% を占めうるという数字が示すように、分離前は監査ログの取り込みコストが運用ログのコストに無条件で乗っかっていました。分離後は保持ポリシーや転送先を分けて設定できます。コンプライアンス上の要件で監査ログを長期保存する必要がある場合でも、運用ログの保持期間と切り離してコストを管理できます。

典型的な振り分け例として、量が多く長期保管向きの監査ログは低コストな S3 へ、リアルタイムに確認したい運用ログは CloudWatch Logs へという設計があります。なお、S3 を配信先にする場合でも CloudWatch の配信料金（ap-northeast-1-S3-Egress-Bytes）が発生します。

出典: Enable logging from AWS services

バージョン別の挙動

Slurm バージョン	`PCS_SCHEDULER_LOGS` の内容	`PCS_SCHEDULER_AUDIT_LOGS`
25.11 より前	監査ログを含む全ログ	利用不可
25.11 以降	運用ログのみ	opt-in で利用可

25.11 以降、PCS_SCHEDULER_LOGS は運用ログのみになり、監査ログは含まれません。監査ログを取得するには、専用ログタイプ PCS_SCHEDULER_AUDIT_LOGS を opt-in で設定してください。

迅速な再キュー（という日本語訳で正しいかは定かではないです）

25.05 ではノード起動失敗時のジョブの自動再キューイングが導入されました。25.11 の 迅速な再キュー（expedited requeue） は、ノード障害（キャパシティ不足エラー等）の影響を受けたジョブを最高の優先度で即時にもう一度キューします。

Slurm 25.11 では AWS PCS のデフォルトで有効化（SchedulerParameters=enable_expedited_requeue）されています。ジョブ投入時は次のオプションで利用できます。

sbatch --requeue=expedite my-job.sh

その他の 25.11 変更点

コンピュートノードグループ単位のスケールダウンアイドルタイム

25.11 以降、個々のコンピュートノードグループがクラスターレベルの scaleDownIdleTimeInSeconds を独自値で上書きできるようになりました。これまでは全グループに同じアイドルタイムが適用されていたため、重いジョブを処理するグループと軽いジョブのグループで個別のスケールダウン戦略を取れませんでした。

HealthCheckNodeState の START_ONLY サポート

HealthCheckProgram は各コンピュートノードで定期実行し、ノードの健全性を確認するスクリプトです。HealthCheckNodeState は、このスクリプトをどのノード状態で実行するかを指定します。25.11 では START_ONLY 値が追加され、slurmd 起動時に 1 回だけ実行できるようになりました。定期チェックの負荷を抑えたい場合に使えます。

スケジューラ監査ログの分離を試してみた

スケジューラ監査ログの分離が実際に機能するか確認してみます。

監査ログ（PCS_SCHEDULER_AUDIT_LOGS）は S3 へ、運用ログ（PCS_SCHEDULER_LOGS）は CloudWatch Logs へ振り分けます。

設計意図としては、監査ログは量が多く（最大 90%）長期保管向きのため、保存コストを抑えられる S3 が適しています。運用ログはリアルタイムに状況を確認したい用途が多いため、検索・フィルタリングが容易な CloudWatch Logs を選びます。

確認したいことは次の 3 点です。

運用ログが CloudWatch Logs に、監査ログが S3 に届く
S3 の監査レコードに AUDIT_RPCS: プレフィックスがある
CloudWatch Logs の運用ログ側に AUDIT_RPCS: が含まれない（分離されている）

検証環境

今回の検証に使用したクラスター構成は次の通りです。

項目	構成
クラスター	Slurm 25.11.6
コントローラーのサイズ	スモール
コンピュートノードグループ	`pcs2511-static`（c6i.large x 1）
運用ログの配信先	CloudWatch Logs ロググループ `/aws/pcs/scheduler-logs`
監査ログの配信先	S3 バケット（vended log delivery 用バケットポリシー付き）

パラレルコンピューティングサービス___ap-northeast-1.png

前提

Slurm 25.11 クラスターが作成済みであること（作成手順は本記事のスコープ外）
クラスターを管理する IAM プリンシパルに pcs:AllowVendedLogDeliveryForResource 権限がある
S3 を配信先にするため、S3 バケットポリシーで delivery.logs.amazonaws.com への書き込みを許可してある

S3 バケットポリシーは、配信サービスからの s3:PutObject と s3:GetBucketAcl を許可します。aws:SourceAccount と aws:SourceArn で自アカウント・自リージョンの配信ソースに限定し、意図しない書き込みを防ぎます。

S3 バケットポリシーの例

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AWSLogDeliveryWrite",
      "Effect": "Allow",
      "Principal": { "Service": "delivery.logs.amazonaws.com" },
      "Action": "s3:PutObject",
      "Resource": "arn:aws:s3:::<audit-bucket-name>/AWSLogs/<account-id>/*",
      "Condition": {
        "StringEquals": {
          "s3:x-amz-acl": "bucket-owner-full-control",
          "aws:SourceAccount": "<account-id>"
        },
        "ArnLike": {
          "aws:SourceArn": "arn:aws:logs:ap-northeast-1:<account-id>:delivery-source:*"
        }
      }
    },
    {
      "Sid": "AWSLogDeliveryAclCheck",
      "Effect": "Allow",
      "Principal": { "Service": "delivery.logs.amazonaws.com" },
      "Action": "s3:GetBucketAcl",
      "Resource": "arn:aws:s3:::<audit-bucket-name>",
      "Condition": {
        "StringEquals": { "aws:SourceAccount": "<account-id>" },
        "ArnLike": {
          "aws:SourceArn": "arn:aws:logs:ap-northeast-1:<account-id>:delivery-source:*"
        }
      }
    }
  ]
}

運用ログを CloudWatch Logs に配信設定

CloudWatch Logs への配信は 3 回に分けて設定します。put-delivery-destination で配信先のロググループを登録します。put-delivery-source でクラスター ARN とログタイプ（PCS_SCHEDULER_LOGS）を紐付けます。最後に create-delivery で両者を接続します。

配信先のロググループが未作成の場合は、先に作成します。

aws logs create-log-group --region ap-northeast-1 \
  --log-group-name /aws/pcs/scheduler-logs

# 1. 配信先を登録（CloudWatch Logs のロググループ）
aws logs put-delivery-destination --region ap-northeast-1 \
  --name pcs-scheduler-logs-dest \
  --delivery-destination-type CWL \
  --delivery-destination-configuration \
  "destinationResourceArn=arn:aws:logs:ap-northeast-1:<account-id>:log-group:/aws/pcs/scheduler-logs"

# 2. 配信ソースを登録（AWS PCS クラスター＋ログタイプ）
aws logs put-delivery-source --region ap-northeast-1 \
  --name pcs-scheduler-logs-source \
  --resource-arn arn:aws:pcs:ap-northeast-1:<account-id>:cluster/<cluster-id> \
  --log-type PCS_SCHEDULER_LOGS

# 3. 配信を作成（ソースと配信先を接続）
aws logs create-delivery --region ap-northeast-1 \
  --delivery-source-name pcs-scheduler-logs-source \
  --delivery-destination-arn \
  arn:aws:logs:ap-northeast-1:<account-id>:delivery-destination:pcs-scheduler-logs-dest

put-delivery-source の応答で service=pcs、logType=PCS_SCHEDULER_LOGS が返れば設定完了です。

実行結果

{
    "deliverySource": {
        "name": "pcs-scheduler-logs-source",
        "arn": "arn:aws:logs:ap-northeast-1:<account-id>:delivery-source:pcs-scheduler-logs-source",
        "resourceArns": ["arn:aws:pcs:ap-northeast-1:<account-id>:cluster/pcs_vhuijft7zz"],
        "service": "pcs",
        "logType": "PCS_SCHEDULER_LOGS"
    }
}

監査ログを S3 に配信設定

監査ログの配信も同じ 3 ステップです。配信先タイプに S3、出力フォーマットに json を指定し、ログタイプを PCS_SCHEDULER_AUDIT_LOGS にします。

# 1. 配信先を登録（S3 バケット）
aws logs put-delivery-destination --region ap-northeast-1 \
  --name pcs-scheduler-audit-logs-dest \
  --delivery-destination-type S3 \
  --output-format json \
  --delivery-destination-configuration \
  "destinationResourceArn=arn:aws:s3:::<audit-bucket-name>"

# 2. 配信ソースを登録（AWS PCS クラスター＋監査ログタイプ）
aws logs put-delivery-source --region ap-northeast-1 \
  --name pcs-scheduler-audit-logs-source \
  --resource-arn arn:aws:pcs:ap-northeast-1:<account-id>:cluster/<cluster-id> \
  --log-type PCS_SCHEDULER_AUDIT_LOGS

# 3. 配信を作成
aws logs create-delivery --region ap-northeast-1 \
  --delivery-source-name pcs-scheduler-audit-logs-source \
  --delivery-destination-arn \
  arn:aws:logs:ap-northeast-1:<account-id>:delivery-destination:pcs-scheduler-audit-logs-dest

create-delivery の応答で deliveryDestinationType=S3、s3DeliveryConfiguration.suffixPath が返ります。S3 オブジェクトのパスがここで確認できます。

実行結果

{
    "delivery": {
        "id": "v2ZWDGuTowmhDjDF",
        "deliveryDestinationType": "S3",
        "recordFields": ["resource_id","resource_type","event_timestamp","log_level","log_name",
          "scheduler_type","scheduler_major_version","scheduler_patch_version","node_type",
          "log_type","message"],
        "s3DeliveryConfiguration": {
            "suffixPath": "{region}/scheduler_audit/{log_name}/{yyyy}/{MM}/{dd}/{HH}/",
            "enableHiveCompatiblePath": false
        }
    }
}

suffixPath の {region}/scheduler_audit/... は、AWS が自動付与する AWSLogs/<account-id>/PCS/ プレフィックスに続く後半部分です。

マネージメントコンソールからクラスターの「ログ」タブでも、2 つの配信設定を確認できます。

パラレルコンピューティングサービス___ap-northeast-1-2.png

ジョブを投入して RPC を発生させる

監査ログに「誰がジョブを投入したか」を残すため、ubuntu ユーザー（uid=1000）から 3 件のジョブを投入します。今回はログインノードなし構成のため、SSM Run Command でコンピュートノードの ubuntu ユーザーとして実行しています。

コンピュートノード（c6i.large）が実行中の状態です。

インスタンス___EC2___ap-northeast-1-6.png

ジョブを投入します。

sudo -u ubuntu bash -lc \
  'id; for i in 1 2 3; do
    sbatch -p pcs2511-queue --wrap="hostname; sleep 15" --job-name audit-demo-$i
  done; squeue --long'

3 件が投入され、1 件が実行中、2 件がキュー待ちになります。

実行結果

===ID===
uid=1000(ubuntu) gid=1000(ubuntu) groups=1000(ubuntu),...
===SUBMIT===
Submitted batch job 2
Submitted batch job 3
Submitted batch job 4
===SQUEUE===
   JOBID PARTITION     NAME     USER    STATE   TIME  NODES NODELIST(REASON)
       3 pcs2511-q audit-de   ubuntu  PENDING  0:00      1 (Resources)
       4 pcs2511-q audit-de   ubuntu  PENDING  0:00      1 (Priority)
       2 pcs2511-q audit-de   ubuntu  RUNNING  0:05      1 pcs2511-static-1

ログの分離を確認する

配信は約 5 分間隔で S3 にオブジェクトが追加されます。数分待ってから確認します。

S3 側（監査ログ）の確認

S3 バケットにオブジェクトが届いているか確認します。

aws s3 ls s3://<audit-bucket-name>/ --recursive

実行結果

2026-06-01 11:25:17  AWSLogs/<account-id>/PCS/ap-northeast-1/pcs_vhuijft7zz/scheduler_audit/slurmctld/2026/06/01/02/PCS_pcs_vhuijft7zz_scheduler_audit_slurmctld_25.11_2026-06-01-02_669eaa1d.log.gz
2026-06-01 11:30:17  .../PCS_pcs_vhuijft7zz_scheduler_audit_slurmctld_25.11_2026-06-01-02_93bc869b.log.gz
2026-06-01 11:35:18  .../PCS_pcs_vhuijft7zz_scheduler_audit_slurmctld_25.11_2026-06-01-02_89cdd846.log.gz
2026-06-01 11:40:17  .../PCS_pcs_vhuijft7zz_scheduler_audit_slurmctld_25.11_2026-06-01-02_adccebd1.log.gz

オブジェクトをダウンロードして中身を確認します。aws s3 ls の出力から最初のキーを取り出してダウンロードします。

KEY=$(aws s3 ls s3://<audit-bucket-name>/ --recursive | sort | head -1 | awk '{print $4}')
aws s3 cp "s3://<audit-bucket-name>/$KEY" /tmp/audit.log.gz
gunzip -c /tmp/audit.log.gz | head -1 | jq .

message フィールドに AUDIT_RPCS: プレフィックスを含む JSON レコードが返ります。

実行結果

{
  "resource_id": "pcs_vhuijft7zz",
  "resource_type": "PCS_CLUSTER",
  "event_timestamp": 1780281294197,
  "log_level": "info",
  "log_name": "slurmctld",
  "scheduler_type": "slurm",
  "scheduler_major_version": "25.11",
  "scheduler_patch_version": "6",
  "node_type": "controller_primary",
  "message": "[2026-06-01T02:34:54.197+00:00] AUDIT_RPCS: [slurmctld-primary:6817(fd:18)] msg_type=REQUEST_PING uid=0 client=[10.0.1.142:42390] protocol=11264\n"
}

全レコードが AUDIT_RPCS: で始まることを確認します。

gunzip -c /tmp/audit.log.gz | wc -l
gunzip -c /tmp/audit.log.gz | grep -c "AUDIT_RPCS:"

総レコード 123 件、全件が AUDIT_RPCS: を含む監査レコードした。

実行結果

123
123

CloudWatch Logs 側（運用ログ）の確認

CloudWatch Logs のストリームには運用ログが届いているか確認します。

aws logs get-log-events --region ap-northeast-1 \
  --log-group-name /aws/pcs/scheduler-logs \
  --log-stream-name AWSLogs/PCS/pcs_vhuijft7zz/slurmctld_25.11.log \
  --limit 8 --start-from-head

実行結果

"[2026-06-01T02:33:19.639+00:00] Terminate signal SIGTERM received"
"[2026-06-01T02:33:19.639+00:00] Saving all slurm state"
"[2026-06-01T02:33:38.152] error: MessageTimeout is too high for effective fault-tolerance"
"[2026-06-01T02:33:38.168+00:00] slurmctld version 25.11.6 started on cluster pcs-slurm-2511-verify-cluster(605)"

AUDIT_RPCS: を含むイベントがないことをフィルターで確認します。

aws logs filter-log-events --region ap-northeast-1 \
  --log-group-name /aws/pcs/scheduler-logs \
  --filter-pattern "AUDIT_RPCS" \
  --query 'length(events)' --output text

実行結果

確認結果

監査ログは S3 側に 123/123 件、運用ログには 0/63 件で、2 つに分離されています。

確認項目	S3（監査ログ）	CloudWatch Logs（運用ログ）
総レコード数	123 件	63 件
`AUDIT_RPCS:` を含む件数	123 件（全件）	0 件
判定	OK	OK

監査証跡としての活用

監査ログの価値は「誰がいつ何をしたか」を追跡できる点にあります。AUDIT_RPCS: レコードには msg_type（操作の種類）と uid（操作ユーザー）が含まれ、ジョブを投入したユーザーや時刻を後から特定できます。

例えば、ubuntu ユーザー（uid=1000）がジョブを投入すると、次のような REQUEST_SUBMIT_BATCH_JOB のレコードが残ります。

実行結果

[2026-06-01T04:17:05.415+00:00] AUDIT_RPCS: [slurmctld-primary:6817(fd:18)] msg_type=REQUEST_SUBMIT_BATCH_JOB uid=1000 client=[10.0.1.63:46356] protocol=11264

ジョブ投入（REQUEST_SUBMIT_BATCH_JOB）のほか、ジョブ照会（REQUEST_JOB_INFO）やジョブ完了など、操作の種類ごとに RPC が記録されます。uid で絞り込めば、特定ユーザーの操作だけを抽出できます。

まとめ

今回のアップデートの個人的な目玉はスケジューラ監査ログの分離でした。検証では監査ログを S3、運用ログを CloudWatch Logs に振り分けました。S3 側は 123 件すべてが AUDIT_RPCS: を含み、CloudWatch Logs 側には 1 件も混ざりませんでした。uid で絞ればジョブを投入したユーザーの操作だけを抽出でき、監査証跡として実用に足ります。

可観測性では slurmctld が OpenMetrics を直接公開できるようになりました。レジリエンス面では迅速な再キューがデフォルトで有効になっています。

監査ログはスケジューラログの最大 90% を占めうるため、大規模なクラスターほど分離の費用対効果は出ることでしょう。コンピュートノードグループ単位のスケールダウン制御も、ジョブの種類でアイドル時間を使い分けたい運用には便利です。

おわりに

同じ様な機能が AWS ParallelCluster にも来て欲しいなとなったアップデートでした。

AWS PCS の Slurm 25.11 がリリース新機能で監査ログを S3、運用ログを CloudWatch Logs に分離してみた

はじめに

AWS PCS の Slurm バージョン振り返り

サポートバージョンと EOL

アップデートチェック

OpenMetrics エンドポイント対応

スケジューラ監査ログの分離

バージョン別の挙動

迅速な再キュー（という日本語訳で正しいかは定かではないです）

その他の 25.11 変更点

コンピュートノードグループ単位のスケールダウンアイドルタイム

HealthCheckNodeState の START_ONLY サポート

スケジューラ監査ログの分離を試してみた

検証環境

前提

運用ログを CloudWatch Logs に配信設定

監査ログを S3 に配信設定

ジョブを投入して RPC を発生させる

ログの分離を確認する

S3 側（監査ログ）の確認

CloudWatch Logs 側（運用ログ）の確認

確認結果

監査証跡としての活用

まとめ

おわりに

参考

関連記事

AWSで探す

注目のテーマ

プロダクトやサービスで探す

特集やシリーズから探す

EVENTS