AWS Summit Japan 初参加レポート

エデュケーショナルサービス課で研修中の竹村です。先日、AWS Summit Japanに初めて参加してきました。このような大規模なTechイベントへの参加は初めてでしたが、非常に勉強になり楽しいイベントでしたので、遅ればせながらその様子を共有したいと思います！

入場

6月20日、21日に開催されたAWS Summit Japanですが、私は初日の20日に参加しました。海浜幕張に9時ごろ到着し、開始より１時間前のこの時間でも駅から歩く人たちが多くいました。入り口には大きなボードがあり、そこで写真を撮ったりしました。

入ったところに自由記入できるボードがあり、たくさんの企業の名前が連なっていました。弊社の名前も見つけました！

入り口で基調講演のチケットとお弁当引換券をいただきました。前日にオンラインで基調講演の予約をなんとかできましたが、早めに会場に着いた人からチケットが配布されているようでした。会場に入ると大きなステージがあり、DJがいて一気にワクワク感が高まりました！ここからは、各コンテンツの印象に残ったことについて紹介させていただきます。

基調講演

AIの歴史、進展、具体事例について多く話されていました。AIはただのツールであり、大事なのはデータの民主化というテーマが強調されていました。食糧問題やヘルスケアへのアクセス拡大、人身売買検知といった社会問題をAWSのテクノロジーで解決した事例が紹介されました。非常にスケールの大きな話で、改めてAWSとAIを用いて社会にどんなことができるかを考えるきっかけになりました。

AWS Village

AWS VillageではAWSを活用した事例の展示が多くありました。

その中でも印象的だったのが以下です。

サーバーレスシステムを利用したコーヒー注文システム サーバーレスアーキテクチャを活用してコーヒー注文受付するシステムを使い、モバイルからコーヒーを注文してみました。QRコードを読み込んで注文する人数に上限があったため、4回目くらいのトライで成功しました（笑）

AWS Outposts ラック

ラックの中を見せていただきました。実際にデータセンターから持ってきたとのことで、扉にはAWSのロゴが入っていて可愛かったです。他にも面白そうなものがたくさんありましたが、全て回りきれませんでした。次回参加時にはセッションの時間を工夫して、現地でしか見られないものを見てみたいと思いました。

認定者ラウンジ

AWSの認定を取得している人が入ることができるエリアです。Credlyで認定の証明を見せることで入場できました。中では作業ができるスペースがあり、認定のシールをいただきました。

セッション

～Pv6 on AWS ～Public IPv4 アドレス削減に向けてできることできないこと～

スピーカー：アマゾンウェブサービスジャパン合同会社山下裕氏

セッションの概要

Public IPv4 アドレスに対する料金体系の変更をきっかけにして、AWS での IPv6 の活用について改めて注目が集まっています。IPv6 on AWS のリファレンスアーキテクチャや IPv4 構成からの移行方法について解説すると共に、AWS のさまざまなサービスとの IPv6 対応状況もご紹介します。IPv6 へ移行することで果たしてコスト最適化が可能なのか、どこまで Public IPv4 アドレス削減に繋げることが可能なのか、IPv4 と IPv6 のデュアルスタック構成例、IPv6 Only の構成例の紹介をユースケースを通じてご説明します。

本セッションでは、AWSで2024年2月1日よりIPv4に対して課金が始まったことの背景から、具体的なIPv6への移行にむけてできることなどのお話を聞くことができました。 AWSにおけるIPv4課金の背景としてはネットワークに接続する機器のの増加により、IPv4アドレスが枯渇しているということでIPv4の仕入れ額の高騰が影響しているとのことでした。また、利用料を払ってIPv4を利用し続けることも可能ですが、IPv6の並行利用を検討していただきたいという意図が含まれた変更であるとのお話がとても印象的でした。

AWSのサービスでもここ2、3年でIPv6がサポートされたサービスは増えているとのことで、IPv4問題に対して力を入れているようだと感じました。以下にAWSでIPv6をサポートしているサービスが紹介されておりますので、見てみると良いかもしれません。

https://docs.aws.amazon.com/ja_jp/vpc/latest/userguide/aws-ipv6-support.html

セッションの後半ではALBにおいてDualstackを利用してIPv4 と IPv6を併用するケースや、NAT gatewayを使って外部サービスとの通信をEgress-only Internet Gateway(無償)に通信をオフロードさせる手法が紹介されておりました。

NAT gatewayはコストを占めやすいサービスのため無償であるEgress-only Internet Gatewayに置き換えることでユーザへのコストメリットはあると感じました。一方で、完全にこれらを置き換えるためにはすべての通信相手がIPv6に対応している必要があるということがやはりハードルなり得るため、サービス提供側やクライアント端末など大きい規模で取り組んでいかなければいけない問題ということを改めて認識しました。

大規模なネットワークであればIPv4の利用にかかるコストも大きなものとなりますし、今後も枯渇は進んでいくだろうと思いますのでまずは現状のAWS利用環境においてIPv4のコストでどのくらいかかっているのか、IPv6に対応している機器/サービスかどうかの現状の確認からでも少しずつできることからやっていくことが大切であると感じました。