[アップデート]EC2 が特定の宛先への帯域幅の拡大とジャンボフレームをサポートするようになりました

[アップデート]EC2 が特定の宛先への帯域幅の拡大とジャンボフレームをサポートするようになりました

Clock Icon2025.04.04

はじめに

皆様こんにちは、あかいけです。

AWSでは様々なアップデートがありワクワクな日々をお過ごしのことかと思いますが、
2025年3月28日に、Amazon EC2のネットワーク性能に関するアップデートが発表されました。
https://aws.amazon.com/about-aws/whats-new/2025/03/amazon-ec2-bandwidth-jumbo-frames/

具体的には、
リージョン間のVPCピアリングAWS Direct Connect を利用する際のネットワーク帯域幅の制限が緩和され、
さらにリージョン間VPCピアリングでジャンボフレームがサポートされるようになったとのことです。

これは、マルチリージョン構成やハイブリッドクラウド環境を運用している方にとっては、嬉しい改善ではないでしょうか?
この記事では、このアップデートで何ができるようになったのか、また実際に試してみた結果をご紹介していきます。

アップデート内容

今回のアップデートのポイントは以下の二つです。

  • リージョン間VPCピアリング / AWS Direct Connect での送信帯域幅が向上

    • 従来:インスタンスサイズに応じて上限あり(32vCPU未満は5 Gbps、32vCPU以上は合計帯域幅の50%)
    • 今後:インスタンスのベースライン帯域幅 or 5Gbps の大きい方まで利用可能
  • リージョン間VPCピアリングでジャンボフレーム(MTU 8500)をサポート

    • 従来:標準的なMTU 1500 まで
    • 今後:最大 MTU 8500 のジャンボフレームに対応

これらの機能は、既存のリソースでも設定変更なしで、
対象となるリージョン(すべての商用リージョン、GovCloud(US)、中国リージョン)で利用可能とのことです。

これは嬉しいですね…!

ジャンボフレーム is 何?

そもそも「ジャンボフレーム」という言葉を初めて聞いた方もいるかもしれません。
私も初見の時は、何かがでっかいこと以外は何も知りませんでした。

「ジャンボフレーム」とは簡単に言うと、
ネットワークで一度に送受信できるデータパケットのサイズ(MTU: Maximum Transmission Unit)が標準よりも大きいフレームサイズのことです。

例えば標準的なMTUは 1500 です。
これはAWSに限った話ではなく基本的にイーサネットはこの規格に対応しています。

次にジャンボフレームとは 1500 を超えるMTUのことを指します、
今回のアップデートではリージョン間のVPCピアリングにおいて、
最大MTU 8500 までのジャンボフレームに対応しました。

メリットについて

MTUを大きくすると、同じデータ量を送るのに必要なパケット数が減ります。
またパケットには必ずヘッダー情報(宛先、送信元など)が付加されるため、
パケット数が減ることで、このヘッダー情報のオーバーヘッドが相対的に少なくなりデータ転送の効率が向上します。
その結果として、スループットの向上が期待できます。

デメリットについて

ジャンボフレームを利用するには、通信経路上のすべてのネットワーク機器(サーバー、スイッチ、ルーターなども含め)がそのMTUサイズに対応している必要があります。
一部でも対応していない機器があると、通信ができなかったり、フラグメンテーション(パケット分割)が発生して逆に性能が低下したりする可能性があります。

そのため今回のアップデートで、
AWS内のリージョン間VPCピアリング経路がMTU 8500に対応したという点が重要です。
この場合において通信経路はAWS上で完結するため、比較的気軽にジャンボフレームを利用することができます。

使ってみた

それでは、実際にリージョン間VPCピアリングでジャンボフレーム(MTU 8500)がサポートされているか、また帯域幅が向上しているか見てみましょう。

1.環境構築

まずはTerraformでまとめて環境を構築します。
これでリージョン間のVPCピアリング作成まで実行し、EC2が疎通できる状態になります。

main.tf
provider "aws" {
  alias  = "tokyo"
  region = "ap-northeast-1"
}

