セッションマネージャーを利用してローカル PC と プライベートサブネットにある EC2 間でデータ転送したときのデータ転送料を調べてみた

セッションマネージャー越しに SCP や rsync でデータ転送したときの転送費用ってどんなもんなのでしょうか?気になったので調べました。
2022.07.01

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

疑問

プライベートサブネットにある EC2 へ、セッションマネージャーを越しに SCP や rsync でデータ転送すると費用はいくらかかるのでしょうか?素朴な疑問解消するべく検証した記録です。

検証結果

公式ドキュメントからは判断つかなかったため、データ転送した結果の請求額から判断しています。

  • セッションマネージャーを経由させるとAWS からのインターネットアウトの料金は発生しない
  • NAT Gateway 経由は NAT Gateway の処理料金のみが発生
    • NAT Gateway の起動代は別途発生します
  • VPC エンドポイント経由は VPC エンドポイントの処理料金のみが発生
    • VPC エンドポイントの起動代は別途発生します
  • 価格は東京リージョン(ap-northeast-1)の2022年7月1日時点の料金を表記しています

2022/7/4追記
追加でパブリックサブネットの場合も検証した結果、セッションマネージャー経由は転送速度が遅いことがわかりました。

準備

プラベートサブネットにファイル送受信用の EC2 を起動します。

EC2 インスタンス

c6gd.large のインスタンスストアをファイル転送用のストレージとして利用します。OS は Amazon Linux 2です。

$ lsblk
NAME          MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
nvme1n1       259:0    0 109.9G  0 disk
nvme0n1       259:1    0     8G  0 disk
├─nvme0n1p1   259:2    0     8G  0 part /
└─nvme0n1p128 259:3    0    10M  0 part /boot/efi

$ sudo mkfs -t xfs /dev/nvme1n1
meta-data=/dev/nvme1n1           isize=512    agcount=4, agsize=7202149 blks
         =                       sectsz=512   attr=2, projid32bit=1
         =                       crc=1        finobt=1, sparse=0
data     =                       bsize=4096   blocks=28808593, imaxpct=25
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096   ascii-ci=0 ftype=1
log      =internal log           bsize=4096   blocks=14066, version=2
         =                       sectsz=512   sunit=0 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0

$ sudo mkdir /scratch
$ sudo mount /dev/nvme1n1 /scratch/
$ sudo chown ec2-user. /scratch/
$ df -h
Filesystem        Size  Used Avail Use% Mounted on
devtmpfs          1.9G     0  1.9G   0% /dev
tmpfs             1.9G     0  1.9G   0% /dev/shm
tmpfs             1.9G  412K  1.9G   1% /run
tmpfs             1.9G     0  1.9G   0% /sys/fs/cgroup
/dev/nvme0n1p1    8.0G  1.6G  6.5G  20% /
/dev/nvme0n1p128   10M  3.8M  6.3M  38% /boot/efi
tmpfs             382M     0  382M   0% /run/user/0
/dev/nvme1n1      110G  145M  110G   1% /scratch

/scratchディレクトリにインスタンスストアをマウントして準備完了しました。

ファイル転送してみる

ローカル PC で10GB サイズのダミーファイルを作成しました。このファイルを EC2 へアップロード、ダウンロードして課金される対象を CloudWatch のメトリクスと、請求書から確認します。

$ mkfile 10g 10GB.dummy
$ ls -lh
total 20979848
-rw-------  1 ohmura.yasutaka  staff    10G  6  7 18:21 10GB.dummy

NAT Gateway 編

ローカル PC からプラベートサブネットの EC2 へセッションマネージャーで接続する経路は図の状態です。

アップロード

セッションマネージャー + SCP で EC2 インスタンスへファイルをアップロードします。かなり遅いです。

$ scp -i ../../sandbox-key.pem ./10GB.dummy ec2-user@i-04bf3f07dd8155134:/scratch
10GB.dummy                                                                                      1%  131MB 859.6KB/s 3:20:42 ETA

セッションマネージャー + rsync でも速度は変わりませんね。このまま rsync でファイルのアップロード終わるまで放置します。

$ rsync -ahv --partial --append --progress -e "ssh -i ../../sandbox-key.pem" ./10GB.dummy ec2-user@i-04bf3f07dd8155134:/scratch
building file list ...
1 file to consider
10GB.dummy
      18.45M   0%  858.65kB/s    3:28:03

3時間半後には終わっていました。

