[アップデート]EC2 が特定の宛先への帯域幅の拡大とジャンボフレームをサポートするようになりました
はじめに
皆様こんにちは、あかいけです。
AWSでは様々なアップデートがありワクワクな日々をお過ごしのことかと思いますが、
2025年3月28日に、Amazon EC2のネットワーク性能に関するアップデートが発表されました。
具体的には、
リージョン間の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に対応しています。
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になるためです
ping -M do -s 8472 -c 5 $LOCAL_IP_ADDRESS
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
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までしか対応していないため、ジャンボフレームは利用できません。
ping -M do -s 8472 -c 5 $GLOBAL_IP_ADDRESS
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
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を利用します。
まずリージョンB側のEC2にて、以下のコマンドで待ち受けます。
iperf3 -s
次にリージョンA側のEC2から、リージョンB側のEC2に向けてコマンドを実行します。
iperf3 -c $LOCAL_IP_ADDRESS -P 8 -t 30
平均して、12.2 Gbits/sec ぐらいの速度が出ています。
今回利用しているインスタンスタイプがm6i.large
でネットワーク帯域幅が最大 12.5Gbpsなので、ほぼインスタンスの理論値が出ていますね。
- - - - - - - - - - - - - - - - - - - - - - - - -
[ 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を指定した場合です。
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経由でのオンプレミスとの大容量データ転送
繰り返しになりますが、既存リソースの設定不要で恩恵を受けられるのは本当にありがたいですね。
皆さんも、ご自身の環境でぜひこの高速化を体感してみてください。