2026 年 7 月 20 日週、私はサンパウロで中南米各地のテクニカルビルダーと 3 日間過ごす機会に恵まれました。ここでは、深く掘り下げたセッション、ハンズオンワークショップ、お客様やパートナーとの会話が盛りだくさんの地域の技術イベントに参加しました。私が最も感銘を受けたのは、単一のセッションではなく、同じ部屋にいる機会はめったにない技術コミュニティのエネルギーでした。人々はコーヒーを飲みながらアーキテクチャのアイデアを交換し、ホワイトボードに解決策をスケッチし、到着したときよりも長い「試してみたいこと」のリストを手にして帰っていきました。私たちが構築するすべてのツールにおいて、それを取り巻くコミュニティこそがテクノロジーを定着させていることを思い出させてくれます。 このコミュニティの精神は、 7 月 27 日週の最大のインフラストラクチャニュースとうまく結びついています。それは、AWS をビルダーが実際にいる場所の近くに届けることに関するものです。 それでは、7 月 27 日週の AWS ニュースを見ていきましょう… 主なトピック ギリシャのアテネの AWS ローカルゾーン : AWS はギリシャのアテネに新しいローカルゾーンを開設しました。これは、Amazon S3 と Amazon EBS ローカルスナップショットをサポートする EMEA の 2 番目のローカルゾーンです。これにより、ギリシャ国内でデータを保存および処理して、ローカルのデータレジデンシー要件を満たすのに役立ちます。アテネローカルゾーンは、Amazon EC2 (C7i、M7i、および R7i インスタンス)、ワンゾーン低頻度アクセスストレージクラスの Amazon S3、Amazon EBS、および Amazon ECS をサポートしています。 AWS ローカルゾーンは、AWS インフラストラクチャを大勢の人口や業界のハブの近くに配置しています。これにより、リアルタイムゲーム、メディア制作、金融サービスなど、数ミリ秒のレイテンシーを必要とするアプリケーションを、エンドユーザーが実際にいる場所で実行できるようになります。ギリシャのビルダーは、レイテンシーの影響を受けやすいワークロードをローカルで実行すると同時に、低レイテンシーを必要としないサービスのために最も近い AWS リージョンにシームレスに接続できるようになりました。これにより、独自のデータセンターインフラストラクチャを管理しなくても、レイテンシーが最適化されたハイブリッドアプリケーションを柔軟に設計できます。詳細については、 AWS グローバルインフラストラクチャと持続可能性に関するブログ投稿 をご覧ください。 7 月 20 日週のリリース 7 月 20 日週のリリースのうち、私が注目したリリースをいくつかご紹介します: AWS 上の Claude Opus 5 : Anthropic の Claude Opus 5 を使用できます。これは、これまでで最も先進的な Opus モデルであり、多くの分野で Claude Fable 5 のトップクラスのインテリジェンスに匹敵する、Opus レベルの料金体系でご利用いただけます。Amazon Bedrock では、デフォルトでゼロデータ保持 (ZDR) が有効になっている Claude Opus 5 を提供しています。これにより、Claude Fable 5 とは異なり、データガバナンス要件を満たしながら、Opus の最高レベルのインテリジェンスを提供できます。Claude Opus 5 にアクセスするには、Amazon Bedrock と Claude Platform on AWS の 2 つの方法があります。詳細については、 詳細なブログ投稿 にアクセスしてください。 .NET 用の AWS Lambda 永続実行 SDK が一般公開されました : カスタムの進捗追跡を実装したり、外部のオーケストレーションサービスを統合したりしなくても、Lambda の永続関数を使用して、回復力のある長時間実行ワークフローを C# で構築できるようになりました。SDKは、支払い処理パイプライン、AI エージェントオーケストレーション、ヒューマンインザループ承認などの複数ステップのアプリケーションに最適です。進行状況を自動的にチェックポイントで確認し、実行を最大 1 年間停止できます。お客様がサーバーレスワークフローを構築している .NET 開発者である場合、これによって手作業で記述していたプラミングの大部分が不要になります。 Amazon Bedrock AgentCore では、トレースとログを 1 つのロググループにまとめることで、統一されたオブザーバビリティを実現できるようになりました : Amazon Bedrock AgentCore は、エージェントのトレースとプロンプトを、エージェントのログと同じ Amazon CloudWatch ロググループに配信するようになりました。以前は、テレメトリは送信先に分散され、トレーススパンは共有ロググループに送られ、プロンプト、入力、出力は別のロググループに送られました。そのため、1 回のエージェント呼び出しをデバッグするには複数の場所を検索する必要がありました。呼び出しを 1 か所でデバッグし、きめ細かなアクセス制御とカスタマーマネージドキー (CMK) 暗号化を個々のエージェントレベルで適用できるようになりました。 Amazon Connect がより自然なエージェント音声体験を提供 : Amazon Connect は、現在、ポルトガル語、スペイン語、フランス語、イタリア語、日本語、韓国語、タイ語を含む 50 以上の言語で、より自然で人間に聞こえるエージェント型音声体験をサポートするようになりました。100 を超える新しい音声オプションと会話の改善により、AI インタラクションがよりスムーズに聞こえるようになりました。Connect のエージェント型セルフサービスにより、AI エージェントは顧客の口調や感情に合わせて、音声やデジタルチャネル全体で理解し、推論し、行動に移すことができます。顧客が実際に話す言語のうち、これまでよりもはるかに多くの言語で、発信者に対して自然に感じられるコンタクトセンター体験を構築できるようになりました。 Amazon SageMaker Unified Studio が Amazon OpenSearch をサポートするようになりました : Amazon OpenSearch の検索データやログ分析データを、Amazon SageMaker Unified Studio の他のデータ資産と一緒に直接クエリして分析できるようになりました。この接続により、OpenSearch の運用検索データを Amazon Redshift、Amazon S3、リレーショナルデータベースなどのソースからのデータと、すべて単一の管理された環境内で組み合わせることができます。アプリケーションログをトランザクションデータと組み合わせてインサイトを引き出すなど、分析ワークロードと運用ワークロードを相互に関連付ける必要がある場合に特に役立ちます。 Amazon CloudWatch がコーディングエージェントのインサイトを発表 : Amazon CloudWatch により、エンジニアリングリーダーは AI コーディングツールが組織全体でどのように価値をもたらしているかを把握できるようになりました。コーディングエージェントインサイトは AWS 用の Claude アプリゲートウェイと統合されているため、追加のインストルメンテーションなしで Claude Code からテレメトリを収集できます。また、Codex や GitHub Copilot などのエージェントもサポートしています。チームが AI コーディングの採用を拡大するにつれて、OpenTelemetry で構築されたメトリクスを使用してその投資収益率を測定できるようになりました。カスタムインストルメンテーションは必要ありません。 AWS のお知らせに関する詳しいリストについては、「 AWS の最新情報 」ページをご覧ください。 AWS のその他のニュース 興味深いと思われる追加の記事やリソースをいくつかご紹介します: AI エージェントの評価: Strands と AgentCore を使った本番環境ブループリント : Strands Agents と Amazon Bedrock AgentCore を使用して、本番環境に移行する前後に AI エージェントを評価するための実践ガイド。エージェントをプロトタイプから本番環境に移行している場合、この投稿は上記の AgentCore Observability のアップデートに役立ちます。エージェントの品質を直感ではなく体系的に測定する方法を説明しています。 AWS CloudFormation カスタムリソースデプロイのためのマルチリージョンの耐障害性の構築 : 単一リージョンに問題が発生した場合でも、コードとしてのインフラストラクチャのデプロイの信頼性が維持されるように、マルチリージョンの耐障害性を実現するために CloudFormation カスタムリソースを設計する方法を学んでください。 Amazon Simple Email Service (SES) 料金プランのご紹介 : Amazon SES では、E メールの量が増えてもコストを予測できる料金プランが提供されるようになりました。大量に送信する場合、請求が大幅に簡素化されます。 近日開催予定の AWS イベント カレンダーを確認して、近日開催予定の AWS イベントにサインアップしましょう。 AWS Summits : AWS Summits は、クラウドや AI のコミュニティが一堂に会し、つながり、学び、最新のテクノロジーを探求するための無料のイベントです。カレンダー全体をご覧になって、2026 年後半にお近くで開催されるサミットを見つけてください。 AWS Community Days : コミュニティリーダーたちがコンテンツを計画、調達、提供するコミュニティ主導のカンファレンス。ラテンアメリカにお住まいの方は、8 月 22 日に開催される AWS Community Day Belo Horizonte をお見逃しなく。登録は awscommunityday.com.br で受付中です。 AWS Builder Center に参加して、ビルダーとつながり、ソリューションを共有し、開発をサポートするコンテンツにアクセスしましょう。 こちら から、今後開催されるすべての AWS 主導の対面イベントおよび仮想イベントとデベロッパー向けのイベントをご覧いただけます。 7 月 27 日週のニュースは以上です。８ 月 3 日週の Weekly Roundup もお楽しみに! この記事は、Weekly Roundup シリーズの一部です。AWS からの興味深いニュースや発表を簡単にまとめて毎週ご紹介します! 原文は こちら です。