provider "aws" {
  alias  = "osaka"
  region = "ap-northeast-3"
}

# 共通設定
locals {
  tokyo = {
    region_code = "ap-northeast-1"
    az          = "ap-northeast-1a"
    vpc_cidr    = "10.0.0.0/16"
    subnet_cidr = "10.0.1.0/24"
    name_prefix = "Tokyo"
  }

  osaka = {
    region_code = "ap-northeast-3"
    az          = "ap-northeast-3a"
    vpc_cidr    = "10.1.0.0/16"
    subnet_cidr = "10.1.1.0/24"
    name_prefix = "Osaka"
  }
}

# Amazon Linux 2023 AMI - 東京
data "aws_ami" "tokyo_amazonlinux_2023" {
  provider    = aws.tokyo
  most_recent = true
  owners      = ["amazon"]

  filter {
    name   = "name"
    values = ["al2023-ami-2023*-kernel-6.1-x86_64"]
  }
}

# Amazon Linux 2023 AMI - 大阪
data "aws_ami" "osaka_amazonlinux_2023" {
  provider    = aws.osaka
  most_recent = true
  owners      = ["amazon"]

  filter {
    name   = "name"
    values = ["al2023-ami-2023*-kernel-6.1-x86_64"]
  }
}

# VPC - 東京
resource "aws_vpc" "tokyo_vpc" {
  provider   = aws.tokyo
  cidr_block = local.tokyo.vpc_cidr

  tags = {
    Name = "${local.tokyo.name_prefix}-VPC"
  }
}

# VPC - 大阪
resource "aws_vpc" "osaka_vpc" {
  provider   = aws.osaka
  cidr_block = local.osaka.vpc_cidr

  tags = {
    Name = "${local.osaka.name_prefix}-VPC"
  }
}

# パブリックサブネット - 東京
resource "aws_subnet" "tokyo_public" {
  provider                = aws.tokyo
  vpc_id                  = aws_vpc.tokyo_vpc.id
  cidr_block              = local.tokyo.subnet_cidr
  availability_zone       = local.tokyo.az
  map_public_ip_on_launch = true

  tags = {
    Name = "${local.tokyo.name_prefix}-Public-Subnet"
  }
}

# パブリックサブネット - 大阪
resource "aws_subnet" "osaka_public" {
  provider                = aws.osaka
  vpc_id                  = aws_vpc.osaka_vpc.id
  cidr_block              = local.osaka.subnet_cidr
  availability_zone       = local.osaka.az
  map_public_ip_on_launch = true

  tags = {
    Name = "${local.osaka.name_prefix}-Public-Subnet"
  }
}

# インターネットゲートウェイ - 東京
resource "aws_internet_gateway" "tokyo_igw" {
  provider = aws.tokyo
  vpc_id   = aws_vpc.tokyo_vpc.id

  tags = {
    Name = "${local.tokyo.name_prefix}-IGW"
  }
}

# インターネットゲートウェイ - 大阪
resource "aws_internet_gateway" "osaka_igw" {
  provider = aws.osaka
  vpc_id   = aws_vpc.osaka_vpc.id

  tags = {
    Name = "${local.osaka.name_prefix}-IGW"
  }
}

# VPCピアリング接続(東京から大阪へ)
resource "aws_vpc_peering_connection" "tokyo_osaka" {
  provider    = aws.tokyo
  vpc_id      = aws_vpc.tokyo_vpc.id
  peer_vpc_id = aws_vpc.osaka_vpc.id
  peer_region = local.osaka.region_code
  auto_accept = false

  tags = {
    Name = "Tokyo-Osaka-Peering"
  }
}

# VPCピアリング接続の承認(大阪側)
resource "aws_vpc_peering_connection_accepter" "osaka_accepter" {
  provider                  = aws.osaka
  vpc_peering_connection_id = aws_vpc_peering_connection.tokyo_osaka.id
  auto_accept               = true

  tags = {
    Name = "Osaka-Tokyo-Peering-Accepter"
  }
}

