こちらは、Japan AWS Ambassadors Advent Calendar 2024 の 13 日目の記事です。
こんにちは、エデュケーショナルサービス課の小倉です。
前回のブログから課名が変わっていますが、変わらずAWSトレーナーとしてトレーニングを実施しています。
私は現地には行っていないのですが、AWS re:Invent 2024 のセッション動画がたくさん公開されていますので、確認して内容をアウトプットしています。 セッション動画は以下から確認でき、再生リストタブではカテゴリ(AI/MLなど)ごとに分類されているため、目的の動画にたどり着きやすくなっています。
本ブログでは、「Amazon VPC: Advanced design and what’s new (NET301)」についてまとめます。こちらのセッションは、VPCの機能と2023/12～2024/12までのアップデートについて説明しており、VPCの現在の機能を知るうえで非常に有用なセッションとなっています。YouTubeの字幕を日本語にすれば内容を理解できますので、VPCの情報をキャッチアップしているみなさんには見ていただきいセッションです。
また、動画の最後にセッションの資料をダウンロードできるQRコードが表示されますので、資料をダウンロードしてあとから手元で確認することもできます。
セッション内容
本セッションは、VPC周りの機能をアップデートを含めて、網羅的に説明してくれています。
今回の大きなところとしては、別のリソースを作らないと使用できない機能がいくつかありましたが、別のリソースを作らなくても使用できる機能が増えてきています。例えば、AWS PrivateLinkを使用するには、これまではNLBを作らないといけなかったのですが、NLBなしで使えるようになったとか、Amazon VPC LatticeでECSに接続するときは間にALBを作らないといけなかったのですが、ALBなしで使えるようになったなどです。VPCでできることは増えていますが、各機能やサービス間の接続はシンプルになりつつあります。
2023/12のVPCの機能
2024/12のVPCの機能
本セッションで私が気になった内容を紹介します。
IPv6 on AWS
AWS内のIPv6についてです。
ここ1年でAWS内でIPv6を利用できるサービスが20以上増え、IPv6が使いやすくなってきています。
また、AWSからインターネットへ経路広告をしないことで、プライベートのIPv6(ユニークローカルアドレス、グローバルユニキャストアドレス)を使用できるようになりました。プライベートIPv6はインターネットから直接通信できないので、セキュリティの向上が見込めます。
ここからは私の感想です。
2024/2/1よりパブリックIPv4アドレスが有料になり、当時の記事には「 パブリック IPv4 アドレスの使用を節約し、IPv6 の採用を奨励すること」と書かれていました。IPv6を使用するとパブリックIPv4アドレスの使用を削減できるのかを考えていきます。
AWS内でIPv6が利用できるようになってはきていますが、IPv4とIPv6は互換性がないため、AWS内をIPv6を利用可能な状態にしても送信元がIPv6に対応していないとIPv6での通信することは難しいです。
VPC内からIPv6を利用したアウトバウンド通信であれば、NAT GatewayでNAT64(IPv6からIPv4へIPアドレスを変換)を利用してVPC外のIPv4への通信は可能です。今までVPC内からVPC外への通信にパブリックIPv4アドレスを使用していたのであれば、送信元がプライベートIPv4、IPv6のどちらでもNAT GatewayにVPC外への通信を集約することでパブリックIPv4アドレスの利用を減らすことができます。
インターネット内ではIPv4 Onlyの構成も存在しています。例えば、送信元がIPv4、AWS内がIPv6の場合、今のところAWSではインバウンド通信でIPアドレスを変換する機能は提供されていませんので、通信することは難しいです。そのため、インターネットから通信がある場合はIPv6 Onlyではなくデュアルスタック(IPv4とIPv6の両方が利用可能)の構成にするしかなく、パブリックIPv4アドレスの利用を削減することは難しいと考えています。
将来、送信元がIPv4、AWS内がIPv6の構成でも通信できるような互換性がない部分を埋める機能がリリースされるとAWSでのIPv6の利用がさらに増えるのではと想像しています。
Amazon CloudFront Private VPC Origin
これまではCloudFrontからオリジンへの通信にはパブリックな接続が必要でしたが、本アップデートにより、プライベートサブネットにあるオリジンに直接通信できるようになっています。
そのため、パブリックサブネットに配置するリソースを減らすことができ、セキュリティの向上が見込めます。
感想としては、先ほどのパブリックIPv4アドレスの利用を削減する一つの答えがこちらのアップデートだと考えています。
IPv4で通信していたとしてもインターネットからCloudFrontを経由し、パブリックIPv4アドレスを使用せずにオリジンに通信できます。セキュリティの向上とともにパブリックIPv4アドレスの削減にもつながりますので、VPCのパブリックサブネットにオリジンを配置している場合は、プライベートサブネットへの移行を検討してみるのがよいと考えています。
Amazon VPC Block Public Access
Amazon VPC Block Public Accessの機能がリリースされ、本機能を有効にするとインターネットゲートウェイを経由する通信を制御することができます。そのため、ルートテーブルを誤って設定してしまって、意図せずインターネットなどと通信可能な状態にすることを防いでくれますので、セキュリティの向上が見込めます。
もし意図的に通信を許可したい場合は、VPC, サブネット単位で除外の設定を入れることでインターネットゲートウェイを経由する通信を許可できます。
感想としては、AWSドキュメントにIAMポリシー例が記載されていますので、おそらく今までは以下のようなIAMポリシーでインターネットゲートウェイの作成やルートテーブルの変更の権限を制限することで、誤ってインターネットなどと通信可能な状態になることを防いでいたと考えられます。この方法だと頻繁ではないとは思いますが、インターネットゲートウェイ向けではないルートテーブルを変更するときに都度権限付与/削除をするなど若干運用が複雑になります。
ポリシー例) 特定のタグを持つルートテーブルの操作と削除を拒否
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": "ec2:DeleteInternetGateway",
"Resource": "arn:aws:ec2:*:*:internet-gateway/*",
"Condition": {
"StringEquals": {
"ec2:ResourceTag/Purpose": "Test"
}
}
},
{
"Effect": "Deny",
"Action": [
"ec2:DeleteRouteTable",
"ec2:CreateRoute",
"ec2:ReplaceRoute",
"ec2:DeleteRoute"
],
"Resource": "arn:aws:ec2:*:*:route-table/*",
"Condition": {
"StringEquals": {
"ec2:ResourceTag/Purpose": "Test"
}
}
}
]
}
Amazon VPC Block Public Accessを有効にすることによって、上記のIAMポリシーでの管理が不要になり、運用の複雑さを軽減できます。
ただ、この状態でAmazon VPC Block Public Accessの設定を変更できてしまうと困るので、以下のようなIAMポリシーを付与し、Amazon VPC Block Public Accessの操作を制限する必要があります。
ポリシー例) Amazon VPC Block Public Accessの設定の変更と除外の作成を除くすべての EC2 API に対するアクセスを許可
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "EC2FullAccess",
"Action": [
"ec2:*"
],
"Effect": "Allow",
"Resource": "*"
},
{
"Sid": "VPCBPAPartialAccess",
"Action": [
"ec2:ModifyVpcBlockPublicAccessOptions",
"ec2:CreateVpcBlockPublicAccessExclusion"
],
"Effect": "Deny",
"Resource": "*"
}
]
}
https://docs.aws.amazon.com/ja_jp/vpc/latest/userguide/vpc-policy-examples.html#vpc-bpa-example-iam
また、Amazon VPC Block Public Accessを有効にするとインターネットゲートウェイを経由するすべての通信ができなくなります。そのため、除外の設定を入れてから有効にしましょう。除外に追加する通信は、事前にVPC フローログなどで確認しておくと、設定漏れの可能性を減らすことができます。
まとめ
AWS re:Invent 2024のセッションの一つである「Amazon VPC: Advanced design and what’s new (NET301)」の内容の一部を紹介しました。本ブログでもいくつか紹介しましたが、最近のVPC関連のアップデートで構成のベストプラクティスが変わってきているように感じます。本セッションは、VPC周りの機能をアップデートを含めて、網羅的に説明してくれていますので、最新のVPCの構成を確認したいというかたはこちらのセッション動画を視聴することをおすすめします。
小倉 大(記事一覧)
アプリケーションサービス部エデュケーショナルサービス課 札幌在住
AWSトレーニングの講師をしています。
最近は7歳の息子と遊ぶのが楽しいです！
Twitter: @MasaruOgura