リクルートのデータ推進室長 野村が自ら聞き手となり、現場の最前線で試行錯誤を続けるスペシャリストたちの「手の内」を紐解く連

駅奪取チームでエンジニアをしている id:kebhr です。 駅奪取では Perl で書かれたゲームサーバーを EC2 上で実行しています。 EC2 インスタンスは CPU 使用率に応じて動的にスケールアウトするようにしています。 駅奪取では cloud-init を用いて、インスタンスの起動時にゲームサーバーのコードや画像が存在するリポジトリ内で git update-index --refresh を走らせています。駅奪取では運用の都合により、ファイルの mtime がインスタンスごとにばらついては困るからです。 git update-index --refresh は、各ファイルの stat を index と突き合わせ、差分があればファイルの中身を読み直して更新します。stat が一致しているファイルの中身は読みません。 現在の AMI の作り方では、この差分が大きくなっています。そのため、この操作を行うとリポジトリ内のほぼすべてのファイルの中身にアクセスします。結果として、インスタンスの起動直後に I/O の負荷が急騰するという特徴があります。 最近この処理が重くなり、cloud-init の完了までに 500 秒以上掛かるようになりました。そのため、次のような問題が発生しました。 cloud-init が完了する前にヘルスチェック失敗が連続することで、起動したインスタンスがサービスインする前に入れ替わる 運良くサービスインしたとしても、負荷が発生してスケールアウトが発生してからサービスインするまでのタイムラグが大きいため、サービスの不安定性に繋がる ファーストタッチペナルティ 原因は EBS ボリュームの初期化プロセスにありました。 EBS スナップショットは S3 上に保存されています。スナップショットから EBS ボリュームを作成すると、S3 から EBS へのデータダウンロードが発生します。このダウンロードは非同期に進むため、EBS ボリュームにすべてのデータがダウンロードされていなくても、EBS ボリュームを利用できます。（AWS のドキュメント上では「遅延読み込み (Lazy Loading)」と表現されています） しかし、この処理は EBS ボリューム上の各ブロックへ初めてアクセスするタイミングで行われます。そのため、インスタンス起動直後に網羅的なファイルアクセスを行うと、ダウンロードされていないブロックへのアクセスが集中することで、I/O 性能が劣化します。 これをファーストタッチペナルティと呼びます。 ファーストタッチペナルティの回避方法 いくつかの方法があります。 Amazon EBS Fast Snapshot Restore (FSR) を使用する Amazon EBS Provisioned Rate for Volume Initialization を設定する Amazon EBS Fast Snapshot Restore (FSR) を使用する EBS スナップショットに FSR を有効にしておくと、そのスナップショットから作成した EBS ボリュームが初期化済みの状態で作成されるようになります。これにより、ファーストタッチペナルティを回避できます。 デメリットは費用です。 FSR は、FSR を有効にしているスナップショットが存在する間、常に課金が発生し続けます。 執筆時点での ap-northeast-1a では、特定 AZ 内の特定スナップショットに対して FSR を有効にすると、毎時 $0.90 の費用が発生します。月あたりでは $648 になります。 なお、スナップショットのサイズは料金に影響しません。 Amazon EBS Provisioned Rate for Volume Initialization を設定する EBS Provisioned Rate は、EBS ボリュームの初期化速度を明示的に指定する機能です。これを利用し、初期化速度を速めることで、ファーストタッチペナルティが発生する期間を短くできます。 初期化速度は 100MB/s ~ 300MB/s で指定できます。 費用は、スナップショットのサイズと、指定した初期化速度に依存します。 執筆時点での ap-northeast-1a では、100MB/s ~ 200MB/s なら $0.00290/GB、201MB/s ~ 300MB/s なら $0.00430/GB です。 例えば、10GB のスナップショットを 200MB/s の初期化速度で初期化する場合、初期化は 50 秒で完了し、費用は $0.029 です。 FSR と異なり、費用はスケールアウトのたびに発生しますが、スナップショットが小さくスケールアウトの回数がそれほど多くないなら、FSR より安くファーストタッチペナルティの影響を抑えられます。 駅奪取での採用結果 駅奪取では EBS Provisioned Rate を採用し、初期化速度を 200MB/s に設定しました。これにより、cloud-init 全体の所要時間が、500 秒から 120 秒前後まで短くなりました。 駅奪取のスナップショットサイズとスケールアウト回数においては、FSR を利用するより、極めて安価に大きな効果が得られています。