# ルートテーブル - 東京
resource "aws_route_table" "tokyo_rt" {
  provider = aws.tokyo
  vpc_id   = aws_vpc.tokyo_vpc.id

  route {
    cidr_block = "0.0.0.0/0"
    gateway_id = aws_internet_gateway.tokyo_igw.id
  }

  route {
    cidr_block                = local.osaka.vpc_cidr
    vpc_peering_connection_id = aws_vpc_peering_connection.tokyo_osaka.id
  }

  tags = {
    Name = "${local.tokyo.name_prefix}-Route-Table"
  }
}

# ルートテーブル - 大阪
resource "aws_route_table" "osaka_rt" {
  provider = aws.osaka
  vpc_id   = aws_vpc.osaka_vpc.id

  route {
    cidr_block = "0.0.0.0/0"
    gateway_id = aws_internet_gateway.osaka_igw.id
  }

  route {
    cidr_block                = local.tokyo.vpc_cidr
    vpc_peering_connection_id = aws_vpc_peering_connection.tokyo_osaka.id
  }

  tags = {
    Name = "${local.osaka.name_prefix}-Route-Table"
  }
}

# ルートテーブルの関連付け - 東京
resource "aws_route_table_association" "tokyo_rta" {
  provider       = aws.tokyo
  subnet_id      = aws_subnet.tokyo_public.id
  route_table_id = aws_route_table.tokyo_rt.id
}

# ルートテーブルの関連付け - 大阪
resource "aws_route_table_association" "osaka_rta" {
  provider       = aws.osaka
  subnet_id      = aws_subnet.osaka_public.id
  route_table_id = aws_route_table.osaka_rt.id
}

# SSMのためのIAMロール
resource "aws_iam_role" "ssm_role" {
  name = "SSMRoleForEC2"

  assume_role_policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Action = "sts:AssumeRole"
        Effect = "Allow"
        Principal = {
          Service = "ec2.amazonaws.com"
        }
      }
    ]
  })
}

# SSMポリシーのアタッチ
resource "aws_iam_role_policy_attachment" "ssm_attach" {
  role       = aws_iam_role.ssm_role.name
  policy_arn = "arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore"
}

# EC2用のインスタンスプロファイル
resource "aws_iam_instance_profile" "ec2_profile" {
  name = "EC2InstanceProfile"
  role = aws_iam_role.ssm_role.name
}

# セキュリティグループ - 東京
resource "aws_security_group" "tokyo_sg" {
  provider    = aws.tokyo
  name        = "tokyo-sg"
  description = "Allow traffic for Tokyo EC2"
  vpc_id      = aws_vpc.tokyo_vpc.id

  tags = {
    Name = "${local.tokyo.name_prefix}-SG"
  }
}

# セキュリティグループ - 大阪
resource "aws_security_group" "osaka_sg" {
  provider    = aws.osaka
  name        = "osaka-sg"
  description = "Allow traffic for Osaka EC2"
  vpc_id      = aws_vpc.osaka_vpc.id

  tags = {
    Name = "${local.osaka.name_prefix}-SG"
  }
}

# 東京SG - VPC内通信許可ルール(東京VPC)
resource "aws_security_group_rule" "tokyo_sg_ingress_tokyo_vpc" {
  provider          = aws.tokyo
  security_group_id = aws_security_group.tokyo_sg.id
  type              = "ingress"
  from_port         = 0
  to_port           = 0
  protocol          = "-1"
  cidr_blocks       = [local.tokyo.vpc_cidr]
  description       = "Allow all traffic from Tokyo VPC"
}

# 東京SG - VPC内通信許可ルール(大阪VPC)
resource "aws_security_group_rule" "tokyo_sg_ingress_osaka_vpc" {
  provider          = aws.tokyo
  security_group_id = aws_security_group.tokyo_sg.id
  type              = "ingress"
  from_port         = 0
  to_port           = 0
  protocol          = "-1"
  cidr_blocks       = [local.osaka.vpc_cidr]
}