building file list ...
1 file to consider
10GB.dummy
      10.74G 100%  804.73kB/s    3:37:10 (xfer#1, to-check=0/1)

sent 10.70G bytes  received 42 bytes  820.79K bytes/sec
total size is 10.74G  speedup is 1.00

ダウンロード

EC2 へアップロードしたファイルを今度はダウンロードします。時間かかるのでまた待ちます。

$ rsync -ahv --partial --append --progress -e "ssh -i ../../sandbox-key.pem" ec2-user@i-04bf3f07dd8155134:/scratch/10GB.dummy ./10GB.dummy.down
receiving file list ...
1 file to consider
10GB.dummy
      15.56M   0%  916.97kB/s    3:14:52

2時間半で完了しました。

$ rsync -ahv --partial --append --progress -e "ssh -i ../../sandbox-key.pem" ec2-user@i-04bf3f07dd8155134:/scratch/10GB.dummy ./10GB.dummy.down
receiving file list ...
1 file to consider
10GB.dummy
       2.32G  21%  915.18kB/s    2:33:22

結果確認

CloudWatch のメトリクスから前半のアップロード、後半のダウンロードのグラフを確認します。

メトリクス 説明
BytesInFromSource VPC 内のクライアントから NAT ゲートウェイによって受信されたバイト数
BytesOutToSource VPC 内の NAT ゲートウェイ経由でクライアントに送信されたバイト数

Amazon CloudWatch による NAT ゲートウェイのモニタリング - Amazon Virtual Private Cloud

オレンジの線はローカル PC から NAT Gateway 経由で EC2(クライアント)へファイルをアップロードしたときのバイト数が確認できます。

青色の線はNAT Gateway 経由で EC2(クライアント)からローカル PC へファイルをダウンロードしたときのバイト数が確認できます。アップロード、ダウンロードともに NAT Gateway を経由していることを確認できました。

翌日、請求書を確認すると10GBファイルのアップロード、ダウンロードで合計20GB の NAT Gateway のデータ処理料が発生してることが確認できます。前日時点でほぼ 0GB 表示のキャプチャを取得しておけばよかったです。

NAT Gateway からローカル PC まではインターネットへ出ているため、インターネットアウトの料金が適用されるかと思ったのですが請求されていません。

NAT ゲートウェイを介して転送されるすべてのデータに対して標準的な AWS データ転送料金が発生します。

料金 - Amazon VPC | AWS

判明したこと

VPC エンドポイント編

ローカル PC からプラベートサブネットの EC2 へセッションマネージャーで接続する経路は図の状態です。請求書のデータアウトの項目が NAT Gateway の経路検証と混在しないよう日を空けて検証を再開しました。

アップロード

セッションマネージャー + rsync で同様にアップロードしました。

$ rsync -ahv --partial --append --progress -e "ssh -i ../../sandbox-key.pem" ./10GB.dummy ec2-user@i-07008295ecdabfa16:/scratch
building file list ...
1 file to consider
10GB.dummy
      10.74G 100%    3.25MB/s    0:52:31 (xfer#1, to-check=0/1)

sent 2.61G bytes  received 42 bytes  827.24K bytes/sec
total size is 10.74G  speedup is 4.11

ダウンロード

同様にアップロードしたファイルをダウンロードしました。

$ rsync -ahv --partial --append --progress -e "ssh -i ../../sandbox-key.pem" ec2-user@i-07008295ecdabfa16:/scratch/10GB.dummy ./10GB.dummy.down
receiving file list ...
1 file to consider
10GB.dummy
      10.74G 100%  921.29kB/s    3:09:41 (xfer#1, to-check=0/1)

sent 38 bytes  received 10.74G bytes  943.31K bytes/sec
total size is 10.74G  speedup is 1.00

結果確認

CloudWatch のメトリクスから前半のアップロード、後半のダウンロードのグラフを確認します。

メトリクス 説明
BytesProcessed エンドポイントとエンドポイントサービスの間で交換されたバイト数 (両方向を集約)。これは、エンドポイントの所有者に料金が請求されるバイト数です。請求書には、この値が GB 単位で表示されます。

AWS PrivateLink の CloudWatch メトリクス - Amazon Virtual Private Cloud

アップロード時の各エンドポイントの状況です。グラフが途切れているのはローカル PC のスリープ設定を誤りスリープで中断しました。それでファイル転送の途切れが2度発生しています。レジュームオプションのおかげで再開して転送を終えました。

ダウンロードはスリープ設定を2度もミスった経験を活かし無事スリープにならずに転送を終えました。

アップロード、ダウンロード通してみてみると、ファイル転送で主に利用される VPC エンドポイントはssmmessagesでした。

エンドポイント名 説明
com.amazonaws.region.ssm Systems Manager サービスのエンドポイント
com.amazonaws.region.ec2messages Systems Manager は、このエンドポイントを使用して、SSM Agent から Systems Manager サービスへの呼び出しを行います。
com.amazonaws.region.ssmmessages このエンドポイントは、Session Manager を使用して安全なデータチャネルを経由してインスタンスに接続する場合にのみ必要です。

ステップ 6: (オプション) Virtual Private Cloud エンドポイントの作成 - AWS Systems Manager

翌日、請求書を確認すると10GBファイルのアップロード、ダウンロードで合計20GB の VPC エンドポイントのデータ処理料が発生していることが確認できます。

Before

After

NAT Gateway の経路と同様に Systems Manager とオンプレ間のインターネットアウトの料金は適用されていません。

Before

After

判明したこと

まとめ

Systems Manager を経由したデータ転送には AWS からのインターネットアウトの料金は発生しませんでした。 NAT Gateway 経由は NAT Gateway の処理料金が、VPC エンドポイント経由は VPC エンドポイントの処理料金が発生します。別途リソースの起動代は発生します。

逆に AWS へアップロード(インターネットから AWS へ)は S3 を経由など費用のかからない経路を利用した方がいいですね。

おわりに

想定と異なった結果だったため、本当にインターネットアウトの料金が発生しないのかあれこれ検証した結果の見どころだけまとめした。

オンプレと Systems Manager 間のセッションマネージャーの主なユースケースはシェルアクセスか、ちょっとしたファイル転送くらいだったため今まで通信経路のコストを意識したことがありませんでした。インターネットのアウト料金は CloudWatch のメトリクスで追えない都合、請求書の料金しか判断できる材料はありませんでした。なにか良い判定方法があればご連絡いただけると嬉しいです。パブリックサブネットにおいた EC2 からの場合、セッションマネージャー経由してファイル転送するとどうなるのかが気になっているので近いうちに検証しようと思います。

2022/7/4追記
パブリックサブネット編を検証しました。

一般的な通信経路の最適化では以下のブログが参考になりますので是非チェックしてください。

参考