# 東京SG - 送信トラフィック許可ルール
resource "aws_security_group_rule" "tokyo_sg_egress" {
  provider          = aws.tokyo
  security_group_id = aws_security_group.tokyo_sg.id
  type              = "egress"
  from_port         = 0
  to_port           = 0
  protocol          = "-1"
  cidr_blocks       = ["0.0.0.0/0"]
}

# 大阪SG - VPC内通信許可ルール(大阪VPC)
resource "aws_security_group_rule" "osaka_sg_ingress_osaka_vpc" {
  provider          = aws.osaka
  security_group_id = aws_security_group.osaka_sg.id
  type              = "ingress"
  from_port         = 0
  to_port           = 0
  protocol          = "-1"
  cidr_blocks       = [local.osaka.vpc_cidr]
}

# 大阪SG - VPC内通信許可ルール(東京VPC)
resource "aws_security_group_rule" "osaka_sg_ingress_tokyo_vpc" {
  provider          = aws.osaka
  security_group_id = aws_security_group.osaka_sg.id
  type              = "ingress"
  from_port         = 0
  to_port           = 0
  protocol          = "-1"
  cidr_blocks       = [local.tokyo.vpc_cidr]
}

# 大阪SG - 送信トラフィック許可ルール
resource "aws_security_group_rule" "osaka_sg_egress" {
  provider          = aws.osaka
  security_group_id = aws_security_group.osaka_sg.id
  type              = "egress"
  from_port         = 0
  to_port           = 0
  protocol          = "-1"
  cidr_blocks       = ["0.0.0.0/0"]
}

# EC2インスタンス - 東京
resource "aws_instance" "tokyo_ec2" {
  provider               = aws.tokyo
  ami                    = data.aws_ami.tokyo_amazonlinux_2023.id
  instance_type          = "m6i.large"
  subnet_id              = aws_subnet.tokyo_public.id
  vpc_security_group_ids = [aws_security_group.tokyo_sg.id]
  iam_instance_profile   = aws_iam_instance_profile.ec2_profile.name

  user_data = <<-EOF
                #!/bin/bash
                sudo dnf install -y iperf3
                EOF

  tags = {
    Name = "${local.tokyo.name_prefix}-EC2"
  }
}

# EC2インスタンス - 大阪
resource "aws_instance" "osaka_ec2" {
  provider               = aws.osaka
  ami                    = data.aws_ami.osaka_amazonlinux_2023.id
  instance_type          = "m6i.large"
  subnet_id              = aws_subnet.osaka_public.id
  vpc_security_group_ids = [aws_security_group.osaka_sg.id]
  iam_instance_profile   = aws_iam_instance_profile.ec2_profile.name

  user_data = <<-EOF
                #!/bin/bash
                sudo dnf install -y iperf3
                EOF

  tags = {
    Name = "${local.osaka.name_prefix}-EC2"
  }
}

# EC2のパブリックIPを取得 - 東京
data "aws_instance" "tokyo_ec2_info" {
  provider    = aws.tokyo
  instance_id = aws_instance.tokyo_ec2.id

  depends_on = [aws_instance.tokyo_ec2]
}

# EC2のパブリックIPを取得 - 大阪
data "aws_instance" "osaka_ec2_info" {
  provider    = aws.osaka
  instance_id = aws_instance.osaka_ec2.id

  depends_on = [aws_instance.osaka_ec2]
}

# セキュリティグループルール追加 - 東京(大阪EC2からのアクセス許可)
resource "aws_security_group_rule" "tokyo_from_osaka" {
  provider          = aws.tokyo
  type              = "ingress"
  from_port         = 0
  to_port           = 0
  protocol          = "-1"
  cidr_blocks       = ["${data.aws_instance.osaka_ec2_info.public_ip}/32"]
  security_group_id = aws_security_group.tokyo_sg.id

  depends_on = [aws_instance.osaka_ec2, data.aws_instance.osaka_ec2_info]
}

# セキュリティグループルール追加 - 大阪(東京EC2からのアクセス許可)
resource "aws_security_group_rule" "osaka_from_tokyo" {
  provider          = aws.osaka
  type              = "ingress"
  from_port         = 0
  to_port           = 0
  protocol          = "-1"
  cidr_blocks       = ["${data.aws_instance.tokyo_ec2_info.public_ip}/32"]
  security_group_id = aws_security_group.osaka_sg.id

  depends_on = [aws_instance.tokyo_ec2, data.aws_instance.tokyo_ec2_info]
}

# インスタンス SSM接続コマンド
output "ssm_start_session" {
  value = {
    tokyo = "aws ssm start-session --target ${aws_instance.tokyo_ec2.id} --region ${local.tokyo.region_code}"
    osaka = "aws ssm start-session --target ${aws_instance.osaka_ec2.id} --region ${local.osaka.region_code}"
  }
}

# インスタンス IPアドレス
output "instance_ip" {
  value = {
    tokyo = {
      local  = aws_instance.tokyo_ec2.private_ip
      global = aws_instance.tokyo_ec2.public_ip
    }
    osaka = {
      local  = aws_instance.osaka_ec2.private_ip
      global = aws_instance.osaka_ec2.public_ip
    }
  }
}
リソース作成
terraform init && \
terraform apply -auto-approve

2.帯域幅測定・ジャンボフレーム確認

次に両方のインスタンスにSSH接続して、帯域幅とジャンボフレームを確認しましょう。

なおアップデート前のVPCピアリング経由の通信を完全に再現することはできないため、
グローバルIPアドレスでの通信を確認することで代わりとします。

接続のコマンドやインスタンスのIPは以下で確認できます。

インスタンス情報 出力
terraform output

(1).EC2が対応しているMTU確認

これは今回のアップデートに関係なく、以前からMTU 9001に対応しています。

https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/network_mtu.html

コマンド
ifconfig | grep mtu
結果
ens5: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 9001
lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536

(2).ジャンボフレーム確認

まずローカルIPアドレスを指定した場合、
つまりVPCピアリング経由でのアクセスであれば、しっかりMTU 8500が利用できています。

なお8472を指定しているのは、pingコマンドの-sオプションはICMPデータ部分のサイズを指定するもので、実際のパケットサイズはIP header(20) + ICMP header(8) + データサイズ(8472)で丁度8500になるためです

ローカルIPアドレス指定
ping -M do -s 8472 -c 5 $LOCAL_IP_ADDRESS
リージョンA → リージョンB 結果
PING 10.1.1.138 (10.1.1.138) 8472(8500) bytes of data.
8480 bytes from 10.1.1.138: icmp_seq=1 ttl=127 time=9.41 ms
8480 bytes from 10.1.1.138: icmp_seq=2 ttl=127 time=9.39 ms
8480 bytes from 10.1.1.138: icmp_seq=3 ttl=127 time=9.42 ms
8480 bytes from 10.1.1.138: icmp_seq=4 ttl=127 time=9.41 ms
8480 bytes from 10.1.1.138: icmp_seq=5 ttl=127 time=9.40 ms

--- 10.1.1.138 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4006ms
rtt min/avg/max/mdev = 9.388/9.405/9.415/0.010 ms
リージョンB → リージョンA 結果
PING 10.0.1.60 (10.0.1.60) 8472(8500) bytes of data.
8480 bytes from 10.0.1.60: icmp_seq=1 ttl=127 time=9.43 ms
8480 bytes from 10.0.1.60: icmp_seq=2 ttl=127 time=9.41 ms
8480 bytes from 10.0.1.60: icmp_seq=3 ttl=127 time=9.42 ms
8480 bytes from 10.0.1.60: icmp_seq=4 ttl=127 time=9.41 ms
8480 bytes from 10.0.1.60: icmp_seq=5 ttl=127 time=9.44 ms

--- 10.0.1.60 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4006ms
rtt min/avg/max/mdev = 9.411/9.423/9.436/0.010 ms

次にグローバルアドレスを指定した場合、
EC2間の通信のためAWSグローバルネットワーク上で通信は完結していますが、MTU 1500までしか対応していないため、ジャンボフレームは利用できません。

https://aws.amazon.com/jp/vpc/faqs/

グローバルIPアドレス指定
ping -M do -s 8472 -c 5 $GLOBAL_IP_ADDRESS
リージョンA → リージョンB 結果
PING 15.168.143.166 (15.168.143.166) 8472(8500) bytes of data.
From 10.0.1.1 icmp_seq=1 Frag needed and DF set (mtu = 1500)
ping: local error: message too long, mtu=1500
ping: local error: message too long, mtu=1500
ping: local error: message too long, mtu=1500
ping: local error: message too long, mtu=1500

--- 15.168.143.166 ping statistics ---
5 packets transmitted, 0 received, +5 errors, 100% packet loss, time 4172ms
リージョンB → リージョンA 結果
PING 18.179.30.62 (18.179.30.62) 8472(8500) bytes of data.
From 10.1.1.1 icmp_seq=1 Frag needed and DF set (mtu = 1500)
ping: local error: message too long, mtu=1500
ping: local error: message too long, mtu=1500
ping: local error: message too long, mtu=1500
ping: local error: message too long, mtu=1500

--- 18.179.30.62 ping statistics ---
5 packets transmitted, 0 received, +5 errors, 100% packet loss, time 4167ms

(3).帯域確認

最後に帯域幅の確認していきましょう。
確認にはiperf3を利用します。

https://github.com/esnet/iperf

まずリージョンB側のEC2にて、以下のコマンドで待ち受けます。

リージョンB EC2コマンド
iperf3 -s

次にリージョンA側のEC2から、リージョンB側のEC2に向けてコマンドを実行します。

リージョンA EC2コマンド ローカルIPアドレス指定
iperf3 -c $LOCAL_IP_ADDRESS -P 8 -t 30

平均して、12.2 Gbits/sec ぐらいの速度が出ています。
今回利用しているインスタンスタイプがm6i.largeでネットワーク帯域幅が最大 12.5Gbpsなので、ほぼインスタンスの理論値が出ていますね。

https://aws.amazon.com/jp/ec2/instance-types/m6i/

結果
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-30.00  sec  5.03 GBytes  1.44 Gbits/sec  306            sender
[  5]   0.00-30.01  sec  5.03 GBytes  1.44 Gbits/sec                  receiver
[  7]   0.00-30.00  sec  5.74 GBytes  1.64 Gbits/sec  136            sender
[  7]   0.00-30.01  sec  5.74 GBytes  1.64 Gbits/sec                  receiver
[  9]   0.00-30.00  sec  5.22 GBytes  1.49 Gbits/sec  183            sender
[  9]   0.00-30.01  sec  5.22 GBytes  1.49 Gbits/sec                  receiver
[ 11]   0.00-30.00  sec  5.58 GBytes  1.60 Gbits/sec  154            sender
[ 11]   0.00-30.01  sec  5.58 GBytes  1.60 Gbits/sec                  receiver
[ 13]   0.00-30.00  sec  6.59 GBytes  1.89 Gbits/sec  128            sender
[ 13]   0.00-30.01  sec  6.59 GBytes  1.89 Gbits/sec                  receiver
[ 15]   0.00-30.00  sec  4.56 GBytes  1.31 Gbits/sec  189            sender
[ 15]   0.00-30.01  sec  4.56 GBytes  1.31 Gbits/sec                  receiver
[ 17]   0.00-30.00  sec  4.35 GBytes  1.24 Gbits/sec  171            sender
[ 17]   0.00-30.01  sec  4.34 GBytes  1.24 Gbits/sec                  receiver
[ 19]   0.00-30.00  sec  5.52 GBytes  1.58 Gbits/sec  188            sender
[ 19]   0.00-30.01  sec  5.52 GBytes  1.58 Gbits/sec                  receiver
[SUM]   0.00-30.00  sec  42.6 GBytes  12.2 Gbits/sec  1455             sender
[SUM]   0.00-30.01  sec  42.6 GBytes  12.2 Gbits/sec                  receiver

iperf Done.

次にグローバルIPを指定した場合です。

リージョンA EC2コマンド グローバルIPアドレス指定
iperf3 -c $GLOBAL_IP_ADDRESS -P 8 -t 30

平均して、4.63 Gbits/sec ぐらいの速度が出ています。
こちらはAWSグローバルネットワーク上を経由しているので、従来通り5 Gbpsが最大のようですね。

結果
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-30.00  sec  1.56 GBytes   448 Mbits/sec  961            sender
[  5]   0.00-30.01  sec  1.56 GBytes   447 Mbits/sec                  receiver
[  7]   0.00-30.00  sec  2.68 GBytes   767 Mbits/sec  277            sender
[  7]   0.00-30.01  sec  2.67 GBytes   765 Mbits/sec                  receiver
[  9]   0.00-30.00  sec  1.83 GBytes   524 Mbits/sec  778            sender
[  9]   0.00-30.01  sec  1.83 GBytes   523 Mbits/sec                  receiver
[ 11]   0.00-30.00  sec  2.00 GBytes   574 Mbits/sec  425            sender
[ 11]   0.00-30.01  sec  2.00 GBytes   573 Mbits/sec                  receiver
[ 13]   0.00-30.00  sec  1.79 GBytes   514 Mbits/sec  407            sender
[ 13]   0.00-30.01  sec  1.79 GBytes   513 Mbits/sec                  receiver
[ 15]   0.00-30.00  sec  2.96 GBytes   848 Mbits/sec  1040            sender
[ 15]   0.00-30.01  sec  2.96 GBytes   848 Mbits/sec                  receiver
[ 17]   0.00-30.00  sec  1.74 GBytes   497 Mbits/sec  832            sender
[ 17]   0.00-30.01  sec  1.73 GBytes   496 Mbits/sec                  receiver
[ 19]   0.00-30.00  sec  1.61 GBytes   460 Mbits/sec  975            sender
[ 19]   0.00-30.01  sec  1.61 GBytes   460 Mbits/sec                  receiver
[SUM]   0.00-30.00  sec  16.2 GBytes  4.63 Gbits/sec  5695             sender
[SUM]   0.00-30.01  sec  16.2 GBytes  4.63 Gbits/sec                  receiver

iperf Done.

3.結果

今回は m6i.large インスタンス(ベースライン帯域幅は最大12.5 Gbps)を利用して検証し、テストした結果は以下の通りでした。

  • MTU 1500 (従来): 最大5 Gbps (実測値: 4.63 Gbps)
  • MTU 8500 (今回): 最大12.5 Gbps (実測値: 12.2 Gbps)

なお上記の数値はあくまで本検証での結果です。
実際の帯域幅はインスタンスタイプ、リージョン間の距離、ネットワークの混雑状況など様々な要因に影響されます。

さいごに

今回は、EC2のリージョン間通信に関するアップデートについてご紹介し、VPCピアリング経由のジャンボフレームと帯域幅を検証してみました。

テスト結果からm6i.largeにおいては、MTU 8500のジャンボフレームを使用することで、従来のMTU 1500と比較して約2.6倍の帯域幅向上(4.63 Gbpsから12.2 Gbps)が確認できました。
これにより、リージョン間通信においてもインスタンスの持つ最大帯域幅まで活用できるようになったと言えるでしょう。

ただ実際にリージョン間通信で、5 Gbps以上の帯域幅やジャンボフレームが必要になる要件はあまりなさそうな気もしますが、以下のようなケースではメリットがありそうです。

  • 大規模なデータを頻繁にリージョン間で同期・バックアップする場合
  • マルチリージョンで展開するアプリケーションのパフォーマンス向上
  • Direct Connect経由でのオンプレミスとの大容量データ転送

繰り返しになりますが、既存リソースの設定不要で恩恵を受けられるのは本当にありがたいですね。
皆さんも、ご自身の環境でぜひこの高速化を体感してみてください。

Share this article

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.