AWSのブログ - TECH PLAY

TECH PLAY

AWS

AWS の技術ブログ

å…š3894ä»¶

本ブログは井村屋グルヌプ株匏䌚瀟様、株匏䌚瀟 Hashup 様、Amazon Web Services Japan 合同䌚瀟が共同で執筆いたしたした。 みなさん、こんにちは。AWS アカりントマネヌゞャヌの藀川です。 昚今、食品・補造業のお客様から「需芁予枬の粟床向䞊」や「属人化した業務の自動化」に぀いおご盞談いただく機䌚が増えおいたす。特に食品業界では、賞味期間の制玄や季節倉動の倧きさから、需芁予枬の粟床が欠品・廃棄に盎結するため、AI 掻甚ぞの期埅が高たっおいたす。 1896幎の創業から130幎、1947幎の蚭立から80幎目を迎え「あずきバヌ」や「肉たんあんたん」で知られる 井村屋グルヌプ株匏䌚瀟 様以䞋、井村屋グルヌプ様は、 株匏䌚瀟 Hashup 様以䞋、Hashup 様ず連携し、 Amazon SageMaker Canvas を掻甚したチルド補品肉たん・あんたん・ピザたん等の翌日出荷数 AI 需芁予枬の自動化のPOCを実斜したした。本蚘事では、熟緎担圓者の経隓ず勘に䟝存しおいた需芁予枬業務を、AWS 䞊で再珟・自動化した取り組みに぀いおご玹介したす。 お客様の状況ず怜蚌に至る経緯 井村屋グルヌプ様は、DX 戊略プロゞェクト2024幎床完了を経お、需絊管理ず SCM 暙準化プロゞェクトを掚進しおきたした。その次のステップずしお、暙準化された需絊デヌタを掻甚した AI 需芁予枬システムの導入に着手したした。 同瀟のチルドタむプの肉たんあんたんは、季節性や営業斜策によっお出荷量の倉動が倧きく、さらに賞味期間が短いため、特に高い予枬粟床が求められたす。しかし、埓来の予枬業務は熟緎担圓者の経隓ず勘に䟝存しおおり、欠品や廃棄のリスクが高く、生産・出荷蚈画の最適化が困難な状況でした。 「業務担圓者が毎日玄2時間をかけお、耇数の Excel シヌトや kintone アプリ、基幹システムからデヌタを手䜜業で抜出・敎圢し、前週トレンドや経隓則をもずに翌日の出荷数を決定しおいたした。たさに運甚圓初から継ぎ足しお䜿われおきた”秘䌝のたれ”のような業務でした」ず熟緎担圓者は圓時を振り返りたす。 たた、この業務は特定の担圓者に属人化しおおり、匕き継ぎリスクや、気象デヌタなど予枬に有効な倖郚情報を掻甚できおいないずいう課題もありたした。 こうした課題を解決するため、井村屋グルヌプ様は AWS ずのパヌトナヌシップに加え、AI・デヌタ掻甚に匷みを持぀ Hashup 様をコンサルティングパヌトナヌずしお迎え、3 瀟䜓制でPOCを実斜・掚進したした。 ゜リュヌション構成 Hashup 様が䞭心ずなり、AWS 䞊に以䞋の 2 ぀のアプロヌチでシステムを構築したした。 ① 業務自動化デヌタレむクの構築 耇数の Excel シヌト、kintone アプリ、基幹システムに散圚しおいたデヌタの参照・抜出・敎圢の流れを、AWS 䞊にデヌタレむクずしお構築し自動化したした。 ·     kintone や基幹システムのデヌタを AWS 䞊に自動連携 ·     æ¯Žæ—¥çŽ„2時間かけお手䜜業で䜜成しおいた芋蟌シヌトを、ボタンひず぀で 5 秒で自動生成 ·     æ°—象情報も自動取埗し、予枬の参考デヌタずしお掻甚可胜に 「担圓者様ぞのヒアリングを䜕床も実斜し、耇雑なデヌタの流れを完党に理解した䞊で AWS 䞊に再珟したした。担圓者様がスムヌズに移行できるよう、出力は既存の芋蟌シヌトずできるだけ同じ芋た目になるよう配慮しおいたす」ず Hashup 様は構築時のこだわりを語りたす。 ② AI 需芁予枬Amazon SageMaker Canvas による時系列予枬モデル Amazon SageMaker Canvas の AutoML 機胜を掻甚し、時系列予枬モデルを構築したした。 ·       孊習デヌタ : 過去 2 幎半の出荷実瞟デヌタに、気枩代衚 6 地点の平均最高・最䜎気枩、販促情報、前週トレンドなどを説明倉数ずしお投入 ·       予枬察象 : チルドたん各商品の翌日出荷数 ·       モデル構築 : AutoML によりハむパヌパラメヌタ最適化を自動実行し、最もパフォヌマンスの高いモデルを自動遞択 ·       有効因子 : 日本の祝日SageMaker が自動付䞎、気枩、小売芋蟌、前日蚈、前週トレンドなどが予枬に寄䞎 導入効果 AI 需芁予枬システムのPOC実斜により、以䞋の顕著な効果が埗られたした。 ·       業務工数 90% 削枛 : 毎日玄2時間を芁しおいた予枬業務のデヌタ抜出・前凊理・予枬・結果出力を自動化し、手䜜業をほがれロに ·       熟緎担圓者ず同等以䞊の予枬粟床を実珟 : あんたん: AI 6.0% vs 担圓者 6.2%WAPE— AI が同等 ゎヌルド肉たん: AI 9.8% vs 担圓者 15.4%WAPE— AI が倧幅に䞊回る ·       属人化からの脱华 特定担圓者の経隓・勘に䟝存しない、再珟性のある予枬プロセスを確立 ·       倖郚デヌタの掻甚 埓来取り入れられおいなかった気象デヌタを予枬に組み蟌み、粟床向䞊に貢献 「Amazon SageMaker Canvas の AutoML 機胜により、機械孊習の専門知識がなくおも高粟床な時系列予枬モデルを構築できたした。たた、AWS 䞊にデヌタレむクを構築したこずで、これたで散圚しおいたデヌタが䞀元化され、AI 予枬だけでなく今埌のデヌタ掻甚基盀ずしおも機胜しおいたす」ず井村屋グルヌプ様は技術面でのメリットを説明したす。 Hashup 様は「井村屋グルヌプ様のデゞタル戊略宀の皆様に倚倧なるご協力をいただき、担圓者様ぞの䞁寧なヒアリングを重ねるこずで、長幎培われおきた”秘䌝のたれ”ずも蚀える業務ノりハりを AWS 䞊に忠実に再珟できたした。AWS のマネヌゞドサヌビスを掻甚するこずで、2025 幎 11 月の開始からわずか玄 4 ヶ月で抂念実蚌を完了できたこずも倧きな成果です」ずプロゞェクトを振り返りたす。 AWS Summitず同日に幕匵メッセ䜵蚭の囜際䌚議堎で開催されたプラむベヌトセッション「AI Leaders Session」ご登壇時の様子井村屋グルヌプ株匏䌚瀟 執行圹員垞務 デゞタル戊略宀長 岡田孝平様 今埌の展望 「2026 幎 秋冬のチルドたんシヌズンに向けお、業務自動化から AI 需芁予枬たでの䞀気通貫システムぞの完党移行を目指しおいたす。さらに、kintone の特売芋蟌み情報ず連携した長期の出荷予枬を実珟し、原材料発泚蚈画の AI 予枬・自動化にも取り組んでいきたす。他カテゎリぞの AI 予枬の展開も蚈画しおいたす」 たた、今回のプロゞェクトを通じお AWS 䞊のデヌタレむクに蓄積された販売実瞟・気象・販促などの倚様なデヌタを、需芁予枬だけでなく経営刀断や珟堎のアクションにも掻かしおいくため、 Amazon Quick の掻甚もご怜蚎いただいおいたす。AI が生成した予枬倀ず実瞟の乖離をダッシュボヌドでリアルタむムに可芖化するこずで、予枬粟床のモニタリングや、需芁倉動の芁因分析をより盎感的に行える環境の構築を目指しおいたす。 株匏䌚瀟Hashup 代衚取締圹 CEO 神野 悊倪郎様巊端 井村屋グルヌプ株匏䌚瀟 執行圹員垞務 デゞタル戊略宀長 岡田孝平様巊から二番目 Amazon Web Services Japan : アカりントマネヌゞャヌ 藀川 高志朗右から二番目、゜リュヌションアヌキテクト 叀屋 楓右端
本文は 2026幎6月26日 に公開された AWS Cloud WAN Routing Policy: Real-World Global Network Scenarios (Part 2) を翻蚳したものです。 Part 1 では、 AWS Cloud WAN のルヌティングポリシヌを玹介し、グロヌバルネットワヌク党䜓でルヌト䌝播ずパス遞択に圱響を䞎えるためのきめ现かな制埡をどのように䜿甚できるかを瀺したした。各ルヌティングポリシヌは、3぀の䞻芁コンポヌネントで構成されたす。1) マッチ条件ルヌトプレフィックスたたは BGP 属性を評䟡したす。2) アクションマッチしたルヌトの凊理方法を決定したす。3) 方向性ポリシヌをむンバりンドずアりトバりンドのどちらのルヌト䌝播に適甚するかを指定したす。これらの構成芁玠は、アタッチメント、セグメント、たたはリヌゞョンのレベルで適甚できたす。 本蚘事では、これらの抂念を螏たえ、ハむブリッド環境やマルチサむト環境で䞀般的に芋られる3぀の実運甚シナリオを取り䞊げたす。AWS Cloud WAN のルヌティングポリシヌを䜿甚しお、 AWS Transit Gateway 環境からの移行䞭にルヌティングを制埡する方法、ロヌカルプリファレンスを䜿甚しお耇数の AWS Direct Connect ロケヌション間のパス遞択を改善する方法、そしお同䞀の BGP 自埋システム番号ASNを持぀ネットワヌク間の接続を蚱可する方法を孊びたす。 これらのパタヌンは、AWS Cloud WAN を集䞭型のポリシヌ適甚ポむントずしお䜿甚し、グロヌバルネットワヌク党䜓のルヌティング制埡を簡玠化する方法を瀺しおいたす。 本蚘事で説明するシナリオは、網矅的なリストではありたせん。AWS Cloud WAN のルヌティングポリシヌは、ここで扱う以倖にも远加のマッチ条件ずアクションをサポヌトしおいるため、お客様の環境固有のルヌティング課題に察応できたす。利甚可胜なマッチ条件ずアクションの完党なリストに぀いおは、 AWS Cloud WAN ルヌティングポリシヌのドキュメント を参照しおください。 前提条件 本蚘事は、2郚構成のシリヌズの第2回です。マッチ条件、アクション、方向性、基本的な蚭定ワヌクフロヌなど、ルヌティングポリシヌの基瀎を扱った Part 1: AWS Cloud WAN Routing Policy — Fine-grained controls for your global network を既に読たれおいるこずを前提ずしたす。たた、 Amazon Virtual Private CloudAmazon VPC 、AWS Cloud WAN、AWS Direct Connect、 AWS Site-to-Site VPN などの䞻芁な AWS ネットワヌクサヌビス、および AS-path、ロヌカルプリファレンス、コミュニティ属性ずいった抂念を含む Border Gateway ProtocolBGP の基瀎を理解しおいるこずを前提ずしたす。AWS Cloud WAN のハむブリッド接続パタヌンに関する補足的な背景情報に぀いおは、 Simplify global hybrid connectivity with AWS Cloud WAN and AWS Direct Connect integration を参照するこずを掚奚したす。 補足AWS Cloud WAN のルヌティングポリシヌには、コアネットワヌクポリシヌバヌゞョン 2025.11 以降が必芁です。本蚘事で説明する蚭定を実装する前に、コアネットワヌクがこのバヌゞョンで動䜜しおいるこずを確認しおください。 シナリオ1既存の Transit Gateway 環境からのルヌト䌝播の制埡 AWS Cloud WAN を採甚する堎合、既に AWS Transit Gateway 䞊に構築された既存環境を運甚しおいるかもしれたせん。移行䞭は、これらの環境を AWS Cloud WAN に接続するこずで、䞀床きりのカットオヌバヌではなく、段階的な移行が可胜になりたす。 こうしたアヌキテクチャでよくある芁件は、AWS Cloud WAN が Transit Gateway から孊習したルヌトを、ネットワヌクの他の郚分、特に AWS Direct Connect や AWS Site-to-Site VPN を通じお接続されたオンプレミス環境にどのように䌝播するかを制埡するこずです。 次の図図1は、ルヌティングポリシヌが適甚されおいない堎合に、AWS Cloud WAN 内でルヌトがどのように孊習され、䌝播されるかを瀺しおいたす。この䟋では、ap-southeast-2 リヌゞョンの Transit Gateway が、AWS Direct Connect を通じおオンプレミスのデヌタセンタヌDC1に接続されおいたす。この Transit Gateway が AWS Cloud WAN にアタッチされるず、DC1 は重耇したルヌトを受信し始めたす。1぀目のルヌトセットは、Transit Gateway から盎接䌝播されたす。2぀目のセットは AWS Cloud WAN 自䜓から来るもので、AWS Cloud WAN は Transit Gateway ルヌトテヌブルのアタッチメントから同じルヌトを孊習し、それらを Direct Connect 経由で DC1 に再配垃したす。ルヌティングポリシヌがない堎合、このルヌトの重耇は、非効率的たたは予枬䞍可胜なルヌティング動䜜に぀ながる可胜性がありたす。 図1ルヌティングポリシヌがない堎合のルヌト䌝播動䜜 AWS Cloud WAN のルヌティングポリシヌは、BGP コミュニティのタグ付けずフィルタリングによっおこの問題を解決し、どのルヌトをオンプレミス環境にアドバタむズするかを正確に制埡できるようにしたす。 図2ルヌティングポリシヌ適甚埌のルヌト䌝播動䜜 図2に瀺すように、Transit Gateway は自身の production ルヌトテヌブルを AWS Cloud WAN の production セグメントに接続したす。ルヌティングポリシヌは2぀のステップで動䜜したす。第1に、Transit Gateway ルヌトテヌブルのアタッチメントから孊習したルヌトに、BGP コミュニティ倀65000:1 などをタグ付けしたす。第2に、このコミュニティタグを、production セグメントから hybrid セグメントぞルヌトを共有する際のフィルタずしお䜿甚したす。タグ付けされたルヌトは、hybrid セグメントの Direct Connect ゲヌトりェむDXGWぞはそれ以䞊アドバタむズ䌝播されたせん。 その結果、オンプレミスのデヌタセンタヌは Transit Gateway から盎接ルヌトのみを受信するこずになり、重耇したアドバタむズが排陀され、Transit Gateway が同じデヌタセンタヌに接続されたたたのアヌキテクチャにおけるルヌティングの競合を回避できたす。 補足AWS Cloud WAN に盎接アタッチされた新しい VPC は、Transit Gateway の背埌にある既存の VPC が AWS Cloud WAN 䞊の VPC ず通信できるように、自身の Classless Inter-Domain RoutingCIDRブロックを Transit Gateway にアドバタむズしたす。ただし、これらの CIDR ブロックは、その関連付けの 蚱可プレフィックスリスト に含たれおいない限り、Transit Gateway の Direct Connect ゲヌトりェむの関連付けを通じおオンプレミスにはアドバタむズされたせん。これにより、Cloud WAN の VPC ルヌトが Transit Gateway パス経由で DC1 にアドバタむズされるのを防ぎ、AWS Cloud WAN の Direct Connect ゲヌトりェむをオンプレミスぞの唯䞀のパスずしお残したす。 仕組み 既存の Transit Gateway から孊習したルヌトは production セグメントに入り、アタッチメントのむンバりンドポリシヌによっおコミュニティ 65000:1 でタグ付けされたす。production の VPC ず AWS Cloud WAN のリ゜ヌスは、Transit Gateway のワヌクロヌドに通垞どおり到達できたす。䞀方、production のルヌトが hybrid セグメントず共有される際、アりトバりンドのセグメントフィルタリングポリシヌがコミュニティタグ 65000:1 にマッチし、それらのルヌトをドロップしたす。その他すべおの production ルヌトVPC からのルヌトは hybrid セグメントに通過し、Direct Connect 経由でオンプレミスにアドバタむズされたす。これにより、同じ Transit Gateway に䟝然ずしお盎接接続されおいるデヌタセンタヌぞの重耇したルヌトアドバタむズを防ぎたす。 ステップ1Transit Gateway のルヌトにコミュニティをタグ付けするTransit Gateway ルヌトテヌブルアタッチメントでむンバりンド このむンバりンドポリシヌを、AWS Cloud WAN の Transit Gateway ルヌトテヌブルアタッチメントに適甚したす。このポリシヌは、Transit Gateway から孊習したすべおのルヌトにマッチし、コミュニティ 65000:1 でタグ付けしたす。 { "routing-policies": [ { "routing-policy-number": 100, "routing-policy-name": "tagTgwRoutes", "routing-policy-description": "Tag routes learned from existing TGW with community 65000:1", "routing-policy-direction": "inbound", "routing-policy-rules": [ { "rule-number": 10, "rule-definition": { "match-conditions": [ { "type": "prefix-in-cidr", "value": "0.0.0.0/0" } ], "condition-logic": "and", "action": { "type": "add-community", "value": "65000:1" } } } ] } ] } ステップ2セグメント共有時にタグ付けされたルヌトをフィルタリングするprod → hybrid このアりトバりンドポリシヌを、production セグメントから hybrid セグメントぞルヌトを共有する際に適甚したす。このポリシヌは、コミュニティ 65000:1 を持぀ルヌトにマッチしおドロップし、Transit Gateway 由来のルヌトが hybrid セグメントおよび Direct Connect 経由でオンプレミスの DC に䌝播されるのを防ぎたす。コミュニティ倀 65000:1 にマッチしないルヌトは暗黙的に蚱可され、通垞どおり䌝播を続けたす。AWS Cloud WAN のルヌティングポリシヌルヌルはデフォルト蚱可default-allowを基本ずしお動䜜し、ドロップルヌルによっお明瀺的にマッチしたルヌトのみがフィルタリングされたす。 { "routing-policies": [ { "routing-policy-number": 200, "routing-policy-name": "filterRoutesToHybrid", "routing-policy-description": "Drop TGW-originated routes (community 65000:1) when sharing prod to hybrid", "routing-policy-direction": "outbound", "routing-policy-rules": [ { "rule-number": 10, "rule-definition": { "match-conditions": [ { "type": "community-in-list", "value": "65000:1" } ], "condition-logic": "and", "action": { "type": "drop" } } } ] } ] } ステップ3ポリシヌを配垃ポむントに関連付ける 3.1 ルヌティングポリシヌラベルを䜿甚しお、タグ付けポリシヌを Transit Gateway ルヌトテヌブルアタッチメントに適甚したす。 { "attachment-routing-policy-rules": [ { "rule-number": 100, "conditions": [ { "type": "routing-policy-label", "value": "TgwInbound" } ], "action": { "associate-routing-policies": [ "tagTgwRoutes" ] } } ] } 関連付けを完了するには、routing-policy-label を Transit Gateway ルヌトテヌブルアタッチメントに割り圓おたす。これは、アタッチメントの䜜成時に routing-policy-label パラメヌタを䜿甚するか、AWS Cloud WAN コン゜ヌルで既存のアタッチメントを線集するこずで実行できたす。このシナリオでは、ラベル TgwInbound を Transit Gateway ルヌトテヌブルアタッチメントに割り圓おたす。 3.2 セグメント共有のレベルでフィルタリングポリシヌを適甚したす。 { "segment-actions": [ { "action": "share", "mode": "attachment-route", "segment": "production", "share-with": [ "hybrid" ], "routing-policy-names": [ "filterRoutesToHybrid" ] } ] } シナリオ2耇数の Direct Connect ロケヌション間でのパス遞択の改善 耇数のオンプレミスロケヌションがある堎合、耐障害性のために耇数のサむトから同じプレフィックスをアドバタむズしおいるこずが倚いでしょう。これは可甚性を向䞊させたすが、AWS Cloud WAN が耇数のロケヌションから固有の優先床なしに同䞀のルヌトを受信するずいうルヌティングの曖昧さを生み出したす。远加の制埡がなければ、トラフィックが適切に誘導されない堎合に非効率的なルヌティング決定に぀ながる可胜性がありたす。 ルヌティングポリシヌが適甚されおいない堎合、AWS Cloud WAN はデフォルトのルヌティング動䜜ロンゲストプレフィックスマッチに䟝存し、ロヌカルプリファレンスやパスステアリングは行われたせん。図3に瀺すように、AWS Cloud WAN が同じプレフィックス䟋えば DC2 から発信される 10.2.0.0/16を3぀の DXGW ずサむトすべおから同時に孊習する堎合、DC2 を通る盎接パスを優先するメカニズムがありたせん。その結果、DC2 宛おのトラフィックが代わりに DC1 や DC3 を経由しお出おいくこずがあり、䞍芁なバックボヌンの通過、レむテンシヌの増加、コストの増加を招きたす。 補足このシナリオでは、オンプレミスのデヌタセンタヌが MPLS や AWS Direct Connect SiteLink などのバックボヌンネットワヌクを通じお盞互接続されおおり、フェむルオヌバヌ時にサむト間でトラフィックを通過させられるこずを前提ずしおいたす。 図3ルヌティングポリシヌがない堎合のルヌトパス遞択 AWS Cloud WAN のルヌティングポリシヌは、ロヌカルプリファレンスなどの BGP 属性を䜿甚しお、パス遞択を集䞭的に制埡したす。図4に瀺すように、各 DXGW アタッチメントに適甚されたむンバりンドルヌティングポリシヌがロヌカルプリファレンス倀を割り圓お、トラフィックを発信元のデヌタセンタヌぞ誘導するこずで、最も盎接的なパスが優先されるようにしたす。 図4ルヌティングポリシヌ適甚埌のルヌトパス遞択 このシナリオでは、各デヌタセンタヌが特定のプレフィックスのセットを保有しおいたす。DC1 は 10.1.0.0/16 を、DC2 は 10.2.0.0/16 を、DC3 は 10.3.0.0/16 を発信したす。耐障害性のため、3぀の DC はいずれも、自身の Direct Connect ロケヌションから3぀すべおのプレフィックスをアドバタむズしたす。各 DC は専甚の DXGW を通じお接続されおおり、DC1 は ASN 65010、DC2 は 65011、DC3 は 65012 を䜿甚したす。AWS Cloud WAN は3぀の DXGW すべおから同じルヌトを孊習し、ロヌカルプリファレンスを䜿甚しお各プレフィックスのトラフィックをその保有元 DC ぞ誘導したす。他の DC は、セカンダリおよび第3タヌシャリのフェむルオヌバヌパスずしお機胜したす。 AWS Cloud WAN の芳点から芋るず、このシナリオのパス優先床マトリックスは次のずおりです。 プレフィックス 1番目ロヌカルプリファレンス 300 2番目LP 200 3番目LP 100 DC1: 10.1.0.0/16 DXGW 65010 DXGW 65011 DXGW 65012 DC2: 10.2.0.0/16 DXGW 65011 DXGW 65012 DXGW 65010 DC3: 10.3.0.0/16 DXGW 65012 DXGW 65011 DXGW 65010 仕組み 3぀の DC はいずれも耐障害性のために3぀すべおのプレフィックスをアドバタむズしたすが、各プレフィックスは特定の DC に属したす。AWS Cloud WAN が 10.1.0.0/16 を3぀の DXGW すべおから孊習するず、ルヌティングポリシヌは、DXGW 65010保有元である DC1から 300、DXGW 65011DC2から 200、DXGW 65012DC3から 100 のロヌカルプリファレンスを割り圓おたす。AWS Cloud WAN は最も高いロヌカルプリファレンスを持぀パスを遞択し、10.1.0.0/16 のトラフィックを DC1 経由で誘導したす。DC1 の Direct Connect パスに障害が発生した堎合、トラフィックは自動的に DC2ロヌカルプリファレンス 200、次いで DC3ロヌカルプリファレンス 100ぞフォヌルバックしたす。同じロゞックが、DC2 保有のプレフィックスプラむマリは DXGW 65011、セカンダリは 65012、第3経路は 65010 経由および DC3 保有のプレフィックスプラむマリは DXGW 65012、セカンダリは 65011、第3経路は 65010 経由にも適甚されたす。 DXGW のレベルでは、VIF 䞊の BGP コミュニティ を通じお、远加のパス制埡レむダヌが利甚できたす。各 DXGW にはプラむマリずセカンダリの2぀の VIF があり、コミュニティタグによっおアりトバりンドトラフィックにどちらの VIF が優先されるかが決たりたす。高優先床には 7224:7300、䜎優先床には 7224:7100 を䜿甚したす。あるいは、アクティブ・アクティブの ECMP ロヌドバランシングのために、䞡方の VIF に 7224:7200 を適甚するこずもできたす。 この蚭定により、AWS Cloud WAN ず DXGW は、むンバりンドのルヌト優先蚭定を䜿甚しおアりトバりンドトラフィックをオンプレミスぞ誘導したす。察称ルヌティングを実珟するには、オンプレミスから AWS ぞ流れるトラフィックに぀いおも、オンプレミスのデバむスが同じパスを優先するように蚭定する必芁がありたす。 補足定矩された3぀のプレフィックスリストのいずれにもマッチしないプレフィックスは、明瀺的なロヌカルプリファレンスが蚭定されないたた通過し、3぀の DXGW すべおにわたっお非決定的なパス遞択ずなりたす。オンプレミスから新しいプレフィックスがアドバタむズされるのに合わせお、プレフィックスリストを最新の状態に保぀ようにしおください。 ステップ1各デヌタセンタヌ甚のプレフィックスリストを定矩する デヌタセンタヌごずに個別のプレフィックスリストを䜜成し、そのサむトから発信される CIDR をグルヌプ化したす。プレフィックスリストは Amazon VPC マネヌゞドプレフィックスリストカスタマヌマネヌゞドプレフィックスリストずしお䜜成され、その埌プレフィックスリスト゚むリアスを䜿甚しおコアネットワヌクに関連付けられたす。ルヌティングポリシヌがプレフィックスをマッチする際に参照するのは、この゚むリアスです。䟋えば、10.1.0.0/16、10.2.0.0/16、10.3.0.0/16 をそれぞれ含む3぀の マネヌゞドプレフィックスリスト を䜜成し、゚むリアス dc1Prefixes、dc2Prefixes、dc3Prefixes を䜿甚しおコアネットワヌクに関連付けたす。 補足–max-entries パラメヌタは必須で、プレフィックスリストが保持できる゚ントリの最倧数を定矩したす。ここで䜿甚しおいる倀 5 は任意のものであり、含める予定のプレフィックス数に応じお調敎できたす。 aws ec2 create-managed-prefix-list --prefix-list-name dc1Prefixes --max-entries 5 --address-family IPv4 --entries Cidr=10.1.0.0/16 aws ec2 create-managed-prefix-list --prefix-list-name dc2Prefixes --max-entries 5 --address-family IPv4 --entries Cidr=10.2.0.0/16 aws ec2 create-managed-prefix-list --prefix-list-name dc3Prefixes --max-entries 5 --address-family IPv4 --entries Cidr=10.3.0.0/16 aws networkmanager create-core-network-prefix-list-association --core-network-id <core-network-id> --prefix-list-arn <dc1-prefix-list-arn> --prefix-list-alias dc1Prefixes aws networkmanager create-core-network-prefix-list-association --core-network-id <core-network-id> --prefix-list-arn <dc2-prefix-list-arn> --prefix-list-alias dc2Prefixes aws networkmanager create-core-network-prefix-list-association --core-network-id <core-network-id> --prefix-list-arn <dc3-prefix-list-arn> --prefix-list-alias dc3Prefixes ステップ2DXGW アタッチメントごずにルヌティングポリシヌを定矩する 各 DXGW は、それぞれ独自のむンバりンドルヌティングポリシヌを持ちたす。このポリシヌは、パス優先床マトリックスに基づいお各プレフィックスにロヌカルプリファレンス倀を割り圓お、各プレフィックスを発信元 DC ぞ、決定的なフェむルオヌバヌ順序で誘導したす。 DXGW 65010DC1のポリシヌ。DC1 のプラむマリ、DC2 ず DC3 の第3経路 { "routing-policies": [ { "routing-policy-number": 100, "routing-policy-name": "pathPreferenceDxgw65010", "routing-policy-description": "DXGW 65010 (DC1): primary for DC1, tertiary for DC2, tertiary for DC3", "routing-policy-direction": "inbound", "routing-policy-rules": [ {"rule-number": 10, "rule-definition": {"match-conditions": [{"type": "prefix-in-prefix-list", "value": "dc1Prefixes"}], "condition-logic": "and", "action": {"type": "set-local-preference", "value": "300"}}}, {"rule-number": 20, "rule-definition": {"match-conditions": [{"type": "prefix-in-prefix-list", "value": "dc2Prefixes"}], "condition-logic": "and", "action": {"type": "set-local-preference", "value": "100"}}}, {"rule-number": 30, "rule-definition": {"match-conditions": [{"type": "prefix-in-prefix-list", "value": "dc3Prefixes"}], "condition-logic": "and", "action": {"type": "set-local-preference", "value": "100"}}} ] } ] } DXGW 65011DC2のポリシヌ。DC2 のプラむマリ、DC1 ず DC3 のセカンダリ { "routing-policies": [ { "routing-policy-number": 200, "routing-policy-name": "pathPreferenceDxgw65011", "routing-policy-description": "DXGW 65011 (DC2): secondary for DC1, primary for DC2, secondary for DC3", "routing-policy-direction": "inbound", "routing-policy-rules": [ {"rule-number": 10, "rule-definition": {"match-conditions": [{"type": "prefix-in-prefix-list", "value": "dc1Prefixes"}], "condition-logic": "and", "action": {"type": "set-local-preference", "value": "200"}}}, {"rule-number": 20, "rule-definition": {"match-conditions": [{"type": "prefix-in-prefix-list", "value": "dc2Prefixes"}], "condition-logic": "and", "action": {"type": "set-local-preference", "value": "300"}}}, {"rule-number": 30, "rule-definition": {"match-conditions": [{"type": "prefix-in-prefix-list", "value": "dc3Prefixes"}], "condition-logic": "and", "action": {"type": "set-local-preference", "value": "200"}}} ] } ] } DXGW 65012DC3のポリシヌ。DC3 のプラむマリ、DC2 のセカンダリ、DC1 の第3経路 { "routing-policies": [ { "routing-policy-number": 300, "routing-policy-name": "pathPreferenceDxgw65012", "routing-policy-description": "DXGW 65012 (DC3): tertiary for DC1, secondary for DC2, primary for DC3", "routing-policy-direction": "inbound", "routing-policy-rules": [ {"rule-number": 10, "rule-definition": {"match-conditions": [{"type": "prefix-in-prefix-list", "value": "dc1Prefixes"}], "condition-logic": "and", "action": {"type": "set-local-preference", "value": "100"}}}, {"rule-number": 20, "rule-definition": {"match-conditions": [{"type": "prefix-in-prefix-list", "value": "dc2Prefixes"}], "condition-logic": "and", "action": {"type": "set-local-preference", "value": "200"}}}, {"rule-number": 30, "rule-definition": {"match-conditions": [{"type": "prefix-in-prefix-list", "value": "dc3Prefixes"}], "condition-logic": "and", "action": {"type": "set-local-preference", "value": "300"}}} ] } ] } ステップ3ポリシヌを DXGW アタッチメントに関連付ける 各ルヌティングポリシヌを routing-policy-label にマッピングし、次にラベルによっおアタッチメントをマッチし、察応するルヌティングポリシヌを関連付ける attachment-routing-policy-rules を定矩したす。routing-policy-label を各アタッチメントに割り圓おたす。 { "attachment-routing-policy-rules": [ {"rule-number": 100, "conditions": [{"type": "routing-policy-label", "value": "dxgw65010inbound"}], "action": {"associate-routing-policies": ["pathPreferenceDxgw65010"]}}, {"rule-number": 200, "conditions": [{"type": "routing-policy-label", "value": "dxgw65011inbound"}], "action": {"associate-routing-policies": ["pathPreferenceDxgw65011"]}}, {"rule-number": 300, "conditions": [{"type": "routing-policy-label", "value": "dxgw65012inbound"}], "action": {"associate-routing-policies": ["pathPreferenceDxgw65012"]}} ] } 次に、routing-policy-label パラメヌタたたはコン゜ヌルを䜿甚しお、察応する routing-policy-label を各 DXGW アタッチメントに適甚したす。このシナリオでは、ラベル dxgw65010inbound を DXGW 65010 アタッチメントに、dxgw65011inbound を DXGW 65011 アタッチメントに、dxgw65012inbound を DXGW 65012 アタッチメントに割り圓おたす。 シナリオ3同䞀 ASN を持぀ネットワヌク間の通信の蚱可 Wide Area NetworkWANを構築する䌁業は、グロヌバル接続のために AWS のバックボヌンむンフラストラクチャをたすたす掻甚しおいたすが、買収、有機的な成長、たたは䞀般的なデフォルト ASN 倀を䜿甚したマルチサむト展開などにより、プラむベヌト ASN の重耇に盎面するこずがよくありたす。耇数のサむトが同䞀の ASN を䜿甚しおいる堎合、BGP のルヌプ防止機胜が、AS-path にそのサむト自身の ASN を含むルヌトを拒吊し、WAN 党䜓の゚ンドツヌ゚ンドの通信を劚げたす。 このシナリオでは、2぀の ASN の競合が゚ンドツヌ゚ンドの通信を劚げおいたす。図5に瀺すように、DC1 ず DC2Aはどちらも ASN 65000 を䜿甚しおいたす。AWS Cloud WAN がそれらの間でルヌトを䌝播するず、各サむトは AS-path に自身の ASN を怜出するため、盞手のルヌトを拒吊したす。これが BGP のルヌプ防止機胜を匕き起こしたす。 図5DC1 ず DC2 間で BGP ルヌプ防止機胜を匕き起こす ASN の競合 2぀目の競合Bは、図6に瀺すように、ASN 64512 を䜿甚する DC3 が、ap-southeast-2 の AWS Cloud WAN コアネットワヌク゚ッゞCNEの ASN ず競合するずいうものです。これにより、DC3 のルヌトは ap-southeast-2 の CNE によっおドロップされ、DC3 もその CNE からのルヌトをドロップしたす。 図6DC3 ず AWS Cloud WAN CNE 間の ASN の競合によるルヌト䌝播のブロック これら2぀の競合が組み合わさるこずで、3぀のデヌタセンタヌすべおにわたっお到達性が完党に倱われる結果ずなりたす。 AWS Cloud WAN のルヌティングポリシヌは、replace-asn-list アクションによっおこの問題に察凊したす。このアクションは、AS-path 党䜓を指定した ASN のセットで眮き換え、ルヌプ防止機胜を匕き起こす競合を取り陀き、オンプレミスの BGP の番号を振り盎すこずなく接続を埩元したす。 図7に瀺すように、3぀のデヌタセンタヌは AWS Cloud WAN を䞭倮のグロヌバルバックボヌンずしお䜿甚したす。DC1 は ap-southeast-2 リヌゞョンの Direct Connect を通じお接続し、DC2 は us-west-2 リヌゞョンの Site-to-Site VPN を通じお接続し、DC3 はメトロファむバヌ経由で DC2 を通じお AWS Cloud WAN に到達したす。むンバりンドルヌティングポリシヌは、2぀のアタッチメントポむントに適甚されたす。(1) DC1 甚の Direct Connect ゲヌトりェむアタッチメント、および (2) DC2 甚の VPN アタッチメントです。DC3 のルヌトは DC2 の VPN アタッチメントを経由しお通過するため、そのアタッチメントのむンバりンドポリシヌが DC2 ず DC3 の䞡方の ASN 眮換を凊理したす。 図73぀のデヌタセンタヌすべおの接続を埩元する ASN 眮換ルヌティングポリシヌ 次の衚は、ASN の眮換をたずめたものです。 ゜ヌス 元の ASN 眮換埌の ASN 理由 DC1Direct Connect 65000 65550 DC2 でのルヌプ怜出を回避 DC2Site-to-Site VPN 65000 65551 DC1 でのルヌプ怜出を回避 DC3DC2 のメトロファむバヌ経由 64512 65552 ap-southeast-2 の CNE ASN ずの競合を回避 重芁AWS Cloud WAN のコアネットワヌク゚ッゞCNEは、むンバりンドルヌティングポリシヌが評䟡される前に、BGP AS-path のルヌプ怜出を実行したす。CNE が自身の ASN ず䞀臎する ASN を持぀ルヌトを受信した堎合、replace-asn-list アクションが実行される前にそのルヌトをドロップしたす。トポロゞヌを蚈画する際は、オンプレミスのルヌトが、受信偎の CNE の ASN ず䞀臎する ASN を持たないようにしおください。 仕組み このアプロヌチは、各サむトに固有で競合しない眮換 ASN を割り圓おるこずで、どのサむトも䌝播されたルヌトの䞭に自身の ASN を芋るこずがなく、たた、どのルヌトもトポロゞヌ内の CNE ず競合する ASN を持たないようにするものです。DC1 が AWS Cloud WAN にルヌトをアドバタむズするず、Direct Connect ゲヌトりェむアタッチメントのむンバりンドポリシヌが、AS-path 党䜓を ASN 65550 で眮き換えたす。これらのルヌトは AWS Cloud WAN を通じお䌝播し、AS-path に 65000 ではなく 65550 を含んだ状態で DC2 に到達するため、DC2 のルヌタヌはルヌプ怜出を匕き起こすこずなくそれらを受け入れたす。 DC2 がルヌトをアドバタむズするず、VPN アタッチメントのむンバりンドポリシヌが AS-path 党䜓を ASN 65551 で眮き換えたす。これにより DC1 は、AS-path に 65000 ではなく 65551 を含んだ状態でこれらのルヌトを受信するため、BGP のルヌプ怜出を防ぎ、DC1 ず DC2 間の双方向通信を埩元したす。 DC3 に぀いおは、ルヌトは ASN 64512DC3ず ASN 65000DC2の䞡方を持った状態で、DC2 の VPN アタッチメントを通じお AWS Cloud WAN に入りたす。むンバりンドポリシヌは AS-path 党䜓を単䞀の専甚 ASN65552で眮き換え、競合する2぀の倀を1回の操䜜で取り陀きたす。これにより、DC3 のプレフィックスが AWS Cloud WAN のルヌトテヌブルに受け入れられ、DC1 およびクラりドリ゜ヌスにアドバタむズされるようになりたす。 すべおの眮換 ASN65550、65551、65552は、コアネットワヌク゚ッゞ甚に蚭定された ASN 範囲の倖から遞択されおいたす。ルヌティングポリシヌの眮換倀は、AWS Cloud WAN の CNE の ASN 範囲ず重耇できないためです。 ステップ1DC1 の Direct Connect ゲヌトりェむアタッチメントにむンバりンドポリシヌを定矩する このポリシヌは、DC1 から到着する AS-path に ASN 65000 を含むルヌトにマッチし、それを 65550 に眮き換えたす。これらのルヌトが DC2 に䌝播されるずき、AS-path には 65000 が含たれなくなるため、DC2 のルヌタヌはそれらを受け入れたす。 { "routing-policies": [ { "routing-policy-name": "replaceasndc1", "routing-policy-description": "Replace ASN 65000 from DC1 with 65550 to avoid loop detection at DC2", "routing-policy-direction": "inbound", "routing-policy-number": 100, "routing-policy-rules": [ {"rule-number": 10, "rule-definition": {"match-conditions": [{"type": "asn-in-as-path", "value": 65000}], "condition-logic": "and", "action": {"type": "replace-asn-list", "value": [65550]}}} ] } ] } ステップ2DC2 の VPN アタッチメントにむンバりンドポリシヌを定矩する このポリシヌは、2぀のルヌティングルヌルを䜿甚しお ASN の競合を解決したす。 ルヌル10 DC3 の ASN64512を 65552 に眮き換えたす。 ルヌル20 DC2 の ASN65000を 65551 に眮き換えたす。 DC3 からのルヌトは DC2 を経由しお通過するため、AS-path に䞡方の ASN を含みたす。そのため、順序が重芁です。replace-asn-list は AS-path 党䜓を䞊曞きするため、DC3 のルヌトが専甚の眮換 ASN65552を受け取れるように、ルヌル10 を先に実行する必芁がありたす。 もしルヌル20 が先に実行されるず、DC2 の ASN にマッチしお AS-path 党䜓を 65551 で眮き換えおしたいたす。DC3 のルヌトは䟝然ずしお受け入れられ、接続は機胜したすが、DC2 のルヌトず区別が぀かなくなり、ルヌトの远跡やトラブルシュヌティングが難しくなりたす。 { "routing-policies": [ { "routing-policy-name": "replaceasndc2", "routing-policy-description": "Replace ASN 65000 from DC2 with 65551 and ASN 64512 from DC3 with 65552", "routing-policy-direction": "inbound", "routing-policy-number": 200, "routing-policy-rules": [ {"rule-number": 10, "rule-definition": {"match-conditions": [{"type": "asn-in-as-path", "value": 64512}], "condition-logic": "and", "action": {"type": "replace-asn-list", "value": [65552]}}}, {"rule-number": 20, "rule-definition": {"match-conditions": [{"type": "asn-in-as-path", "value": 65000}], "condition-logic": "and", "action": {"type": "replace-asn-list", "value": [65551]}}} ] } ] } ステップ3ポリシヌをアタッチメントに関連付ける routing-policy-label にマッチする attachment-routing-policy-rules を定矩するこずで、各ルヌティングポリシヌをアタッチメントに関連付けたす。routing-policy-label パラメヌタたたはコン゜ヌルを䜿甚しお、各アタッチメントに指定の routing-policy-label をタグ付けしたす。 { "attachment-routing-policy-rules": [ {"rule-number": 100, "conditions": [{"type": "routing-policy-label", "value": "dc1inbound"}], "action": {"associate-routing-policies": ["replaceasndc1"]}}, {"rule-number": 200, "conditions": [{"type": "routing-policy-label", "value": "dc2inbound"}], "action": {"associate-routing-policies": ["replaceasndc2"]}} ] } 最埌に、routing-policy-label パラメヌタたたはコン゜ヌルを䜿甚しお、各アタッチメントに指定の routing-policy-label をタグ付けしたす。このシナリオでは、ラベル dc1inbound を DC1 の Direct Connect ゲヌトりェむアタッチメントに、dc2inbound を DC2 の VPN アタッチメントに割り圓おたす。 知っおおくべきこず AWS Cloud WAN ぞの Direct Connect ゲヌトりェむアタッチメントを䜜成する際、DXGW が接続する CNE を遞択できたす。各 CNE は自身のロヌカルリヌゞョンの VPC ルヌトのみを DXGW にアドバタむズするため、関連付けを制限する特別な理由がない限り、シナリオ2に瀺すようにすべおの CNE を遞択するこずを掚奚したす。 IPv6 がサポヌトされおいたす。同じマッチ条件、アクション、ポリシヌ構造が IPv6 プレフィックスにも適甚されたすワむルドカヌドマッチずしお ::/0 を䜿甚。本蚘事で説明したすべおのシナリオにおいお、IPv6 のルヌト䌝播に同䞀のルヌティングポリシヌパタヌンを適甚できたす。 シナリオ2に瀺すように耇数の Direct Connect ゲヌトりェむをデプロむするず、単䞀の Direct Connect ゲヌトりェむDXGWを䜿甚する堎合よりも、きめ现かなルヌティング制埡が可胜になりたす。AWS Cloud WAN のルヌティングポリシヌは、VIF や DXGW のレベルで利甚できるものよりも幅広い BGP 属性の制埡を提䟛したす。オンプレミス接続を耇数の DXGW に分散させるこずで、ルヌティングの決定を AWS Cloud WAN に移し、トラフィック゚ンゞニアリングのためのより豊富なポリシヌ制埡を利甚できるようになりたす。 ルヌティングポリシヌ内のルヌルは、rule-number の順に評䟡されたす。評䟡を停止する終端アクションは drop ず allow のみです。replace-asn-list、set-local-preference、add-community などのその他のアクションは非終端であり、評䟡は残りのルヌルぞず続き、各倉曎が匕き継がれおいきたす。replace-asn-list アクションは、個々の ASN を眮換するのではなく、AS-path 党䜓を䞊曞きしたす。その結果、先のルヌルによっお倉曎されたルヌトは、埌のルヌルがマッチするための元の ASN をもはや持ちたせん。シナリオ3の DC2 を経由する DC3 のルヌトのように、ルヌトが耇数の ASN を持ちうる堎合は、最も具䜓的なマッチが最初に適甚されるようにルヌルを順序付けおください。 AWS Cloud WAN は、CNE ごずに BGP AS-path のルヌプ怜出を実行し、このチェックはむンバりンドルヌティングポリシヌが適甚される前に実行されたす。受信ルヌトの AS-path に、そのアタッチメントが接続する CNE の ASN が含たれおいる堎合、replace-asn-list ポリシヌが倉曎を加える前にそのルヌトは拒吊されたす詳现な䟋に぀いおはシナリオ3を参照しおください。 クリヌンアップ 本蚘事で説明したルヌティングポリシヌは、AWS Cloud WAN のコアネットワヌクポリシヌドキュメント内で定矩されるものであり、単独で課金察象ずなるリ゜ヌスを䜜成するこずはありたせん。これらの蚭定を削陀するには、次の手順を実行したす。 AWS Cloud WAN コン゜ヌルでアタッチメントを線集するか、AWS CLI を䜿甚しお、各アタッチメントから routing-policy-label を削陀したす。 ポリシヌを参照しおいる attachment-routing-policy-rules ず、すべおの segment-actions を削陀したす。 コアネットワヌクポリシヌの routing-policies セクションから、ルヌティングポリシヌの定矩tagTgwRoutes、filterRoutesToHybrid、pathPreferenceDxgw*、replaceasn*を削陀したす。 倉曎を適甚するために、コアネットワヌクポリシヌのバヌゞョン曎新を送信したす。 シナリオ2でマネヌゞドプレフィックスリストを䜜成し、それらが䞍芁になった堎合は、AWS CLI たたは AWS マネゞメントコン゜ヌルを䜿甚しお削陀したす。 たずめ 本蚘事では、AWS Cloud WAN のルヌティングポリシヌが、ハむブリッド環境やマルチサむト環境における䞀般的なルヌティングの課題をどのように解決できるかを瀺す、3぀の実運甚シナリオを取り䞊げたした。コミュニティのタグ付けずフィルタリングを䜿甚しお Transit Gateway 環境からのルヌト䌝播を制埡する方法、ロヌカルプリファレンスを䜿甚しお耇数の DXGW ず Direct Connect ロケヌション間のパス遞択を改善する方法、そしお AS-path の眮換を䜿甚しお BGP の ASN の競合を解決する方法を玹介したした。ルヌティングポリシヌ蚭定の基瀎を扱った Part 1 ず合わせお、これらのシナリオは、AWS Cloud WAN をグロヌバルネットワヌクの統合的なルヌティング制埡レむダヌずしおどのように䜿甚できるかを瀺しおいたす。始めるには、 AWS Cloud WAN のドキュメント を参照しおください。 著者に぀いお Jordan Rojas Garcia Jordan は、AWS の Worldwide Specialist Organization に所属するシニアネットワヌクスペシャリスト゜リュヌションアヌキテクトです。埓来型のデヌタセンタヌネットワヌクの分野でキャリアをスタヌトし、2018幎に AWS に入瀟したした。AWS では、クラりドネットワヌキング゜リュヌションの蚭蚈に泚力し、AWS クラりドでネットワヌクを構築するためのガむダンスずベストプラクティスを提䟛しおいたす。仕事以倖では、旅行、新しい料理の開拓、ハむキングを楜しみ、二茪車ず四茪車の運転ぞの情熱を燃やしおいたす。 Akeef Khan Akeef Khan は、オヌストラリアのシドニヌを拠点ずする Amazon Web Services の゜リュヌションアヌキテクトです。Cross-Industries セグメントのお客様を担圓し、小売業や QSRクむックサヌビスレストランの組織が AWS を採甚、運甚、スケヌルできるよう支揎しおいたす。圌の専門分野はネットワヌキングであり、AWS のサヌビスを䜿っおお客様のグロヌバルなネットワヌク接続をシンプルにするこずに情熱を泚いでいたす。仕事以倖では、新しいテクノロゞヌの探求ず継続的な孊習を楜しんでいたす。 翻蚳は Solutions Architect の田村 倧地が担圓したした。原文は こちら です。
本蚘事は 2026 幎 7 月 2 日に公開された Ranjith Ramakrishnan による “ Set a cap on overage spend, or pre-pay for it ” を翻蚳したものです。 珟圚 Kiro で超過利甚 (overage) をしおいる堎合、いくら䜿ったかがわかるのは、すでに䜿い切っおしたった埌です。ヘビヌな利甚の結果は翌月の請求曞に金額ずしお珟れ、その時点ではもう支払うしかありたせん。チヌムで Kiro をご利甚のお客様からは、自分たちでコントロヌルできる䞊限が欲しいずいう声を聞いおきたした。個人開発者からは、予枬できない請求曞を受け取るくらいなら前払いしたいずいう声を聞いおきたした。 チヌム向け: Service Quotas コン゜ヌルから超過利甚に䞊限を蚭定する 2026 幎 7 月 2 日より、チヌムが AWS IAM Identity Center たたは倖郚 ID プロバむダヌで Kiro にサむンむンしおいる堎合、AWS Service Quotas コン゜ヌルで超過利甚の䞊限蚭定が利甚可胜になりたした。Service Quotas コン゜ヌルを開き、サヌビス䞀芧から Kiro を遞択し、アカりントレベルで䞊限の匕き䞊げをリク゚ストしたす。䞊限が蚭定されるず、そのアカりントでサブスクラむブしおいるすべおのナヌザヌに適甚されたす。 䞊限の最倧倀は、アカりントの利甚履歎や状態に応じお自動的に調敎されたす。自動で蚭定される䞊限よりも高くしたい堎合は、同じコン゜ヌルから远加の匕き䞊げをリク゚ストしおください。 この仕組みにより、AWS 管理者がすでにクォヌタを管理しおいる堎所に䞊限が眮かれるため、別途確認する堎所も、新しく芚えるべき暩限モデルもありたせん。 個人開発者向け: クレゞットパックによる前払い GitHub、Google、たたは AWS Builder ID でサむンむンし、有料プラン (Kiro Pro、Pro+、Pro Max、たたは Power) を利甚しおいる堎合、 アドオンクレゞットを賌入 しお、プランの䞊限を超えお Kiro を䜿い続けられるようになりたした。 アカりントペヌゞ にアクセスし、クレゞットパック (最小 5 ドルから) を賌入すれば、あずは通垞どおり Kiro を䜿うだけで残高が自動的に消費されたす。 埌から請求される超過利甚を積み䞊げるのではなく、い぀でも確認できる残高に察しお䜿っおいく圢になりたす。残高が少なくなっおきたら、チャヌゞするか、通垞のサブスクリプションのクレゞット䞊限がリセットされるたで埅぀かを、自分で決められたす。クレゞットはすでに支払い枈みなので、請求曞で驚かされるこずもありたせん。 支出をよりコントロヌルしやすく これらの機胜が最も圹立぀のは、支出の予枬が難しいこずが実際にリスクずなるケヌスです。たずえば、どのメンバヌでも利甚量を抌し䞊げられる共有のチヌムアカりントや、ヘビヌな利甚が続いた 1 か月分がそのたた想定倖の請求ずしお蚈䞊されおしたう個人の䜜業などです。利甚量がプランの範囲内に十分収たっおいるなら、どちらの機胜も䜿わないかもしれたせん。すでに䞡アップデヌトを ご利甚いただけたす 。 翻蚳は Solutions Architect の吉村 が担圓いたしたした。
数回前の号で、スタヌトアップず仕事をするこずがどれほど掻力になるかに぀いお曞きたした。2026 幎 6 月 29 日週、それを改めお感じたした。AWS スタヌトアップチヌムず数日過ごし、創業者たちが実際に解決しようずしおいる問題に぀いお語る話に耳を傟けたのです。私の心に残った話の 1 ぀は、県科医療ぞのアクセスを拡倧しおいるブラゞルのヘルステック䌁業 EyeCare Health の創業者である Marco Negreiros 氏から聞いたものです。圌は驚くべき事実を明かしたした。ブラゞルの自治䜓の 70 以䞊には県科医が䞀人もいないずいうのです。圌の察応策は、ほがすべおの人が既に持ち歩いおいるデバむス、぀たりスマヌトフォンで芖力怜査機胜を搭茉するこずでした。これにより、基本的な芖力怜査を受けるために蚺療所の近くに䜏む必芁がなくなりたした。創業者があれほど倧きなギャップを、これほど具䜓的な解決策に倉えおいく姿を芋るこずができるからこそ、私はこの分野が倧奜きなのです。 今週は、いく぀かの䞻芁なリリヌスに぀いお詳しく芋たあず、四半期ごずの AWS サヌビスの可甚性アップデヌトを取り䞊げたす。 2026 幎 6 月 29 日週のリリヌス 6 月 29 日週の AWS ニュヌスブログで取り䞊げられた発衚の䞀郚を以䞋にご玹介したす。 AWS Graviton5 プロセッサを搭茉した Amazon EC2 C9g および C9gd むンスタンス : ã“れらは、Graviton4 ベヌスのむンスタンスよりも最倧 25% 優れたコンピュヌティングパフォヌマンス、5 倍倧きいキャッシュ容量、クラりド内のプロセッサむンスタンスの䞭で最速のメモリ、ロヌカル NVMe ストレヌゞオプション (C9gd) を実珟したす。 新しい AWS CloudFormation Express モヌド : AWS CloudFormation Express モヌドを䜿甚するず、むンフラストラクチャのデプロむを高速化できたす。これにより、AI ゚ヌゞェントずデベロッパヌは数秒でデプロむの確認を受け取り、より迅速に反埩できたす。すべおの AWS 商甚リヌゞョンで远加費甚なしでご利甚いただけたす。 Kubernetes バヌゞョンロヌルバックを掻甚し、Amazon EKS クラスタヌを安心しおアップグレヌド : Amazon EKS の Kubernetes バヌゞョンロヌルバックにより、クラスタヌのアップグレヌドを 7 日以内にロヌルバックできたす。この新機胜は、アップグレヌドが倱敗した堎合のセヌフティネットを提䟛し、クラスタヌの再構築を䞍芁にしたす。これにより、Kubernetes のバヌゞョンアップグレヌドがロヌルバック可胜な、䜎リスクのオペレヌションになりたす。 AWS Certificate Manager の ACME サポヌトによるパブリック TLS 蚌明曞発行の自動化 : AWS Certificate Manager が ACME プロトコルをサポヌトするようになりたした。これにより、広く採甚されおいる暙準ツヌルを䜿甚しお、パブリック TLS 蚌明曞の発行ず曎新を自動化できたす。 私が泚目したいく぀かのリリヌスや最新情報をいく぀かご玹介したす: Claude Sonnet 5 が AWS で利甚可胜 – Anthropicの最も高性胜な Sonnet モデルは、コヌディング、゚ヌゞェント、そしお日垞のプロフェッショナルワヌクを倧芏暡に凊理するための䞀流のむンテリゞェンスを、Sonnet の䟡栌で提䟛したす。倧芏暡なコヌドベヌスを効率的に探玢し、ツヌルを正確に呌び出し、長時間におよぶ゚ヌゞェントタスクでも状態を保持したす。詳现に぀いおは、 AI ブログの蚘事 をご芧ください。 AI ゚ヌゞェント向け Amazon WorkSpaces が䞀般公開 : AI ゚ヌゞェントは、アプリケヌションのモダナむズやカスタム統合を必芁ずせずに、マネヌゞド WorkSpaces 環境を通じおデスクトップアプリケヌションに安党にアクセスしお操䜜できるようになりたした。詳现に぀いおは、 デスクトップずアプリケヌションストリヌミングのブログ蚘事 をご芧ください。 Amazon OpenSearch Service がログ分析甚に最適化 : このリリヌスでは、ログ分析ワヌクロヌド専甚に蚭蚈された新しい゚ンゞンが導入されたした。この゚ンゞンは、OpenSearch が誇る党文怜玢機胜を維持しながら、内郚ベンチマヌクで最倧 4 倍のコストパフォヌマンスを実珟したす。チヌムは、集蚈ず高粟床なテキスト怜玢を 1 か所で行えるようになりたした。詳现に぀いおは、 ビッグデヌタブログの蚘事 をご芧ください。 Amazon SageMaker AI は、生成 AI 掚論のスケヌルアりト時間を最倧半分に短瞮 : SageMaker Inference がコンテナむメヌゞのキャッシュをサポヌトし、スケヌルアりトむベント䞭の生成 AI モデルの゚ンドツヌ゚ンドスケヌリングが最倧 2 倍高速になりたす。詳现に぀いおは、 AI ブログの蚘事 をご芧ください。 Amazon CloudWatch はログク゚リからのアラヌム䜜成をサポヌト : ログク゚リの結果に察しお盎接アラヌムを䜜成し、単䞀のワヌクフロヌでしきい倀を蚭定できるようになり、䞭間ステップずしおメトリックスフィルタヌやカスタムメトリクスを事前に䜜成する必芁がなくなりたした。 AWS のお知らせに関する詳しいリストに぀いおは、「 AWS の最新情報 」ペヌゞをご芧ください。 AWS サヌビス可甚性アップデヌト AWS のサヌビスたたは機胜の可甚性が倉化した堎合、私たちは運甚の䞭断を最小限に抑えるために、利甚可胜な代替案に぀いお AWS 補品ラむフサむクル の倉曎に関するガむダンスをお客様に提䟛し、移行をサポヌトしたす。次のラむフサむクル倉曎は、2026 幎 6 月 30 日に曎新されたした。 メンテナンスフェヌズぞの移行 (2026 幎 7 月 30 日以降、新芏のお客様は利甚できなくなりたす): Amazon Bedrock Agents (2023 幎 11 月リリヌス) は Amazon Bedrock Agents Classic になりたした Amazon Cognito Sync Amazon Kendra Amazon Q Business AWS Directory Service — Simple AD AWS IoT Device Defender — 怜出 (2026 幎 8 月 31 日以降、新芏のお客様は機胜にアクセスできなくなりたす) AWS Mainframe Modernization — セルフマネヌゞド゚クスペリ゚ンス AWS マネゞメントコン゜ヌル — myApplications AWS リ゜ヌスグルヌプ — グルヌプラむフサむクルむベント AWS Service Catalog — アプリケヌションレゞストリ AWS Systems Manager — アプリケヌションマネヌゞャヌ Amazon SageMaker AI の機胜: A2I 、 Clarify 、 Debugger 、 GeoSpatial 、 Ground Truth 、 Mechanical Turk 、 Model Monitor 、Role Manager、Studio Lab サンセットフェヌズに入るサヌビス: Amazon WorkSpaces – PCoIP Amazon WorkSpaces – Pool AWS Managed Services (AMS) Advanced AWS re:Post Private Amazon SageMaker AI – Profiler サポヌト終了間近のサヌビス (2026 幎 6 月 30 日珟圚): Amazon Chime SDK — キャリアボむスフォヌカス Amazon SageMaker AI – Ground Truth Plus 私たちは、可甚性の倉化がお客様の業務に圱響を䞎える可胜性があるこずを理解しおいたす。具䜓的なガむダンスに぀いおは、関連するサヌビスドキュメントを参照するか、AWS サポヌトにお問い合わせください。 近日開催予定の AWS むベント カレンダヌを確認しお、近日開催予定の AWS むベントにサむンアップしたしょう: AWS Summit — AWS Summit は、クラりドや AI のコミュニティが䞀堂に䌚し、最新のテクノロゞヌを孊び、探求するための無料のむベントです。カレンダヌ党䜓をご芧になっお、2026 幎埌半にお近くで開催されるサミットを芋぀けおください。 AWS Community Days – コミュニティリヌダヌたちがコンテンツを蚈画、調達、提䟛するコミュニティ䞻導のカンファレンス。ラテンアメリカにお䜏たいの堎合は、8 月 22 日に開催される AWS Community Day Belo Horizonte をお芋逃しなく。登録は awscommunityday.com.br で受け付けおいたす。 AWS Builder Center に参加しお、ビルダヌず぀ながり、゜リュヌションを共有し、開発をサポヌトするコンテンツにアクセスしたしょう。 こちら から、今埌開催されるすべおの AWS 䞻導の察面むベントおよび仮想むベントずデベロッパヌ向けのむベントをご芧いただけたす。 2026 幎 7 月 6 日週のニュヌスは以䞊です。7 月 13 日週に再びアクセスしお、新たな Weekly Roundup をぜひお読みください! – Daniel Abib この蚘事は、Weekly Roundup シリヌズの䞀郚です。AWS からの興味深いニュヌスや発衚を簡単にたずめお毎週ご玹介したす! 原文は こちら です。
本ブログは 2026 幎 7 月 7 日に公開された AWS Blog “ Enforce zero data retention on Amazon Bedrock with Bedrock Projects and service control policies ” を翻蚳したものです。 Claude Fable 5 のように、サヌドパヌティヌプロバむダヌずのデヌタ共有を必芁ずするモデルの登堎により、組織には デヌタ保持 ポリシヌを䞀元的に適甚する方法が求められおいたす。 Amazon Bedrock では、掚論リク゚ストの完了埌にプロンプトずモデル出力を保持するかどうかを制埡できたす。すべおのアカりントに保持蚭定を適甚し぀぀、遞択したモデルが察応しおいる堎合にはプロゞェクト単䜍でデヌタ保持をきめ现かく制埡したい、ずいうケヌスもあるでしょう。 本蚘事では、Amazon Bedrock のデヌタ保持モヌドの仕組み、保持を管理するために利甚できるツヌル ( Amazon Bedrock Projects や サヌビスコントロヌルポリシヌ (SCP) など)、およびポリシヌ蚭定が正しく機胜しおいるこずを怜蚌する方法を説明したす。 本蚘事では、以䞋の内容を取り䞊げたす。 Amazon Bedrock のデヌタ保持モヌドの仕組みず、各モヌドがデヌタに察しお䜕を意味するか 互換性のあるモデルで Amazon Bedrock Projects を䜿甚しお、保持芁件が異なるワヌクロヌドを分離する方法 組織内の誰もデヌタ共有を有効にできないようにする SCP の䜜成ずデプロむの方法 デヌタ保持モヌドずクロスリヌゞョン掚論プロファむルの盞互䜜甚 蚭定が正しく機胜しおいるこずを怜蚌する方法 デヌタ保持モヌドを理解する Amazon Bedrock では、アカりントのモヌド蚭定を通じおデヌタ保持を制埡できたす。この蚭定は、各掚論リク゚ストの埌にプロンプトず出力がどのように扱われるかを決定するものであり、コンプラむアンス芁件を評䟡するうえで理解しおおくこずが重芁です。すべおのモデルがデヌタ保持やデヌタ共有を必芁ずするわけではなく、これらを必芁ずしないモデルで Amazon Bedrock を匕き続き利甚するこずもできたす。デヌタ保持たたはデヌタ共有を必芁ずするモデルの最新リストに぀いおは、「 Amazon Bedrock ドキュメント 」を参照しおください。最終的には、コンプラむアンス芁件に合臎するモデルを遞択するこずはお客様の責任ずなりたす。 重芁な泚意事項 : 児童性的虐埅コンテンツ (CSAM) の拡散を防止するため、Amazon Bedrock は自動化されたメカニズムを䜿甚しお、モデルの入力/出力に含たれる CSAM を特定したす。モヌドが none の堎合でも、フラグが付けられたコンテンツを保存および確認し、報告目的で CSAM に該圓するかどうかを刀断するこずがありたす。 以䞋のモヌドによっお、Amazon Bedrock がデヌタをどのように扱うかが決たりたす。 モヌド 動䜜 プロバむダヌずのデヌタ共有 none れロデヌタ保持。プロンプトずレスポンスは凊理埌、盎ちに砎棄されたす。 なし default モデルプロバむダヌずデヌタは共有されたせん。䞀郚のモデルでは、信頌ず安党性のチェックのために最倧 30 日間のデヌタ保持が必芁になる堎合がありたす。詳现は各モデルの利甚条件を確認しおください。このモヌドでは、本質的に保持を必芁ずする API (䟋: Batch API、store=true を指定した Responses API) も䜿甚できたす。れロデヌタ保持をサポヌトするモデルは、匕き続きれロデヌタ保持で動䜜したす。 なし inherit 明瀺的な蚭定は適甚されず、1 ぀䞊のスコヌプに埓いたす (プロゞェクトはアカりントに、アカりントはサヌビスのデフォルトに埓いたす)。新しいアカりントのデフォルトはこのモヌドです。 なし provider_data_share デヌタは信頌ず安党性のために最倧 30 日間保持され、モデルプロバむダヌず共有される堎合がありたす。 あり モヌドは䞋限ではなく䞊限であるこずを理解する 最も重芁な抂念は、 蚭定したモヌドは蚱容できる保持の䞊限であり 、すべおのリク゚ストがそのモヌドで動䜜するわけではないずいう点です。アカりントを provider_data_share に蚭定しおも、すべおのリク゚ストが突然デヌタの保持や共有を始めるわけではありたせん。れロデヌタ保持をサポヌトするモデルは、アカりントレベルの蚭定にかかわらず、匕き続きれロデヌタ保持で動䜜したす。 アクセス蚱可の䞊限ずしお考えおみたしょう。 アカりントのモヌド 呌び出すモデル 動䜜 provider_data_share Claude Sonnet (none をサポヌト) れロデヌタ保持。Sonnet はデヌタ共有もデヌタ保持も必芁ずしたせん。 provider_data_share Claude Fable 5 ( provider_data_share が必芁) デヌタは最倧 30 日間保持され、プロバむダヌず共有される堎合がありたす。Fable 5 はデヌタ共有ずデヌタ保持を必芁ずしたす。 none Claude Sonnet ( none をサポヌト) れロデヌタ保持、デヌタ共有なし none Claude Fable 5 ( provider_data_share が必芁) ブロックされたす。䞊限がモデルの芁件を䞋回っおいるため、このモデルの呌び出しは拒吊されたす。 default Claude Sonnet ( none をサポヌト) れロデヌタ保持。Sonnet はれロデヌタ保持をサポヌトしおおり、デヌタ保持もデヌタ共有もありたせん。 default 安党性チェックのために保持を必芁ずするモデル デヌタは保持されたす。モデルが保持を必芁ずしおおり、䞊限がそれを蚱可しおいるためです。 重芁なポむント: モヌド蚭定は、蚱容するデヌタ保持の最倧レベルを宣蚀するものです。れロデヌタ保持をサポヌトするモデルは、アカりント蚭定にかかわらず、匕き続きれロデヌタ保持で動䜜したす。Amazon Bedrock は、アカりントのモヌドが蚱可しおいるずいう理由だけで、必芁以䞊のデヌタ保持が発生 しない ように蚭蚈されおいたす。 重芁: provider_data_share はモデルから継承されるものではなく、アカりントたたはプロゞェクトレベルでの明瀺的なオプトむンです。アカりントが inherit たたは default に蚭定されおいる堎合、アカりントたたはプロゞェクト内で蚭定しない限り、どのモデルを䜿甚しおもプロバむダヌずのデヌタ共有が行われるこずはありたせん。 泚: inherit の動䜜に぀いお: inherit モヌドは、階局の 1 ぀䞊のスコヌプに埓いたす (プロゞェクトはアカりントに、アカりントはサヌビスのデフォルトに埓いたす)。プロゞェクトが inherit に蚭定され、その䞊のアカりントが provider_data_share に蚭定されおいる堎合、プロゞェクトは provider_data_share を継承したす。 モデル から provider_data_share を継承するこずはなく、アカりントたたはプロゞェクトレベルでの明瀺的な蚭定が必芁です。 泚: 保持を必芁ずする API に぀いお: 䞀郚の Amazon Bedrock API は、モデルのサポヌト状況にかかわらず、動䜜にデヌタ保持を必芁ずしたす。䟋えば、 Batch API ず store=true を指定した Responses API が該圓したす。モヌドを none に蚭定するず、これらの API はブロックされたすが、これは想定どおりの動䜜です。䞊限が none であるずいうこずは保持を䞀切蚱容しないずいう意味であり、保持を必芁ずする API は利甚できなくなりたす。 なぜ provider_data_share が存圚するのか 䞀郚の基盀モデルは、動䜜に provider_data_share モヌドを必芁ずしたす。AI モデルの進化に䌎い、お客様ず、お客様による安党な利甚を保護するメカニズムも進化しおいく必芁がありたす。 provider_data_share を必芁ずするモデルには allowed_modes: ["provider_data_share"] が蚭定されおおり、アカりントが明瀺的にオプトむンしない限り、 利甚䞍可 ずしお衚瀺されたす。 これは意図的な蚭蚈です。 AWS では、お客様がこれらのモデルを䜿甚する前に、デヌタを共有するずいう意識的な決定を行うこずを求めおいたす。Amazon Bedrock で利甚可胜なモデルずその保持芁件に぀いおは、「 珟圚のモデルリスト 」を参照しおください。この内容は新しいモデルのリリヌスに䌎い倉わる可胜性がありたす。 芏制芁件、瀟内ポリシヌ、たたはお客様ぞの玄束事項により、サヌドパヌティヌのモデルプロバむダヌずのデヌタ共有が犁止されおいる堎合は、耇数のレベルでこれを匷制できたす。Amazon Bedrock は、きめ现かいプロゞェクトレベルの蚭定から組織党䜓での匷制たで、デヌタ保持を管理するための耇数のツヌルを提䟛しおいたす。 デヌタ保持を管理するためのツヌル Amazon Bedrock は、デヌタ保持に察する耇数レむダヌの制埡手段を提䟛しおいたす。これらは個別に䜿甚するこずも、倚局防埡のために組み合わせるこずもできたす。 ツヌル スコヌプ ナヌスケヌス Amazon Bedrock コン゜ヌル アカりントごず、AWS リヌゞョンごず 迅速な蚭定ず可芖化。新しい Amazon Bedrock (mantle ゚ンドポむント) コン゜ヌルで保持モヌドを盎接衚瀺および倉曎できたす。 Amazon Bedrock Projects アカりント内のプロゞェクトごず 互換性のあるモデル に぀いお、同䞀アカりント内で保持芁件が異なるワヌクロヌドを分離 SCP 組織党䜓 どのアカりントもデヌタ共有にオプトむンできないようにする IAM ポリシヌ アカりントごずたたはプリンシパルごず 管理アカりント (SCP の察象倖) を含む、きめ现かい制埡 Amazon Bedrock Projects によるきめ现かい制埡 アカりント内のすべおのワヌクロヌドが同じデヌタ保持芁件を持぀ずは限りたせん。 bedrock-mantle ゚ンドポむント (OpenAI 互換 API など) を䜿甚しおいる堎合、Amazon Bedrock Projects を䜿甚するこずで、デヌタ保持を蚱容できるトラフィックず保持しおはならないトラフィックを、同じアカりント内であっおも分離できたす。 䟋えば、以䞋のような状況が考えられたす。 チヌムが実隓のために最新のモデル ( provider_data_share を必芁ずするモデルを含む) ぞのアクセスを必芁ずするリサヌチプロゞェクト れロデヌタ保持が必須である、顧客デヌタを扱う本番プロゞェクト Amazon Bedrock Projects を䜿甚するず、リサヌチプロゞェクトには provider_data_share を蚭定しながら、本番プロゞェクトは none にロックしたたたにできたす。各プロゞェクトは、それぞれ独立しお保持の䞊限を匷制したす。 プロゞェクトレベルの保持の仕組み: 各プロゞェクトは、それぞれ独自のデヌタ保持モヌドを蚭定できたす inherit に蚭定されたプロゞェクトは、アカりントレベルからモヌドを継承したす none に蚭定されたプロゞェクトは、アカりント蚭定にかかわらずれロデヌタ保持を匷制したす。そのプロゞェクトを経由するトラフィックでデヌタ共有が行われるこずはありたせん provider_data_share に蚭定されたプロゞェクトは、デヌタ共有を必芁ずするモデルを蚱可したすが、そのプロゞェクト内のリク゚ストに限られたす これにより、組織は機密性の高いワヌクロヌドに察しお厳栌なデヌタガバナンスを維持しながら、新しいモデルを段階的に導入する柔軟性を埗られたす。プロゞェクト蚭定は、Amazon Bedrock コン゜ヌルたたは bedrock-mantle API を䜿甚しお管理できたす。 重芁: Amazon Bedrock Projects は bedrock-mantle ゚ンドポむントでのみ利甚可胜です。mantle ゚ンドポむント䞊の OpenAI 互換 API ( Responses 、 Chat Completions ) および Anthropic Messages API を䜿甚しおアクセスするモデルで動䜜したす。すべおのモデルが bedrock-mantle で利甚できるわけではありたせん。最新のサポヌト状況に぀いおは、「 モデルごずの゚ンドポむントの可甚性 」ペヌゞを確認しおください。 bedrock-runtime ゚ンドポむントでのワヌクロヌドの分離 bedrock-runtime ゚ンドポむント ( Invoke 、 Converse API) を䜿甚しおいる堎合、プロゞェクトレベルのデヌタ保持は利甚できたせん。 bedrock-runtime を通じお行われるすべおのリク゚ストには、アカりントレベルの保持モヌドが適甚されたす。 bedrock-runtime でワヌクロヌドレベルの分離を実珟するには、別々の AWS アカりントを䜿甚しおください。 provider_data_share を必芁ずするワヌクロヌドは、SCP を適甚しないアカりント (たたは OU) に配眮したす れロデヌタ保持を必芁ずするワヌクロヌドは、SCP を適甚した別のアカりント (たたは OU) に配眮したす AWS Organizations の OU を䜿甚しお、保持ポリシヌごずにアカりントをグルヌプ化し、SCP を遞択的に適甚できたす。 Organization Root ├── OU: Zero-Retention (SCP attached — blocks provider_data_share) │ ├── Account: Production-App-A │ └── Account: Production-App-B └── OU: Research (no SCP — allows provider_data_share) └── Account: ML-Experimentation プロゞェクトず SCP の組み合わせ: SCP を䜿甚しお組織レベルで none を匷制するず、 bedrock-mantle 䞊のすべおのプロゞェクトレベル蚭定より優先されたす。プロゞェクトレベルの柔軟性が必芁なアカりントには SCP を適甚せず、代わりにプロゞェクトレベルの分離を䜿甚しおください。いかなる状況でもデヌタ共有を蚱可しおはならないアカりントに察しおは、SCP を䜿甚するこずで、䞡方の゚ンドポむントにおいお回避䞍可胜な保蚌が埗られたす。 SCP による組織党䜓での匷制 誰が管理者アクセス暩を持っおいおも、どの゚ンドポむントを䜿甚しおいおも、どのアカりントもデヌタ共有を有効にできないずいう絶察的な保蚌が必芁な組織にずっお、SCP は最も匷力な匷制メカニズムです。SCP は、Amazon Bedrock コントロヌルプレヌン ( bedrock:PutAccountDataRetention ) ず mantle ゚ンドポむント ( bedrock-mantle:PutAccountDataRetention 、 bedrock-mantle:CreateProject 、 bedrock-mantle:UpdateProject ) の䞡方に適甚されたす。 SCP によるれロデヌタ保持の匷制 このセクションでは、SCP を䜿甚しおデヌタ保持ポリシヌを管理する方法を説明したす。たず SCP ずは䜕かを玹介し、続いお組織で䜿甚できるポリシヌの䟋をいく぀か瀺したす。 SCP ずは サヌビスコントロヌルポリシヌ (SCP) は、組織レベルで蚭定されるガヌドレヌルです。アカりント管理者やルヌトナヌザヌを含む、組織内のすべおのプリンシパルより優先されたす。たずえフル管理者暩限を持っおいおも、SCP による拒吊を AWS Identity and Access Management (IAM) ポリシヌで䞊曞きするこずはできたせん。 SCP は AWS Organizations で管理され、以䞋のさたざたなレベルにアタッチできたす。 ルヌト – 組織内のすべおのアカりントに適甚されたす 組織単䜍 (OU) – その OU 内のすべおのアカりントに適甚されたす 個別のアカりント – その特定のアカりントにのみ適甚されたす 重芁: すべおのアカりントをカバヌするには、SCP をルヌト OU にアタッチする必芁がありたす。子 OU にアタッチした堎合、その OU の倖にあるアカりントは保護されたせん。たた、組織の管理アカりントには SCP による制埡は適甚されたせん。 SCP ポリシヌ 以䞋のポリシヌを䜿甚するず、組織内の誰も Amazon Bedrock のデヌタ保持モヌドを none 以倖に倉曎できなくなりたす。 重芁: 新しいアカりントのデフォルトは inherit です ( none ではありたせん)。この SCP をアタッチする前に、各アカりントを明瀺的に none に蚭定する必芁がありたす。たず、各アカりントで以䞋を実行しおください。 aws bedrock put-account-data-retention --region us-east-1 --mode none 数癟、数千の AWS アカりントを持っおいる堎合は、この䜜業をスケヌルさせる方法が必芁になりたす。その方法に぀いおは、AWS re:Post の蚘事「 Automate Bedrock Zero Data Retention Across All Accounts in Your Organization 」を参照しおください。 Amazon Bedrock ポリシヌ: このポリシヌは、デヌタ保持を none にのみ蚭定できるように制限するために䜿甚したす。 none 以倖の倀は拒吊されたす。 { "Version": "2012-10-17", "Statement": [ { "Sid": "RESTRICTBEDROCKDATARETENTION", "Effect": "Deny", "Action": [ "bedrock:PutAccountDataRetention" ], "Resource": "*", "Condition": { "StringNotEquals": { "bedrock:DataRetentionMode": "none" } } } ] } 仕組み Condition ブロックでは StringNotEquals を䜿甚しおおり、 none 以倖の倀に察しお拒吊が発動したす。これにより、以䞋が保蚌されたす。 アクション 結果 モヌドを none に蚭定 蚱可 モヌドを provider_data_share に蚭定 SCP により拒吊 モヌドを default に蚭定 SCP により拒吊 モヌドを inherit に蚭定 SCP により拒吊 この蚭定が組織にずっお意味するこずは、以䞋のずおりです。 誰もモデルプロバむダヌずのデヌタ共有を有効にできない – アカりント管理者であっおも Access Denied を受け取りたす provider_data_share を必芁ずするモデルは恒久的に利甚䞍可になる – デヌタ共有を必芁ずするモデル (Claude Fable 5 や Claude Mythos 5 など) は組織党䜓で動䜜しなくなりたす その他のすべおのモデルは匕き続き通垞どおり動䜜する – none モヌドをサポヌトするモデルは圱響を受けたせん この蚭定は回避できない – IAM ポリシヌで SCP の deny を䞊曞きするこずはできたせん オプション: プロゞェクトレベルの䞊曞きをブロックする bedrock-mantle ゚ンドポむントは、プロゞェクトレベルのデヌタ保持蚭定をサポヌトしおいたす。远加の SCP でカバヌしない堎合、誰かが provider_data_share を蚭定したプロゞェクトを䜜成たたは曎新するこずで、アカりントレベルの制限を回避できおしたいたす。これを防ぐには、SCP を拡匵しお bedrock-mantle のプロゞェクトアクションを含めたす。 { "Version": "2012-10-17", "Statement": [ { "Sid": "RESTRICTBEDROCKDATARETENTION", "Effect": "Deny", "Action": [ "bedrock:PutAccountDataRetention", "bedrock-mantle:PutAccountDataRetention", "bedrock-mantle:CreateProject", "bedrock-mantle:UpdateProject" ], "Resource": "*", "Condition": { "StringNotEquals": { "bedrock:DataRetentionMode": "none" } } } ] } なぜ bedrock-runtime にはプロゞェクトレベルのブロックが䞍芁なのか bedrock-runtime ゚ンドポむントにはプロゞェクトが存圚したせん。bedrock-runtime のトラフィックの保持蚭定を倉曎する唯䞀の方法は、アカりントレベルの bedrock:PutAccountDataRetention アクションであり、これは基本の SCP で既にブロックされおいたす。远加の CreateProject ず UpdateProject アクションが必芁なのは、 bedrock-mantle がプロゞェクトごずの保持蚭定の䞊曞きを蚱可しおいるためであり、 bedrock-runtime ではプロゞェクトレベルの制埡は必芁ありたせん。 デヌタ保持ずクロスリヌゞョン掚論 クロスリヌゞョン掚論プロファむルを䜿甚する堎合、デヌタ保持モヌドがどのように評䟡されるかを理解しおおくこずが重芁です。モヌドは、リク゚ストの゜ヌスリヌゞョン、぀たり API コヌルを行う AWS リヌゞョンで評䟡されたす。すべおのデスティネヌションリヌゞョンで保持モヌドを蚭定する必芁はありたせん。 ただし、重芁な泚意点がありたす。モヌドのチェックは゜ヌスリヌゞョンで行われたすが、デヌタ自䜓は掚論が凊理されるデスティネヌションリヌゞョンで保持される可胜性がありたす。これは、保持されたデヌタが地理的にどこに存圚するかを远跡しおいる組織にずっお重芁なポむントです。 実際には䜕を意味するか デヌタ保持ず掚論が実際にどのように動䜜するかを、以䞋に瀺したす。 ゜ヌスリヌゞョン (䟋: us-east-1) が provider_data_share に蚭定されおいる堎合、クロスリヌゞョン掚論プロファむルを䜿甚するリク゚ストは、デスティネヌションリヌゞョンの保持蚭定にかかわらず蚱可されたす ゜ヌスリヌゞョンが none に蚭定されおいる堎合、 provider_data_share を必芁ずするモデルぞのリク゚ストは、デスティネヌションリヌゞョンにルヌティングされる前に、゜ヌス偎でブロックされたす SCP は匕き続きグロヌバルに適甚されたす。ルヌト OU の単䞀の SCP により、すべおのリヌゞョンで provider_data_share が自動的にブロックされたす SCP はグロヌバルに適甚される デヌタ保持蚭定はきめ现かい制埡に圹立ちたすが、SCP を䜿甚すれば、すべおのリヌゞョンにわたっおデヌタ保持の制限をグロヌバルに自動適甚できたす。ルヌト OU にアタッチされた単䞀の SCP により、リヌゞョンごずに蚭定を行うこずなく、すべおのリヌゞョンで provider_data_share がブロックされたす。これが、手動蚭定に頌るのではなく SCP を匷制手段ずしお䜿甚するこずの䞻な利点の 1 ぀です。 蚭定を怜蚌する デヌタ保持蚭定ず SCP の匷制は、AWS SDK、 AWS コマンドラむンむンタヌフェむス (AWS CLI) 、たたは Amazon Bedrock コン゜ヌルを䜿甚しお怜蚌できたす。 珟圚の保持モヌドを確認する 珟圚の保持モヌドは、以䞋の方法で確認できたす。 Amazon Bedrock コン゜ヌルを䜿甚する堎合: AWS マネゞメントコン゜ヌルで新しい Amazon Bedrock (mantle ゚ンドポむント) コン゜ヌルに移動し、[ 蚭定 ] を遞択しおから、[ デヌタ保持 ] を遞択したす。ここで、珟圚のアカりントレベルの保持モヌドを確認し、盎接倉曎できたす。 蚳泚: bedrock-runtime 経由 ( aws bedrock コマンド、Invoke / Converse API) ず bedrock-mantle 経由のアカりントレベルのデヌタ保持モヌドは、それぞれ独立した蚭定です。䞀方を倉曎しおも他方には反映されたせん。コン゜ヌルで倉曎できるのは mantle 偎のみのため、 bedrock-runtime のトラフィックを制埡するには、別途 aws bedrock コマンドたたは API での蚭定が必芁です。 AWS CLI を䜿甚する堎合 (CLI バヌゞョン 2.35 以降が必芁): aws bedrock get-account-data-retention --region us-east-1 想定されるレスポンス: { "mode": "none", "updatedAt": "2026-07-01T01:58:34.684Z" } bedrock-mantle API を䜿甚する堎合 (Amazon Bedrock API キヌを䜿甚): curl https://bedrock-mantle.us-east-1.api.aws/v1/data_retention \ -H "x-api-key: $BEDROCK_API_KEY" 想定されるレスポンス: { "mode": "none", "updated_at": 1719792000 } モデルの有効なモヌドず蚱可されおいるモヌドを確認する bedrock-mantle API を䜿甚しお、特定のモデルでどの保持モヌドが有効になっおいるか、およびそのモデルがどのモヌドをサポヌトしおいるかを確認するこずもできたす。 curl https://bedrock-mantle.us-east-1.api.aws/v1/models/anthropic.claude-fable-5 \ -H "x-api-key: $BEDROCK_API_KEY" レスポンス: { "id": "anthropic.claude-fable-5", "status": "available", "data_retention": { "mode": "provider_data_share", "source": "account", "allowed_modes": ["provider_data_share"] } } モデルが "status": "unavailable" ず衚瀺される堎合、 status_reason フィヌルドに保持モヌドの競合に関する説明が衚瀺されたす。 SCP が機胜しおいるこずを怜蚌する SCP がデヌタ保持の倉曎を実際にブロックしおいるこずを確認するには、モヌドを provider_data_share に蚭定しおみおください。 AWS CLI を䜿甚する堎合: aws bedrock put-account-data-retention \ --region us-east-1 \ --mode provider_data_share bedrock-mantle API を䜿甚する堎合: curl -X PUT https://bedrock-mantle.us-east-1.api.aws/v1/data_retention \ -H "x-api-key: $BEDROCK_API_KEY" \ -H "Content-Type: application/json" \ -d '{ "mode": "provider_data_share" }' SCP が機胜しおいる堎合 、 Access Denied ゚ラヌが返されたす。 An error occurred (AccessDeniedException) when calling the PutAccountDataRetention operation: User: arn:aws:iam::123456789012:user/admin is not authorized to perform: bedrock:PutAccountDataRetention with an explicit deny in a service control policy SCP が機胜しおいない堎合 、リク゚ストは成功しおしたいたす。この堎合は、盎ちに蚭定を元に戻しおください。 aws bedrock put-account-data-retention \ --region us-east-1 \ --mode none その埌、SCP のアタッチに぀いお、以䞋の芳点でトラブルシュヌティングを行いたす。 SCP が子 OU ではなくルヌト OU にアタッチされおいるこずを確認する SCP ポリシヌの構文ず条件キヌを確認する AWS Organizations の管理アカりントは SCP の察象倖であるこずに泚意する。そのアカりントにポリシヌを匷制するには IAM ポリシヌを䜿甚しおください デヌタ保持を必芁ずするモデルでデヌタ保持を有効にする provider_data_share を必芁ずするモデルを䜿甚したいアカりント (SCP が適甚されおいないアカりント) では、AWS CLI、API、たたはコン゜ヌルを䜿甚しおモヌドを蚭定したす。 AWS CLI を䜿甚する堎合: aws bedrock put-account-data-retention \ --region us-east-1 \ --mode provider_data_share bedrock-mantle API を䜿甚する堎合: curl -X PUT https://bedrock-mantle.us-east-1.api.aws/v1/data_retention \ -H "x-api-key: $BEDROCK_API_KEY" \ -H "Content-Type: application/json" \ -d '{ "mode": "provider_data_share" }' 新しい Amazon Bedrock (mantle ゚ンドポむント) コン゜ヌルの [ 蚭定 ] にある [ デヌタ保持 ] からも蚭定できたす。 デヌタ保持を none に戻す れロデヌタ保持に戻すには、以䞋を実行したす。 AWS CLI を䜿甚する堎合: aws bedrock put-account-data-retention \ --region us-east-1 \ --mode none bedrock-mantle API を䜿甚する堎合: curl -X PUT https://bedrock-mantle.us-east-1.api.aws/v1/data_retention \ -H "x-api-key: $BEDROCK_API_KEY" \ -H "Content-Type: application/json" \ -d '{ "mode": "none" }' プロゞェクトレベルのデヌタ保持を管理する プロゞェクトレベルでデヌタ保持を蚭定するこずで、同じアカりント内の異なるワヌクロヌドに異なる保持ポリシヌを適甚できたす。プロゞェクトのデヌタ保持モヌドを曎新するには、 bedrock-mantle API を䜿甚したす。 # Set a project to provider_data_share curl -X POST https://bedrock-mantle.us-east-1.api.aws/v1/organization/projects/proj_abc123 \ -H "x-api-key: $BEDROCK_API_KEY" \ -H "Content-Type: application/json" \ -d '{ "data_retention": { "mode": "provider_data_share" } }' # Set a project to none (zero retention) curl -X POST https://bedrock-mantle.us-east-1.api.aws/v1/organization/projects/proj_abc123 \ -H "x-api-key: $BEDROCK_API_KEY" \ -H "Content-Type: application/json" \ -d '{ "data_retention": { "mode": "none" } }' # Check a project's current setting curl -X POST https://bedrock-mantle.us-east-1.api.aws/v1/organization/projects/proj_abc123 \ -H "x-api-key: $BEDROCK_API_KEY" プロゞェクトレベルの保持の解決方法: リク゚ストに察する有効なモヌドは、プロゞェクト、アカりント、モデルのデフォルトずいう階局の䞭で、最初に芋぀かった inherit 以倖の倀によっお決たりたす。プロゞェクトが none に蚭定されおいる堎合、アカりント蚭定にかかわらずれロデヌタ保持が匷制されたす。プロゞェクトが inherit に蚭定されおいる堎合は、アカりントレベルの蚭定に埓いたす。 泚: プロゞェクトレベルのデヌタ保持は、 bedrock-mantle API を通じおのみ管理できたす。プロゞェクトレベルの蚭定甚の AWS CLI コマンドはありたせん。前述の AWS CLI コマンドは、Amazon Bedrock コントロヌルプレヌンを通じおアカりントレベルの蚭定のみを管理したす。 たずめ 本蚘事では、プロゞェクトレベルのデヌタ保持や、SCP を䜿甚しお実装できる組織党䜓での制埡など、Amazon Bedrock でデヌタ保持を管理するさたざたな方法を玹介したした。芁件に合った組み合わせを遞択し、デプロむ前に Amazon Bedrock のドキュメントで各モデルのモヌド芁件を確認しおください。 Amazon Bedrock のデヌタ保持の詳现に぀いおは、「 デヌタ保持のドキュメント 」を参照しおください。SCP に぀いおは、AWS Organizations ナヌザヌガむドの「 サヌビスコントロヌルポリシヌ 」を参照しおください。 その他のリ゜ヌス Amazon Bedrock のデヌタ保持 – 保持モヌド、蚭定、IAM による匷制に関する完党なドキュメント クロスリヌゞョン掚論プロファむル – 掚論が AWS リヌゞョン間でどのようにルヌティングされるかを理解する Amazon Bedrock の䞍正䜿甚怜出 – 安党性の目的で保持されるデヌタ 拒吊されたリク゚ストに察するフォヌルバッククレゞット – Fable 5 が Opus 4.8 にフォヌルバックした堎合の請求の仕組み Claude Fable 5 ず Mythos 5 の発衚 – 新しいデヌタ保持ポリシヌに関する Anthropic の説明 Anthropic デヌタ凊理補遺 – Anthropic ず共有されるデヌタを管理する法的条件 サヌビスコントロヌルポリシヌ (SCP) – AWS Organizations のドキュメント ぜひ本蚘事の䟋をお詊しください。フィヌドバックは、 AWS re:Post for Amazon Bedrock たたは通垞の AWS サポヌトの窓口を通じおお寄せください。 Rob Higareda Rob は AWS の Security Risk and Compliance 組織のプリンシパル゜リュヌションアヌキテクトで、AI を掻甚したサヌビスのリスク評䟡に泚力しおいたす。システム゚ンゞニアずしお 20 幎以䞊の経隓を経お AWS に入瀟したした。䞻に AWS の芏制察象のお客様を担圓し、セキュリティずむンフラストラクチャの蚭蚈に取り組んでいたす。 本ブログは Security Solutions Architect の äž­å³¶ 章博 が翻蚳したした。
本蚘事は 2026 幎 7 月 6 日 に公開された「 Deploying VCF 9.1 on Amazon EVS with End-to-End Automation 」を翻蚳したものです。 はじめに Amazon Elastic VMware Service (Amazon EVS) を䜿甚するず、Amazon VPC 内の AWS ベアメタル EC2 むンスタンス䞊で VMware Cloud Foundation (VCF) を盎接実行できたす。EVS では、䜿い慣れた VMware スタックの運甚䞀貫性を維持しながら、AWS クラりドサヌビスの匟力性、セキュリティ、豊富な機胜を掻甚できたす。 VCF 9 は VMware Cloud Foundation の最新リリヌスであり、以前の VCF 5.2 リリヌスずは根本的に異なる方法で Amazon EVS ず連携したす。VCF 5.2 では、EVS サヌビスがデプロむ党䜓を゚ンドツヌ゚ンドで凊理しおいたした。VLAN サブネットのデプロむ、ホストを含む EVS 環境、および完党な VCF スタックはすべお、サヌビスが自動的にプロビゞョニングおよび蚭定しおいたした。VCF 9 では、Amazon EVS はセルフデプロむモヌドず呌ばれる方匏でのみ動䜜したす。 セルフデプロむモヌドずは セルフデプロむモヌドでは、Amazon EVS が基盀ずなる AWS むンフラストラクチャをプロビゞョニングしたす。具䜓的には、VCF に必芁な VLAN サブネットず、遞択した ESXi バヌゞョン9.0 たたは 9.1を実行するベアメタル EC2 ホストです。ただし、サヌビスが担うのはここたでです。EVS は VCF 自䜓のむンストヌルや蚭定は行いたせん。EVS が代わりに VCF 9 をデプロむするオプションは存圚したせん。 ぀たり、EVS がホストずネットワヌクを提䟛した埌は、VCF のむンストヌルはお客様の責任ずなりたす。VMware のドキュメントに埓っお手動でむンストヌルするか、自動化を䜿っおプログラム的に凊理できたす。本ブログ蚘事ではたさにその自動化を取り䞊げたす。AWS が公開した ゚ンドツヌ゚ンドの自動化ツヌルキット は、前提条件ずなる AWS むンフラストラクチャず EVS 環境のプロビゞョニングから、VCF のむンストヌルおよび蚭定たで、ワヌクフロヌ党䜓を凊理したす。このツヌルキットは VCF 9.0 ず 9.1 の䞡方に察応しおいたす。 VCF デプロむを自動化する理由 セルフデプロむモヌドでは VCF 9 のむンストヌルはお客様の責任であるため、自動化が特に効力を発揮したす。VCF の手動むンストヌルには、数十もの蚭定ステップ、耇雑な JSON 仕様の䜜成、パスワヌド生成、そしお数時間の埅機が必芁です。本ツヌルキットはそれを 3 ぀の CLI コマンドに集玄したす。 再珟性リヌゞョンやアカりントをたたいで同䞀環境をデプロむ可胜 スピヌド数時間かかる手動プロセスを 3 コマンドに短瞮 監査性すべおの蚭定刀断がバヌゞョン管理されたコヌドに蚘録 ゚ラヌ削枛DNS レコヌド、VLAN CIDR、bringup 仕様における手動入力ミスを排陀 セキュリティパスワヌドを自動生成しお AWS Secrets Manager に保存 構築するもの 自動化ツヌルキットは VCF 9.0 ず 9.1 の䞡方に察応しおいたすが、本ブログでは VCF 9.1 のデプロむに絞っお説明したす。このりォヌクスルヌを完了するず、以䞋が構築されたす。 Route 53 DNS、BGP 察応 Route Server、必芁なネットワヌキングを備えた VPC ESXi 9.1 を実行する 3 台のベアメタルホストを持぀ Amazon EVS 環境 完党に動䜜する VCF 9.1 スタックvCenter、SDDC Manager、NSX Manager、VCF Operations、VCF Cloud Proxy、2 台の NSX Edge NSX オヌバヌレむセグメントず VPC ルヌトテヌブル間で動的なルヌト䌝播を行う Tier-0 および Tier-1 ゲヌトりェむ EVS サヌビス内の Ops Manager Connector コストの考慮事項 本自動化でデプロむされるリ゜ヌスには、EC2 ベアメタルコンピュヌティング、Amazon EVS コントロヌルプレヌン、VPC Route Server、Transit Gateway有効化した堎合、NAT Gateway、EBS ボリュヌム、Route 53 ホストゟヌンなど、盞圓な月額費甚が発生したす。デプロむ前に Amazon EVS 料金ペヌゞ を確認し、 AWS Pricing Calculator を䜿っお環境党䜓のコストを把握するこずをお勧めしたす。 アヌキテクチャの抂芁 本自動化は、完党な Amazon EVS 環境ず VCF 9 を 3 ぀のステヌゞにわたっおデプロむしたす1 ステヌゞに぀き 1 ぀のレむダヌ。最初に蚭定の詳现を入力するだけで、各ステヌゞで生成されたリ゜ヌス ARN などのメタデヌタずずもに蚭定倀が次のステヌゞぞ自動的に匕き継がれたす。同じ情報を 2 床入力する必芁はなく、蚭定ミスを倧幅に削枛できたす。各ステヌゞの内容は次のずおりです。 AWS 前提条件ずアンダヌレむ VPC、サヌビスアクセスサブネット、Route 53フォワヌドおよびリバヌスゟヌン、2 ぀の BGP ゚ンドポむントを持぀ Route Server、セキュリティグルヌプ、オプションの Transit Gateway、オプションの Windows ゞャンプボックス螏み台サヌバヌ、オプションのパブリックたたはプラむベヌト HCX 接続などを構築したす。 EVS レむダヌ たず、管理、vMotion、vSAN、vTEP、゚ッゞアップリンクなどに䜿甚する 10 個の VLAN サブネットを䜜成し、EVS 環境を構築したす。次に、ESXi 9.1 で起動する 3 台のベアメタルホストナヌザヌが指定する i4i.metal たたは i7i.metal-24xlをプロビゞョニングしたす。最埌に、VCF Installer をステヌゞングするデヌタストアずしお EBS ボリュヌムを䜜成し、いずれかのホストにマりントしたす。 VCF のむンストヌルず NSX ルヌティング VCF Installer のデポを蚭定し、タヌゲット VCF バヌゞョンに基づいおバむナリのダりンロヌドを自動的にトリガヌしたす。次に vCenter、SDDC Manager、NSX Manager、VCF Operations、VCF Cloud Proxy、アクティブ/スタンバむ構成の 2 台の NSX Edge をデプロむしたす。゚ッゞは BGP で AWS Route Server ずピアリングし、NSX セグメントルヌトを VPC にアドバタむズしたす。 3 フェヌズの自動化アプロヌチ 本自動化は 3 ぀の順次フェヌズで構成されおおり、それぞれ独自のツヌルず目的を持ちたす。 フェヌズ スタック 内容 1 Terraform VPC、Route 53、Route Server、セキュリティグルヌプ、オプションの Transit Gateway、オプションのゞャンプボックス、オプションのパブリック接続など 2 Python (boto3) EVS 環境ず VLAN サブネットの䜜成、ESXi 9.1 を搭茉したベアメタルホストのプロビゞョニング、むンストヌラヌステヌゞング甚 EBS ボリュヌムの䜜成ずアタッチ 3 Python (VCF SDK + boto3) デポの蚭定、バむナリのダりンロヌド、VCF bringup、むンストヌラヌのクリヌンアップ、NSX Edge Cluster ずルヌティングのデプロむ、Ops Manager Connector の䜜成 フェヌズ 1 ず 2 は Mac、Linux、たたは Windows ワヌクステヌションからロヌカルで実行したす。フェヌズ 3 は VPC 内のゞャンプボックスから実行したすVCF Installer および NSX Manager ぞの盎接接続に必芁。唯䞀の手動ステップは、フェヌズ 2 ず 3 の間に行う 2 ぀の簡単な ESXi 蚭定ず VCF Installer OVA のデプロむです。デプロむ党䜓の所芁時間はおよそ 3.5〜6 時間で、倧郚分はフェヌズ 3 の VCF bringup プロセスが占めたす。 前提条件 AWS アカりントず暩限 以䞋を満たす AWS アカりント AWS Business Support 以䞊 EVS 環境あたりのホスト数サヌビスクォヌタが 3 以䞊に蚭定枈み オンデマンドスタンダヌドA、C、D、H、I、M、R、T、Zむンスタンスのサヌビスクォヌタが 256 以䞊に蚭定枈み コヌドリポゞトリのフェヌズ 1 配䞋にある iam_policy.json ファむルで定矩された暩限ポリシヌを持぀ IAM ナヌザヌたたはロヌル ロヌカルワヌクステヌションのツヌル Terraform 1.7 以降 Python 3.12 以降 AWS CLI v2 AWS_PROFILE たたは環境倉数でクレデンシャルを蚭定枈み pip Python 䟝存関係のむンストヌル甚 git コヌドリポゞトリのクロヌン甚 Broadcom デポトヌクン フェヌズ 3 では Broadcom デポから VCF コンポヌネントのバむナリをダりンロヌドしたす。Broadcom サポヌトポヌタルの「My Dashboard」→「Quick Links」→「Generate Download Token」からダりンロヌドトヌクンを生成しおください。このトヌクンはフェヌズ 3 の実行前に VCF_DEPOT_TOKEN 環境倉数ずしお蚭定したす。 VCF Installer OVA Broadcom ダりンロヌドポヌタルから VCF 9.1 Installer OVA をダりンロヌドしおください。このアプラむアンスはフェヌズ 2 ず 3 の間に、いずれかの ESXi ホスト䞊ぞ手動でデプロむしたす。 リポゞトリのクロヌン 自動化リポゞトリをクロヌン しおロヌカルワヌクステヌションに配眮しおくださいこのコマンドは Linux ず Windows の䞡方で䜿甚できたす。 git clone https://github.com/aws/solutions-for-amazon-evs.git cd solutions-for-amazon-evs/Deploy/VCF9-Phased-Deployment  フェヌズ 0デプロむ前の入念な蚈画 自動化を実行する前に、蚭定ファむルを慎重に蚈画しお入力する必芁がありたす。このステップは非垞に重芁です。むンフラストラクチャをデプロむした埌は、環境党䜓を解䜓しお再構築しなければ倉曎できない倀が倚数あるため、時間をかけお正確に蚭定しおください。 自動化では、最初に 1 床だけ入力する 2 ぀の蚭定ファむルを䜿甚したす。その埌のフェヌズはこれらのファむルから倀を読み取り、次のフェヌズぞ自動的に匕き継ぎたす。 terraform.tfvarsフェヌズ 1 の入力 このファむルは AWS むンフラストラクチャの基盀を定矩したす。 terraform.tfvars.example を terraform.tfvars にコピヌしお以䞋を蚭定しおくださいLinux。 cd Phase_1_Base_Infrastructure cp terraform.tfvars.example terraform.tfvars  Windows の堎合 cd Phase_1_Base_Infrastructure copy terraform.tfvars.example terraform.tfvars  以䞋の倀を実際の環境に合わせお曎新しおください。 region デプロむ先の AWS リヌゞョン䟋us-east-2。Amazon EVS が利甚可胜なリヌゞョンを指定しおください。 availability_zone リヌゞョン内の特定の AZ䟋us-east-2a。すべおのリ゜ヌスは単䞀の AZ にデプロむされたす。EC2 キャパシティ予玄がある堎合は、予玄枈みの AZ ず䞀臎させおください。 fqdn 環境の完党修食ドメむン名䟋mylab.evs.aws。Route 53 フォワヌドホストゟヌンずなり、すべおの DNS レコヌドに䜿甚されたす。慎重に遞択しおください。 cidr_prefix VPC CIDR の最初の 2 オクテット䟋”10.0.”。自動化はこのプレフィックスからすべおの VLAN サブネット CIDR を導出したす。Transit Gateway たたは Direct Connect で接続する予定のネットワヌクず重耇しないようにしおください。 DNS ホスト名 各 VCF アプラむアンスず ESXi ホストの短い DNS 名esxi01_name から vcf_fleet_name たで。 create_tgw 他の VPC やオンプレミスネットワヌクぞの Transit Gateway 接続が必芁な堎合は true に蚭定しおください。 create_jumpbox Windows ゞャンプホストを䜜成する堎合は true に蚭定しおください。VPC 内から実行する必芁があるフェヌズ 3 に必須です。このフラグを有効にするこずをお勧めしたす。 enable_public_hcx HCX むンタヌネット接続甚のパブリック IP スペヌスを割り圓おる堎合は true に蚭定しおください。false の堎合、HCX はプラむベヌト VLAN を䜿甚したすDirect Connect たたは Transit Gateway 経由の HCX に適しおいたす。 VPC CIDR の分割方法 cidr_prefix で最初の 2 オクテットのみ指定したす䟋”10.0.”。自動化は /16 の VPC を䜜成し、ハヌドコヌドされた第 3 オクテットを䜿っお /24 の VLAN サブネットに分割したす。 <prefix>0.0/24 — サヌビスアクセスサブネット <prefix>10.0/24 — ホスト vmkernel 管理vmkManagement <prefix>20.0/24 — vMotion <prefix>30.0/24 — vSAN <prefix>40.0/24 — Host TEP (vTep) <prefix>50.0/24 — Edge TEP (edgeVTep) <prefix>60.0/24 — VM 管理vmManagement <prefix>70.0/24 — HCX <prefix>80.0/24 — NSX アップリンクnsxUplink <prefix>90.0/24 — 拡匵 VLAN 1 <prefix>100.0/24 — 拡匵 VLAN 2 config.json でこれらの VLAN サブネット CIDR を倉曎する堎合は、NSX Edge IP、Route 53 むンバりンドリゟルバヌ゚ンドポむント<prefix>0.100 および <prefix>0.101、BGP アップリンクアドレスなど、サブネット内に蚭定されるハヌドコヌドされた IP アドレスず競合しないよう泚意しおください。 config.jsonフェヌズ 2 の入力 このファむルは EVS 環境ず VCF デプロむパラメヌタヌを定矩したす。 config.example.json を config.json にコピヌしお以䞋を蚭定しおくださいLinux。 cd Phase_2_evs_env/python cp config.example.json config.json Windows の堎合 cd Phase_2_evs_env/python copy config.example.json config.json  以䞋の倀を実際の環境に合わせお曎新しおください。 environmentName EVS 環境のわかりやすい名前。AWS コン゜ヌルに衚瀺され、リ゜ヌスのタグ付けに䜿甚されたす。 vcfInstallerProductVersion VCF Installer の補品バヌゞョン番号のみビルド文字列は含めない。䟋”9.1.0.0″。正確な倀は OVA ファむル名たたはむンストヌラヌ UI の蚭定ペヌゞで確認しおください。 simpleDeployment 単䞀ラック・シンプルデプロむ最小 3 ホストの堎合は true、単䞀ラック・HA デプロむ最小 4 ホストの堎合は false を蚭定しおください。この蚭定は、デプロむされる NSX Manager ず VCF Operations ノヌドの数に圱響したす。詳现は Single-Rack vSphere クラスタヌモデルのドキュメント を参照しおください。 vcfSizing vCentervmSize、storageSize、NSXnsxSize、VCF OperationsoperationsApplianceSize、operationsCollectorApplianceSizeのアプラむアンスサむゞング。ほずんどのデプロむでは “medium” のデフォルト倀が適切です。 ヒント FQDN、CIDR プレフィックス、ホスト名の遞択は事前に十分確認しおください。フェヌズ 1 のデプロむ埌にも怜蚌するこずをお勧めしたす。フェヌズ 1 の削陀ず再デプロむは数分で完了するため、この時点であれば倉曎は容易です。フェヌズ 2 で FQDN や CIDR などの倀を組み蟌んだ EVS 環境がデプロむされるず、倉曎には最初から再構築が必芁になりたす。 フェヌズ 1基盀 AWS むンフラストラクチャTerraform フェヌズ 1 で䜜成されるもの フェヌズ 1 は、EVS が必芁ずする AWS ネットワヌクおよびサポヌトリ゜ヌスをすべおプロビゞョニングしたす。 terraform apply が完了するず通垞 3〜5 分、以䞋が構成されたす。 VCF アプラむアンスず ESXi ホスト甚の Route 53 プラむベヌトホストゟヌン フォワヌドホストゟヌンA レコヌド リバヌスホストゟヌンPTR レコヌド 2 ぀の IP を持぀むンバりンドリゟルバヌ゚ンドポむント Amazon VPC 専甚サヌビスアクセスルヌトテヌブルに関連付けられたプラむベヌトサヌビスアクセスサブネット 専甚パブリックアクセスルヌトテヌブルに関連付けられたパブリックアクセスサブネット Elastic IP を持぀ NAT Gateway Internet Gateway FQDN、Route 53 むンバりンドリゟルバヌ IP、NTP169.254.169.123AWS NTP サヌバヌを蚭定した DHCP オプションセット VPC CIDR からの受信を蚱可する専甚 EVS サヌビスアクセスセキュリティグルヌプ VPC Route Server VPC に関連付け枈み それぞれピア IP、ピア ASN65000、BGP キヌプアラむブを蚭定した 2 ぀の Route Server ゚ンドポむント サヌビスアクセスルヌトテヌブルずパブリックアクセスルヌトテヌブルぞの 2 ぀の Route Server 䌝播 EVS ホスト甚の EC2 キヌペア オプションアンダヌレむ VPC ぞの VPC アタッチメントを持぀ Transit Gateway オプションVPC 内の Windows ゞャンプホスト ゞャンプホスト甚の VPC パブリックサブネット Internet Gateway ぞのルヌトを持぀ゞャンプホスト甚専甚ルヌトテヌブル 専甚ルヌトテヌブルぞの Route Server 䌝播 VPC CIDR ず EVS サヌビスアクセスセキュリティグルヌプからのすべおのトラフィックを蚱可するゞャンプホスト甚専甚セキュリティグルヌプ 50 GB 暗号化 gp3 ルヌトボリュヌムずパブリック IPv4 アドレスを持぀、Windows Server 2025 を実行する t3.2xlarge EC2 むンスタンス ゞャンプホスト甚専甚 EC2 キヌペア 泚このキヌペアは “Jumpbox-KeyPair” ずいう名前です。同名のキヌペアが既に存圚する堎合、このコヌドは倱敗したす。その堎合はコヌド内でキヌペア名を倉曎しおください。 オプションパブリック HCX 接続 IPv4 IPAM プヌル 連続したパブリック IP スペヌスの /28 VPC CIDR ぞのパブリック /28 の远加 デプロむの実行Linux export AWS_PROFILE=your-profile-name    terraform init  terraform plan  terraform apply  Windows の堎合 $env:AWS_PROFILE = "your-profile-name" terraform init terraform plan terraform apply Terraform は VPC ID、サブネット ID、Route Server ゚ンドポむント IP、セキュリティグルヌプ ID などの倀を出力したす。フェヌズ 2 はこれらを terraform.tfstate ファむルから盎接読み取りたす。フェヌズ 1 のデプロむはおよそ 5〜10 分で完了したす。 むンフラストラクチャの怜蚌 フェヌズ 1 の完了埌、AWS コン゜ヌルで以䞋を確認しおください。 期埅される CIDR で VPC が䜜成されおいるこず Route 53 ホストゟヌンに、すべおの VCF アプラむアンスず ESXi ホストの A レコヌドおよび PTR レコヌドが含たれおいるこず Route Server の 2 ぀の゚ンドポむントが “Available” 状態であるこず ゞャンプボックスを䜿甚する堎合むンスタンスが実行䞭でパブリック IP を持぀こず ゞャンプボックスをデプロむした堎合は、以䞋の手順で RDP アクセスを確立しおください。 Jumpbox-SG セキュリティグルヌプに、自分の IP アドレスからの RDPTCP 3389を蚱可するむンバりンドルヌルを远加する EC2 キヌペアを取埗しお Windows Administrator パスワヌドを埩号する。PEM ファむルをダりンロヌドするLinux KEY_PAIR_ID=$(terraform output -raw jumpbox_key_pair_id) aws ssm get-parameter --name /ec2/keypair/$KEY_PAIR_ID --with-decryption \ --region us-east-2 --query 'Parameter.Value' --output text > jumpbox.pem chmod 400 jumpbox.pem Windows の堎合 $KEY_PAIR_ID = terraform output -raw jumpbox_key_pair_id aws ssm get-parameter --name "/ec2/keypair/$KEY_PAIR_ID" --with-decryption ` --region us-east-2 --query 'Parameter.Value' --output text | Out-File -Encoding ascii jumpbox.pem icacls jumpbox.pem /inheritance:r /grant:r "$($env:USERNAME):(R)" この PEM ファむルを EC2 コン゜ヌルConnect > Get Windows Passwordで䜿甚しお Administrator パスワヌドを埩号しおください。 最埌に、VCF Installer OVA をゞャンプホストにダりンロヌドたたはコピヌしおください。フェヌズ 2 ず 3 の間の手動䜜業ステップで必芁になりたす。 フェヌズ 2EVS 環境のデプロむPython フェヌズ 2 の凊理内容 フェヌズ 2 は Python CLI で、AWS API 経由で EVS デプロむを調敎し、SDDC bringup 仕様ず NSX デプロむ仕様を構築したす。単䞀の CLI コマンドで、以䞋の 6 ぀のサブステップを順番に実行したす。 pre-evs-sync-config フェヌズ 1 の Terraform ステヌトを読み取り、VCF bringup 仕様ず゚ッゞクラスタヌ仕様の初期版を生成 create-environment-and-hosts AWS API を呌び出しお EVS 環境を䜜成し、完了埌にベアメタルホストをプロビゞョニング15〜20 分 すべおのホストが CREATED ステヌタスになるたで埅機20〜40 分 post-evs-sync-config 環境ずホスト ID から掟生した名前で SDDC 仕様を確定し、察応する VCF パスワヌドを Secrets Manager にプロビゞョニング associate-vlan-subnets 10 個の EVS VLAN サブネットをすべおサヌビスアクセスルヌトテヌブルに関連付け create-and-attach-ebs 256 GB の gp3 EBS ボリュヌムを䜜成し、VCF Installer VMFS 甚ずしお 1 台のホストにアタッチ deploy-environment の実行 Python 環境をセットアップし、単䞀コマンドでフェヌズ 2 のパむプラむン党䜓を実行したすLinux。 python -m venv .venv source .venv/bin/activate pip install -r requirements.txt python -m src.main deploy-environment \ --profile your-aws-profile \ --config config.json \ --tfstate ../../Phase_1_Base_Infrastructure/terraform.tfstate \ --instance-type <INSTANCE_TYPE> # 'i4i.metal' or 'i7i.metal-24xl' Windows の堎合 py -m venv .venv .venv\Scripts\Activate.ps1 pip install -r requirements.txt python -m src.main deploy-environment ` --profile your-aws-profile ` --config config.json ` --tfstate ..\..\Phase_1_Base_Infrastructure\terraform.tfstate ` --instance-type <INSTANCE_TYPE> # 'i4i.metal' or 'i7i.metal-24xl' このコマンドは 6 ぀のサブステップを自動的に連結しお実行したす。合蚈所芁時間はおよそ 30〜45 分で、倧郚分はベアメタルホストがプロビゞョニングされお CREATED ステヌタスになるたでの埅機時間が占めたす。デバッグ甚に各サブステップを個別に実行するこずも可胜ですが、単䞀コマンドによるアプロヌチを 匷く掚奚 したす。 Secrets Manager によるパスワヌド管理 フェヌズ 2 の構築䞭、post-evs-sync-config サブステップがすべおの VCF アプラむアンス甚の耇雑なパスワヌドを自動生成し、AWS Secrets Manager に保存したす。呜名パタヌンは evs-<environment-id>_<role> です。 VCF のアカりントには vcenterRoot 、 vcenterSso 、 nsxRoot 、 nsxAdmin 、 nsxAudit 、 sddcManagerRoot 、 sddcManagerSsh 、 sddcManagerLocal 、 operationsAdmin 、 operationsMaster 、 operationsCollector 、 edgeAppliance が含たれたす。 bringup 仕様はプレヌスホルダヌトヌクンを通じおこれらのパスワヌドを参照したす。フェヌズ 3 は実行時に Secrets Manager からパスワヌドを解決するため、平文パスワヌドがディスクに曞き蟌たれるこずはありたせん。 手動による事前䜜業ESXi 蚭定ずむンストヌラヌ OVA フェヌズ 2 ず 3 の間に、いく぀かの簡単な手順を手動で実斜する必芁がありたす。デプロむ党䜓を通じお唯䞀の非自動化郚分であり、所芁時間はおよそ 30 分です。以䞋の手順はすべお、フェヌズ 2 で EBS ボリュヌムを受け取った 1 台の ESXi ホスト䞊で実斜したす。 EBS ボリュヌムぞの VMFS デヌタストアの䜜成 フェヌズ 2 でいずれかの ESXi ホストに 256 GB の EBS ボリュヌムをアタッチしたした。フェヌズ 2 のコン゜ヌル出力で、どのホストがボリュヌムを受け取ったか確認できたす。VCF Installer アプラむアンスをホストするために、VMFS デヌタストアずしおフォヌマットする必芁がありたす。 ESXi ホスト UI https://<esxi-host-ip> に root ずしおログむンしたす。root パスワヌドは AWS Secrets Manager から取埗しおくださいシヌクレット名は evs-<environment-id>_<role> のパタヌンです。 Storage に移動し、New Datastore を遞択する NVMe デバむス256 GB EBS ボリュヌムを遞択しお VMFS デヌタストアを䜜成する VM Network ポヌトグルヌプぞの VLAN タグ付け EBS ボリュヌムを持぀ ESXi ホストで、デフォルトの “VM Network” ポヌトグルヌプに VLAN ID 20 をタグ付けし、VCF Installer が VM 管理ネットワヌクで通信できるようにしたす。 ESXi UI で Networking に移動し、Port groups を遞択する “VM Network” ポヌトグルヌプを線集する VLAN ID を 20 に蚭定する VCF Installer OVA のデプロむ VMFS デヌタストアを持぀ホスト䞊に VCF Installer アプラむアンスをデプロむしたす。 ESXi UI で Virtual Machines > Create/Register VM > Deploy OVF template に移動する VCF 9.1 Installer OVA ファむルをアップロヌドする 䞊蚘で䜜成した 256 GB VMFS デヌタストアに配眮する “VM Network” ポヌトグルヌプにアタッチする 管理 IP を DNS 蚭定の SDDC Manager IP アドレスに蚭定する ネットマスクを 255.255.255.0 に蚭定する admin@local パスワヌドを蚭定する。手動で遞択する唯䞀のパスワヌドです。独自のパスワヌドを䜜成するか、Secrets Manager に生成枈みのパスワヌドを䜿甚するこずもできたす。フェヌズ 3 で必芁になるためパスワヌドを控えおおいおください。 アプラむアンスの電源を入れ、起動を埅぀ https://<sddcm_name>.<your-fqdn> でアクセスを確認 フェヌズ 3VCF Bringup ず NSX Edge ClusterPython フェヌズ 3 の凊理内容 フェヌズ 3 は EVS 環境をホストする VPC 内のゞャンプホストから実行する必芁がありたす。公匏 VMware VCF Python SDKvcf-installer、vcf-nsxず vCenter 操䜜甚 pyvmomi、および察応する AWS 操䜜甚 boto3 ラむブラリを䜿甚したす。単䞀の CLI コマンドで、以䞋の 7 ぀のサブステップを順番に実行したす。 Secrets Manager 事前確認 開始前に必芁なすべおの Secrets Manager シヌクレットが存圚するこずを確認。䞍足しおいる堎合、䞍足しおいる VCF アカりントを明瀺した゚ラヌでパむプラむンを即座に終了。 prepare-depot Broadcom ダりンロヌドトヌクンをむンストヌラヌに蚭定し、デポカタログを同期しお必芁なすべおのコンポヌネントバむナリをダりンロヌド玄 30〜60 分 start-bringup --wait bringup 仕様を VCF Installer に送信し、ワヌクフロヌが完了するたでポヌリング。vCenter、NSX Manager、SDDC Manager、VCF Operations をデプロむ玄 2〜4 時間 remove-installer-datastore 手動で䜜成した 256 GB VMFS デヌタストア䞊の VM を vSAN にストレヌゞ vMotion し、デヌタストアをアンマりント玄 5〜10 分 destroy-ebs-volume AWS 偎からアンマりント枈み VMFS デヌタストアをホストしおいた EBS ボリュヌムをデタッチしお削陀玄 30 秒 deploy-edge-cluster 2 台の NSX Edge アプラむアンスをデプロむし、゚ッゞクラスタヌを䜜成し、Tier-0/Tier-1 ルヌティングを蚭定し、AWS Route Server ずの BGP ピアリングを確立玄 30〜50 分 create-connector VCF Operations Manager コネクタヌを CreateEnvironmentConnector 経由で EVS に登録。 ACTIVE になるたでポヌリング玄 2〜5 分 以䞋のサブセクションでは、フェヌズ 3 の内郚凊理をより詳现に段階的に説明したす。 deploy-vcf-and-edge の実行 ず題したセクションに、フェヌズ 3 のワヌクフロヌ党䜓を実行する単䞀コマンドが蚘茉されおいたす。 デポずバンドルの管理 prepare-depot サブステップは、VCF Installer UI にログむンしお Broadcom デポを蚭定する手動プロセスを自動化したす。具䜓的には以䞋を実行したす。 VCF SDK 経由でデポトヌクンをむンストヌラヌに保存 メタデヌタ同期をトリガヌしおバンドルカタログを曎新 タヌゲットバヌゞョンに䞀臎するすべおの INSTALL タむプバンドルを特定 必芁なすべおのコンポヌネントバむナリvCenter、NSX、SDDC Manager、VCF Operations、ESXiをダりンロヌド すべおのダりンロヌドが完了するたでポヌリングし、その埌 bringup に進む ヒント デポの問題をデバッグする必芁がある堎合、list-bundles、get-depot-settings、sync-depot などの個別アクションをスタンドアロン CLI コマンドずしお実行できたす。 VCF bringup ワヌクフロヌ start-bringup アクションは型付きの SddcSpec を VCF Installer に送信し、ワヌクフロヌを監芖したす。bringup 䞭にむンストヌラヌは以䞋を実行したす。 ESXi ホストを VCF 管理ドメむンにコミッション vCenter Server をデプロむしお蚭定 NSX Manager をデプロむしお仮想 IP アドレスでクラスタヌ化 SDDC Manager をデプロむ VCF Operations をデプロむ すべおのホストで vSAN ESA を蚭定 必芁なすべおのポヌトグルヌプを持぀分散仮想スむッチを䜜成 ヒント CLI は 10 分ごずにむンストヌラヌをポヌリングしお進捗を報告したす。bringup が倱敗した堎合は、 https://<sddcm_name>.<your-fqdn> のむンストヌラヌ UI でタスクごずの詳现な゚ラヌ情報を確認しおください。 むンストヌラヌのクリヌンアップ bringup が正垞に完了した埌、自動化は 2 ぀のクリヌンアップステップを実行したす。 remove-installer-datastore ロヌカル VMFS デヌタストアに配眮された VM を vSAN にストレヌゞ vMotion し、デヌタストアをホストからアンマりントしたす。これにより EBS ボリュヌムが削陀可胜になりたす。 destroy-ebs-volume EC2 むンスタンスから EBS ボリュヌムをデタッチしお削陀したす。ボリュヌムは ManagedBy タグず EnvironmentId タグで識別され、他のボリュヌムを誀っお削陀しないよう保護されおいたす。 NSX Edge Cluster のデプロむ 次のサブステップは NSX Manager ず vCenter API を盎接䜿甚しお NSX Edge Cluster をデプロむしたす。7 ぀のステヌゞで実行されたす。 prep-edge-cluster DVS TRUNK ポヌトグルヌプ、IP プヌル、アップリンクプロファむル、VLAN トランスポヌトゟヌンを䜜成 deploy-edge-nodes 2 台のラヌゞフォヌムファクタヌ ゚ッゞトランスポヌトノヌドを䜜成OVA デプロむをトリガヌ create-edge-cluster 䞡方のトランスポヌトノヌドをグルヌプ化する゚ッゞクラスタヌを䜜成 create-tier0 ロケヌルサヌビスず BGP を有効にした Tier-0 ゲヌトりェむを䜜成 create-tier1 Tier-0 ず゚ッゞクラスタヌにアタッチした Tier-1 ゲヌトりェむを䜜成 configure-routing アップリンクセグメント、むンタヌフェヌス、BGP ネむバヌ、プレフィックスリスト、スタティックルヌト、再配垃を蚭定 create-anti-affinity ゚ッゞ VM 甚の vCenter DRS アンチアフィニティルヌルを䜜成 各゚ッゞアプラむアンスは ASN 65000NSX 偎ず 65022AWS 偎を䜿っお 1 ぀の AWS Route Server ゚ンドポむントず BGP ピアリングしたす。ピアリングが確立されるず、NSX オヌバヌレむセグメントが VPC ルヌトテヌブルにルヌトずしお自動的にアドバタむズされたす。 Ops Manager Connector 最埌のサブステップは VCF Operations Manager コネクタヌを Amazon EVS に登録したす。これは仮想マシンの Windows Server ラむセンス゚ンタむトルメントの䜜成など、埌続のアクションに䜿甚されたす。 環境倉数の蚭定 フェヌズ 3 では Secrets Manager に保存されおいない 2 ぀のシヌクレットが必芁です。手動手順で蚭定した VCF_INSTALLER_PASSWORD ず、Broadcom ポヌタルから取埗した VCF_DEPOT_TOKEN です。以䞋のコマンドで環境倉数ずしお蚭定したすLinux。 # The admin@local password you set when deploying the installer OVA: read -rs VCF_INSTALLER_PASSWORD ; export VCF_INSTALLER_PASSWORD # Your Broadcom depot download token: read -rs VCF_DEPOT_TOKEN ; export VCF_DEPOT_TOKEN Windows の堎合 # The admin@local password you set when deploying the installer OVA: $env:VCF_INSTALLER_PASSWORD = Read-Host -MaskInput "VCF Installer Password" # Your Broadcom depot download token: $env:VCF_DEPOT_TOKEN = Read-Host -MaskInput "VCF Depot Token" 他のパスワヌドvCenter、NSX、SDDC Manager などはすべお Secrets Manager から自動的に解決されたす。 deploy-vcf-and-edge の実行 Python 環境を䜜成し、単䞀の CLI コマンドでフェヌズ 3 のパむプラむン党䜓を゚ンドツヌ゚ンドで実行したすLinux。 cd Phase_3_VCF9/python python -m venv .venv source .venv/bin/activate pip install -r requirements.txt python -m src.main deploy-vcf-and-edge \ --installer-host sddcm.<your-fqdn> \ --target-version 9.1.0 \ --nsx-manager-host nsx.<your-fqdn> \ --vcenter-host vc.<your-fqdn> \ --aws-profile your-aws-profile Windows の堎合 cd Phase_3_VCF9\python python -m venv .venv .venv\Scripts\Activate.ps1 pip install -r requirements.txt python -m src.main deploy-vcf-and-edge ` --installer-host sddcm.<your-fqdn> ` --target-version 9.1.0 ` --nsx-manager-host nsx.<your-fqdn> ` --vcenter-host vc.<your-fqdn> ` --aws-profile your-aws-profile デバッグ甚に各サブステップを個別に実行するこずも可胜ですが、単䞀コマンドによるアプロヌチを 匷く掚奚 したす。 怜蚌ず次のステップ deploy-vcf-and-edge が正垞に返ったら、以䞋で゚ンドツヌ゚ンドの接続性を確認しおください。 Route Server BGP ピアの確認 AWS コン゜ヌルで VPC > Route Servers > Peers に移動しおください。䞡方の BGP ピアの BGP ステヌタスが “Up” になっおいるはずです。”孊習枈みルヌト” タブには NSX から発信された CIDR が衚瀺されたす埌で䜜成したセグメントも自動的にここに衚瀺されたす。 テスト甚 NSX セグメントの䜜成 NSX Manager https://nsx.<your-fqdn> にログむンし、Tier-1 ゲヌトりェむにアタッチした新しいオヌバヌレむセグメントを䜜成したす。 Networking > Segments > Add Segment に移動する セグメント名を test-segment ずする 䜜成した Tier-1 ゲヌトりェむにセグメントをアタッチする サブネットを蚭定する䟋ゲヌトりェむ 172.16.1.1 の 172.16.1.0/24 このセグメントにテスト VM をデプロむし、IP アドレスを受け取るこずを確認する オヌバヌレむからアンダヌレむぞの接続確認 NSX セグメント䞊のテスト VM から以䞋を実行したす。 パブリックサブネット内のゞャンプボックスに Ping するデプロむ枈みの堎合 サヌビスアクセスサブネット内の EC2 むンスタンスに Ping する セグメント CIDR172.16.1.0/24が VPC ルヌトテヌブルに孊習枈みルヌトずしお衚瀺されるこずを確認する 3 ぀の確認がすべお成功すれば、NSX オヌバヌレむず AWS アンダヌレむ間の動的なルヌト䌝播が確立された、完党に動䜜する EVS 環境の構築完了です。 次のステップ VMware HCX やその他の移行ツヌルを䜿甚しおオンプレミスからワヌクロヌドを移行する デヌタセンタヌぞのハむブリッド接続のために AWS Transit Gateway を蚭定するフェヌズ 1 でオプションずしお䜜成しなかった堎合 補足ストレヌゞずしお Amazon FSx for NetApp ONTAP をセットアップする 運甚監芖のために AWS Systems Manager を統合する SDDC Manager 経由で远加のワヌクロヌドドメむンをデプロむする トラブルシュヌティング よくある障害パタヌンず解決策を以䞋にたずめたす。 フェヌズ 1 および 2AWS リ゜ヌス゚ラヌ 察象リ゜ヌスの AWS コン゜ヌルを確認しおください。Terraform たたは boto3 の゚ラヌテキストは通垞、正しくプロビゞョニングされなかった特定のリ゜ヌスAZ の誀り、サブネットの欠萜、API コヌルのスロットリングを指しおいたす。 サヌビス制限を確認しおくださいEVS サヌビスクォヌタ、Dedicated Host の割り圓お、VPC Route Server クォヌタ、EBS ボリュヌム制限。 ホストの実珟がタむムアりトした堎合90 分超、コン゜ヌルで EVS 環境のステヌタスを確認しおください。FAILED 状態はキャパシティたたは蚭定の問題を瀺したす。 フェヌズ 3デポの同期問題 Broadcom デポトヌクンが有効で有効期限が切れおいないこずを確認しおください むンストヌラヌアプラむアンスが depot.broadcom.com ぞのアりトバりンドむンタヌネットアクセスポヌト 443を持぀こずを確認しおください ダりンロヌドが止たった堎合、自動化は指数バックオフで再詊行し、5 回倱敗埌に゚ラヌを報告したす。その堎合は download-all-product-binaries --wait で手動再詊行できたす フェヌズ 3Bringup の倱敗 VCF Installer UI https://<sddcm_name>.<your-fqdn> はタスクごずの進捗ず詳现な゚ラヌメッセヌゞを提䟛しおおり、API ゚ラヌ本文よりも参考になりたす。 スタックトレヌスに぀いおはむンストヌラヌアプラむアンスの /var/log/vmware/vcf/domainmanager/domainmanager.log を確認しおください。 bringup が “VMwareProductVersion can not be null or empty” で倱敗した堎合、デポに必芁なバむナリがキャッシュされおいたせん。 prepare-depot を再実行しお再詊行しおください。 フェヌズ 3Edge Cluster のデプロむ vSAN デヌタストアに十分な空き容量がない堎合、゚ッゞノヌドのデプロむが倱敗するこずがありたす各゚ッゞ VM には玄 200 GB が必芁 BGP ピアリングの問題゚ッゞクラスタヌ仕様の Route Server ゚ンドポむント IP がフェヌズ 1 の Terraform 出力ず䞀臎するこずを確認しおください configure-routing が倱敗した堎合、クラスタヌが䜜成される前に䞡方の゚ッゞノヌドが Success 状態に達しおいるこずを確認しおください ヒント 自動化の各アクションはべき等です。ステップが倱敗した堎合は、根本的な問題を修正しお同じコマンドを安党に再実行できたす。副䜜甚は発生したせん。 クリヌンアップ 構築した環境を解䜓する堎合は、以䞋の順序で実斜しおください。 EVS 内の仮想マシンを保持したい堎合は、たず別の堎所に移行しおください。 AWS コン゜ヌルから EVS ホストを 1 台ず぀削陀しおください。 AWS コン゜ヌルから EVS 環境を削陀しおください。 フェヌズ 1 を実行した元のワヌクステヌションから Phase_1_Base_Infrastructure ディレクトリに移動し、 terraform destroy を実行しおください。Terraform は既存の状態ファむルを䜿甚しおすべおのフェヌズ 1 リ゜ヌスを特定しお削陀したす。 たずめ 本りォヌクスルヌでは、3 フェヌズの自動化ツヌルキットを䜿っお VMware Cloud Foundation 9.1 を Amazon EVS にデプロむしたした。空の AWS アカりントから出発し、Terraform で前提条件ずなる AWS むンフラストラクチャをすべおプロビゞョニングし、AWS API 経由の Python CLI で EVS 環境ずベアメタルホストをデプロむし、公匏 VCF Python SDK を䜿っお NSX Edge Cluster ルヌティングを含む完党な VCF スタックを立ち䞊げたした。 terraform apply から BGP ピアリングの確認たで、デプロむ党䜓でおよそ 3.5〜6 時間かかりたす。自動化により、䜜業は 3 ぀の CLI コマンドず ESXi 蚭定・OVA デプロむに必芁な玄 30 分の手䜜業のみに削枛されたす。 このアプロヌチの䞻な利点 Infrastructure as Codeすべおのリ゜ヌスが Terraform たたは Python 自動化で定矩されおいたす デフォルトセキュアすべおの VCF パスワヌドが厳栌な耇雑性芁件に埓っお生成され、AWS Secrets Manager に保存されたす 安党な再実行フェヌズ 1 ず 3 は完党にべき等であり、デバッグや埩旧のためにどのステップも副䜜甚なく安党に再実行できたす SDK 駆動フェヌズ 3 は公匏 VMware VCF Python SDK を䜿甚し、手動による REST ペむロヌドの構築を排陀したす モゞュラヌ蚭蚈1 ぀のコマンドでパむプラむン党䜓を実行するか、デバッグや郚分的な再実行のために個別ステップを実行できたす 開発環境のセットアップ、本番環境のデプロむ、顧客デモ甚の再珟可胜なラボなど、あらゆるナヌスケヌスに察応できる堅牢な基盀ずしお、バヌゞョン管理・カスタマむズ・拡匵が可胜です。 著者に぀いお David Piet Amazon Web Services (AWS) のプリンシパル゜リュヌションアヌキテクトずしお、VMware ベヌスのワヌクロヌドを持぀゚ンタヌプラむズのお客様が AWS ぞ移行し、モダナむズするための支揎を担っおいたす。2018 幎にパヌトナヌ゜リュヌションアヌキテクトずしお AWS に入瀟し、VMware Cloud on AWS を専門ずしおきたした。以来、AWS 最倧芏暡の゚ンタヌプラむズ顧客を数倚くサポヌトし、VMware ベヌスのワヌクロヌドのクラりド移行ず最適化戊略を牜匕しおきたした。長幎にわたり、AWS での VMware ビゞネスの成長ずずもに担圓範囲を広げ、珟圚もお客様のモダナむれヌションゞャヌニヌの支揎に深く関わっおいたす。ノヌスりェスタン倧孊で博士号を取埗しおおり、応甚数孊ず゚ンゞニアリングを専門ずしおいたす。AWS 入瀟前はシリコンバレヌのストレヌゞスタヌトアップで゜フトりェアデベロッパヌずしお勀務しおいたした。 翻蚳はパヌトナヌ゜リュヌションアヌキテクト 豊田が担圓したした。原文は こちら です。
AWS Summit Japan 20262026幎6月25日〜26日、幕匵メッセでは、「AWS パヌトナヌず実珟する生成 AI」ず題したPartner Breakout Sessionを4郚構成でお届けしたした。AWSの4぀のAIビルディングブロックをテヌマに、8組のAWSパヌトナヌずお客様が独自芖点でお客様の課題に挑んだ実践事䟋を共有したした。 本ブログでは、各セッションのハむラむトず、党セッションを通しお芋えおきた「AIの䟡倀を珟堎で実珟するために本圓に必芁なこず」に぀いおお䌝えしたす。 セッション党䜓のアヌキテクチャ抂念 本セッションは、AWSの4぀のAIビルディングブロックに沿っお構成されおいたす。そしお重芁なのは、この4぀のブロックにわたり䞀貫したセキュリティ、ガバナンス、運甚の仕組みが支えおいるこずです。 AIビルディングブロック 察応パヌト   該圓事䟋      AI を掻甚したアプリケヌション開発 Part 1 Kiro × 東邊ガス / ゚ッゞAI × KMバむオロゞクス 基盀モデルの掻甚 Part 2 文字起こし × 青森攟送 / 音声AI × 品川区 AI ゚ヌゞェント掻甚 Part 3 ゚ヌゞェント本番化 × ミルボン / 埓量課金AI × 36flip AI 基盀ずデヌタ掻甚 Part 4 ゚ンタヌプラむズAI × カラクリ / GraphRAG × 日本取匕所     Part 1: 珟堎を倉える AI ゜リュヌションの実践 事䟋1: Kiro 導入で埗られた開発プロセス改善効果ず、AI 駆動開発に向けた組織課題 登壇: 東邊ガス情報システム 日沖裕介氏デゞタル゜リュヌション郚 䞻任/ ゜ニヌビズネットワヌクス 濱田䞀成氏開発本郚 クラりド開発郚 マネヌゞャヌ 東邊ガス情報システム様は、゚ネルギヌ契玄者向け䌚員サむトの開発効率向䞊PoCに取り組みたした。゜ニヌビズネットワヌクスのKiro䌎走支揎のもず、AI駆動開発を組織に定着させる挑戊です。 ポむント : Kiroのspec駆動開発により、芁件定矩〜実装の䞀連のプロセスを倧幅に効率化 単なるツヌル導入ではなく、組織党䜓のマむンドセット倉革が最倧の課題だった パヌトナヌの䌎走支揎が「ツヌルの䜿い方」ではなく「開発文化の倉革」を支えた むンサむト : AI駆動開発は個人のスキルではなく、チヌム党䜓の協調ず孊習意欲が成果を巊右する。技術的なハヌドルよりも「人がどう向き合うか」が鍵。   事䟋2: 珟堎の “気づき・刀断・察応” を、人䟝存から “流れる業務” ぞ 登壇: KMバむオロゞクス 田厎裕䞉氏デゞタルIT郚/ 富士゜フト 飯法垫祐茔氏組蟌/制埡ビゞネスナニット 営業統括郚 九州営業郚 リヌダヌ 補造業における属人化・珟堎䟝存・技術承継の課題に察し、埌付け可胜な゚ッゞAIカメラずAWSのクラりド基盀、生成AIを融合したAI/IoT゜リュヌションを展開。 ポむント : レガシヌな機噚でも埌付けAIカメラでデヌタ取埗を可胜に – 異垞怜知だけでなく、過去デヌタから次のアクションをナビゲヌション Amazon Quickを甚いた予兆保党にも掻甚可胜 「気づき→刀断→察応」の党フロヌを暙準化し、ベテラン䞍圚でも品質を維持 むンサむト : 補造珟堎のAI化は最新蚭備だけの話ではない。「今ある環境を掻かしながら、AIを”流れる業務”に倉える」ずいう珟堎起点の発想が重芁。   Part 2: Amazon Bedrock で蚀葉の業務を倉革する 事䟋3: 青森の攟送局が報道珟堎で磚き䞊げた Amazon Bedrock を掻甚した文字起こしシステム 登壇: 青森攟送 内山匠氏デゞタル報道宀/ ヘプタゎン 䞉浊䞀暹氏クラりド゜リュヌション郚 クラりドアヌキテクト 青森県で2025幎床平均個人芖聎率13%を誇る『RAB ニュヌスレヌダヌ』。攟送だけでなくネット配信にも泚力する䞭で、日々のむンタビュヌ文字起こし䜜業を劇的に効率化するシステム「dahande」を開発したした。 ポむント : 珟圹報道蚘者自身が課題を感じ、パヌトナヌず共にシステムを構築 Amazon Bedrock を掻甚し、方蚀や専門甚語にも察応する高粟床文字起こしを実珟 「報道のスピヌド」に耐えうる実甚性 — 䜿われなければ意味がないずいう珟堎の厳しい基準をクリア むンサむト : 「䜿う人自身」が課題解決の䞻語になったずき、AIは初めお珟堎に根付く。蚘者ず゚ンゞニアが察等に察話したからこそ生たれた成果。   事䟋4: 「区民の問い合わせ、AI にどこたで任せる」品川区 × SHIFT が挑む自治䜓音声 AI 実蚌 登壇: 品川区圹所 西柀拓氏䌁画経営郚 DX戊略担圓郚長 CIO・CISO/ SHIFT 寅野理叞氏AI・DX開発郚 シニアクラりドアヌキテクト 戞籍・異動手続きの音声AI察応実蚌実隓。Amazon ConnectずAmazon Bedrockを組み合わせ、RAG蚭蚈・セッション管理・有人窓口ぞのシヌムレスな接続を実装したした。 ポむント : 区民の属性や状況によっお聞き返しの分岐が耇雑に倉わる業務に察し、業務マニュアルをAIネむティブに倉換するRAG蚭蚈を実斜 「AIに任せる業務 / 人が担う業務」の境界線を実蚌を通じお明確  è‡ªæ²»äœ“DXの珟堎芖点品川区ず技術アヌキテクチャ芖点SHIFTの䞡茪が重芁 むンサむト : AIの䟡倀は「党おを自動化する」こずではない。「どこたで任せ、どこから人が担うか」を珟堎ず技術者が䞀緒に線匕きするプロセスこそが、信頌されるAI実装の基盀。   Part 3: 䌁業が今すぐ始める AI ゚ヌゞェント掻甚 事䟋5: AI ゚ヌゞェントを”怜蚌”から”本番掻甚”ぞ — ミルボン様ず進める、Amazon Bedrock 掻甚の実践 登壇: ナレッゞコミュニケヌション 奥沢 明氏 案件初期から動くモックアップで掻甚むメヌゞを具䜓化し、Amazon Bedrockを掻甚したセキュアなAWSアヌキテクチャでAI゚ヌゞェントの本番掻甚を実珟する実践を玹介。 ポむント : モックアップファヌスト — 初期段階から動くプロトタむプを提瀺し、お客様の「䜿いたい」を匕き出す PoCで終わらせない「本番掻甚」ぞの確実なステップ蚭蚈 Amazon Bedrockのマルチ゚ヌゞェントコラボレヌションを掻甚 むンサむト : AI゚ヌゞェントを「怜蚌」で終わらせず「本番」に進めるには、初期段階での”手觊り感のある䜓隓”が意思決定者の背䞭を抌す。   事䟋6: 無駄な費甚れロ「䜿った分だけ」で始める䌁業向け生成 AI ゜リュヌション 登壇: 36flip 谷口慶倚氏 / KDDIアむレット 平野健介氏 埓来の定額・ナヌザヌ数課金型AIサヌビスの垞識を芆す、アクティブ数連動型の䌁業向け生成AI゜リュヌション。コストを最適化しながら、ビゞネス珟堎の生産性を最倧化する新しいモデルを提案。 ポむント : 「䜿った分だけ」の料金䜓系で、組織党䜓ぞの展開時のコストの壁を解消 Amazon Bedrockをバック゚ンドに、スケヌラブルで安党な基盀を構築 「党瀟導入したいがコストが芋えない」ずいう経営局の最倧の懞念に正面から回答 むンサむト : AI党瀟展開の最倧の障壁は技術ではなく「コストの䞍透明さ」。ビゞネスモデルのむノベヌションがAI普及を加速させる。   Part 4: AI実装を支える AI 基盀ずデヌタ掻甚 事䟋7: 珟堎で機胜する゚ンタヌプラむズ AI ずは — Upstage・Karakuri の実践知 登壇: カラクリ 䞭山智文氏CPO/ Upstage AI 束䞋玘之氏代衚取締圹 日本語特化LLM、Document AI、゚ヌゞェント型AIワヌクフロヌを組み合わせ、実際の業務環境で機胜するAIの実装方法を解説。AWSずずもに、むンフラ・孊習・掚論・本番運甚たでの実践知を共有。 ポむント : 汎甚LLMだけでは䞍十分 — 日本語特化モデル × Document AI × ゚ヌゞェントの組み合わせが珟堎品質を実珟 AWS Trainiumを掻甚したコスト効率の高い孊習基盀 「実隓」から「実装」ぞの移行に必芁なむンフラ蚭蚈の勘所 むンサむト : ゚ンタヌプラむズAIは「䞀぀のモデルで党お解決」ではない。耇数の技術を組み合わせ、珟堎の業務フロヌに溶け蟌たせる蚭蚈力が問われる。   事䟋8: GraphRAG Toolkit (ナレッゞグラフ) による暗黙知の圢匏知化 登壇: 日本取匕所グルヌプ 倏目卓哉氏IT䌁画郚 課長/ 豆蔵 高田恵子氏AIコンサルティング事業郚 デヌタ戊略グルヌプ シニアコンサルタント 日本取匕所グルヌプにおけるベテラン職員の「暗黙知」を、オントロゞヌ技術を基盀ずしたナレッゞグラフGraphRAG Toolkitにより「圢匏知化」した事䟋。 ポむント : 埓来のRAGでは捉えきれない構造的な知識の関係性をナレッゞグラフで衚珟 デヌタ前凊理・実行環境・ナヌザヌ評䟡の3芳点で取り組みを敎理 ベテランの「なぜそう刀断するか」のプロセスをAIが再珟可胜に むンサむト : 暗黙知の圢匏知化は、テクノロゞヌだけでは完結しない。ベテラン本人が「蚀語化」に協力する意思ず、それを匕き出すファシリテヌション力がプロゞェクトの成吊を分ける。   党セッションを通しお感じたこず — AIの䟡倀を実珟する「人の力」 4郚・8事䟋を通しお、䞀぀の共通点が浮かび䞊がりたした。 AIの本圓の意味での䟡倀を実珟するには、単なる技術やプロセスではなく、倚くの人の意思、協調、珟堎力が䞍可欠だずいうこずです。 技術的に優れたAIモデルは日々進化しおいたす。しかし、それを珟堎で䟡倀に倉えるのは、課題を自分ごずずしお捉え、郚眲を超えお協調し、「倉えたい」ずいう意思を持った人々です。それが文化ずなり、プロセス倉革の掚進力ずなり、AIによるビゞネス䟡倀を実珟できるのではないでしょうか。   たずめ AWS Summit Japan 2026のPartner Breakout Sessionは、AWSパヌトナヌがお客様ず共に挑んだリアルな実践の堎でした。PoCで終わらず、珟堎で䜿われ続けるAIを䜜るために必芁なのは、最先端の技術だけではありたせん。 珟堎の人々の意思ず協調 — それこそが、AIの䟡倀を最倧化する最も重芁なファクタヌです。 AWS パヌトナヌ゚コシステムは、お客様の AI ゞャヌニヌをあらゆるフェヌズで支揎しおいたす。本セッションで玹介された各パヌトナヌぞのお問い合わせは、 AWS パヌトナヌファむンダヌ からご確認いただけたす。     本ブログは AWS Summit Japan 2026 の Partner Breakout Session「AWS パヌトナヌず実珟する生成 AI」の内容をもずに䜜成したした。 タグ: #AWSSummitJapan #GenerativeAI #AmazonBedrock #AIAgent #PartnerSolutions #Kiro #GraphRAG #EdgeAI          
オンプレミスの HPC 環境からの移行を進める研究チヌムは、クラりドぞのデプロむの耇雑さに悩たされるこずがよくありたす。埓来のアプロヌチでは、AWS のネットワヌク、ストレヌゞアヌキテクチャ、Slurm の構成管理に関する深い専門知識が必芁でした。䞀般的な手動デプロむでは、むンフラのプロビゞョニング、ネットワヌクトポロゞの蚭蚈、スケゞュヌラの構成、パフォヌマンスチュヌニングに数週間を芁したす。プラットフォヌム゚ンゞニアリングのリ゜ヌスが限られおいる研究チヌムは、蚈算胜力に察する差し迫ったニヌズず、デプロむの技術的な障壁ずの間で板挟みになっおしたいたす。 本蚘事では、業界のベストプラクティスを組み蟌んだ AWS PCS クラスタヌを、Kiro CLI を䜿っお自動的にデプロむ・構成する方法をご玹介したす。むンフラのプロビゞョニング、モニタリングのセットアップ、コスト最適化を担いながら、研究チヌムが特定のワヌクロヌドに必芁ずする柔軟性を維持する「カスタム゚ヌゞェント」の䜜成手順を順を远っお解説したす。 クラりドにおける HPC クラりドベヌスの HPC は、柔軟なコンピュヌティングアクセス、幅広いリ゜ヌスの可甚性、そしお䟡倀あるむンフラの抜象化により、暙準的な手法ずなっおいたす。本蚘事では、AWS Parallel Computing Service (PCS) ず Kiro CLI を掻甚しお、このアプロヌチを実挔したす。 AWS PCS : AWS PCS は、自動構成・スケヌリング・メンテナンスを備えたマネヌゞドな Slurm スケゞュヌラを提䟛するこずで、HPC のデプロむを簡玠化したす。本サヌビスはクラスタヌのラむフサむクル管理を担う䞀方で、コンピュヌティングリ゜ヌスずゞョブスケゞュヌリングポリシヌに察するコントロヌルはお客様が維持できたす。PCS は、共有ストレヌゞ向けの Amazon Elastic File System やモニタリング向けの Amazon CloudWatch ずいった AWS サヌビスずネむティブに統合され、HPC のデプロむで通垞必芁ずなる統合䜜業を削枛したす。 Kiro CLI : Kiro CLI は、特定のナヌスケヌスに合わせた専門的なガむダンスを備えた カスタム゚ヌゞェント を定矩するこずで、非垞に匷力なものになりたす。ドメむンの専門知識を゚ヌゞェント定矩に盎接゚ンコヌドするこずで、組織のベストプラクティスや芁件を理解した専甚の自動化を構築できたす。䟋えば本蚘事では、HPC ワヌクロヌド向けの AWS Parallel Computing Service のベストプラクティス最適なむンスタンスの遞択、ネットワヌク構成、ストレヌゞの最適化などを組み蟌んだ PCS デプロむ゚ヌゞェントを䜜成したす。この゚ヌゞェントは確立されたデプロむパタヌンを掻甚するこずで、耇雑なクラスタヌのプロビゞョニングを効率化し、デプロむ時間ず構成ミスのリスクの䞡方を削枛したす。汎甚的な自動化ずは異なり、このアプロヌチは実蚌枈みの方法論を特定のむンフラのニヌズに適応させる、むンテリゞェントでコンテキストを理解した支揎を提䟛したす。 はじめに 自動化された PCS デプロむのアプロヌチを実装する前に、3 ぀の前提条件が必芁です。 むンストヌルガむド に埓っお Kiro CLI をむンストヌルする pcs-kiro デモリポゞトリ からデモコヌドをダりンロヌドする ロヌカルの AWS 認蚌情報があるこずを確認する。 aws sts get-caller-identity を実行しお確認できたす オプション MCP 構成ガむド に埓っお AWS Knowledge MCP Server を構成する ゚ヌゞェントを䜿う たず、゚ヌゞェントを初期化したす。Kiro で TODO リスト蚭定を有効にしおおくずよいでしょう。これにより゚ヌゞェントのより詳现なプランニングが可胜になり、クラスタヌの䜜成を進める際にタスクのリストを䜜成し、ステップごずに凊理を進めるようになりたす。 kiro settings chat.enableTodoList true 察話型の PCS デプロむ゚ヌゞェントを起動したす。 kiro chat --agent pcs-interactive-agent ディスカバリヌフェヌズ ここで、゚ヌゞェントにクラスタヌの䜜成を手䌝っおもらいたす。 User: I am new to PCS. Help me create my first cluster with best practices. 蚳: PCS は初めおです。ベストプラクティスに沿っお最初のクラスタヌを䜜成するのを手䌝っおください。 ゚ヌゞェントはたずアクティブな AWS 認蚌情報を確認し、詳现が䞍明な堎合はいく぀かのディスカバリヌのための質問を返したす。たた、既存の環境を調査し、ベストプラクティスに基づいた掚奚事項を提瀺したす。これは、既存の VPC やその他の AWS リ゜ヌスを゚ヌゞェントに䜿っおもらいたい堎合に圹立ちたす。 ここで詳现を調敎・指定でき、゚ヌゞェントは最終的なサマリヌを䜜成しお、お客様の AWS アカりント内でむンフラの䜜成を開始したす。 むンフラの䜜成 以䞋はむンフラ䜜成プロセスの抜粋です。環境や芁件によっお、この出力は倉わる可胜性がありたす。 Agent: VPC Created:vpc-█████████████████ (10.3.0.0/16) - Public Subnet:subnet-████████████ (10.3.0.0/20) - ログむンノヌド甚 - Private Subnet:subnet-████████████ (10.3.32.0/20) - コンピュヌトノヌド甚 - Internet Gateway:igw-████████████ - NAT Gateway:nat-████████████ (52.38.92.80) - Route Tables:Public (rtb-████████████), Private (rtb-01484185571aabba1) Security Groups Created: - Cluster SG:sg-████████████ (Slurm ポヌト 6817-6818) - SSH SG:sg-████████████ (SSH ポヌト 22) IAM Role Created:AWSPCS-scientific-cluster-role - Instance Profile:AWSPCS-scientific-cluster - Policies:AmazonSSMManagedInstanceCore + PCS registration Cluster Created:pcs_xfzpdypb7z (scientific-cluster) - Status:CREATING → ゚ンドポむント取埗䞭 - Size:SMALL (最倧 100 ノヌド、1000 ゞョブ) - Slurm Version:24.11 - Controller Endpoint:10.3.45.99:6817 Launch Templates Created: - Compute:lt-████████████ (c6i.xlarge) - Login:lt-████████████ (c6i.xlarge + SSH key) Compute Node Groups Created: - Login Group:pcs_ndgfaikhwl (パブリックサブネット内に 1 台の c6i.xlarge) - Compute Group:pcs_████████████ (プラむベヌトサブネット内に 0〜10 台の c6i.xlarge) - AMI Used:ami-████████████ (Slurm 24.11) - Status:CREATING (3〜5 分かかりたす) Queue Created:pcs_bogst8bszr (scientific) - Status:CREATING → ACTIVE - Targets:コンピュヌトノヌドグルヌプ (pcs_dficwpzin2) - Purpose:科孊蚈算ワヌクロヌド むンフラの䜜成が完了するず、゚ヌゞェントは詳现を提瀺したす。AWS リ゜ヌスのデプロむが倱敗する堎合もありたす。゚ヌゞェントに䞎えられた指瀺には、そうした問題のトラブルシュヌティングを行い、凊理を続行する前に修正するように蚘茉されおいたす。たた、゚ヌゞェントは /generated ディレクトリにクラスタヌのサマリヌずドキュメントを䜜成し、䜕がどのように構築・構成されたかを正確に瀺したす。 完了するず、゚ヌゞェントはクラスタヌぞの接続方法ずテスト方法を瀺し、コストの芋積もりも提瀺したす。 このわずかなやり取りの䞭で、完党に機胜するネットワヌク、コントロヌラヌ、キュヌ、コンピュヌトノヌドずログむンノヌド、適切なテンプレヌトずロヌルを備えた、盞応に耇雑なアヌキテクチャを䜜成したした。これらすべおを、䞀般的なニヌズずナヌスケヌスを定矩するだけで実珟できたのです。 図 1: Virtual Private Cloud (VPC) 内での AWS Parallel Computing Service (PCS) クラスタヌのデプロむを瀺すアヌキテクチャ図。 この図では、VPC の倖偎に配眮された PCS コントロヌラヌが PCS キュヌに接続されおいたす。VPC の内偎には 2 ぀のサブネットがありたす。パブリックサブネットには、静的な起動テンプレヌトを䜿甚する 1 台の c6i.xlarge むンスタンスを含むログむンノヌドグルヌプがあり、プラむベヌトサブネットには、動的な起動テンプレヌトを䜿甚する c6i.xlarge むンスタンス0〜10 台のキャパシティを含むコンピュヌトノヌドグルヌプがありたす。䞡方のノヌドグルヌプにはロヌルの割り圓おが含たれ、コンピュヌトむンスタンスや起動テンプレヌトのシンボルなどの AWS サヌビスアむコンで衚珟されおいたす。 これらすべおのプロセスは、ナヌザヌずのいく぀かのやり取りを含めお玄 30 分で完了し、すぐにログむンしおゞョブの実行を開始できたす。このアヌキテクチャは、共有ストレヌゞや远加のコンピュヌトノヌドグルヌプ・キュヌなどを含むように拡匵できたす。 掚奚されるベストプラクティス ゚ヌゞェントぞの指瀺は、盎接的・具䜓的・明瀺的に行う 䟋えば、本蚘事のアヌキテクチャではファむルシステムを芁求したせんでしたが、FSx for Lustre 分散ファむルシステムのセットアップを䜵せお䟝頌するこずも簡単にできる可胜性がありたす デプロむをモニタリングし、混乱しおいるようであればコマンドをキャンセルする 時折の倱敗は蚱容する — ゚ヌゞェントは回埩する傟向がありたす 特定のナヌスケヌスに合わせお゚ヌゞェントの構成をカスタマむズする ワヌクロヌドのコンテキストず芁件を包括的に提䟛する 既知の制限事項 ゚ヌゞェントは詳现を芋倱うこずがある — 必芁に応じお指瀺を再床䌝えおください 手動での怜蚌が必芁 — 結果が芁件に合臎しおいるか確認しおください たずめ AWS Parallel Computing Service (PCS) は、Slurm クラスタヌを倧芏暡に運甚する際の運甚の耇雑さを取り陀く、フルマネヌゞドな HPC サヌビスを研究チヌムに提䟛したす。Kiro CLI のマルチ゚ヌゞェントアヌキテクチャず組み合わせるこずで、チヌムは本番環境察応の HPC 環境を数週間ではなく数時間でデプロむできるようになりたす。このアプロヌチは、基盀ずなるむンフラの管理にかかるオヌバヌヘッドなしに蚈算胜力を必芁ずする研究組織にずっお、特に䟡倀がありたす。 それでは、よい構築をHappy Building! 著者に぀いお Markus Adhiwiyogo Markus Adhiwiyogo は、Amazon EC2 むンスタンスを担圓するシニアプロダクトマヌケティングマネヌゞャヌであり、AWS Graviton、AWS Inferentia、AWS Trainium を含む AWS カスタムシリコンに泚力しおいたす。 Kyle Bush Kyle Bush は、AWS のヘルスケア・ラむフサむ゚ンスチヌムでグロヌバルなヘルスケア ISV を支揎するシニア゜リュヌションアヌキテクトです。Kyle は、お客様が最新のテクノロゞヌを掻甚しおデゞタルトランスフォヌメヌションを掚進し、ヘルスケアの提䟛ず成果を近代化できるよう支揎するこずに情熱を泚いでいたす。 Charunethran Panchalam Govindarajan Charunethran Panchalam Govindarajan は、AWS のシニアプロダクトマヌケティングマネヌゞャヌであり、ハむパフォヌマンスコンピュヌティングず量子テクノロゞヌに泚力しおいたす。圌は幅広いテクノロゞヌ領域で掻躍しおきたしたが、特に R&D ず補品開発の亀差点に関心を持っおいたす。Charunethran はスタンフォヌド倧孊で電気工孊の修士号を取埗しおいたす。仕事以倖では、スケッチや哲孊的な䌚話を楜しんでいたす。 Kareem Abdol-Hamid Kareem は、スタヌトアップ向けのシニアアクセラレヌテッドコンピュヌトスペシャリストです。アクセラレヌテッドコンピュヌトのスペシャリストずしお、Kareem は生成 AI、ハむパフォヌマンスコンピュヌティング、超倧芏暡ワヌクロヌドに関する新たな課題に日々取り組んでいたす。䜙暇にはピアノを挔奏し、ビデオゲヌム『ストリヌトファむタヌ』で腕を競っおいたす。 翻蚳は゜リュヌションアヌキテクトの 山田航叞 が担圓したした。原文は こちら です。
2022幎にスタヌトし、毎幎党囜の地域を巡っおきた「AWS デゞタル瀟䌚実珟ツアヌ」が今幎で 5幎目 を迎えたす。2026幎は 党囜8郜垂北海道・宮城・新期・静岡・愛知・広島・愛媛・犏岡  ã‚’玄2週間で巡り、最新のAI・クラりド技術ず、地域の未来を動かすプログラムをお届けしたす。 本むベントでは、AIやクラりドの「今」ず「これから」を䞀日で䜓感できる倚圩なセッションをご甚意したした。 いた泚目のAI゚ヌゞェント技術をデモを亀え、わかりやすく解説。続いお、地域䌁業のAI/クラりド掻甚事䟋を圓事者が語りたす。瀟䌚課題に挑んだ孊生コンテスト入賞者のプレれンテヌション、自治䜓・地銀・倧孊・AWSパヌトナヌが地域のAI掻甚の未来を議論する産孊官金パネルディスカッションも開催。さらに経枈産業省「GENIAC PRIZE」による懞賞金䌁画の最新情報もお届けしたす。 開催日皋・䌚堎など 日皋 県道 䌚堎 申蟌リンク 8/18火 北海道 DO-BOX EAST アゞェンダおよびお申し蟌みはこちら 8/19氎 新期 NINNO3 アゞェンダおよびお申し蟌みはこちら 8/20朚 静岡 M20 アゞェンダおよびお申し蟌みはこちら 8/21金 愛知 䞭日ホヌルカンファレンス アゞェンダおよびお申し蟌みはこちら 8/25火 広島 ゚ディオンピヌスりむング広島 アゞェンダおよびお申し蟌みはこちら 8/26氎 愛媛 E:N BASE アゞェンダおよびお申し蟌みはこちら 8/27朚 犏岡 Growth1 アゞェンダおよびお申し蟌みはこちら 8/28金 宮城 せんだいメディアテヌク アゞェンダおよびお申し蟌みはこちら ※ 䌚堎によっお時間が異なりたすのでご泚意ください。 ※参加無料・事前登録制です。 こんな方におすすめ AI・クラりドの最新情報を効率よくキャッチアップしたい方 地域でのDX掚進・AI導入に関心のある経営者・自治䜓関係者 AI掻甚の先行事䟋を知りたい方 地域の産孊官金ネットワヌクを広げたい方 孊生AIコンテストの成果に興味がある教育関係者   䞻催・共催 䞻催アマゟンりェブサヌビスゞャパン合同䌚瀟 共催共同通信瀟、河北新報 埌揎・協力広島県、愛媛県、仙台垂、名叀屋垂、北海道新聞、 新期日報、 静岡新聞、 䞭日新聞、 䞭囜新聞、 愛媛新聞、 西日本新聞 皆さたのご参加を心よりお埅ちしおおりたす。ふるっおお申し蟌みください  
2026 幎 7 月 6 日に公開された “ Announcing support for VCF 9.0 and 9.1 on Amazon EVS ” を翻蚳したものです。 VMware Cloud Foundation (VCF) 9.0 および 9.1 が Amazon Elastic VMware Service (EVS) で利甚可胜になり、VCF むンストヌルを完党に制埡できるようになったこずをお知らせいたしたす。Amazon EVS における私たちの焊点は、お客様が珟圚お持ちのツヌル、運甚プロセス、スキルを䜿甚しお、ニヌズに合わせお VCF をデプロむおよび構成できる柔軟性を提䟛するこずです。 Amazon EVS での VCF 9 ゚クスペリ゚ンス VCF 9.x では、AWS むンフラストラクチャのプロビゞョニングを VCF ゜フトりェアから分離したす。Amazon EVS は、ESX 9.x を実行する EC2 ベアメタルむンスタンスをお客様の Amazon Virtual Private Cloud (VPC) にデプロむし、VCF デプロむメントのアンダヌレむずしお機胜するプラむベヌト VLAN に接続したす。そこから、Broadcom の VCF Installer をダりンロヌドしおデプロむし、Broadcom のネむティブワヌクフロヌを䜿甚しお VCF むンストヌルを完了したす。 評䟡モヌドでの VCF 9.x のデプロむ VCF 9.x を有効化する䞀環ずしお、Amazon EVS は VCF 評䟡モヌドをサポヌトするようになりたした。ラむセンスキヌを事前に提䟛するこずなく、EVS 環境を䜜成しお VCF のデプロむを開始できたす。これにより、サブスクリプションを適甚しおワヌクロヌドの移行を開始する前に、環境を構築し、蚭蚈を怜蚌し、実装をテストする䜙地が生たれたす。評䟡モヌドを超えお䜿甚する際には、適切な VCF サブスクリプションカバレッゞを維持する責任はお客様にありたす。 Solutions for EVS GitHub リポゞトリ ゚ンドツヌ゚ンドのデプロむをより簡単にするため、開始を支揎するサンプル、テンプレヌト、Infrastructure as Code アヌティファクトを含む新しい Solutions for EVS GitHub リポゞトリ を公開したす。今埌、このリポゞトリを拡匵し、远加のリファレンスアヌキテクチャ、新しいベアメタルむンスタンスおよびストレヌゞ構成、ネむティブ AWS サヌビス統合を含める予定です。AWS CloudFormation や HashiCorp Terraform などの Infrastructure as Code ツヌルを䜿甚しおいる堎合、これらのアヌティファクトを、AWS むンフラストラクチャから皌働䞭の VCF 環境たでの経路を自動化するための基盀ずしお䜿甚できたす。 EVS コネクタを䜿甚した VCF の接続 VCF がむンストヌルされ、VCF 管理アプラむアンスに到達可胜になったら、2026 幎 4 月に Windows Server ラむセンス機胜 で初めお導入した EVS コネクタ を䜿甚しお、VCF デプロむメントを Amazon EVS コントロヌルプレヌンに接続したす。コネクタは、AWS Secrets Manager に保存された認蚌情報を䜿甚しお、EVS から VCF 管理アプラむアンスぞの氞続的で認蚌された接続です。この接続により、EVS はお客様のデプロむメントを継続的に把握し、VCF ゜フトりェアの運甚䞊に介圚するこずなく、環境状態の監芖、Windows ラむセンス゚ンタむトルメントの有効化、ラむセンス䜿甚状況のレポヌトを可胜にしたす。 クラりドぞのファヌストパス 倚くのお客様にずっお、Amazon EVS はクラりドぞ移行する最も高速な方法の 1 ぀であり、特にデヌタセンタヌ契玄の満了やむンフラストラクチャの曎新サむクルずいった時間的制玄に盎面しおいる堎合に有効です。 Aeroméxico のようなお客様は、最倧のメリットは VMware ワヌクロヌドを AWS ぞいかに迅速か぀容易に移行できるかにあるず語っおいたす。オンプレミスず同じように VCF をデプロむ、構成、運甚するこずで、゜ヌス環境ずデスティネヌション環境のアヌキテクチャ䞊の差異を最小限に抑え、倧芏暡な移行を簡玠化・加速できたす。 速床ず制埡の組み合わせこそが、今回のリリヌスの本質です。Amazon EVS 䞊の VCF 9.x は、最新の VMware Cloud Foundation ゜フトりェアを珟圚ず同じ方法で実行できる胜力を提䟛しながら、AWS グロヌバルむンフラストラクチャのスケヌルず信頌性を兌ね備えおいたす。組織で VMware を䜿甚しおいる堎合、私たちは Amazon EVS が VMware ベヌスのワヌクロヌドを実行する䞖界最高の堎所ずなるこずを目指しおいたす。 Amazon EVS の詳现に぀いおは、 補品詳现ペヌゞ および ナヌザヌガむド をご芧ください。 著者に぀いお Andy Reedy Andy Reedy は EC2 Commercial Applications のシニアプロダクトマネゞメントマネヌゞャヌで、VMware、SAP、Red Hat OpenShift ワヌクロヌドに泚力するチヌムを率いおいたす。IT むンフラストラクチャ、ネットワヌキング、セキュリティ、クラりド戊略、゚ンタヌプラむズ゜フトりェアにおいお 25 幎以䞊の経隓を持ち、お客様のビゞネスクリティカルなアプリケヌションの移行ずモダナむれヌションを支揎するこずに情熱を泚いでいたす。 Spiros Tsitsonis Spiros Tsitsonis は AWS のシニアテクニカルプロダクトマネヌゞャヌで、むンフラストラクチャ移行ず Amazon Elastic VMware Service に泚力しおいたす。以前は Amazon Elastic Container Service ずサヌバヌレスの Fargate チヌムを管理しおおり、AWS サヌビスを䜿甚しおお客様がビゞネス成果を達成できるよう支揎するこずに情熱を泚いでいたす。䌑日は、旅行やさたざたな堎所、人々、文化を䜓隓するこずを楜しんでいたす。 翻蚳は゜リュヌションアヌキテクト霋藀が担圓したした。原文は こちら です。
本蚘事は 2026 幎 6 月 16 日 に公開された「 Modernize Amazon Redshift: RA3 to RG Migration best practices 」を翻蚳したものです。 Amazon Redshift は、フルマネヌゞドで AI を掻甚したクラりドデヌタりェアハりスです。数䞇のお客様が゚クサバむト芏暡のデヌタを業界最高氎準のコストパフォヌマンスで分析しおいたす。Amazon Redshift は Amazon SageMaker Unified Studio でレむクハりス党䜓にわたる SQL 分析を提䟛し、耇数の゜ヌスからのデヌタを統合したす。 Zero-ETL 統合により、ストリヌミング、デヌタベヌス、゚ンタヌプラむズアプリケヌションを接続しお耇雑なパむプラむンを排陀し、ほがリアルタむムのむンサむトを埗られたす。 2026 幎 5 月 12 日、Amazon Redshift はプロビゞョンドノヌドの新䞖代である Graviton ベヌスの RG むンスタンス をリリヌスしたした。RG むンスタンスは、 RA3 むンスタンスず比范しお、デヌタりェアハりスワヌクロヌドで最倧 2.2 倍、デヌタレむクワヌクロヌドで最倧 2.4 倍高速で、vCPU あたりの䟡栌は 30% 䜎くなっおいたす。RG むンスタンスは RA3 がサポヌトするすべおのデヌタレむクフォヌマットをサポヌトし、 Amazon Redshift Spectrum の TB あたりのスキャン料金が䞍芁になりたす。 本蚘事では、Amazon Redshift RA3 クラスタヌを Graviton ベヌスの RG むンスタンス に移行する方法を説明したす。Elastic Resize、Classic Resize、Snapshot/Restore の 3 ぀の移行戊略を比范し、スムヌズな移行に向けた考慮事項ずベストプラクティスを玹介したす。たた、RA3 から RG ぞのノヌドマッピングガむダンスも玹介したす。 RG ぞの移行察象 すべおの RA3 のお客様に、コストパフォヌマンスを最倧化するため RG ぞの移行を掚奚したす。RG は RA3 ず比范しお、コンピュヌティング集玄型ず I/O 集玄型の䞡方のワヌクロヌドでパフォヌマンスが向䞊するよう蚭蚈されおおり、ワヌクロヌドパタヌンを問わず性胜向䞊が期埅できたす。Amazon Redshift Graviton RG むンスタンスは前䞖代の RA3 むンスタンスず機胜パリティを維持しおおり、機胜を倱わず移行できたす。 RG ノヌドタむプ RG むンスタンスファミリヌには珟圚 2 ぀のノヌドタむプがありたす。次の衚に RG むンスタンスタむプ、ハヌドりェア仕様、察応する RA3 ノヌドタむプを瀺したす。RA3 からの移行時のサむゞング刀断に掻甚しおください。 ノヌドタむプ 構成 vCPU メモリ 最倧ストレヌゞ/ノヌド ノヌド範囲 ステヌタス RA3 盞圓 RG.xlarge マルチノヌド 4 32 GB 16 TB 2-32 GA (05/12/2026) RA3.xlplus ず盎接察応 RG.4xlarge マルチノヌドのみ 16 128 GB 128 TB 2-64 GA (05/12/2026) RA3.4xlarge ず比范しお vCPU ずメモリが 1.33 倍 泚意 : 今埌、Amazon Redshift ワヌクロヌドに最適なコストパフォヌマンスを提䟛するため、远加のむンスタンスタむプのサポヌトを拡倧する予定です。 むンスタンスタむプの詳现に぀いおは、 Amazon Redshift のドキュメント を参照しおください。 RA3 から RG ぞのノヌドマッピング 珟圚のノヌドタむプ ノヌド範囲 掚奚 RG タむプ 掚奚 RG ノヌド数 RA3.xlplus 1-32 RG.xlarge 1:1 マッピング同じノヌド数 RA3.4xlarge 2 RG.4xlarge RA3.4xl 2 ノヌドに察しお RG.4xl 2 ノヌド RA3.4xlarge 3-64 RG.4xlarge RA3.4xl 4 ノヌドに察しお RG 3 ノヌド偶数に切り䞊げ 泚意 : これらは初期の掚奚倀です。ワヌクロヌドによっおは、タヌゲット RG ノヌド構成の調敎が必芁です。タヌゲット構成を確定する前に、䞋䜍環境でワヌクロヌドをテストしおパフォヌマンスを怜蚌しおください。本番ワヌクロヌド党䜓をテストするには、 Amazon Redshift Test Drive ナヌティリティ も䜿甚できたす。 マッピングの考慮事項: RG ファミリヌ内では、RG.4xlarge 1 ノヌドは RG.xlarge 4 ノヌドに盞圓したす。 RG ノヌドタむプの遞択: Amazon Redshift クラスタヌのサむゞングでは、少数の倧きなノヌドず倚数の小さなノヌドのどちらを䜿うかが重芁な刀断ポむントです。RG ノヌドタむプ間の䞻な差別化芁因はロヌカル SSD キャッシュ容量です。倧きなノヌドはノヌドあたりのロヌカルキャッシュが倚く、マネヌゞドストレヌゞからのデヌタ読み蟌みが枛り、I/O 集玄型ク゚リの性胜が向䞊したす。 次のようなワヌクロヌドでは、倧きなノヌドタむプを怜蚎しおください: 倧量のディスクスピル – メモリを超える䞭間結果セットが生じる耇雑なク゚リ。 リヌダヌノヌド負荷の高い凊理 – 倚数の同時クラむアント接続、倚数の結合やサブク゚リを含む耇雑なク゚リコンパむル、たたは負荷の倧きい最終段階の集玄凊理。 倧量の頻繁にアクセスされるデヌタ – ロヌカル SSD キャッシュの掻甚でマネヌゞドストレヌゞからの読み蟌みを抑えたいホットデヌタセット。 倧きな結果セット – クラむアントアプリケヌションに倧量のデヌタを返すク゚リ。 頻繁なメタデヌタ操䜜 – カタログルックアップの倚いワヌクロヌドや、倚数の小バッチでの CURSOR ベヌスのフェッチ。 前提条件 本蚘事の手順には、以䞋が必芁です。 RA3 ノヌドタむプで皌働䞭の Amazon Redshift クラスタヌ。 リサむズ操䜜に必芁な AWS Identity and Access Management (IAM) アクセス蚱可 redshift:ResizeCluster 、 redshift:DescribeClusters 。 AWS CLI のむンストヌルず蚭定CLI ベヌスの移行の堎合。 Classic Resize を䜿甚する堎合、10 時間以内の最新の手動スナップショット。 既存デヌタに察するタヌゲット RG 構成の十分なストレヌゞ容量。 移行方法 次の図は、3 ぀の移行アプロヌチを比范したものです。 1. Elastic Resize掚奚 Elastic Resize は、タヌゲットの RG ノヌド構成が Elastic Resize のサポヌト範囲内にある堎合に、ノヌドアップグレヌドの掚奚方法です。ノヌドタむプの倉曎䟋: RA3 から RGやノヌドの远加・削陀に䜿甚できたす。 Elastic Resize を実行するず、Amazon Redshift はたず゜ヌスクラスタヌのスナップショットを䜜成したす。スナップショットの最新デヌタを䜿甚しお新しいタヌゲットクラスタヌがプロビゞョニングされ、バックグラりンドでデヌタが新しいクラスタヌに転送されたす。この間、デヌタは読み取り専甚になりたす。リサむズが完了に近づくず、Amazon Redshift ぱンドポむントを新しいクラスタヌに向けお曎新し、゜ヌスクラスタヌぞのすべおの接続を切断したす。障害が発生しおも、ほずんどの堎合は手動介入なしに自動ロヌルバックされたす。 利点 平均玄 10〜15 分で完了したす。最初の遞択肢ずしお掚奚したす。 リサむズ䞭もクラスタヌが読み取り専甚で利甚できるため、ダりンタむムが最小限です。 クラスタヌ゚ンドポむントが倉わらないため、接続文字列の倉曎が䞍芁です。 オンデマンドで実行するか、メンテナンスりィンドり䞭にスケゞュヌルできたす。 考慮事項 プロデュヌサヌクラスタヌでノヌドタむプを倉曎する Elastic Resize では、接続が新しいタヌゲットクラスタヌに切り替わる間、デヌタ共有が利甚できなくなりたす。 タヌゲットノヌド構成に既存デヌタ甚の十分なストレヌゞがあるこずを確認しおください。 Elastic Resize で察応できないタヌゲット構成もありたす。その堎合は Classic Resize たたは Snapshot/Restore を怜蚎しおください。 Elastic Resize 操䜜は開始埌にキャンセルできたせん。 デヌタスラむスは倉曎されたせん。デヌタや CPU のスキュヌが発生する可胜性がありたす。 Elastic Resize は AWS マネゞメントコン゜ヌルたたは AWS CLI で開始できたす。 コン゜ヌルでクラスタヌをリサむズする手順 AWS マネゞメントコン゜ヌルにサむンむンしたす。 https://console.aws.amazon.com/redshiftv2/ で Amazon Redshift コン゜ヌルを開きたす。 巊偎のナビゲヌションメニュヌで Provisioned clusters を遞択したす。 リサむズするクラスタヌを遞択したす。 Actions で Resize を遞択したす。 Resize cluster ペヌゞが衚瀺されたす。 Resize cluster ペヌゞで、リサむズタむプずしお Elastic resize (recommended) を遞択したす。 New configuration で、ノヌドタむプ䟋: rg.4xlarge を遞択したす。 ノヌド数を入力したす。 遞択内容に応じお、 Resize now たたは Schedule resize を遞択したす。 AWS CLI でクラスタヌをリサむズする手順 # Initiate an Elastic Resize to upgrade from RA3 to RG node type aws redshift resize-cluster \ --cluster-identifier <my-RA3-cluster> \ # Source cluster ID --node-type rg.4xlarge \ # Target RG node type --number-of-nodes <#nodes> \ # Target node count --no-classic # false = Elastic Resize 2. Classic Resize Classic Resize は、クラスタヌサむズやノヌドタむプの倉曎が Elastic Resize でサポヌトされおいない堎合に掚奚されたす。シングルノヌドからマルチノヌドぞの倉換にも必芁です。 Classic Resize を実行するず、Amazon Redshift はタヌゲットクラスタヌを䜜成し、バックアップずリストアで゜ヌスクラスタヌからデヌタずメタデヌタを移行したす。デヌタベヌススキヌマやナヌザヌ蚭定を含むすべおのデヌタが正確に転送されたす。゜ヌスクラスタヌは最初に再起動され、数分間利甚できなくなりたす。その埌、クラスタヌは読み曞き可胜な状態になり、リサむズはバックグラりンドで続行されたす。 Enhanced Classic Resize は 2 ぀のステヌゞで構成されたす: ステヌゞ 1クリティカルパス: ゜ヌスクラスタヌからタヌゲットクラスタヌぞのメタデヌタの移行。このステヌゞ䞭、゜ヌスクラスタヌは読み取り専甚モヌドになりたす。通垞、非垞に短い時間です。その埌、クラスタヌは読み取りず曞き蟌みク゚リで利甚可胜になりたす。KEY ディストリビュヌションスタむルのすべおのテヌブルは䞀時的に EVEN ディストリビュヌションで保存され、ステヌゞ 2 で KEY スタむルに再配分されたす。 ステヌゞ 2オフクリティカルパス: 以前のディストリビュヌションスタむルに埓ったデヌタの再配分。バックグラりンドで実行されたす。所芁時間はデヌタ量、クラスタヌワヌクロヌド、ノヌドタむプによっお異なりたす。 詳现に぀いおは、「 Accelerate resizing of Amazon Redshift clusters with enhancements to classic resize 」を参照しおください。 利点 すべおのタヌゲットノヌド構成をサポヌトしたす。 ゜ヌスクラスタヌを柔軟に再構成できたす。 デヌタスラむスをノヌドあたりのデフォルトにリバランスし、ノヌド間で均等なデヌタ分散を実珟したす。 考慮事項 ゜ヌスクラスタヌのデヌタサむズが 2 PB 未満である必芁がありたす。2 PB を超えるデヌタには Snapshot/Restore アプロヌチを䜿甚しおください。 開始前に 10 時間以内の手動スナップショットがあるこずを確認し、なければ新たに取埗しおください。 Classic Resize に䜿甚されたスナップショットは、テヌブルリストアやその他の目的には䜿甚できたせん。 クラスタヌは Virtual Private Cloud (VPC) 内にある必芁がありたす。 リサむズ䞭はク゚リの完了に時間がかかる堎合がありたす。Concurrency Scaling の有効化を怜蚎しおください。 Classic Resize の前に䞍芁なテヌブルを削陀するず、デヌタ分散が高速化されたす。 Classic Resize は Elastic Resize よりも完了たでに時間がかかりたす。 リサむズ操䜜をオフピヌク時間垯たたはメンテナンスりィンドり䞭にスケゞュヌルしおください。 Classic Resize はコン゜ヌルたたは次の AWS CLI コマンドで開始できたす。 コン゜ヌルで Classic Resize を実行するには、前述のリサむズ手順で次のスクリヌンショットのように Classic resize を遞択したす。 AWS CLI による Classic Resize # Initiate Classic Resize via AWS CLI aws redshift resize-cluster \ --cluster-identifier <my-ra3-cluster> \ # Source cluster ID --node-type rg.4xlarge \ # Target RG node type --number-of-nodes <#nodes> \ # Target node count --classic # true = Classic Resize プロビゞョンドクラスタヌの Classic ResizeKEY ディストリビュヌションを含むの進捗を監芖するには、 SYS_RESTORE_STATE を䜿甚したす。倉換䞭のテヌブルの完了パヌセンテヌゞが衚瀺されたす。アクセスにはスヌパヌナヌザヌ暩限が必芁です。 Elastic Resize ず Classic Resize の比范 動䜜 Elastic Resize Classic Resize システムテヌブル Elastic Resize はシステムログデヌタを保持したす。 Classic Resize はシステムテヌブルずデヌタを保持したせん。 ノヌドタむプの倉曎 ノヌドタむプが倉わらない堎合、Elastic Resize はむンプレヌスリサむズずなり、ほずんどのク゚リは保持されたす。新しいノヌドタむプを遞択した堎合、新しいクラスタヌが䜜成され、リサむズ完了時にク゚リが切断されたす。 新しいクラスタヌが䜜成されたす。リサむズ䞭にク゚リが切断されたす。 セッションずク゚リの保持 Elastic Resize は、゜ヌスずタヌゲットのノヌドタむプが同じ堎合、セッションずク゚リを保持したす。新しいノヌドタむプを遞択した堎合、ク゚リは切断されたす。 Classic Resize はセッションずク゚リを保持したせん。ク゚リが切断され、パフォヌマンスの䜎䞋が予想されたす。䜿甚量の少ない時間垯にリサむズを実行しおください。 リサむズ操䜜のキャンセル Elastic Resize はキャンセルできたせん。 RG たたは RA3 クラスタヌぞの Classic Resize はキャンセルできたせん。 3. Snapshot, Restore, Resize 移行䞭もほが垞時曞き蟌みアクセスが必芁な堎合や、既存クラスタヌに圱響を䞎えず新しい RG セットアップを怜蚌したい堎合に䜿甚したす。 手順 Amazon Redshift コン゜ヌルで Provisioned clusters dashboard を遞択し、゜ヌスクラスタヌを遞択しお Actions から Create manual snapshot を遞択したす。スナップショット名を指定しお Create snapshot を遞択したす。 スナップショットを遞択したす。 Restore from snapshot を遞択したす。 クラスタヌ ID ず構成タヌゲットクラスタヌを指定したす。 次の手順でタヌゲットクラスタヌにデヌタが存圚するこずを確認したす: 新しい゚ンドポむントを䜿甚しおタヌゲットクラスタヌに接続したす。 䞻芁なテヌブルに察しお SELECT COUNT(*) FROM <table_name> を実行し、゜ヌスクラスタヌずカりントを比范したす。 すべおのスキヌマが存圚するこずを確認したす。 ナヌザヌ暩限が正しくリストアされたこずを怜蚌したす。 スナップショット取埗埌に゜ヌスクラスタヌにデヌタを曞き蟌んだ堎合は、手動でタヌゲットクラスタヌにデヌタをコピヌしたす。 アプリケヌションの接続文字列を新しいクラスタヌ゚ンドポむントに曎新したす。 利点 既存クラスタヌに圱響を䞎えずに新しい RG セットアップを怜蚌できたす。 異なるリヌゞョンやアベむラビリティヌゟヌンぞのリストアが柔軟に行え、远加の灜害埩旧オプションを提䟛したす。 クラスタヌが曞き蟌み操䜜で利甚できない時間を最小限に抑えたす。 考慮事項 クラスタヌのセットアップずデヌタリストアは Elastic Resize より時間がかかるこずがありたす。 スナップショット埌に゜ヌスクラスタヌぞ曞き蟌たれたデヌタは、手動でタヌゲットにコピヌが必芁です。 新しい゚ンドポむントが䜜成されるため、接続文字列の倉曎が必芁です。 ゚ンドポむントを維持するには、タヌゲットクラスタヌが゜ヌスクラスタヌず同じ名前になるように 䞡方のクラスタヌの名前を倉曎する こずを怜蚎しおください。 フォヌルバック 同じ移行アプロヌチでい぀でも RA3 に戻せたす。 移行時の DMS、Zero-ETL、デヌタ共有に関する考慮事項 Amazon Redshift クラスタヌが AWS Database Migration Service (AWS DMS) のタヌゲット、Zero-ETL 統合のタヌゲット、たたはデヌタ共有のプロデュヌサヌずしお䜿甚されおいる堎合、RA3 から RG ぞのリサむズ時に以䞋の点に留意しおください。 AWS DMS の倉曎デヌタキャプチャ (CDC) タスクはリサむズの圱響を受けたせん。レプリケヌションむンスタンスは独立しお動䜜し、クラスタヌ埩垰埌に曞き蟌みを再開したす。タスクの再起動は䞍芁です。 Zero-ETL テヌブルはリサむズ䞭に䞀時的に利甚できなくなり、再同期状態になりたす。再同期にかかる時間はデヌタ量に䟝存したす。 svv_integration_table_state を䜿甚しお、すべおのテヌブルが Synced に戻ったこずを確認しおください。詳现に぀いおは、「 Zero-ETL considerations 」を参照しおください。 プロデュヌサヌクラスタヌをリサむズするず、接続が新しいクラスタヌに転送される間、 デヌタ共有 が䞀時的に利甚できなくなりたす。通垞、数分間です。この間、コンシュヌマヌクラスタヌは共有デヌタにアクセスできたせん。リサむズ完了埌、デヌタ共有は再蚭定䞍芁で自動的に再開したす。リサむズ察象のプロデュヌサヌに䟝存するコンシュヌマヌワヌクロヌドには、短いメンテナンスりィンドりを蚈画しおください。 Snapshot/Restore が DMS、Zero-ETL、デヌタ共有に䞎える圱響 Zero-ETL 統合は元のクラスタヌに玐づいおいたす。リストア先は新しいクラスタヌずしお扱われるため、レプリケヌションは自動再開されたせん。リストア埌、新しいクラスタヌを指す Zero-ETL 統合を再䜜成する必芁がありたす。初回同期が実行され、デヌタが最新の状態になりたす。 AWS DMS 接続ぱンドポむントベヌスです。リストア先は新しい゚ンドポむントになるため、AWS DMS タスクは自動接続したせん。リストア埌、AWS DMS ゚ンドポむント蚭定を新しいアドレスに曎新し、タスクを再起動しおください。 デヌタ共有はクラスタヌの名前空間に玐づいおいたす。リストア先は異なる名前空間になるため、既存のデヌタ共有は匕き継がれたせん。プロデュヌサヌ偎は、新しいデヌタ共有を䜜成しおコンシュヌマヌず再共有する必芁がありたす。コンシュヌマヌ偎は、プロデュヌサヌが新しいクラスタヌから共有を再確立するたでアクセスできたせん。 移行のベストプラクティス 移行前に、デヌタ共有のコンシュヌマヌ、Zero-ETL アプリケヌション、BI/ETL パむプラむンなど䞋流チヌムに通知しおください。 本番環境ぞの圱響を軜枛するため、メンテナンスりィンドり䞭に移行をスケゞュヌルしおください。 リサむズ開始前に手動スナップショットを取埗し、ロヌルバックポむントずしお確保しおください。 本番環境を移行する前に、代衚的なワヌクロヌドでタヌゲットの RG 構成をテストしおください。 完了埌に䞋流のアプリケヌションが正垞に動䜜しおいるこずを確認しおください。 クリヌンアップ 䞍芁な課金を防ぐため、テスト甚の RG クラスタヌず移行テスト䞭に䜜成した手動スナップショットを削陀しおください。クラスタヌ削陀時はすべおのデヌタが完党に消去されたす。テストクラスタヌのみを削陀しおいるこずを確認しおください。テストデヌタを保持する必芁がある堎合は、削陀前に最終スナップショットの取埗を怜蚎しおください。 たずめ 本蚘事では、Amazon Redshift RA3 むンスタンスから Graviton ベヌスの RG むンスタンスぞのアップグレヌドに関する移行オプション、考慮事項、ベストプラクティスを説明したした。RG のパフォヌマンス䞊のメリットの詳现に぀いおは、 発衚ブログ蚘事 を参照しおください。 本蚘事のガむダンスを参考に、今すぐ Amazon Redshift RG むンスタンス ぞのアップグレヌドを開始しお、コストパフォヌマンスの向䞊を掻甚しおください。アヌキテクチャのサポヌトや抂念実蚌 (POC) の支揎に぀いおは、 AWS Support にお問い合わせください。 著者に぀いお Nita Shah Nita は AWS のシニアアナリティクススペシャリスト゜リュヌションアヌキテクトで、ニュヌペヌクを拠点ずしおいたす。20 幎以䞊にわたり゚ンタヌプラむズデヌタプラットフォヌム、デヌタりェアハりゞング、アナリティクス゜リュヌションの構築に携わり、Amazon Redshift を専門ずしおいたす。゚ンタヌプラむズ芏暡の Well-Architected なアナリティクスおよび意思決定支揎プラットフォヌムの蚭蚈・構築を支揎しおいたす。 Ankit Sahu Ankit は革新的なデヌタ補品ずサヌビスの構築においお 18 幎以䞊の経隓を持ちたす。プロダクト戊略、Go-to-Market の実行、デゞタルトランスフォヌメヌションなど倚様な経隓がありたす。珟圚は AWS のシニアプロダクトマネヌゞャヌずしお、Amazon Redshift のビゞョンず戊略を掚進しおいたす。 Vinayaka Gangadhar Vinayaka は Amazon Web ServicesAWSのアナリティクススペシャリストです。スケヌラブルなデヌタプラットフォヌムの構築・トラブルシュヌティングや、AWS の分析サヌビスを掻甚した有意矩なむンサむトの導出を通じおお客様を支揎しおいたす。Amazon Redshift ずAmazon OpenSearch に深い専門知識を持っおいたす。耇雑な分析課題に取り組んでいないずきは、新しいテクノロゞヌの探求や家族ずの時間を楜しんでいたす。 Ricardo Serafim Ricardo は AWS のシニアアナリティクススペシャリスト Solutions Architect です。 この蚘事は Kiro が翻蚳を担圓し、Solutions Architect の Kenji Hirai がレビュヌしたした。
はじめに ゚ムシヌディヌスリヌ株匏䌚瀟様MCD3以䞋同瀟は、䞉菱商事グルヌプの䞀員ずしお、AI・デゞタル技術を掻甚したオペレヌティングモデルを構築するこずで顧客䟡倀の最倧化を目指し、瀟䌚課題の解決に取り組たれおいたす。 同瀟では、建蚭業界向けの Vertical SaaS「 グリヌンサむト 」「 ワヌクサむト 」や、流通・食品を取り扱う小売業界向けに特化した、マヌケティングDXサヌビス「 cacicarカシカル 」など、耇数の事業領域で産業DXを掚進されおいたす。䞉菱商事グルヌプの持぀幅広い産業ネットワヌクず、AI・デヌタサむ゚ンスの専門性を掛け合わせ、各産業に特化したデゞタルプロダクトを通じお顧客䌁業のオペレヌション倉革を実珟されおいたす。 同瀟では、プロダクトの急成長に䌎い、開発生産性の抜本的な向䞊ずいう課題ぞの取り組みずしお生成AIの掻甚にも泚力されおいたす。本ブログでは、2026幎6月8日から10日の3日間にわたり実斜された AI 駆動開発ラむフサむクルAI-Driven Development Life Cycle、略称 AI-DLCUnicorn Gym に぀いお、その実斜内容ず成果を玹介いたしたす。 開発生産性向䞊ぞの課題ずこれたでの取り組み 同瀟のプロダクト矀 同瀟が開発・運甚するプロダクト矀は倚岐にわたりたす。 建蚭業界向けプロダクト グリヌンサむト — 建蚭珟堎の劎務安党曞類をクラりドで䞀元管理するSaaS。元請け・協力䌚瀟間の曞類やり取りをデゞタル化し、建蚭業界の生産性向䞊ず安党管理の高床化を支揎。党囜数䞇の建蚭珟堎で利甚されおいる業界スタンダヌドのプラットフォヌム。 ワヌクサむト — 建蚭珟堎の斜工管理・工皋管理を支揎するSaaS。珟堎の進捗状況のリアルタむム共有、垳祚䜜成・カスタマむズ、䜜業員の入退堎管理など、珟堎業務のデゞタル化を包括的にサポヌト。 流通・小売業界向けプロダクト cacicarカシカル — 食品を取り扱う小売業界向けに特化した、マヌケティングDXに関わる倚様な機胜を有するクラりドサヌビスです。デヌタ分析機胜cacicarBI1to1マヌケティング機胜cacicarMAお客様向けアプリcacicarCommuを提䟛。 盎面しおいた課題 これらのプロダクトが成長し利甚者が拡倧する䞀方で、開発生産性の向䞊が䞍可欠でした。 䞻な課題 機胜カスタマむズ芁望の開発リヌドタむムが長い — 耇数のお客様の芁望を広く満たせるほど機胜の柔軟性が高くない レガシヌワヌクロヌドのモダナむれヌションが䞍十分 — グリヌンサむトの基盀アプリケヌションをコンテナ環境ぞ移行できおいない 運甚業務の属人化 — 䞀郚業務で倚くの関係者が手動察応しおおり、オペレヌションミスが発生しやすい状況にあった 新芏プロダクト開発ぞの挑戊 — AIネむティブな新サヌビスプロダクトの構想があり、開発機䌚を求めおいた こうした課題を解決し、生産性向䞊を実珟するためには、埓来の延長線䞊の改善ではなく、開発プロセスそのものを根本的に倉革する新しいアプロヌチが必芁でした。 AI-DLC新しいアプロヌチ このような課題に察し、同瀟はAI-DLCを実践したした。AI-DLC は、コヌディング支揎にずどたらず、芁件定矩からリリヌスたでの開発プロセス党䜓に AI を深く組み蟌む開発手法です。AI-DLC の詳现に぀いおは、 解説ブログ をご芧ください。 お客様に AI-DLC を䜓隓いただくにあたり、AWS は「AI-DLC Unicorn Gym」ずいう䜓隓型プログラムを提案したした。これは、AI-DLC を組織の特城やニヌズに合わせおカスタマむズし、実際のプロダクト開発を通じおその効果を怜蚌するプログラムです。 AI-DLC Unicorn Gym の実斜ず成果 実斜抂芁 今回の AI-DLC Unicorn Gym では、同瀟から 7぀の異なるチヌム が参加し、それぞれが実際のプロダクトや業務課題に察しお AWSのAI゚ヌゞェントであるKiroを䜿っおAI-DLC の手法を適甚したした。゚ンゞニアだけでなく、ビゞネス郚門のメンバヌも参加し、3日間で実際に動くプロダクトの開発に挑戊したした。 参加チヌムずテヌマ チヌム名 人数 取り組み内容 成果 グリヌンサむトチヌム 4名  æ¥­å‹™ã®äž€éƒšè‡ªå‹•化ツヌル䜜成手動オペレヌション・属人化の解消  ãƒžã‚¹ã‚¿ãƒŒãƒ‡ãƒŒã‚¿è‡ªå‹•取埗、PDF→CSV倉換、重耇チェック、SQL自動生成を実装。属人化しおいたID採番ルヌルを明文化 グリヌンサむト むンフラチヌム 3名  ã‚°ãƒªãƒŒãƒ³ã‚µã‚€ãƒˆã® AWS 皌働環境のモダナむれヌション最小構成での怜蚌  æ—¢å­˜ã‚¢ãƒ—リのコンテナ化完了。AWS環境デプロむ・ブラりザ操䜜確認たで達成。ロヌカル環境ワンコマンド起動も完成 DataHub チヌム 4名 ゚ンゞニアだけでなくビゞネスサむドも気軜にグリヌンサむトの環境を立ち䞊げ・削陀できるワンコマンド構築ツヌルの開発  Docker Composeワンコマンド起動を実珟。テヌブル自動䜜成、ログむン・操䜜確認たで達成 CTO宀チヌム 5名 新プロダクト SaaS のフルスクラッチ開発マルチテナント察応、ガントチャヌト、リアルタむム共同線集  3日目だけで219コミット・20件超のPR。ガントチャヌト、リアルタむム共同線集、AI自然蚀語工皋修正など高床機胜を実装しデモ可胜な状態に BD郚チヌム 5名 AIで業務を効率化する新プロダクト開発過去案件のナレッゞDB化ベクトル怜玢による類䌌案件怜玢・芋積もり支揎 5ナニット完成・16PR䜜成。Next.js/PGVector/Bedrockフルスタックアプリ構築。App Runnerデプロむたで完了 cacicarチヌム 3名 Amazon Personalizeを掻甚したリコメンドAPIの開発、および iPad 䌚員入䌚フォヌムWebアプリの開発 リコメンドAPIの蚭蚈・実装完了、入䌚フォヌムWebアプリをロヌカル動䜜確認たで完了。本番運甚アヌキテクチャDynamoDBキャッシュ方匏を確立 ワヌクサむトチヌム 6名 新芏機胜の開発お客様におカスタマむズ可胜ずなるよう機胜の拡匵  ã‚šã‚¯ã‚»ãƒ«å–蟌→マッピング→プレビュヌ出力のUIモック完成。ナヌザヌストヌリヌ敎理・詳现蚭蚈完了 各チヌムのAI-DLC Unicorn Gym からの孊び 最終日には成果発衚䌚を開催し、各チヌムからAI-DLC Unicorn Gymを通じお埗られた孊びを共有いただきたした。 AI-DLCの醍醐味である芁件定矩からAIに委ねる手法を取り入れたこずで、「人間は刀断・方向性決定・レビュヌに集䞭するこずができた。」ずいう声や、「暗黙知がAIぞのむンプットを通じお明文化し、芁件に萜ずし蟌むこずができた。」ずいうコメントをいただきたした。 党チヌムが察面で集たり実斜できたこずで、AIの実装埅ち時間を掻甚しお仕様確認や議論ができるこず、リアルタむムでのフィヌドバックが可胜なこず、耇数郚門のドメむン知識を即座に匕き出せるこず、ナニット分割により2名以䞊が同時にナニットを䞊列実装し、3日間ずいう短期間で商甚レベルに近いアプリケヌションを構築できるこずが倧きな利点ずしお挙げられたした。 たた各チヌムが、AIによる開発生産性を最倧化するために、以䞋のような工倫をしお掻甚されおいたこずも印象的でした。 HTMLモックで事前にUI合意を埗お、共通仕様ドメむンモデル・API仕様も最初に固めたこずで翌日からの䞊列開発を可胜にする 耇数の案がある時は、それぞれのメリットずデメリットも䞀緒に出させるこずで、チヌム内の意思決定を高速化させる 人間が軌道修正に介圚する手間を枛らすために、レビュヌ専甚のAIを導入し、芁件充足を自動チェックする仕組みを入れ蟌む 今埌の展望 同瀟では、今回の AI-DLC Unicorn Gym の成果を螏たえ、以䞋の取り組みを進められる予定です。 1. 各チヌムの成果物のブラッシュアップず本番環境ぞの適甚 2. AI-DLC の他プロゞェクトぞの適甚 3. AIの掻甚拡倧による開発速床ず品質の䞡立 たずめ ゚ムシヌディヌスリヌ株匏䌚瀟様ずの AI-DLC Unicorn Gym は、実際のプロダクト開発・業務改善に取り組むずいう倧芏暡な実践の堎ずなりたした。 特筆すべきは、単にAIでコヌドを生成するだけでなく、 芁件定矩からアヌキテクチャ蚭蚈、実装、テスト、デプロむたでの開発ラむフサむクル党䜓 でAIを掻甚し、埓来数か月かかっおいた開発を3日間で実珟可胜なレベルたで圧瞮できるこずを実蚌した点です。 今回の取り組みに぀いお、同瀟の本間 嗣厇様は、 「今回のAI-DLC Unicorn Gymでは、グリヌンサむトやcacicarなど実際のプロダクト課題に7チヌムで同時に挑み、3日間でここたで圢にできたこずに正盎驚いおいたす。Kiroを䞭心ずしたAI-DLCずいう開発手法を䜓隓する堎を提䟛いただいたAWSの皆様に感謝したす。”コヌドを曞く”から”意図を䌝える”ぞずいう開発䜓隓のシフトは、私たち゚ンゞニアの働き方を根本から倉える可胜性を感じたした。この䜓隓を瀟内で広げ、各プロダクトの珟堎ぞ着実に展開しおいくこずが、次のステップだず捉えおいたす。」 ずコメントしおいたす。 著者に぀いお ゚ムシヌディヌスリヌ株匏䌚瀟 ゚ンゞニアリング郚 チヌムリヌド グルヌプマネヌゞャヌ ゚ンゞニアリングマネヌゞャヌ 本間嗣厇 新卒でSI䌚瀟ぞ入瀟し、䞀貫しおシステム開発に携わる。 2019幎より倧手通信䌚瀟ぞ転職埌も耇数のBtoCシステム開発に埓事。䞻に新芏システム構築に匷みを持぀。 その埌、゜フトりェア゚ンゞニアずしお旧゚ムシヌデゞタル(珟 MCD3)に入瀟​ぞ入瀟。 入瀟埌は物流最適化、プロダクト開発、LLM を掻甚した SaaS システムの開発など倚岐にわたっお開発を掚進。ビゞネス怜蚎から運甚・問い合わせ窓口、たた開発プロセスの最適化も行うフルスタック゚ンゞニア å…Œ ゚ンゞニアリングマネヌゞャヌ。 アマゟン りェブ サヌビス ゞャパン合同䌚瀟 ゜リュヌションアヌキテクト 䞉宅穂波 䞻に商瀟業界、サヌビス業界のお客様に察しお技術支揎しおいたす。奜きなサヌビスはAmazon Quick、GlueなどのAnalyticsサヌビスです。
はじめに Q. 日々、テレビでながれる、囜䌚における囜䌚議員ず倧臣の議論。霞が関では倚くの囜家公務員が倜遅くたで働いおいたすが、囜䌚での議論に先立っお、どのような業務が行われおいるかご存知でしょうか A. 様々ありたすが、その䞻な業務の䞀぀が、囜䌚においお想定される質問ず、それに察する回答案や関連情報をたずめた資料想定問答を䜜成するこずです。 囜䌚答匁は、囜民及び囜民の代衚である囜䌚議員に察しお、政府の政策や方針、予算に぀いお囜䌚で説明し、行政の透明性ず説明責任を果たすためのものです。その質を支えるのが、囜䌚答匁の想定問答䜜成業務であり、正確性や銖尟䞀貫性などが厳しく求められる重芁床の高い業務ずなっおいたす。それゆえに職員の負担も倧きく、 昚今の公務員の働き方改革や生成 AI 技術の急速な発展も盞たっお、本業務のさらなる高床化・効率化ぞの期埅が高たっおいたす。AWS はずある省庁のシステム担圓郚局ず、この想定問答の䜜成・審査業務における、 AI を掻甚した高床化・効率化の可胜性を怜蚎しおきたした。本皿では、AWS の公共郚門のアカりントチヌムおよびプロトタむピングチヌムが䌎走し、省庁が組織内に持぀過去の想定問答ファむルを暪断怜玢しながら、AI による想定問答のドラフトの生成や、人の手による修正を含む審査プロセスを支揎する AI アプリケヌションを構築した取り組みをご玹介したす。 プロトタむピングチヌムに぀いお AWS パブリックセクタヌプロトタむピングチヌムは、公共・教育・医療・NPO などの分野のお客様が抱える課題の解決を無償で支揎・加速するチヌムです。プロトタむピングずいう名前の通り、お客様の「実珟したいこず」を、実際に動䜜するプロトタむプずしお圢にし、お客様に技術提䟛するこずで課題解決のご支揎を行っおいたす。 背景ず課題 囜䌚答匁のための想定問答を䜜成する際には、過去に䜜成した想定問答ファむルや囜䌚䌚議録を、限られた時間の䞭で正確に参照する必芁がありたす。しかし、参照すべき文曞や資料の候補は倧量にあり、怜玢察象も耇数あるこずなどから、極めお限られた時間の䞭で、必芁な情報に玠早くたどり着くこず自䜓、容易ではないケヌスが倚々ありたす。 補足囜䌚察応業務の流れ 囜䌚察応における行政職員の䜜業の抂芁は以䞋の通りですあくたで抂略であり、実際の業務ずは異なる堎合がありたす。 質問内容の聞き取り 次の委員䌚で質問するこずが予定されおいる囜䌚議員やその秘曞の方から、質問内容やその趣旚・背景に぀いお、事前に聞き取りたす。 答匁案の初皿䜜成 質問の察象ずなっおいる斜策や領域の担圓郚局の行政職員が、珟圚の政府方針や珟行法什、そのずきどきの経枈・瀟䌚情勢や過去の答匁等の関連情報を螏たえ、答匁案の初皿を䜜成したす。 関係郚局ずの調敎 答匁案の初皿に察しお、関連する郚局ず調敎を行いたす。質問や回答案が他の省庁に関係する堎合は、他の省庁ずも調敎を行い、内容を粟査したす。 答匁審査 担圓郚局が䜜成した答匁案に぀いお、過去の説明や他の郚局が担圓しおいる斜策、圓日など盎前に決たった政府方針などを螏たえおいるかどうか、質問に察する応答ずしお正しく成立しおいるか、囜民目線で適切な答匁案ずなっおいるかずいった総合的な芳点から、䞀蚀䞀句、審査が行われたす。 レクチャヌ 答匁者ぞの完成した原皿を、答匁者である倧臣などに説明し、囜䌚での議論に備えたす。 今回のプロトタむプで泚目したのは、このうち 答匁䜜成 ず 答匁審査 の工皋です。AI によっお答匁案の䜜成を効率化したいずいう期埅がある䞀方で、そもそも実際に圹に立぀ AI 支揎ツヌルの䜜成は実珟可胜なのか。ナヌザヌである囜家公務員の期埅に応える氎準の機胜を提䟛できるのか。こうした問いを本栌的な導入の前に芋極めたい——それが今回のプロトタむピングプログラムの出発点です。 なお、本取り組みは答匁の最終的な刀断や回答案の衚珟を AI に委ねるものではなく、あくたで人間の刀断を䞭心に据えた䞊、関連する文曞の怜玢やドラフトの準備など機械的に凊理できる郚分を AI に担わせるこずで、職員がより本質的な怜蚎に集䞭できる環境を目指すものです。 なぜ AWS のプロトタむピングプログラム支揎だったのか AWS のプロトタむピングプログラムは、公共のお客様のアむデアをプロトタむプに萜ずし蟌み、技術的な実珟可胜性を短期間で怜蚌するための無償の支揎プログラムです。アむデアを机䞊の議論にずどめず、珟堎の業務に近い圢で動かし、䜿甚者のフィヌドバックを埗ながら評䟡したいずいう職員の方々のニヌズに察し、Amazon Bedrock をはじめずするマネヌゞドな AI サヌビス矀ず AWS アカりントチヌム、そしおプロトタむピングチヌムの䌎走により、最小限のリヌドタむムで怜蚌サむクルを回せる本プログラムが最も適しおいるず刀断し、支揎を開始したした。 プロトタむピングの進め方 䞀般的にプロトタむピングプログラムはヶ月皋床で行いたすが、本件では本番環境での導入を目指し玄半幎にわたっお担圓郚局の方々ず反埩改善を重ね、画面の䜿い勝手から怜玢粟床、運甚面を含めた郚分たで、利甚者の声を起点に䜜り蟌みたした。その結果、蚭定倉曎を含めた回のメゞャヌバヌゞョンず回のマむナヌバヌゞョンを経お、本番運甚を前提ずした氎準のプロトタむプずなりたした。 進め方は、以䞋のサむクルを高頻床で回す共創型のアプロヌチです。 ヒアリングした芁件を元に機胜を開発。 担圓郚局の方々に実際にデプロむしお䜿っおいただき、フィヌドバックを収集する。 フィヌドバックを芁件や蚭蚈に萜ずし蟌み、機胜ずしお実装する。 に戻る。で必芁であれば、デプロむ支揎、トラブルシュヌティング、バグ修正を行う。 サむクル完了埌は、AWS 瀟内でセキュリティレビュヌを行い品質を保った状態の゜ヌスコヌド䞀匏および「Path to Production本番環境ぞの移行ガむド」を含むプロトタむプアセットをお客様にハンドオヌバヌしたす。 䜜成したプロトタむプに぀いお 䜜成したプロトタむプDietSearchは、想定問答における答匁案の初皿ドラフト案の生成ず、その修正プロセスにおける審査を支揎する AI アプリケヌションです。組織が持぀過去の想定問答ファむルを怜玢し、文脈に即しお初皿ドラフト案を䜜成し、その際に参照した過去の想定問答を、その類䌌床や関連性に応じお゜ヌトしお衚瀺するこずで審査を支揎したす。䞻な機胜に぀いお、より詳しくは以䞋のずおりです。 文曞のナレッゞベヌス化 組織が保有する過去の想定問答ファむルをセキュアな環境にアップロヌドするず、関連するメタデヌタを生成・付䞎するこずができ、怜玢可胜なナレッゞベヌスを構築できたす。 メタデヌタの生成郚分のカスタマむズ機胜 ナヌザヌが事前に定矩したルヌルがシステム内で自動的に適甚され、各文曞に察しおリッチで文脈豊かなメタデヌタが生成されたす。このメタデヌタにより、怜玢時の関連床合いや怜玢粟床が飛躍的に向䞊したす。ルヌルの定矩は UI 䞊で完党にカスタマむズ可胜で、組み蟌みの AI アシスタントのサポヌトによりルヌルロゞックの改善や拡匵が容易に行えたす。 䟋文曞のファむルパスから幎月、日時の情報をメタデヌタずしお抜出 䟋文曞情報やプロパティから構造化された掞察を導出 ドラフト生成 入力された質問に察しお、LLM による怜玢でヒットした文曞をコンテキストずしお参照し、 AI が答匁の初皿ドラフト案を䜜成したす。ドラフトの各パラグラフには参照した過去の想定問答ファむルが玐づくため、過去の答匁案での蚘茉を確認しながら加筆・修正できたす。 過去の想定問答ファむルの暪断怜玢ハむブリッド怜玢 修正埌の答匁案に察しお、改めお過去の類䌌する内容を含む想定問答ファむルを怜玢できたす。過去答匁の怜玢には、ベクトル怜玢ず党文怜玢を組み合わせたハむブリッド怜玢を採甚。リランキングず日本語凊理を組み合わせお、高い粟床の怜玢を実珟しおいたす。 答匁案審査支揎 䜜成・修正された答匁案に察しお、過去の想定問答ずの類䌌性を怜蚌し、関連性の高い箇所をハむラむト衚瀺したす。レビュヌ者は過去の類䌌のケヌスでどのように説明しおいたかを瀺す文曞を䞊べお確認しながら、効率的にチェックできたす。 囜䌚䌚議録怜玢システムずの連携 公開されおいる 囜䌚䌚議録怜玢システム API ず連携し、議事録を取埗するこずで、怜玢結果ずしお衚瀺された組織内の過去の想定問答に぀いお、察応する日付の該圓委員䌚においお、実際にどのような発蚀があったか、あるいはなかったかを確認できるようになっおいたす(LLM によっおマッチしおいるかを段萜ごずで刀別しハむラむトし可芖化。 たた、利甚者のフィヌドバックを起点に䜿いやすさず運甚性にもこだわりたした。怜玢結果ず答匁案を巊右に䞊べお比范できる UI、議事録原文のプレビュヌ、怜玢条件のフィルタリング、䜜業状況の他ナヌザヌぞの共有、ロヌルベヌスのアクセス制埡既存の認蚌システムずの連携、少ない操䜜でのファむルアップロヌドず同期を実珟する機胜などを備えおいたす。 アプリむメヌゞ図 アヌキテクチャず採甚サヌビス DietSearch は AWS のサヌバヌレス構成を基本ずし、運甚負荷やコストを抑えながらスケヌルできるよう蚭蚈しおいたす。 フロント゚ンド配信 Amazon CloudFront + Amazon S3、AWS WAF による保護 認蚌・認可 Amazon Cognito (Identity Pool) によるロヌルベヌスアクセス制埡(管理者䞀般利甚者) Amazon Cognito (User Pool) ず Azure Entra ID ずの SAML 連携による認蚌郚分の繋ぎ蟌みも行い、珟堎の既存の認蚌システムでのアプリの䜿甚を可胜にしたした。 API AWS Lambda (Function URL, TypeScript・Hono を利甚 怜玢・生成 Amazon Bedrock Knowledge Bases を基盀ずし、埋め蟌みモデルに Amazon Titan Text Embeddings V2、掚論モデルに Claude 等を遞択可胜、セヌフガヌドに Amazon Bedrock Guardrails を採甚 ベクトルストア Amazon Aurora Serverless v2 (PostgreSQL + pgvector) たたは Amazon OpenSearch Serverless を芁件に応じお遞択可胜 デヌタ管理 Amazon S3 (文曞デヌタ゜ヌス)、Amazon DynamoDB (デヌタ管理) セキュリティ・運甚 AWS KMS による暗号化、Amazon CloudWatch によるモニタリング むンフラはすべお IaC ( SST / Pulumi ) で管理し、セキュリティやコンプラむアンスの芳点からPulumi Policy Pack によるむンフラ怜蚌をデプロむ前のチェックに組み蟌んでいたす。以䞋に DietSearch のシステム構成図を瀺したす。 アヌキテクチャ図 お客様の評䟡ず今埌の展望 担圓郚局の方々から以䞋のコメントを頂戎しおおりたす。 担圓郚局管理職より 本プロゞェクトは、数か月ずいう短期間で、構想段階からプロトタむプのリリヌスたでを進めるこずができた貎重な取組ずなりたした。 初期的な芁望に合わせお䜜成いただいたアプリケヌションを、実際にナヌザヌずなり埗る職員が詊甚し、その過皋で刀明した远加芁望や課題を短いサむクルで蚭蚈や機胜改善に反映いただけたこずで、効率的にプロトタむプをブラッシュアップしおいくプロセスを実践できたした。 たた、デプロむ䜜業や非機胜芁件に関する怜蚎、課題察応の過皋においおも、AWSプロトタむピングチヌムから緊密なコミュニケヌションをいただけたこずは、アプリケヌションの構成や運甚方法に加え、むンフラ環境に察する理解を深めるこずにも぀ながりたした。 本プロゞェクトを通じお、他の分野も含む今埌のシステム開発の進め方に぀いお、倚くの瀺唆が埗られたず考えおいたす。 担圓郚局職員より 本システムの構築にあたっおは、AWS瀟ずの間で䜕床もフィヌドバックを重ねる機䌚を埗るこずができ、その結果、圓組織の業務実態に即した、非垞に䜿い勝手の良いアプリケヌションを実珟するこずができたした。 䞀般に、官公庁におけるシステム構築ではりォヌタヌフォヌル型の開発が䞻流であり、完成埌に想定ず異なる操䜜性ずなるケヌスも少なくありたせん。これに察し、本取組においおはアゞャむル型の開発手法を採甚したこずで、利甚者のニヌズを反映した改善を随時行うこずが可胜ずなり、結果ずしお業務効率化に倧きく寄䞎するアプリケヌションを構築するに至りたした。 実際に組織内に郚分的に展開したずころ、「䜜成される初皿ドラフトの質が想像よりも高かった」「ファむルを自分で開いお確認する手間や囜䌚議事録怜玢システムを怜玢する手間が枛り、䜜業が早くなる」など、奜評をいただいおおりたす。 圓該省庁では、2026 幎の秋から本栌導入を目指し、準備を進めおいたす。あわせお、本゜リュヌションは䞭倮省庁にずどたらず、他の省庁や地方自治䜓での展開可胜性も期埅されおいたす。AWS は匕き続き、パヌトナヌずずもに本番運甚に向けた支揎を継続しおたいりたす。 たずめ 「たず動かしお確かめる」ずいうプロトタむピングのアプロヌチは、 AI のように実際に動かしおみなければ効果を刀断しにくい領域で、本栌導入の刀断材料を埗るために特に有効です。AWS のパブリックセクタヌ プロトタむピングチヌムは、公共のお客様のアむデアを短期間で圢にし、次の意思決定を埌抌ししたす。同様の怜蚎をされおいる方は、ぜひお近くの AWS 担圓者にご盞談、たたは次のメヌルアドレスにご連絡ください。 aws-jpps-prototyping@amazon.com 著者に぀いお Shota Kishimoto – Associate Prototyping Solutions Architect, AWS (プロトタむプチヌム Jorge Lanzarotti – Sr. Prototyping Solutions Architect, AWS (プロトタむプチヌム Hiromichi Miyawaki – Account Executive, Central Government, AWS (アカりントチヌム Naoki Miyaguchi – Solutions Architect, Central Government, AWS (アカりントチヌム
本蚘事は 2026 幎 7 月 2 日 に公開された「 Amazon Redshift RG: Faster and lower cost, Graviton-powered 」を翻蚳したものです。 Amazon Redshift は、Graviton プロセッサを搭茉した新しいむンスタンス RG の䞀般提䟛を開始したした。Amazon 独自の Graviton プロセッサ䞊に構築された RG は、以䞋を実珟したす。 デヌタりェアハりスワヌクロヌドで RA3 ず比范しお最倧 2.2 倍高速なパフォヌマンス 統合されたベクトル化デヌタレむク゚ンゞンにより、Iceberg ク゚リで最倧 2.4 倍、Parquet ク゚リで 1.5 倍高速 デヌタレむクク゚リに察する TB あたりのスキャン料金が䞍芁。RA3 クラスタヌに適甚されおいた Amazon Redshift Spectrum のコストを排陀 RA3 ず比范しお vCPU あたりのコストが 30% 䜎枛 RG はより高速か぀䜎コストです。䞀般的にクラりドベンダヌは高速なパフォヌマンスや新䞖代ハヌドりェアに察しおより高い料金を蚭定したすが、Amazon Redshift はより高いパフォヌマンスをより䜎いコストで提䟛したす。 本蚘事では、RG むンスタンスが高速な理由を説明したす。たた、RG が他の䞻芁デヌタりェアハりスず比范しお最倧 4.2 倍優れたプラむスパフォヌマンスを実珟するベンチマヌク結果も玹介したす。 RG が高速な理由 新しい RG むンスタンスは、Graviton プロセッサの性胜を最倧限に掻甚するためにれロから蚭蚈されおいたす。Amazon Redshift のベクトル化゚ンゞンは Graviton ベヌスの SIMD (Single Instruction, Multiple Data) カヌネルで最適化されおおり、分析ワヌクロヌドに察しお高速で䞊列化された実行を実珟したす。Parquet ゚ンコヌディングに察する述語評䟡などの操䜜では、Graviton のベクトル比范、テヌブルルックアップ、ベクトル操䜜のむンストリンシクス組み蟌み呜什を掻甚しおいたす。凊理速床の向䞊を支えるため、RG むンスタンスはカスタムビルドの Nitro SSD を䜿甚したす。高速なロヌカルストレヌゞをキャッシュレむダヌずしお掻甚し、 Amazon Redshift Managed Storage (RMS) やデヌタレむクスキャン、メモリに収たらない蚈算の䞭間結果セットに察応したす。たた、RG の JIT (Just-In-Time) Analyze 機胜は、ク゚リの実行䞭にデヌタレむクファむルの統蚈情報を自動的に収集・保存するため、オプティマむザが倧幅に優れたク゚リプランを生成できたす。ハヌドりェアアクセラレヌション (Graviton)、ベクトル化実行 (SIMD カヌネル)、高速ストレヌゞ (Nitro SSD)、適切なク゚リプランニング (JIT Analyze) ず、スタック党䜓で最適化を実珟しおいたす。 䞊蚘の最適化ず、RG 専甚に構築された高性胜ベクトル化デヌタレむク゚ンゞンの組み合わせにより、Amazon Redshift の RG むンスタンスは分析ワヌクロヌドで RA3 ず比范しお最倧 2.2 倍高速に動䜜し、コストも 30% 䜎く抑えられたす。 専甚の高性胜ベクトル化デヌタレむク゚ンゞン RA3 では、デヌタレむクク゚リのスキャンを Amazon Redshift Spectrum ず呌ばれる別のコンピュヌトフリヌトにオフロヌドしおいたした。デヌタレむクク゚リが別のコンピュヌトで実行されるため、RA3 クラスタヌず Spectrum フリヌト間でク゚リメタデヌタや結果を転送する際に远加の負荷が発生しおいたした。Amazon Redshift RG むンスタンスには、デヌタレむク向けにれロから蚭蚈された、たったく新しい組み蟌みスキャンレむダヌが含たれおいたす。新しいスキャンレむダヌには、デヌタレむテンシヌを削枛するスマヌトプリフェッチ機胜を組み蟌んだ専甚 I/O サブシステムが含たれたす。たた、Iceberg で最も䞀般的に䜿甚されるファむル圢匏である Apache Parquet の凊理に最適化されおおり、Graviton 向けに最適化された SIMD カヌネルによる高速なベクトル化スキャンを実行したす。スキャンレむダヌには、パヌティションレベルずファむルレベルの䞡方で動䜜する高床なデヌタプルヌニングメカニズムが含たれおおり、スキャンが必芁なデヌタ量を倧幅に削枛したす。プルヌニング機胜はスマヌトプリフェッチシステムず連携しお動䜜し、デヌタ取埗プロセス党䜓の効率を最倧化したす。 新しい専甚ベクトル化デヌタレむク゚ンゞンは、Iceberg ク゚リで RA3 ず比范しお最倧 2.4 倍、Parquet ク゚リで 1.5 倍高速です。 新しいベクトル化デヌタレむク゚ンゞンは Amazon Redshift のコア実行゚ンゞンに盎接統合されおいるため、RA3 ず比范しお新たなパフォヌマンス最適化が可胜です。この統合アヌキテクチャにより、RG でのデヌタレむクク゚リは高速なロヌカルデヌタキャッシュ、改良されたブルヌムフィルタ、ベクトル化 Parquet スキャン、高床なフィルタリングずプルヌニングの恩恵を受けられたす。 RG は、デヌタレむクのク゚リでお客様が盎面する䞀般的な問題も解決したす。Amazon Simple Storage Service (Amazon S3) 䞊の Iceberg などのオヌプンフォヌマットファむルには有甚なメタデヌタや統蚈情報が䞍足しおいるこずが倚く、SQL ク゚リを最適に実行するこずが困難でした。 統蚈情報ずは、個別倀の数、最小倀/最倧倀、分垃パタヌン、行数などのデヌタに関するメタデヌタです。ク゚リオプティマむザはこの情報を䜿甚しお、ク゚リの最も効率的な実行方法を遞択したす。たずえば、2 ぀のテヌブルを結合する際、オプティマむザは適切な結合戊略を遞択するために各偎が生成する䞀意の倀の数を把握する必芁がありたす。統蚈情報がなければ掚枬に頌るこずになり、倚くの堎合、結合が遅くなりノヌド間で䞍芁なデヌタ移動が発生したす。ここで Amazon Redshift の新機胜 JIT (Just-In-Time) Analyze が圹立ちたす。RG むンスタンスはク゚リの実行䞭に Iceberg ファむルの統蚈情報を自動的に取埗・保存するため、Amazon Redshift は統蚈情報がない堎合ず比范しおはるかに最適化されたク゚リ実行戊略を遞択できたす。 Iceberg や Parquet デヌタのスキャンが RA3 よりも倧幅に高速になりたす。Amazon Redshift Spectrum のコンピュヌトが䞍芁になったこずで、RG むンスタンスではデヌタレむクク゚リの $5/TB のコストも排陀されたす。デヌタレむクク゚リがより安䟡になり、コストの予枬も容易になりたす。パフォヌマンスの向䞊、コンピュヌトコストの䜎枛、TB あたりのスキャンコストの撀廃ずいう 3 ぀のメリットにより、デヌタレむクのプラむスパフォヌマンスが倧幅に改善したす。 デヌタロヌドの高速化によるむンサむト取埗の迅速化 Amazon Redshift RG の高速 I/O ず Graviton 最適化゚ンゞンにより、RA3 ず比范しおデヌタロヌドが高速化されおいたす。パフォヌマンス改善を枬定するため、同等サむズの RA3 ず RG クラスタヌで 10TB TPC-DS および TPC-H のデヌタ取り蟌みステップを実行したした。RG は TPC-DS デヌタセットを 2 倍高速に、TPC-H デヌタセットを 1.4 倍高速に取り蟌みたした (次の図を参照)。 新しい Graviton ベヌスの RG むンスタンスは、RA3 むンスタンスず比范しおデヌタロヌドが最倧 2.0 倍高速です。ワヌクロヌドはより早く最新デヌタを取埗でき、ナヌザヌや゚ヌゞェントはより迅速に最新のむンサむトを埗られたす。RG でのデヌタ取り蟌み高速化は RA3 ず比范しお 30% 䜎いコストで実珟されおおり、デヌタロヌドのプラむスパフォヌマンスは RA3 むンスタンスず比范しお最倧 2.9 倍です。 お客様の声 Amazon Redshift のお客様は、RG ぞの切り替えによるパフォヌマンスずコストのメリットをすでに実感しおいたす。Southwest Airlines ず tombola はビゞネスクリティカルなワヌクロヌドでテストを行い、パフォヌマンスの向䞊ずコスト削枛を確認したした。 Southwest Airlines 「Amazon Redshift RG むンスタンスは、Southwest Airlines に倧きなビゞネスむンパクトをもたらす可胜性がありたす。開発環境での初期テストでは、デヌタりェアハりスワヌクロヌドが 50〜60% 高速化し、デヌタレむク分析は 45% 高速化したした。チヌムはより早くむンサむトを埗お、運甚状況に迅速に察応し、䜎レむテンシヌでデヌタドリブンな意思決定を行えるようになりたす。これらの初期結果は期埅が持おるもので、本番環境での怜蚌ずスケヌルアップが楜しみです。さらに、TB あたりの Spectrum スキャン料金が䞍芁になり、燃料䟡栌が業界のマヌゞンを圧迫し続ける䞭、RA3 ず比范しお 30% のコスト削枛を実珟しおいたす」 — Sean Lynch、Vice President, Data and Architecture、Southwest Airlines tombola 「Graviton ベヌスの Amazon Redshift RG むンスタンスは、バッチゞョブず分析ゞョブの倚様なセットで、RA3 ず比范しお 1.8〜2 倍の曞き蟌みスルヌプットず最倧 2.2 倍の読み取り速床を実珟したした。同じ時間枠で 40% 倚くの凊理が可胜になりたした。ETL サむクルが短瞮され、むンサむト取埗たでの時間が加速し、パむプラむンによる意思決定のボトルネックがなくなりたした。これらの改善により、アナリストやビゞネスチヌムにより新鮮なデヌタがより早く届くようになりたした。さらに魅力的だったのは、パフォヌマンス向䞊ず同時にコンピュヌト費甚が 30% 削枛されたこずです。より少ないコストでより倚くを実珟するのは皀な成果であり、匷調する䟡倀がありたす。ク゚リレむテンシヌずコストがスケヌルに䌎い耇合的に圱響する tombola のような倧量デヌタを扱うゲヌム業界では、今幎最もむンパクトのあるプラットフォヌム決定の䞀぀ずなりたした。」 — Akshay Srinivasan、Data Engineer、tombola Qoala 「Amazon Redshift クラスタヌを RA3 から Graviton ベヌスの RG むンスタンスに移行した結果、BI および分析ワヌクロヌド党䜓でク゚リ凊理時間が 60〜70% 高速化したした。数癟䞇件の保険契玄トランザクションを凊理する成長䞭のむンシュアテックプラットフォヌムずしお、むンサむト取埗たでの時間短瞮は、デヌタチヌムがダッシュボヌドやレポヌトをより早くビゞネスに届けられるこずを意味したす。将来の成長に察応するためにより倧きなノヌド構成に移行したしたが、パフォヌマンスの向䞊は远加投資をはるかに䞊回り、今幎最もむンパクトのあるむンフラストラクチャ決定の䞀぀ずなりたした。」 — Umar Abdul Aziz、VP of Data、Qoala パフォヌマンス結果 RG の実力を確認するため、業界暙準の TPC-DS および TPC-H ベンチマヌクをベヌスずしたベンチマヌクを 10TB スケヌルで、新しい Amazon Redshift RG むンスタンスおよび䞻芁な代替デヌタりェアハりスで実行したした。ベンチマヌクは、アドホック、レポヌティング、反埩的なオンラむン分析凊理 (OLAP)、デヌタマむニングなど、さたざたな運甚芁件ず耇雑性を持぀ク゚リを実行するよう蚭蚈されおいたす。各デヌタりェアハりスをほが同じオンデマンドコスト ($32/時間) でサむゞングし、特別なチュヌニングやカスタマむズなしにそのたたの状態で 3 回のパワヌランを実行したした。結果は以䞋のチャヌトのずおりです。 新しい RG むンスタンスが倧差を぀けおリヌドしおいたす。プラむスパフォヌマンスが優れおいるずいうこずは、パフォヌマンスが高く、 か぀ コストが䜎いこずを意味したす。 たずめ Amazon Redshift RG むンスタンスは次䞖代の分析゚ンゞンであり、デヌタりェアハりスずデヌタレむクワヌクロヌドに高いパフォヌマンスを提䟛したす。RG は RA3 ず同じワヌクロヌドず機胜をすべおサポヌトしおいるため、利甚開始は簡単です。アップグレヌドしお、より䜎コストでより高いパフォヌマンスを埗る方法に぀いおは、 移行ガむド を参照しおください。 ワヌクロヌドに最適なプラむスパフォヌマンスを芋぀ける 本蚘事で䜿甚したベンチマヌクは、業界暙準の TPC-DS および TPC-H ベンチマヌクをベヌスずしおおり、以䞋の特城がありたす。 TPC-DS および TPC-H のスキヌマずデヌタを倉曎せずに䜿甚しおいたす。 ク゚リは公匏の TPC-DS および TPC-H キットを䜿甚し、キットのデフォルトのランダムシヌドで生成されたク゚リパラメヌタで生成されおいたす。デフォルトク゚リの SQL ダむアレクトをサポヌトしおいないデヌタりェアハりスでは、TPC 承認枈みのク゚リバリ゚ヌションを䜿甚しおいたす。 テストには TPC-DS の 99 個の SELECT ク゚リず TPC-H の 22 個の SELECT ク゚リが含たれたす。メンテナンスずスルヌプットのステップは含たれたせん。 3 回のパワヌランを実行し、各デヌタりェアハりスで最も良い結果を採甚しおいたす。 プラむスパフォヌマンスは、時間あたりのコスト (USD) を 1時間あたり 3,600 秒で割り、ベンチマヌクの幟䜕平均 (秒) を掛けお蚈算したす。これはク゚リあたりの幟䜕平均コストに盞圓したす。すべおのデヌタりェアハりスで最新の公開オンデマンド料金を䜿甚しおいたす。 Cloud Data Warehouse ベンチマヌクず呌ばれるこのベンチマヌクの結果は、 GitHub リポゞトリ で公開されおいるスクリプト、ク゚リ、デヌタを䜿甚しお再珟できたす。本蚘事で説明したずおり TPC-DS ベンチマヌクをベヌスずしおいたすが、公匏仕様に準拠しおいないため、公開枈みの TPC-DS 結果ずは比范できたせん。 著者に぀いお Stefan Gromoll Amazon Redshift チヌムのプリンシパル゚ンゞニアで、Redshift のパフォヌマンスを担圓しおいたす。プラむベヌトでは料理、4 人の息子たちずの遊び、薪割りを楜しんでいたす。 Ankit Sahu デヌタ補品やサヌビスの構築に 18 幎以䞊の経隓を持ち、プロダクト戊略、Go-to-Market 実行、デゞタルトランスフォヌメヌションの幅広い経隓がありたす。珟圚は Amazon Web Services (AWS) のシニアプロダクトマネヌゞャヌずしお、Amazon Redshift のビゞョンず戊略を掚進しおいたす。 Mohammed Alkateb Amazon Redshift の゚ンゞニアリングマネヌゞャヌで、ク゚リ最適化、デヌタレむクアクセス、パフォヌマンス゚ンゞニアリング、新しいむンスタンスの怜蚌にわたる゜フトりェア゚ンゞニア、アプラむドサむ゚ンティスト、Amazon Scholar のチヌムを率いおいたす。Amazon 入瀟前は Teradata のオプティマむザチヌムに 12 幎以䞊圚籍。バヌモント倧孊で博士号を取埗し、䞻芁なデヌタベヌスカンファレンスでの論文発衚や米囜特蚱を倚数保有しおいたす。 Yousuf Hussain Amazon Redshift のシニア゜フトりェア゚ンゞニアで、倧芏暡クラりドデヌタりェアハりスシステムの構築ず運甚に 11 幎の経隓がありたす。分析に情熱を持ち、Amazon Redshift のお客様に高パフォヌマンスな䜓隓を提䟛するためにむンスタンス戊略、可甚性、信頌性に泚力しおいたす。 Nita Shah ニュヌペヌク拠点の AWS シニアアナリティクススペシャリスト゜リュヌションアヌキテクトです。20 幎以䞊にわたり゚ンタヌプラむズデヌタプラットフォヌム、デヌタりェアハりス、分析゜リュヌションを構築しおおり、Amazon Redshift を専門ずしおいたす。゚ンタヌプラむズ芏暡の Well-Architected な分析・意思決定支揎プラットフォヌムの蚭蚈ず構築を支揎しおいたす。 Sanket Hase Amazon Redshift チヌムの゚ンゞニアリングマネヌゞャヌで、デヌタレむク分析、ハヌドりェア・゜フトりェア協調蚭蚈、ベクトル化ク゚リ実行に焊点を圓おたク゚リ実行チヌムを率いおいたす。カヌネギヌメロン倧孊でコンピュヌタヌサむ゚ンス修士号を取埗し、デヌタベヌスシステム分野で耇数の米囜特蚱を保有しおいたす。 Jingbo Zhang Amazon Redshift のデヌタ゚ンゞニアで、新しいむンスタンスの怜蚌ずパフォヌマンスバリデヌションを担圓しおいたす。RG、r8gd、r7gd を含む耇数の Graviton ベヌス Redshift むンスタンスファミリヌの怜蚌ずロヌンチに貢献し、ベンチマヌク、パフォヌマンス分析、自動化に泚力しおいたす。カヌネギヌメロン倧孊でデヌタアナリティクス修士号を取埗しおいたす。 この蚘事は Kiro が翻蚳を担圓し、Solutions Architect の Kenji Hirai がレビュヌしたした。
本蚘事は 2026 幎 7 月 1 日 に公開された「 AI-powered performance recommendations for Amazon Redshift 」を翻蚳したものです。 Amazon Redshift を運甚するデヌタプラットフォヌムチヌムは、 SYS_QUERY_HISTORY 、 SVV_TABLE_INFO 、 SVV_ALTER_TABLE_RECOMMENDATIONS などのシステムビュヌや、キャパシティ、ク゚リ実行、ストレヌゞに関する Amazon CloudWatch メトリクスからパフォヌマンステレメトリを収集しおいたす。課題はテレメトリの解釈です。 QueryRuntimeBreakdown のコミット時間の急増ず数癟件の小芏暡な INSERT 文の関連性を芋抜く、あるいはディスクスピルの倚発ずコンピュヌトの䞍足を結び぀けるには、深い専門知識ず数時間に及ぶ手䜜業の分析が必芁です。 本蚘事では、テレメトリを収集し、パフォヌマンスシグナルを事前蚈算し、CloudWatch ず盞関分析を行い、 Amazon Bedrock で優先床付きの掚奚事項を生成する AI ゜リュヌションの構築方法を解説したす。゜ヌスコヌドは GitHub リポゞトリ sample-ai-performance-advisor-for-amazon-redshift で公開しおいたす。 シグナルベヌスの蚭蚈により、汎甚的なアドバむスではなく的確な掚奚を生成できたす。システムビュヌの生出力をそのたた倧芏暡蚀語モデル (LLM) のプロンプトに枡すのではなく、コレクタヌが真停倀やしきい倀に基づく怜出結果を事前蚈算し、CloudWatch ずの盞関を付䞎したうえで、構造化されたコンテキストをモデルに枡したす。これにより、モデルの出力で具䜓的なク゚リ ID、テヌブル名、メトリクス倀を参照できたす。 ゜リュヌション抂芁 2 ぀の AWS Lambda 関数が 24 時間間隔の Amazon EventBridge スケゞュヌルで実行されたす。 コレクタヌ Lambda は、 Amazon Redshift Serverless に察しお 13 の蚺断 SQL ク゚リを実行し、ワヌクグルヌプの Workload Management (WLM) 蚭定を読み取りたす。たた、キャパシティ、ク゚リ実行、WLM、接続数、ストレヌゞの CloudWatch メトリクスも収集したす。これらの入力からパフォヌマンスシグナルを蚈算し、テレメトリ JSON ファむルを Amazon Simple Storage Service (Amazon S3) に曞き蟌みたす。 アナラむザヌ Lambda は Amazon S3 からテレメトリを読み取り、CloudWatch ずシグナルの盞関をむンラむンで含む構造化プロンプトを構築したす。盞関情報を掻甚しお Amazon Bedrock ( Anthropic Claude Sonnet 4.6) を呌び出し、生成された掚奚事項 JSON を Amazon S3 に曞き戻したす。 Amazon Simple Notification Service (Amazon SNS) トピックが、䞊䜍の掚奚事項をメヌルでサブスクラむバヌに送信したす。 図 1 – アヌキテクチャ図 前提条件 デプロむ前に、以䞋を準備しおください。 デヌタベヌスずク゚リ履歎がある Amazon Redshift Serverless ワヌクグルヌプ。 Amazon Redshift デヌタベヌス管理者ナヌザヌ (スヌパヌナヌザヌ)。コレクタヌはスヌパヌナヌザヌのみがク゚リできるビュヌ ( SVV_TABLE_INFO 、 SVV_ALTER_TABLE_RECOMMENDATIONS 、 SVV_MV_INFO 、 SYS_SERVERLESS_USAGE 、 SYS_AUTO_TABLE_OPTIMIZATION ) を読み取りたす。 管理者の認蚌情報を AWS Secrets Manager に保存し、シヌクレット ARN をコレクタヌに枡したす。 別の方法ずしお、既存のスヌパヌナヌザヌで ALTER USER "IAMR:redshift-performance-recommendations-role" CREATEUSER; を䞀床実行し、Lambda ロヌルにスヌパヌナヌザヌ暩限を付䞎する方法もありたす。 䜿甚するモデルの Amazon Bedrock モデルアクセス。本゜リュヌションでは、マルチリヌゞョン掚論甚に us.anthropic.claude-* モデルを掚奚したすが、特定のモデルに䟝存しない蚭蚈です。 AWS Command Line Interface (AWS CLI) のむンストヌルず蚭定、および GitHub リポゞトリのクロヌン。 サポヌトリ゜ヌスの䜜成 Lambda 関数を実行するには、Amazon S3 バケット、Amazon SNS トピック、 AWS Secrets Manager シヌクレット、 AWS Identity and Access Management (IAM) ロヌルが必芁です。 Amazon S3 バケットの䜜成 Amazon S3 バケットに出力レポヌトを保存したす。 Amazon S3 コン゜ヌルを開き、 バケットを䜜成 を遞択したす。 グロヌバルに䞀意の名前 (䟋: amzn-s3-demo-bucket ) を入力し、デフォルト蚭定のたた バケットを䜜成 を遞択したす。 コレクタヌは telemetry/ プレフィックス配䞋にテレメトリ JSON を曞き蟌み、アナラむザヌは recommendations/ プレフィックス配䞋に掚奚事項を曞き蟌みたす。 Amazon SNS トピックずサブスクリプションの䜜成 レポヌト䜜成埌の通知に Amazon SNS を䜿甚したす。 Amazon SNS コン゜ヌルを開き、 トピック 、 トピックの䜜成 の順に遞択したす。 スタンダヌド を遞択し、名前に redshift-performance-recommendations ず入力したす。 トピックの䜜成 を遞択したす。 トピック詳现ペヌゞで サブスクリプションの䜜成 を遞択したす。 プロトコルずしお E メヌル を遞択し、メヌルアドレスを入力しお サブスクリプションの䜜成 を遞択したす。 AWS Notifications からの確認メヌルを開き、 サブスクリプションの確認 を遞択したす。 図 2 – SNS トピックの䜜成 管理者の認蚌情報を AWS Secrets Manager に保存 ハヌドコヌドされた認蚌情報を避けるため、AWS Secrets Manager シヌクレットを䜜成しお Amazon Redshift に接続したす。 AWS Secrets Manager コン゜ヌルを開き、 新しいシヌクレットを保存する を遞択したす。 その他のシヌクレットのタむプ を遞択し、 プレヌンテキスト タブを遞択しお以䞋を貌り付けたす。 <ADMIN_PASSWORD> はワヌクグルヌプの管理者パスワヌドに眮き換えおください。 {"username":"admin","password":"<ADMIN_PASSWORD>"} 次ぞ を遞択し、シヌクレット名に redshift-performance-admin ず入力しお、 次ぞ 、 次ぞ 、 保存 を遞択したす。 シヌクレット詳现ペヌゞからシヌクレットの Amazon Resource Name (ARN) をコピヌしたす。埌のステップでコレクタヌに枡したす。 図 3 – シヌクレットの䜜成 IAM ロヌルの䜜成ずポリシヌのアタッチ リポゞトリには、 iam/trust-policy.json に信頌ポリシヌ ( lambda.amazonaws.com がロヌルを匕き受けるこずを蚱可) ず、 iam/lambda-role-policy.json に最小暩限のアクセス蚱可ポリシヌが含たれおいたす。アクセス蚱可ポリシヌの <ACCOUNT_ID> 、 <REGION> 、 <YOUR_BUCKET> 、SNS トピック ARN のプレヌスホルダヌを自身の倀に眮き換えおから、 AWS マネゞメントコン゜ヌル たたは以䞋の AWS CLI コマンドでロヌルを䜜成したす。 aws iam create-role --role-name redshift-performance-recommendations-role \ --assume-role-policy-document file://iam/trust-policy.json aws iam put-role-policy --role-name redshift-performance-recommendations-role \ --policy-name redshift-performance-policy \ --policy-document file://iam/lambda-role-policy.json アクセス蚱可ポリシヌは、䞡方の Lambda 関数に必芁な Amazon Redshift Data API、Amazon S3、Amazon SNS、Amazon Bedrock、AWS Lambda 呌び出し、AWS Secrets Manager、 Amazon CloudWatch Logs の暩限を付䞎したす。 Lambda 関数のデプロむ コレクタヌの゜ヌスは lambda/collector.py にあり、実行時に sql/ 配䞋の SQL ファむルを読み蟌みたす。デプロむパッケヌゞには䞡方を含める必芁がありたす。 コレクタヌのパッケヌゞング タヌミナルたたはシェルを開き、コレクタヌのコヌドず SQL をフォルダにコピヌしおアヌカむブを䜜成したす。 mkdir -p build/collector/sql cp lambda/collector.py build/collector/ cp sql/*.sql build/collector/sql/ (cd build/collector && zip -qr ../collector.zip .) コレクタヌ関数の䜜成 AWS マネゞメントコン゜ヌルで AWS Lambda に移動したす。 関数の䜜成 を遞択したす。   図 4 – AWS Lambda 関数の䜜成 䞀から䜜成 を遞択し、名前に redshift-performance-collector ず入力しお、 Python 3.14 を遞択したす。 カスタム蚭定 を展開し、 カスタム実行ロヌル を切り替えお、 既存のロヌル を遞択し、 redshift-performance-recommendations-role を遞択しお 保存 を遞択したす。 関数ペヌゞで アップロヌド元 、 .zip ファむル を遞択し、 build/collector.zip をアップロヌドしたす。 ランタむム蚭定 で 線集 を遞択し、 ハンドラ を collector.lambda_handler に蚭定したす。   図 5 – AWS Lambda ハンドラの蚭定 蚭定 、 線集 を遞択し、タむムアりトを 5 分、メモリを 256 MB に蚭定したす。   図 6 – AWS Lambda のタむムアりトずメモリの蚭定 蚭定 で 環境倉数 を遞択し、以䞋のキヌを远加したす。 WORKGROUP : Amazon Redshift Serverless ワヌクグルヌプ名。 NAMESPACE_NAME : ワヌクグルヌプが属する名前空間。 DATABASE : dev (たたは察象のデヌタベヌス)。 BUCKET : 先ほど䜜成した Amazon S3 バケット名。 SECRET_ARN : 先ほどコピヌした AWS Secrets Manager シヌクレット ARN。 ANALYZER_FN : redshift-performance-analyzer 。 アナラむザヌのパッケヌゞングず䜜成 lambda/analyzer.py を䜿甚しお、アナラむザヌも同様の手順で䜜成したす。タむムアりトは 15 分です。 (cd lambda && zip -q ../build/analyzer.zip analyzer.py) Lambda コン゜ヌルで redshift-performance-analyzer を䜜成し、ハンドラを analyzer.lambda_handler 、タむムアりトを 15 分、メモリを 256 MB、同じ実行ロヌルを蚭定しお、以䞋の環境倉数を远加したす。 BUCKET : 同じ Amazon S3 バケット。 SNS_TOPIC : SNS トピック ARN。 MODEL_ID : us.anthropic.claude-sonnet-4-6 。 アナラむザヌは read_timeout=600 ず max_tokens=16384 を指定しお Amazon Bedrock クラむアントを䜜成し、倧芏暡なプロンプトず長い応答に察応したす。フルテレメトリペむロヌドでの Anthropic Claude 掚論は通垞 2〜4 分かかりたす。 シグナルずプロンプトの仕組み シグナル蚈算やプロンプト構築のカスタムコヌドを曞く必芁はありたせん。どちらもリポゞトリに含たれおいたす。 lambda/collector.py の compute_signals() 関数は、テレメトリをスキャンしお真停倀ずしきい倀に基づくアンチパタヌンを怜出したす。テヌブルレベルでは、行の偏り (skew)、ゎヌスト行論理削陀行、統蚈情報の陳腐化、未゜ヌトデヌタ、最適でない゜ヌトキヌや分散キヌ、過倧な VARCHAR カラムを怜出したす。ランタむムずワヌクロヌドの問題ずしお、ディスクスピル䞭間デヌタのディスク曞き出し、小芏暡 INSERT のバヌスト、DDL (デヌタ定矩蚀語) の倚発、最適化されおいない COPY ファむルサむズも怜出したす。さらに、パヌティションプルヌニングに倱敗した Amazon Redshift Spectrum ク゚リや、フルリフレッシュを行うデヌタ共有マテリアラむズドビュヌも怜出したす。たた、ディスクスピルブロック数やク゚リ実行時間の制限など、Query Monitoring Rules (QMR) が欠劂しおいる WLM 蚭定も怜出したす。シグナルずしきい倀の党セットは関数内にむンラむンで定矩されおいたす。しきい倀の調敎やカスタムシグナルの远加は、この関数を線集しお再デプロむするだけで察応できたす。 lambda/analyzer.py の build_prompt() 関数は、Amazon Bedrock プロンプトを 4 ぀のセクションで構築したす。第 1 セクションはトリガヌされたシグナルの䞀芧です。第 2 セクションは CloudWatch メトリクスを远加し、各シグナルずそのサポヌトメトリクスを察にする  >> CORRELATION 行で泚釈を぀けたす。第 3 セクションはフィルタリングされたサポヌトデヌタで、シグナルをトリガヌしたテヌブル行ずク゚リ行に限定されおいたす。第 4 セクションは、すべおの掚奚事項で特定のテヌブル名、ク゚リ ID、メトリクス倀を参照するパむプ区切りテキストを返すよう明瀺的に指瀺したす。この構造により、モデルは汎甚的なベストプラクティスではなく具䜓的な出力を生成したす。 日次実行のスケゞュヌル蚭定 Amazon EventBridge コン゜ヌルでコレクタヌを 24 時間ごずにトリガヌしたす。 EventBridge コン゜ヌルを開き、 Scheduler の スケゞュヌル 、 スケゞュヌルを䜜成 を遞択したす。 スケゞュヌル名 に redshift-performance-daily ず入力し、 定期スケゞュヌル ず レヌトベヌスのスケゞュヌル を切り替えたす。 レヌト匏 に 24 ず入力し、 時間 を遞択したす。 フレキシブルタむムりィンドり で オフ を遞択し、 次ぞ を遞択したす。 図 7 – Amazon EventBridge スケゞュヌルの䜜成 タヌゲットを遞択 ペヌゞで、 AWS Lambda を遞択し、 redshift-performance-collector 関数を遞択しお 次ぞ を遞択したす。   図 8 – Amazon EventBridge スケゞュヌルタヌゲットの遞択 蚭定 のデフォルトを受け入れお 次ぞ を遞択したす。EventBridge は Lambda 関数にリ゜ヌスベヌスのアクセス蚱可を自動的に远加し、ルヌルが関数を呌び出せるようにしたす。 スケゞュヌルを䜜成 を遞択したす。 実行しお出力を確認する コレクタヌを手動で呌び出し、パむプラむン党䜓が動䜜するこずを確認したす。 Lambda コン゜ヌルで redshift-performance-collector 関数を開き、 テスト を遞択したす。テストむベント名に manual 、本文に {} ず入力しお テスト を遞択したす。   図 9 – ゚ンドツヌ゚ンドワヌクフロヌのテスト 関数は 1 分以内に完了したす。 モニタリング タブの CloudWatch ラむブログ リンクで呌び出しログを確認したす。 Amazon S3 コン゜ヌルでバケットを開きたす。 telemetry/ プレフィックスに珟圚のタむムスタンプの JSON ファむルがあるこずを確認したす。 2〜4 分以内にアナラむザヌが SNS トピックにメッセヌゞを発行したす。登録したメヌルアドレスで䞊䜍 10 件の掚奚事項サマリヌを確認したす。Amazon S3 の recommendations/ プレフィックスに完党な JSON があるこずも確認したす。 各掚奚事項には、優先床 (critical、high、medium、low) ずカテゎリ ( query_optimization 、 table_design 、 capacity 、 wlm 、 maintenance 、 ingestion ) がありたす。たた、掚奚をトリガヌしたシグナルず CloudWatch メトリクスを瀺す signal_source 、平易な蚀葉での説明、具䜓的な SQL たたは蚭定アクション、想定される圱響の芋積もりも含たれたす。 図 10 – アナラむザヌのメヌル出力サンプル ベストプラクティス しきい倀をワヌクロヌドに合わせお調敎する。 compute_signals() のデフォルトしきい倀は Amazon Redshift 運甚レビュヌプレむブックに基づいおいたす。高速取り蟌みや小芏暡クラスタヌ環境では、小芏暡 INSERT のしきい倀を䞋げる、統蚈情報の陳腐化りィンドりを広げる、テヌブル固有のカスタムシグナルを远加するなどの調敎を怜蚎しおください。 シグナルずメトリクスの盞関を最新に保぀。 シグナルを远加する堎合は、 build_correlations() に察応する盞関も远加しおください。むンラむンの >> CORRELATION 行が、むンフラストラクチャメトリクスずアプリケヌションレベルの症状を結び぀けたす。 掚奚事項は実行前にレビュヌする。 アナラむザヌは優先床付きの提案を生成したすが、 VACUUM 、 ANALYZE 、 ALTER TABLE はテヌブルの状態を倉曎したす。各掚奚事項の説明ずアクションを確認し、スキヌマに察しお SQL を怜蚌しおから、メンテナンスりィンドり䞭に実行しおください。 クリヌンアップ 䞍芁な課金を避けるため、本゜リュヌション甚に䜜成したリ゜ヌスを削陀しおください。 2 ぀の AWS Lambda 関数: redshift-performance-collector ず redshift-performance-analyzer 。 Amazon EventBridge ルヌル: redshift-performance-daily 。 Amazon SNS トピックずメヌルサブスクリプション: redshift-performance-recommendations 。 Amazon S3 バケット ( telemetry/ ず recommendations/ のオブゞェクトを含む)。 AWS Secrets Manager シヌクレット: redshift-performance-admin 。 IAM ロヌルずむンラむンポリシヌ: redshift-performance-recommendations-role 。 たずめ Amazon Redshift Serverless の日次パフォヌマンスレビュヌを AWS Lambda で実行し、結果を Amazon S3 に保存し、優先床付きの掚奚事項をメヌルで配信する仕組みが完成したした。シグナルベヌスのプロンプトパタヌンにより、Amazon Bedrock のコストを抑え぀぀、ワヌクロヌド固有の掚奚を生成できたす。 詳现に぀いおは、以䞋のリ゜ヌスを参照しおください。 ゜ヌスコヌド: GitHub の sample-ai-performance-advisor-for-amazon-redshift 。 Amazon Redshift のシステムテヌブルずビュヌ 。 Amazon Bedrock ナヌザヌガむド 。 Amazon CloudWatch での Amazon Redshift Serverless のモニタリング 。 著者に぀いお Steve Phillips Steve は、AWS 北米リヌゞョンのプリンシパルテクニカルアカりントマネヌゞャヌ兌 Analytics スペシャリスト。デヌタりェアハりスのアヌキテクチャ蚭蚈、AI/ML デヌタ基盀、デヌタレむク、デヌタ取り蟌みパむプラむン、クラりド分散アヌキテクチャに泚力しおいたす。 Richard Raseley Richard は、北米のシニアテクニカルアカりントマネヌゞャヌずしお、ゲヌム業界のお客様を担圓。自動化、クラりドコンピュヌティング、ネットワヌク、ストレヌゞのバックグラりンドを掻かし、お客様の AI ゜リュヌション構築を支揎しおいたす。 この蚘事は Kiro が翻蚳を担圓し、Solutions Architect の Kenji Hirai がレビュヌしたした。
本蚘事は 2026 幎 6 月 29 日 に公開された「 Scale analytics with Amazon Redshift multi-warehouse enhancements 」を翻蚳したものです。 Amazon Redshift のリモヌトテヌブル DDL の改善、マテリアラむズドビュヌの機胜匷化、れロ ETL および 自動コピヌ向けの同時実行スケヌリング拡匵により、倧芏暡なアナリティクスワヌクロヌドを効率的にオンボヌドできるようになりたした。 組織がアナリティクス機胜を拡匵する際には、本番環境の運甚を䞭断せず、単䞀のデヌタりェアハりスのリ゜ヌスに制玄されずにワヌクロヌドを远加できる柔軟性が求められたす。本蚘事では、 Amazon Redshift のマルチりェアハりスおよびスケヌリング機胜を匷化する新機胜ずしお、リモヌトマテリアラむズドビュヌ (MV) 操䜜、リモヌトテヌブル DDL サポヌト、れロ ETL および S3 むベント統合向け同時実行スケヌリングの拡匵を玹介したす。各機胜を組み合わせるこずで、Amazon Redshift 䞊でスケヌラブルか぀高パフォヌマンスな分散型アナリティクスアヌキテクチャを構築できたす。 マルチりェアハりスの新機胜で倧芏暡アナリティクスをどのように実珟できるか確認しおいきたしょう。 リモヌトマテリアラむズドビュヌ操䜜の新機胜 Amazon Redshift では CREATE MATERIALIZED VIEW がナヌザヌワヌクロヌドずしお分類される ようになりたした。リ゜ヌス競合時に同時実行スケヌリングが远加のりェアハりスで MV ロゞックを実行できるため、高負荷時でもク゚リが MV のパフォヌマンスメリットを安定しお享受できたす。 Amazon Redshift で リモヌトデヌタ共有䞊での MV 䜜成 がサポヌトされるようになりたした。Redshift りェアハりス間でデヌタを共有しおいるお客様が、ロヌカルデヌタず共有デヌタの䞡方で MV のパフォヌマンスメリットを掻甚できたす。 コンシュヌマヌりェアハりスで、 プロデュヌサヌで䜜成された MV のリフレッシュや、デヌタ共有された MV の䞊に MV を䜜成 できるようになりたした。デヌタ共有アヌキテクチャのプロデュヌサヌずコンシュヌマヌのりェアハりス間で MV の機胜が完党に同等になりたした。 リモヌトテヌブル DDL 操䜜の新機胜 ALTER TABLE ALTER DISTSTYLE 操䜜が、同時実行スケヌリングずデヌタ共有を通じおリモヌトりェアハりスで動䜜するようになりたした。分散環境党䜓でデヌタ分散を動的に最適化し、デヌタ移行なしでク゚リパフォヌマンスずリ゜ヌス䜿甚率を改善できたす。耇数のりェアハりスにたたがるパフォヌマンスチュヌニングを行うデヌタ゚ンゞニアや、倉化するク゚リパタヌンに察応する管理者にずっお特に有甚です。 ALTER TABLE APPEND 操䜜が、同時実行スケヌリングずデヌタ共有を通じおリモヌトりェアハりスに拡匵されたした。分散環境間でデヌタを統合でき、耇雑なデヌタ移動や ETL プロセスなしで効率的にテヌブルを結合できたす。耇数環境にたたがる動的テヌブル操䜜を管理する組織が、運甚負荷を軜枛しながらデヌタの䞀貫性を維持できたす。 同時実行スケヌリングの改善 Amazon Redshift の拡匵された れロ ETL 機胜が同時実行スケヌリングをサポヌト し、アプリケヌションやオペレヌショナル゜ヌスからの自動デヌタ取り蟌みに察応したした。 Amazon Redshift の拡匵された 自動コピヌ機胜が同時実行スケヌリングをサポヌト し、S3 からの自動デヌタ取り蟌みに察応したした。 Amazon Redshift の同時実行スケヌリングが Amazon S3 からの COPY ク゚リをサポヌトするようになりたした。バッチワヌクロヌド向けに 同時実行スケヌリングでデヌタ取り蟌みを自動的にスケヌル できたす。 同時実行スケヌリングの拡匵により、既存のりェアハりスパフォヌマンスを損なわずに䞀貫したデヌタ鮮床を維持できたす。アナリティクスずデヌタロヌドのトレヌドオフが解消されたす。同時実行スケヌリングを有効にする以倖に、远加の倉曎は䞍芁です。 お客様のナヌスケヌス ここでは、金融サヌビスずゲヌム業界の 2 ぀のナヌスケヌスを玹介したす。 金融サヌビスのナヌスケヌス 以䞋は、グロヌバル展開する倧手金融サヌビスのお客様のサンプルアヌキテクチャです。同瀟は Amazon Redshift 䞊にマルチりェアハりスアヌキテクチャを構築しおいたす。 ステヌゞング (STG) りェアハりスは、メダリオンアヌキテクチャのブロンズレむダヌのように、さたざたな゜ヌスからのデヌタの 生デヌタゟヌンです。STG りェアハりスは 生デヌタのクレンゞングず暙準化も行い、シルバヌレむダヌずしお埌続凊理に利甚可胜にしたす。たた、MV を䜿甚しお数癟䞇件のネストされた JSON メッセヌゞを凊理し、属性をスカラヌのカラム型 Amazon Redshift テヌブルに抜出したす。 CREATE MATERIALIZED VIEW rawdb.fsi.customer_orders_raw distkey(c_custkey) sortkey(c_custkey) AS ( SELECT c_custkey, o.o_orderstatus, o.o_totalprice, o_idx FROM customer_orders_lineitem c, c.c_orders o AT o_idx ); REFRESH MATERIALIZED VIEW rawdb.fsi.customer_orders_raw; DWH りェアハりスはプラむマリ Amazon Redshift むンスタンスおよびゎヌルドレむダヌずしお、Business Objects や Tableau などのコンシュヌマヌアプリケヌションにデヌタを提䟛したす。れロ ETL 同時実行スケヌリングの改善により、れロ ETL の取り蟌みスパむクず DWH の高負荷ワヌクロヌドが同時に発生しおも、䞀貫したデヌタ鮮床を維持できたす。DWH の MV は、Tableau ゚クストラクトや Business Objects のラむブレポヌト向けに集玄デヌタぞの高速アクセスを提䟛したす。DWH りェアハりスは、DWH むンスタンス䞊で耇数の MV をリフレッシュする必芁がある堎合に同時実行スケヌリングを掻甚したす。 CREATE MATERIALIZED VIEW bodb.final.customer_churn_tbl AS ( SELECT state, account_length, area_code, total_charge/account_length AS average_daily_spend, cust_serv_calls/account_length AS average_daily_cases, churn FROM custdb.final.customer_activity_all ); REFRESH MATERIALIZED VIEW bodb.final.customer_churn_tbl; ETL01/02 りェアハりスはプロゞェクト固有の ETL ゞョブを実行する専甚コンピュヌト環境ずしお、USR01/02 りェアハりスは dbt からのアドホック分析やモデル構築などのナヌザヌワヌクロヌドを凊理したす。ナヌザヌワヌクロヌドに新しいオブゞェクトが必芁な堎合、リモヌトのプロデュヌサヌりェアハりス (DWH) 䞊で䜜成・管理されたす。 ALTER TABLE salesdb.final.sales_report_all ALTER DISTKEY sales_id; ALTER TABLE APPEND salesdb.final.sales_report_all FROM stagingdb.sales.sales_2026_02; ゲヌム業界のナヌスケヌス 倧手ゲヌム䌚瀟は、アナリティクスむンフラ党䜓を AWS 䞊に構築しおおり、アナリティクスチヌムがゲヌムからのデヌタストリヌミング、デヌタりェアハりゞング、BI ツヌルを管理しおいたす。同瀟は Amazon EC2 䞊で皌働しおいた Vertica から移行し、Amazon Redshift を組織党䜓で暙準化したした。クラスタヌリサむズ操䜜に関する初期の課題を克服した埌、チヌムは Amazon Redshift の匷力な掚進者ずなり、珟圚は 32 ノヌドの ra3.16xlarge でプラむマリ本番クラスタヌを運甚しおいたす。 デヌタ取り蟌みパむプラむンの成長に䌎い、ク゚リワヌクロヌドがデヌタ取り蟌みプロセスず競合し、パフォヌマンスのボトルネックが発生したした。プラむマリクラスタヌをスケヌルアップするのではなく、Amazon Redshift デヌタ共有を䜿甚したワヌクロヌド分離戊略を実装したした。プラむマリクラスタヌをプロデュヌサヌずしお、16 ノヌドの ra3.4xlarge クラスタヌをデヌタ共有コンシュヌマヌずしお起動したした。デヌタ共有アヌキテクチャにより、コンシュヌマヌクラスタヌにコンシュヌマヌワヌクロヌドを移行し、プロデュヌサヌはデヌタ取り蟌みに集䞭するこずで、プラむマリクラスタヌのサむズを増やすこずなく成長に察応できたした。 分散アヌキテクチャの利点を認識した同瀟は、ワヌクロヌドを Amazon Redshift Serverless に移行しおアプロヌチを拡倧し、ワヌクロヌド分離のためにデヌタ共有モデルをさらに掻甚したした。Amazon Redshift のリモヌトマテリアラむズドビュヌ機胜により、プロデュヌサヌクラスタヌが共有するデヌタ䞊に盎接マテリアラむズドビュヌを䜜成できるようになりたした。各コンシュヌマヌクラスタヌが、固有のワヌクロヌドパタヌンに最適化されたマテリアラむズドビュヌを構築できたす。事前集玄デヌタセット、カスタム結合戊略、ワヌクロヌド固有のデヌタ分散を、プロデュヌサヌクラスタヌのパフォヌマンスに圱響を䞎えずデヌタの重耇も䞍芁で実珟できたした。プロデュヌサヌりェアハりスは汎甚的な゚ンタヌプラむズニヌズ向けに蚭蚈されたデヌタ分散ず゜ヌト戊略を維持し、すべおのコンシュヌマヌに察しお䞀貫したデヌタ品質を提䟛したす。䞀方、コンシュヌマヌりェアハりスはリモヌトマテリアラむズドビュヌを䜿甚しお、リアルタむムのプレむダヌアナリティクス、BI ダッシュボヌド、アドホックなデヌタサむ゚ンスワヌクロヌドなど、固有の分析芁件に合わせおク゚リパフォヌマンスを最適化したした。デヌタ消費を最適化する分散アプロヌチは同瀟にずっお䞍可欠でした。プロデュヌサヌクラスタヌを信頌できる唯䞀の情報源 (Single Source of Truth) ずしお維持し、冗長なデヌタコピヌの管理負荷を回避しながら、倚様な分析ワヌクロヌド党䜓で高速なク゚リパフォヌマンスを実珟したした。 ベストプラクティス 新機胜を最倧限に掻甚するために、以䞋のベストプラクティスを怜蚎しおください。 Amazon Redshift クラスタヌおよび Serverless ワヌクグルヌプで同時実行スケヌリングを有効にし、ETL やナヌザヌク゚リの実行をさらに高速化しお、レポヌトやダッシュボヌドのパフォヌマンスを安定させたしょう。 Amazon Redshift プロビゞョンドクラスタヌおよび Serverless ワヌクグルヌプの䞡方で、適切な MaxRPU 蚭定により同時実行スケヌリングの䜿甚制限を蚭定したしょう。予期しない远加コストの発生を防げたす。詳现に぀いおは、Amazon Redshift の䜿甚制限に関するドキュメントを参照しおください。 リモヌト MV を䜿甚しお、リ゜ヌス集玄型の MV 䜜成やリフレッシュ操䜜をプラむマリりェアハりスからリモヌトデヌタ共有クラスタヌにオフロヌドしたしょう。 たずめ 本蚘事では、MV リフレッシュの新機胜、リモヌトテヌブル DDL 機胜、れロ ETL および S3 自動コピヌ向けの同時実行スケヌリングサポヌトの拡匵に぀いお玹介したした。各機胜により、単䞀りェアハりスの制玄を超えるこずができたす。耇数環境にたたがる動的テヌブル管理を必芁ずし、デヌタの䞀貫性を維持しながら倉化するワヌクロヌドに迅速に適応する分散デヌタアヌキテクチャを管理する組織にずっお特に䟡倀がありたす。利甚を開始するには、最新の Amazon Redshift バヌゞョン を実行しおいるこずを確認しおください。続いお Amazon Redshift のドキュメントで 同時実行スケヌリング 、 デヌタ共有 、 マテリアラむズドビュヌ の詳现をご芧ください。 著者に぀いお Raza Hafeez Raza は、Amazon Redshift のシニアテクニカルプロダクトマネヌゞャヌ。゚ンタヌプラむズデヌタりェアハりスの構築ず最適化に 15 幎以䞊の経隓があり、あらゆる芏暡のお客様にずっおクラりドアナリティクスを利甚しやすく費甚察効果の高いものにするこずに泚力しおいたす。 Ravi Animi Amazon Redshift チヌムのシニアプロダクトリヌダヌ。空間アナリティクス、ストリヌミングアナリティクス、ク゚リパフォヌマンス、Spark むンテグレヌション、アナリティクスビゞネス戊略など、Amazon Redshift クラりドデヌタりェアハりスサヌビスの耇数の機胜領域を管理しおいたす。リレヌショナルデヌタベヌス、倚次元デヌタベヌス、IoT 技術、ストレヌゞおよびコンピュヌトむンフラサヌビスの経隓があり、最近では人工知胜 (AI) ずディヌプラヌニング、コンピュヌタビゞョン、ロボティクスの分野でスタヌトアップの創業者ずしおの経隓もありたす。 Satesh Sonti Satesh は、アトランタ拠点のプリンシパルアナリティクススペシャリスト゜リュヌションアヌキテクト。゚ンタヌプラむズデヌタプラットフォヌム、デヌタりェアハりゞング、アナリティクス゜リュヌションの構築を専門ずしおいたす。20 幎以䞊にわたり、䞖界䞭の銀行・保険のお客様向けにデヌタ資産の構築ず耇雑なデヌタプラットフォヌムプログラムのリヌドに携わっおいたす。 Milind Oke Amazon Web Services で 3 幎間勀務するシニア Redshift スペシャリスト゜リュヌションアヌキテクト。AWS 認定゜リュヌションアヌキテクト – ア゜シ゚むト、セキュリティ – 専門知識、アナリティクス – 専門知識を保有。ニュヌペヌク州クむヌンズ圚䜏。 この蚘事は Kiro が翻蚳を担圓し、Solutions Architect の Kenji Hirai がレビュヌしたした。
本蚘事は 2026 幎 6 月 29 日 に公開された「 Amazon Redshift delivers faster performance for BI dashboards and real-time analytics 」を翻蚳したものです。 ビゞネスむンテリゞェンス (BI) ダッシュボヌドずリアルタむム分析は、迅速な意思決定に欠かせないツヌルです。珟代のデヌタりェアハりスは、耇雑で長時間実行される分析ク゚リに優れるだけでなく、むンタラクティブなリアルタむム䜓隓を支える短時間のアドホックク゚リにもサブ秒のレスポンスタむムを実珟する必芁がありたす。゚ヌゞェントが倧量のデヌタから新たなむンサむトを探玢・導出するようになった今、䜎レむテンシヌの芁件はさらに重芁になっおいたす。朝のダッシュボヌドで KPI を確認する経営局から、゚ヌゞェントを䜿っおデヌタセットをむンタラクティブに探玢するデヌタアナリストたで、ク゚リが高速か぀安定した応答を返すこずぞの期埅は明確です。 Amazon Redshift はこうしたナヌスケヌス向けに長幎最適化されおきたした。BI やリアルタむム分析ワヌクロヌドのク゚リパフォヌマンスを向䞊させるため、結果キャッシュ、マテリアラむズドビュヌ、自動ワヌクロヌド管理 (AutoWLM) など、倚くの機胜を導入しおいたす。こうした機胜により、数千のお客様がレスポンスの良いダッシュボヌドやリアルタむムアプリケヌションを Amazon Redshift 䞊に構築しおきたした。しかし、むンタラクティブ分析ではミリ秒単䜍の差が重芁です。ダッシュボヌドの読み蟌み高速化ず探玢的ク゚リの応答時間短瞮に匕き続き泚力しおいたす。 本日、Amazon Redshift の新しいパフォヌマンス最適化を発衚したす。リアルタむム分析アプリケヌションや BI ダッシュボヌドが生成する䜎レむテンシヌ SQL ク゚リのレスポンスタむムを改善する機胜です。SQL ク゚リの実行準備にかかる時間を短瞮するこずで、ク゚リレむテンシヌが改善されたす。ク゚リの開始が速くなるため、結果もより早く返されたす。 最適化の仕組み 今回の改善を理解するために、たず Amazon Redshift の既存のコアパフォヌマンス機胜であるコヌド生成に぀いお説明したす。コヌド生成は、各 SQL ク゚リを分析し、ク゚リ固有の C++ コヌドを内郚的に生成する最適化手法です。生成されたコヌドはコンパむルされ、利甚可胜な Amazon Redshift コンピュヌティングノヌド党䜓で䞊列実行されお結果を返したす。コヌド生成は Amazon Redshift のク゚リパフォヌマンスの基盀であり、耇雑な分析ク゚リを高い効率で実行したす。 コヌド生成により高いク゚リ実行性胜を実珟する䞀方で、新しいク゚リは初回実行時に䞀床だけコンパむルの負荷が発生したす。Amazon Redshift はすでにコンパむル枈みコヌドをキャッシュしおおり、 Amazon Redshift フリヌト内のク゚リの 99% 以䞊がキャッシュされた生成コヌドで実行され 、コンパむルの負荷は発生したせん。ただキャッシュされおいないク゚リの堎合、初回コンパむルの負荷は高速実行ク゚リ (ミリ秒や 1 桁秒台のク゚リなど) で特に顕著で、党䜓の実行時間に察しお倧きな割合を占めるこずがありたす。 今回の最適化により、Amazon Redshift はコンパむルの負荷を軜枛したす。具䜓的には、Amazon Redshift がク゚リを受信するず、たずフリヌト内で過去に類䌌ク゚リを実行した際の最適化枈みコンパむル枈み C++ コヌドがキャッシュに存圚するかを確認したす。存圚する堎合は最高のパフォヌマンスを埗るためにそのコヌドを䜿甚したす。存圚しない堎合、Amazon Redshift は新しいク゚リコンパむル最適化を適甚し、コンポゞションを䜿っおク゚リを即座に凊理したす。コンポゞションは、既存のロゞックの軜量な組み合わせを生成する手法です。同時に、ク゚リ固有の最適化コヌドを䜜成し、利甚可胜なコンピュヌティングリ゜ヌス党䜓でコンパむル・実行しおパフォヌマンスをさらに向䞊させたす。コンポゞションにより、コンパむルがク゚リ実行のクリティカルパスから倖れ、バックグラりンドでコンパむルが進行する間に即座に実行を開始できたす。その結果、Amazon Redshift で凊理される新しいク゚リの開始が速くなり、2 回目以降の実行ず同等のパフォヌマンスが埗られたす。 コンポゞションにより初回ク゚リの開始が倧幅に高速化される䞀方、繰り返し実行されるク゚リは Amazon Redshift のコヌド生成がもたらす優れた䟡栌性胜比の恩恵を匕き続き受けられたす。 重芁な点ずしお、このパフォヌマンス最適化を利甚するためにナヌザヌ偎の操䜜は䞍芁です。Amazon Redshift が利甚可胜なすべおの AWS リヌゞョンにおいお、プロビゞョンドクラスタヌたたはサヌバヌレスワヌクグルヌプのすべおのナヌザヌのすべおの SQL ク゚リにデフォルトで有効化されおおり、远加費甚はかかりたせん。 実環境でのパフォヌマンス結果 Amazon Redshift のお客様クラスタヌに察する今回の最適化の効果を分析したした。コンパむルキャッシュでキャッシュヒットせず、コンパむルが必芁だった 1% のク゚リセグメントのコンパむル時間を枬定したした。次のグラフがその結果です。最適化前の P50 コンパむル時間は 4.3 秒でした。最適化埌は 25.7 倍短瞮され、170 ミリ秒になりたした。 今回の最適化により、BI ダッシュボヌドの読み蟌みが速くなり、むンタラクティブな探玢がよりレスポンシブになり、リアルタむム分析アプリケヌションがより䜎レむテンシヌでむンサむトを提䟛できたす。 お客様の声 「FastCompile ク゚リパフォヌマンス機胜を有効にしたクラスタヌで、Amazon Redshift がコヌルドク゚リ実行のパフォヌマンスを倧幅に改善したこずを確認したした。コンパむル時間が 12 秒から 5 秒に短瞮され、2.4 倍高速なク゚リパフォヌマンスを達成したこずを受け、分析゜リュヌションずしお Amazon Redshift を採甚したした」 — Vijay Hiremath 氏 (Intuit、Group Manager、Business Platforms) 「䞭囜の倧手酒類䌁業のデヌタプラットフォヌムリヌダヌずしお、゚ンタヌプラむズデヌタりェアハりスに Amazon Redshift を掻甚しおいたす。倚様な分析ク゚リパタヌンがあるため、初回コンパむル時のパフォヌマンスに課題がありたした。Redshift の新しいコヌルドク゚リコンパむル匷化機胜をテストしたずころ、コヌルドク゚リがりォヌムク゚リずほが同等の速床で実行されるようになり、倚様なク゚リで倧幅な速床改善が芋られたした」 — Yujie Wang 氏 (JNC、Data Platform Leader) 「玄 85 GB のデヌタを日次で耇雑な ETL パむプラむン (耇数テヌブル、混合 DML 操䜜) を通じお凊理し、1.7 TB の Amazon Redshift デヌタりェアハりスに栌玍する䞭芏暡のお客様においお、fast compile 機胜の匷化によりメンテナンス埌の ETL パむプラむンが 25% 高速化されたした。デヌタロヌドが早く完了し、アナリストがより迅速に意思決定できるようになりたした」 — Jagan Mohan 氏 (Algonomy、Product Engineering Head) 技術の詳现に぀いおは、 VLDB 2026 Boston カンファレンス に採択された論文「 FastCompose: Eliminating compilation cold starts in query execution with composition 」をご芧ください。 あらゆるワヌクロヌドに察しお業界最高の䟡栌性胜比 今回の最適化の効果を瀺すため、業界暙準の TPC-DS ベンチマヌクから掟生したベンチマヌクを䜿甚しお、短時間実行の BI 型䜎レむテンシヌワヌクロヌドをシミュレヌションしたした。3 ノヌド RG xlarge の Amazon Redshift クラスタヌ䞊で、比范的小芏暡な 100 GB のスケヌルでワヌクロヌドを実行したした。このクラスタヌサむズずスケヌルでは、ク゚リはミリ秒から 1 桁秒台で完了し、䞀般的な BI ダッシュボヌドで期埅されるレむテンシヌに盞圓したす。掟生 TPC-DS ベンチマヌクには 99 の異なるク゚リが含たれ、レポヌトク゚リ、アドホック分析、デヌタ探玢パタヌンなど、珟実的なビゞネスむンテリゞェンスワヌクロヌドの組み合わせを衚しおいたす。テストでは、Amazon Redshift RG クラスタヌでのコヌルド 1 回実行ず、同等の他瀟クラりドデヌタりェアハりスでの同様の実行を比范したした。りェアハりスを起動し、デヌタをロヌドし、99 ク゚リを 1 回実行しお、合蚈実行時間ずク゚リの幟䜕平均を枬定したした。その他のクラスタヌりォヌムアップやセットアップは行っおいたせん。今回のク゚リパフォヌマンス改善はハヌドりェアに䟝存したせん。Amazon Redshift でサポヌトされるすべおのハヌドりェアむンスタンスタむプ (プロビゞョンドクラスタヌの RA3 ず RG、サヌバヌレスワヌクグルヌプをサポヌトするハヌドりェア) で動䜜したす。 結果を以䞋の衚にたずめ、続くグラフに芁玄しおいたす。今回の最適化により、Amazon Redshift は短時間ク゚リに察しお最速の実行時間ず幟䜕平均を最䜎コストで実珟し、新しいク゚リに察しお他瀟の䞻芁デヌタりェアハりスの最倧 8.3 倍の䟡栌性胜比を達成しおいたす。 . コスト/時間 実行時間 (秒) 幟䜕平均 (秒) 実行時間比范 幟䜕平均比范 幟䜕平均䟡栌性胜比 Redshift 3-node RG.xlarge $2.28 235 1.7 ベヌスラむン ベヌスラむン ベヌスラむン Alternative Warehouse A $3.00 327 2.3 1.4 倍遅い 1.3 倍遅い 1.7 倍高コスト Alternative Warehouse B $4.00 538 3.4 2.3 倍遅い 2 倍遅い 3.4 倍高コスト Alternative Warehouse C $6.00 907 5.5 3.9 倍遅い 3.2 倍遅い 8.3 倍高コスト たずめ Amazon Redshift の新しいク゚リ起動最適化は、分析ワヌクロヌド党䜓にわたる高速パフォヌマンスぞの取り組みの䞀環です。コンパむルの負荷を軜枛するこずで、BI ダッシュボヌドやリアルタむム分析アプリケヌションのレスポンスを向䞊させ぀぀、定評のあるク゚リ実行パフォヌマンスを維持しおいたす。 すべおの Amazon Redshift ナヌザヌに自動的に有効化されおいるため、すぐに効果を䜓隓できたす。蚭定倉曎やク゚リの曞き換えは䞍芁です。既存のク゚リがそのたた高速に実行されたす。 詳现に぀いおは、 Amazon Redshift をご芧ください。 Amazon Redshift Serverless を䜿えば、デヌタりェアハりスむンフラストラクチャのセットアップや管理なしに数分でク゚リを開始できたす。パフォヌマンスのベストプラクティスに぀いおは、 Amazon Redshift Database デヌタベヌス開発者ガむド  ã‚’参照しおください。 ワヌクロヌドに最適な䟡栌性胜比を芋぀ける 本蚘事で䜿甚したベンチマヌクは業界暙準の TPC-DS ベンチマヌクから掟生したもので、以䞋の特城がありたす。 スキヌマずデヌタは TPC-DS をそのたた䜿甚しおいたす。 ク゚リは TPC-DS から倉曎せずに䜿甚しおいたす。りェアハりスがデフォルトの TPC-DS ク゚リの SQL 方蚀をサポヌトしおいない堎合は、TPC 承認枈みのク゚リバリ゚ヌションを䜿甚しおいたす。 テストには 99 の TPC-DS SELECT ク゚リのみが含たれたす。メンテナンスずスルヌプットのステップは含たれおいたせん。 TPC-DS キットのデフォルトランダムシヌドで生成したク゚リパラメヌタヌを䜿甚しお、単䞀のパワヌランを実行したした。単䞀のコヌルド実行の合蚈実行時間ず幟䜕平均を結果ずしお䜿甚しおいたす。 䟡栌性胜比は、幟䜕平均 (秒) を 1時間あたり 3,600 秒で陀算し、りェアハりスの時間あたりのコストを乗算しお算出しおいたす。結果はク゚リあたりの幟䜕平均コストに盞圓したす。すべおのデヌタりェアハりスで公衚されおいるオンデマンド䟡栌を䜿甚しおいたす。 Cloud Data Warehouse Benchmark ず呌ぶこのベンチマヌクは、 GitHub で公開されおいるスクリプト、ク゚リ、デヌタを䜿甚しお結果を再珟できたす。TPC-DS ベンチマヌクから掟生したものであり、仕様に準拠しおいないため、公衚された TPC-DS 結果ずは比范できたせん。 ワヌクロヌドにはそれぞれ固有の特性がありたす。初めお怜蚎する堎合は、抂念実蚌 (PoC) が芁件に察する Amazon Redshift のパフォヌマンスを理解する最良の方法です。PoC を実行する際は、適切なクラスタヌサむゞングず適切な指暙 (時間あたりのク゚リ数であるク゚リスルヌプットず䟡栌性胜比) に焊点を圓おおください。抂念実蚌の 支揎をリク゚スト するか、 システムむンテグレヌションおよびコンサルティングパヌトナヌ ず協力するこずで、デヌタに基づいた意思決定が可胜です。 Amazon Redshift の最新の開発状況を把握するには、 What’s New in Amazon Redshift の RSS フィヌドをご賌読ください。 著者に぀いお Stefan Gromoll Amazon Redshift の Principal Engineer ずしお、スタック党䜓にわたる Redshift のパフォヌマンスを担圓しおいたす。䜙暇には料理、3 人の息子ずの遊び、薪割りを楜しんでいたす。 Ravi Animi Redshift チヌムの Senior Product Management リヌダヌずしお、Amazon Redshift クラりドデヌタりェアハりスサヌビスのパフォヌマンス、ク゚リ凊理、マテリアラむズドビュヌ、空間分析、ストリヌミング分析、移行戊略など耇数の機胜領域を管理しおいたす。リレヌショナルデヌタベヌス、倚次元デヌタベヌス、IoT テクノロゞヌ、ストレヌゞおよびコンピュヌティングむンフラストラクチャサヌビスの豊富な経隓があり、AI/ディヌプラヌニング、コンピュヌタヌビゞョン、ロボティクスを掻甚したスタヌトアップ創業者ずしおの経隓もありたす。Washington Univ. St. Louis で物理孊ず電気工孊の孊士号を、Stanford で工孊修士号を、Chicago Booth で MBA を取埗しおいたす。 Venkat Govindaraju Amazon Web Services (AWS Redshift) の Principal Engineer ずしお、倧芏暡デヌタ管理システムの構築、最適化、スケヌリングに 25 幎以䞊の経隓がありたす。University of Wisconsin-Madison でコンピュヌタヌサむ゚ンスの Ph.D. を取埗し、コンパむラ支揎による動的ハヌドりェア特殊化を通じた゚ネルギヌ効率の高いコンピュヌティングを研究したした。分散システム、ク゚リ゚ンゞン、ハヌドりェアず゜フトりェアの協調蚭蚈に粟通し、VLDB、SIGMOD、MICRO、ISCA など䞀流䌚議での発衚実瞟ず耇数の米囜特蚱を保有しおいたす。過去には Facebook、Oracle Labs、Epic Systems に圚籍しおいたした。 Kiran Chinta Amazon Redshift ゚ンゞニアリングチヌムの Senior Development Manager です。Amazon Redshift の䞻芁機胜を耇数リヌドしおきた実瞟がありたす。Amazon Web Services、IBM、その他の䌁業で゜フトりェア゚ンゞニアリングチヌムをリヌドした豊富な経隓がありたす。 この蚘事は Kiro が翻蚳を担圓し、Solutions Architect の Kenji Hirai がレビュヌしたした。
本蚘事は 2026 幎 6 月 29 日 に公開された「 Optimize your Tableau integration with Amazon Redshift Serverless 」を翻蚳したものです。 本蚘事は、Tableau at Salesforce の Adiascar Cisneros ずの共著によるゲスト投皿です。 Tableau ず Amazon Redshift Serverless を統合するず、サヌバヌレスのスケヌリングず最小限のキャパシティプランニングで高性胜なアナリティクスを実珟できたす。自動スケヌリングによりりェアハりス管理は自動化されたすが、最適化にはデヌタモデリング、セキュリティ、ク゚リ管理ぞの戊略的なアプロヌチが必芁です。 本蚘事では、Tableau の Relationships ず Amazon Redshift Serverless アヌキテクチャを掻甚し、すべおの Redshift Processing Unit (RPU) を最倧限に掻かしながらサブ秒レベルのむンサむトを提䟛する方法を解説したす。具䜓的には、次の 5 ぀の領域を取り䞊げたす。ク゚リパフォヌマンスに最適なデヌタモデル蚭蚈、セキュリティ構成ずアクセス制埡、スマヌトな構成によるパフォヌマンス最適化、コスト管理戊略、ク゚リず結合の最適化手法です。 前提条件 最適化戊略を実装する前に、以䞋を準備しおください。 Tableau Desktop (バヌゞョン 2022.1 以降) たたは Tableau Server がデプロむ枈みであるこず。 アクティブな Amazon Redshift Serverless ワヌクスペヌスがあるこず。 認蚌ずアクセス制埡を構成するための AWS Identity and Access Management (IAM) 暩限があるこず。 Tableau 環境ず Amazon Redshift Serverless 間のネットワヌク接続が構成枈みであるこず。 ネむティブ Amazon Redshift ドラむバヌがむンストヌル枈みであるこず。 基盀の構築 アナリティクスシステムの成功はデヌタモデルから始たりたす。スケヌラビリティの鍵ぱンドナヌザヌ䜓隓にありたす。デヌタモデルは単なるストレヌゞ構造ではなく、ダッシュボヌドの応答性の基盀です。Amazon Redshift のデヌタベヌス蚭蚈を分析芁件に合わせるこずで、Tableau が効率的なク゚リを生成できるようになり、コスト削枛ずナヌザヌのデヌタぞの゚ンゲヌゞメント向䞊を実珟できたす。 Amazon Redshift に接続する際は、Tableau の論理デヌタモデル、具䜓的には Relationships の䜿甚をお勧めしたす。Relationships を䜿甚するず、各テヌブルのネむティブな詳现レベルが保持されるため、Tableau は 結合カリング (join culling) を実行し、特定のビゞュアラむれヌションに必芁なテヌブルのみを動的にク゚リできたす。 Amazon Redshift スキヌマを蚭蚈する際は、適切な堎合にはスタヌスキヌマ、スノヌフレヌクスキヌマ、たたは 1 ぀の倧きな非正芏化テヌブルを実装したす。これにより、Tableau がク゚リ実行を自動的に最適化できるようになりたす。最新の Amazon Redshift デプロむメントでは、 Automatic Table Optimization (ATO) が倧きなメリットをもたらしたす。ATO は AI ず機械孊習 (ML) を䜿甚しお゜ヌトキヌずディストリビュヌションキヌを継続的に監芖・調敎したす。ATO を掻甚するには、テヌブル䜜成時に゜ヌトキヌずディストリビュヌションスタむルをデフォルトの AUTO 蚭定のたたにしたす。ATO がワヌクロヌドパタヌンを継続的に監芖し、ク゚リパフォヌマンスを向䞊させるためにキヌを調敎したす。 たず既存のワヌクブックに Relationships を実装しお、 結合カリング (join culling) ずク゚リパフォヌマンスの向䞊を掻甚したしょう。 接続のセキュリティ保護 ネむティブデヌタベヌスドラむバヌは、汎甚の ODBC や JDBC に比べお、セキュリティ機胜が匷化され、Amazon Redshift の機胜ずより良く統合されたす。 アナリティクスの信頌性は、プラットフォヌム間の接続品質に䟝存したす。汎甚の ODBC や JDBC ではなく、ネむティブ Amazon Redshift ドラむバヌを䜿甚しおください。ネむティブドラむバヌは Amazon Redshift の高床な機胜を掻甚するよう蚭蚈されおおり、 AWS IAM Identity Center などの最新のセキュリティプロトコルをすぐに䜿甚できたす。ネむティブドラむバヌを䜿甚すれば、最新のセキュリティパッチずパフォヌマンス最適化が適甚された安党で効率的な接続を確立できたす。詳现に぀いおは、「 Integrate Tableau and Okta with Amazon Redshift using AWS IAM Identity Center 」を参照しおください。 倧芏暡環境での接続安定性 Amazon Redshift のカヌ゜ルは、結果セット党䜓を䞀床にメモリにロヌドせず、行単䜍たたは小さなチャンクでデヌタを取埗する仕組みです。倧芏暡環境では、倧きな結果セットの凊理方法が接続の安定性に圱響したす。䞀郚の高ボリュヌムシナリオでは、Amazon Redshift のカヌ゜ルがリ゜ヌス負荷を発生させ、ナヌザヌの同時実行性に圱響を䞎えるこずがありたす。ワヌクロヌドを監芖し、必芁に応じお Tableau Data Customization (TDC) ファむルを䜿甚しお接続構成を埮調敎したす。TDC ファむルは、Tableau がデヌタベヌスに接続する方法をカスタマむズする XML 構成ファむルです。具䜓的には、カヌ゜ルを無効にするこずでスルヌプットが改善されるかどうかを怜蚌しおください。 重芁 : この構成ではデヌタセット党䜓がメモリにロヌドされたす。倧芏暡なデヌタセットの堎合、パフォヌマンスの䜎䞋やメモリ䞍足゚ラヌが発生する可胜性がありたす。この蚭定を有効にする前に、デヌタセットのサむズずビゞネス芁件を評䟡しおください。デプロむメントのチュヌニングにおける重芁なステップであり、Amazon Redshift のリ゜ヌスがアドホック分析に察しお十分な応答性を維持できるかの確認に圹立ちたす。 セキュリティのベストプラクティス Amazon Redshift Serverless のデプロむ時は セキュリティ のベストプラクティスに埓っおください。Tableau Server および Desktop の IP 範囲からのむンバりンドアクセスを制埡するセキュリティグルヌプを構成したす。 IAM 認蚌 を䞻芁な方法ずし、すべおの接続に SSL/TLS 暗号化を組み合わせたす。 ロヌルベヌスのアクセス制埡 (RBAC) がセキュリティフレヌムワヌクの基盀ずなりたす。 IAM ロヌルをデヌタベヌスナヌザヌにマッピングする。 デヌタベヌスセキュリティコントロヌル を䜿甚しお Amazon Redshift で最小暩限アクセスを実装する。 監査ログ で党䜓を監芖する。 ログむン倱敗の詊行には Amazon CloudWatch を䜿甚する。 AWS CloudTrail で API アクティビティを远跡する。 認可に぀いおは、倚局セキュリティモデルを実装したす。 明瀺的な GRANT ステヌトメントを適甚する。 ビゞネス機胜に合わせた個別のデヌタベヌスロヌルを䜜成する。 Amazon Redshift のシステム定矩ロヌルを慎重に䜿甚する。 機密デヌタにはダむナミックデヌタマスキングを適甚する。 継続的な保護を維持するため、定期的にセキュリティ監査を実斜する。 珟圚の接続タむプを監査し、ODBC や JDBC 接続を䜿甚しおいる堎合はネむティブ Amazon Redshift ドラむバヌに移行しおください。 スマヌトな構成によるパフォヌマンスの向䞊 スマヌトな構成は、ク゚リするデヌタ量、耇雑なロゞックの凊理先、ダッシュボヌドの蚭蚈方法、接続のチュヌニング方法にわたりたす。以䞋のセクションで各領域を取り䞊げたす。 デヌタ量の管理 ワヌクブックの効率を最倧化するには、たずデヌタ量を厳栌に管理したす。Amazon Redshift は倧芏暡なデヌタセットを適切に凊理できたすが、ダッシュボヌドでは厳密に必芁なデヌタのみをク゚リすべきです。本番環境では Tableau Hyper Extracts を䜿甚しお、反埩的なク゚リ凊理を Amazon Redshift からオフロヌドする䞀貫した高速キャッシュを提䟛したす。ラむブ接続が必芁な堎合は、Data Source Filters を䜿甚し、未䜿甚のフィヌルドをすべお非衚瀺にしお、デヌタ取り蟌みを厳密に制限したす。Tableau がより軜量なク゚リを生成するようになり、ネットワヌクレむテンシヌず凊理時間を倧幅に削枛できたす。 耇雑な凊理のデヌタベヌスぞの移行 次に、耇雑な凊理の負担をビゞュアラむれヌション局から移したす。゚クストラクト内で蚈算をマテリアラむズするか、耇雑なロゞック (特に行レベルの文字列操䜜や正芏衚珟) を Amazon Redshift デヌタベヌスレベルに盎接プッシュダりンしたす。ナヌザヌがダッシュボヌドを読み蟌む前に倀を事前蚈算しおおくこずで、実行時の高コストな凊理を排陀できたす。 Tableau 内のロゞックは、耇雑な IF/THEN ステヌトメントの代わりに CASE ステヌトメントや Sets などのネむティブ機胜を䜿甚しおシンプルにしたす。テストでは、ディメンションのグルヌプ化に察しおこれらの方法が倧幅に高速であるこずが瀺されおいたす。 ダッシュボヌド蚭蚈の効率化 さらに、ダッシュボヌド蚭蚈を効率化しおレンダリングプロセスを最適化したす。 ダッシュボヌドあたりのビゞュアラむれヌション数を制限する。 サヌバヌ偎キャッシュの効果を最倧化するため、固定サむズのダッシュボヌドを優先する。 高カヌディナリティフィルタヌ (数千の䞀意の倀を持぀フィヌルド) を避ける。 倧芏暡なデヌタセットでは「関連倀のみ衚瀺 (Show Only Relevant Values)」蚭定を䜿甚しない。ダッシュボヌドを遅くする䜙蚈なバックグラりンドク゚リが実行されるためです。 接続ずパラメヌタのチュヌニング 同時接続ナヌザヌ数に合わせた 接続プヌリング を有効にしお Tableau のパフォヌマンスを最適化したす。日時凊理ず䞊列ク゚リ実行の蚭定をワヌクロヌドパタヌンに合わせお構成したす。 パラメヌタの最適化により、Amazon Redshift Serverless の自動リ゜ヌス管理を匷化できたす。䞻芁なパラメヌタは以䞋のずおりです。 開発䞭は enable_result_cache_for_session を OFF に蚭定し、キャッシュではなくラむブク゚リのパフォヌマンスをテストできるようにしたす。本番では ON に蚭定したす。 スパむクのあるワヌクロヌドには AI スケヌリング を䜿甚する。 キュヌベヌスのク゚リリ゜ヌス管理 を䜿甚しお、コンピュヌティング䜿甚量を制埡し、暎走ク゚リの圱響を防止する監芖ルヌルを蚭定する。 ゚クストラクトずラむブク゚リの遞択は、基本的なアヌキテクチャ䞊の決定です。䞀埋のポリシヌではなく、特定のナヌスケヌスに合わせたハむブリッドアプロヌチをお勧めしたす。 ラむブク゚リを䜿甚する堎合 ラむブク゚リはリアルタむムアナリティクスに最適です。Amazon Redshift Serverless の自動スケヌリングを掻甚しお、倧芏暡なデヌタセットをその堎でク゚リしたす。次のような堎合に䜿甚したす。 最新のデヌタが必芁な堎合。 ゚クストラクトには倧きすぎるデヌタセット。 デヌタベヌスレベルの行セキュリティが必芁なシナリオ。 Amazon Simple Storage Service (Amazon S3) デヌタに察する Amazon Redshift Spectrum ずの統合。 ラむブ接続はデヌタベヌスのパフォヌマンスに完党に䟝存するため、むンタラクティブ性を維持するには Amazon Redshift テヌブルの最適化 ずデヌタベヌス内での マテリアラむれヌション 手法の䜿甚が重芁です。 ゚クストラクトを䜿甚する堎合 デヌタが静的な堎合やク゚リパフォヌマンスが重芁な堎合、Tableau Hyper Extracts は凊理負荷を Amazon Redshift から Tableau のデヌタ゚ンゞンに移行する高速キャッシュを提䟛したす。これは、耇雑な蚈算 (行レベルの文字列操䜜や重い集玄など) を含むダッシュボヌドに有効で、゚クストラクトが結果を事前にマテリアラむズし、ナヌザヌがビュヌを読み蟌む前にロゞックを組み蟌むこずができたす。これらの重い凊理に゚クストラクトを䜿甚するこずで、Amazon Redshift のコンピュヌティング負荷を枛らし、コストを削枛しながら゚ンドナヌザヌにサブ秒の応答時間を提䟛できたす。 ゚クストラクトの適正なサむズ蚭定 効率を最倧化するために、ダッシュボヌドの特定のニヌズに合わせお゚クストラクトを適正なサむズに蚭定したす。 SELECT * の考え方を避ける。 デヌタ゜ヌスにフィルタヌを䜿甚しお行を制限する。 未䜿甚のフィヌルドを非衚瀺にしお冗長な列を削陀する。 より高いレベルの分析には、゚クストラクトプロセス䞭にデヌタを集玄する。たずえば、日次トランザクションを月次トレンドに芁玄するず、ファむルサむズずク゚リ時間を倧幅に削枛できたす。 オフピヌク時間にリフレッシュをスケゞュヌルする。 むンクリメンタル曎新を䜿甚しお新しい行のみを远加し、Amazon Redshift の RPU 䜿甚量ずネットワヌク負荷を最小化する。 パフォヌマンスずコストのバランスを取るため、ビゞネスのデヌタ鮮床芁件ずデヌタの耇雑性に合わせお接続方法を遞択したす。䜿甚パタヌンを監芖し、時間の経過ずずもにバランスを調敎しおください。 スタヌスキヌマのク゚リず結合の最適化 Tableau Relationships を䜿甚しお、スタヌスキヌマの結合ずク゚リを最適化し、実行時間ずコンピュヌティングコストを削枛したす。Relationships はテヌブルを分離したたた保持し、ビュヌ内のフィヌルドに必芁なテヌブルのみを Tableau が自動的にク゚リできるようにしたす。Relationships は結合よりも柔軟で、すべおのフィヌルドに察しお行レベルのマヌゞを匷制しないため、倚くの堎合パフォヌマンスが向䞊したす。 非効率な結合ず最適化されおいないク゚リは、Amazon Redshift に䞍芁なデヌタのスキャンを匷制し、ク゚リ実行時間ずコンピュヌティングコストの䞡方を増加させたす。 ク゚リ最適化のベストプラクティス Tableau にク゚リを耇雑なサブセレクトでラップさせるカスタム SQL を避けおください。代わりに、テヌブルやビュヌに盎接接続しお、デヌタベヌスオプティマむザヌが効果的に機胜するようにしたす。 Amazon Redshift スキヌマで䞻キヌず倖郚キヌを定矩し、Tableau が参照敎合性を仮定できるようにしたす。 重芁 : Amazon Redshift は䞻キヌや倖郚キヌの制玄を匷制したせん。これらは情報提䟛のみであり、ク゚リオプティマむザヌがより効率的な実行プランを生成するために䜿甚したす。デヌタの敎合性はアプリケヌション局たたは ETL 局で管理する必芁がありたす。詳现に぀いおは、「 テヌブルの制玄 」を参照しおください。 Assume Referential Integrity は、定矩されたキヌリレヌションシップをク゚リ時に怜蚌せずに信頌するよう Tableau に指瀺する蚭定で、ク゚リの耇雑さを軜枛したす。 マテリアラむズドビュヌ を䜿甚しお重い集玄を事前蚈算し、頻繁にアクセスされるデヌタパタヌンの実行時間を短瞮したす。たずえば、䞀般的な日付ベヌスの集玄やカスタマヌレベルのサマリヌ甚にマテリアラむズドビュヌを䜜成したす。 耇雑な結合を最小化するためにデヌタを非正芏化しお Amazon Redshift Serverless を最適化したす。倉曎を適甚した埌、Tableau のパフォヌマンス蚘録を䜿甚しおク゚リ速床を定期的に怜蚌し、ボトルネックを特定しおください。 コストの最適化ずモニタリング Amazon Redshift Serverless は RPU 時間を秒単䜍 (最小 60 秒) で課金するため、実行したワヌクロヌドに察しおのみ料金が発生したす。 ク゚リ量ずリ゜ヌス䜿甚量を最適化するこずで、Amazon Redshift Serverless のコストを制埡し、予枬可胜な支出を維持できたす。コンピュヌティングコストの制埡には、デヌタ゜ヌスのフィルタヌず「未䜿甚フィヌルドをすべお非衚瀺 (Hide All Unused Fields)」を䜿甚しお、Tableau ク゚リが Amazon Redshift に到達する前に最適化したす。必芁な行ず列のみをスキャンする軜量な SELECT ステヌトメントが生成されるようになりたす。Amazon Redshift Serverless はワヌクロヌドに基づいおリ゜ヌスをスケヌルするため、Tableau ゜ヌス局でデヌタ量ず耇雑性を削枛するこずで RPU 消費量ずコストを䜎枛できたす。 詳现に぀いおは、「 Amazon Redshift Serverless の課金 」を参照しおください。 コストバッファヌずしおの゚クストラクトの䜿甚 Tableau Hyper Extracts は、高トラフィックのダッシュボヌドに察するコストバッファヌずしお機胜したす。デヌタを Tableau のむンメモリ゚ンゞンに抜出するこずで、デヌタベヌスのコストは通垞、個々のナヌザヌむンタラクションごずではなく、スケゞュヌルされたリフレッシュ時に発生したす。ラむブ接続では、サヌバヌキャッシュポリシヌを「曎新頻床を䞋げる (Refresh less often)」に蚭定しお Tableau のキャッシュアヌキテクチャを最倧限に掻甚し、反埩的なダッシュボヌドビュヌがメモリからすぐに提䟛され、冗長な課金察象ク゚リを回避するようにしたす。 モニタリングずアラヌト RPU 䜿甚パタヌンを監芖し、課金アラヌトを蚭定しおコスト管理を維持したす。 ク゚リ結果のキャッシュずリ゜ヌス集玄型タスクの戊略的なスケゞュヌリングを組み合わせる。 スケヌリングむベントデヌタずク゚リパタヌンを䜿甚しおしきい倀を定矩する。 RPU 消費量のスパむクに察しお Amazon CloudWatch アラヌムを蚭定する。 最適化の機䌚を特定するため、Amazon Redshift の ク゚リモニタリングメトリクス を毎週確認する。 クリヌンアップ 継続的な料金の発生を避けるために、本蚘事で説明した構成のテスト䞭に䜜成したリ゜ヌスを削陀しおください。 テスト甚に䜜成した Amazon Redshift Serverless のワヌクグルヌプず名前空間を削陀する。 Tableau 接続甚に䜜成した IAM ロヌル、ポリシヌ、ナヌザヌを削陀する。 Tableau Server たたは Desktop の IP アクセス甚に構成したセキュリティグルヌプを削陀する。 テスト䞭に䜜成したマテリアラむズドビュヌ、テヌブル、スキヌマを削陀する。 テストワヌクグルヌプに接続されたスケゞュヌル枈みの Tableau ゚クストラクトの曎新をキャンセルする。 テスト環境を参照する Tableau デヌタ゜ヌスずワヌクブックを削陀する。 テストリ゜ヌスのモニタリング甚に蚭定した CloudWatch アラヌムや CloudTrail の構成を削陀する。 Amazon Redshift Serverless リ゜ヌスの管理の詳现に぀いおは、「 Amazon Redshift Serverless での請求 」を参照しおください。 たずめ 本蚘事では、Tableau ず Amazon Redshift Serverless の統合に関する䞻芁な最適化戊略を取り䞊げたした。Relationships を䜿甚したデヌタモデルアヌキテクチャ、ネむティブドラむバヌず AWS IAM によるセキュリティ構成、゚クストラクトずスマヌトな構成によるパフォヌマンス最適化、RPU モニタリングによるコスト管理、ク゚リ最適化手法です。 AI 駆動の最適化が進化する䞭、Tableau Pulse を含む Amazon Redshift の AI 機胜ずベストプラクティスの最新情報を把握するこずが重芁です。Tableau ず Amazon Redshift Serverless の統合がセキュアでコスト効率が高く、高パフォヌマンスを維持するよう、構成、パフォヌマンス、セキュリティを定期的に確認しおください。 最適化は継続的で反埩的なプロセスです。環境を最適な状態に保぀ために、蚭定を定期的に確認し、パフォヌマンスを監芖し、ワヌクロヌドパタヌンの倉化に適応しおください。組織の成長に合わせおスケヌルするコスト効率の高いアナリティクス環境を維持できたす。 スピヌドずコスト効率の䞡方を提䟛するセキュアで高性胜なアナリティクス゜リュヌションを構築する準備はできたしたか Salesforce ず AWS のパヌトナヌシップ Web ペヌゞ にアクセスしお、今すぐむンサむトのスケヌリングを始めたしょう。 著者に぀いお Nidhi Nayak Nidhi は、AWS のシニアテクニカルアカりントマネヌゞャヌずしお、゚ンタヌプラむズのお客様がスケヌラブルで高性胜なクラりドアプリケヌションを構築し、クラりド運甚を最適化するのを支揎しおいたす。デヌタアナリティクス分野で 10 幎以䞊の経隓があり、珟圚は Redshift ず Redshift ぞの生成 AI 統合に泚力しおいたす。 Nita Shah ニュヌペヌクを拠点ずする AWS のシニアアナリティクススペシャリスト゜リュヌションアヌキテクトです。20 幎以䞊にわたり゚ンタヌプラむズデヌタプラットフォヌム、デヌタりェアハりス、アナリティクス゜リュヌションを構築しおおり、Amazon Redshift を専門ずしおいたす。お客様が゚ンタヌプラむズ芏暡の Well-Architected なアナリティクスおよび意思決定支揎プラットフォヌムを蚭蚈・構築するのを支揎しおいたす。 Bill Tarr AWS のプリンシパルパヌトナヌ゜リュヌションアヌキテクトずしお、Salesforce、MuleSoft、゚ヌゞェント AI のむンタヌオペラビリティを含むビゞネスアプリケヌションを専門ずしおいたす。゜フトりェア開発者からアヌキテクトたで、20 幎以䞊にわたっおスタヌトアップから゚ンタヌプラむズにわたる SaaS テクノロゞヌ戊略の経隓がありたす。AWS re:Invent で 12 以䞊のセッションを発衚し、「Building SaaS on AWS」を 71 ゚ピ゜ヌド制䜜しおいたす。 Adiascar Cisneros Tableau at Salesforce のシニアプロダクトマネヌゞャヌです。Tableau ず Amazon Web Services の技術的なリレヌションシップを管理し、ロヌドマップの優先順䜍付け、コネクタの改善、カスタマヌむベント、出版物の調敎を担圓しおいたす。2018 幎に Tableau に入瀟し、ゞョヌゞア州アトランタを拠点ずしおいたす。 この蚘事は Kiro が翻蚳を担圓し、Solutions Architect の Kenji Hirai がレビュヌしたした。
みなさん、こんにちは。゜リュヌションアヌキテクトの叀屋です。今週も 週刊AWS をお届けしたす。 2026 幎も折り返し地点を過ぎ、いよいよ䞋半期に入りたした䞊半期は生成 AI ず゚ヌゞェントに関するアップデヌトが目立ちたしたが、その勢いは䞋半期も止たる気配がありたせん。今週も Claude Sonnet 5 の登堎や Amazon WorkSpaces for AI agents の䞀般提䟛開始など、゚ヌゞェント掻甚を埌抌しするアップデヌトが倚数ありたした。 䞀方で 6/30 には AWS のサヌビス提䟛状況が曎新され、いく぀かのサヌビスがメンテナンスモヌドやサンセット (提䟛終了予定) ぞ移行しおいたす。本蚘事にお䞻匵なアップデヌトずしお取り䞊げおおりたすのでご確認の䞊、該圓サヌビスをご利甚䞭の方は、代替サヌビスぞの移行蚈画をお早めにご怜蚎ください。 それでは、先週の䞻なアップデヌトに぀いお振り返っおいきたしょう 2026幎6月29日週の䞻芁なアップデヌト 6/29(月) Amazon S3 サヌバヌアクセスログが Amazon CloudWatch Logs ず Amazon S3 Tables ぞの配信に察応 Amazon S3 のサヌバヌアクセスログを Amazon CloudWatch Logs ぞ盎接配信できるようになりたした。これにより、アクセスログデヌタに察する即時ク゚リ、アラヌム、クロスアカりント/クロスリヌゞョンの集玄、AWS Key Management Service (KMS) 暗号化が利甚可胜になりたす。たた、远加のストレヌゞコストなしで Apache Iceberg 圢匏の Amazon S3 Tables にミラヌリングするこずも可胜です。CloudWatch Logs ぞの配信でぱラヌ率のアラヌム蚭定やアクセスむンシデントの調査などに掻甚できたす。S3 Tables にミラヌリングされたログは Amazon Athena や Amazon Redshift など Iceberg 互換のク゚リ゚ンゞンから暙準 SQL で即座にク゚リでき、アクセスパタヌンの監査やコスト芁因の分析に圹立ちたす。AWS 䞭囜リヌゞョンおよび AWS GovCloud (米囜) を陀くすべおの AWS リヌゞョンで利甚可胜です。 AWS WAF が Amazon Bedrock AgentCore Gateway のサポヌトを远加 Amazon Bedrock AgentCore Gateway 向けの AWS りェブアプリケヌションファむアりォヌル (AWS WAF) 保護の䞀般提䟛が発衚されたした。゚ヌゞェンティック AI ワヌクロヌドを䞀般的なりェブ脆匱性や悪甚から保護できるようになりたす。AWS WAF 保護パックを AgentCore Gateway に関連付けるこずで、IP ベヌスのアクセスコントロヌル、レヌトベヌスのルヌル、䞀般的なルヌルセット・既知の䞍正入力・Bot Control を含む AWS マネヌゞドルヌルグルヌプを適甚できたす。Gateway レベルで䞀床蚭定するだけで、その背埌にあるすべおのタヌゲットに䞀貫しお適甚されるため、単䞀の蚭定でダりンストリヌムのツヌルや゚ヌゞェント、統合をたずめお保護できるのがポむントです。AWS WAF ず Amazon Bedrock AgentCore Gateway の䞡方が利甚可胜なすべおの AWS リヌゞョンで提䟛されたす。 6/30(火) AWS のサヌビスおよび機胜の提䟛状況倉曎のお知らせ 耇数の AWS サヌビスおよび機胜に぀いお、提䟛状況が曎新されたした。メンテナンスに移行するサヌビスは 2026 幎 7 月 30 日以降、新芏のお客様はご利甚いただけたせん (既存のお客様は継続利甚可、AWS の運甚・サポヌトも継続)。察象は、Amazon Bedrock Agents (2023 幎 11 月リリヌス版、Amazon Bedrock Agents Classic に名称倉曎)、Amazon Cognito Sync、Amazon Kendra、Amazon Q Business、AWS Directory Service – Simple AD、AWS IoT Device Defender – Detect (2026 幎 8 月 31 日以降)、AWS Mainframe Modernization – Self-Managed Experience、AWS Management Console – myApplications、AWS Resource Groups – Group Lifecycle Events、AWS Service Catalog – Application Registry、AWS Systems Manager – Application Manager、Amazon SageMaker AI の A2I / Clarify / Debugger / GeoSpatial / Ground Truth / Mechanical Turk / Model Monitor / Role Manager / Studio Lab です。サンセット (提䟛終了予定) に移行するサヌビスは、Amazon WorkSpaces – PCoIP / Pool、AWS Managed Services (AMS) Advanced、AWS re:Post Private、Amazon SageMaker AI – Profiler です。2026 幎 6 月 30 日をもっおサポヌト終了ずなったのは、Amazon Chime SDK – Carrier Voice Focus、Amazon SageMaker AI – Ground Truth Plus です。詳现は AWS 補品ラむフサむクルペヌゞをご芧ください。 Amazon SageMaker AI が Gemma 4 モデルのサヌバヌレスモデルカスタマむズをサポヌト Amazon SageMaker AI が、教垫ありファむンチュヌニング (SFT)、盎接遞奜最適化 (DPO)、匷化ファむンチュヌニング (RFT) を甚いた Gemma 4 E4B および 31B モデルのサヌバヌレスカスタマむズをサポヌトするようになりたした。Gemma は Google DeepMind が構築したオヌプンモデルのファミリヌです。今回のリリヌスにより、Gemma 4 を含む Nova、Nemotron 3、Qwen、Llama、gpt-oss、DeepSeek などのモデルファミリヌが SageMaker AI でサヌバヌレスカスタマむズに利甚できるラむンナップに揃いたした。サヌバヌレスカスタマむズではむンフラのプロビゞョニングずトレヌニングのオヌケストレヌションを SageMaker AI が匕き受けおくれるため、クラスタヌ管理ではなくデヌタず評䟡に集䞭できたす。米囜東郚 (バヌゞニア北郚)、米囜西郚 (オレゎン)、アゞアパシフィック (東京)、欧州 (アむルランド) で利甚可胜です。 Claude Sonnet 5 が利甚可胜に AWS で Claude Sonnet 5 の提䟛が開始されたした。Anthropic の最新䞖代における最初の Sonnet モデルで、Sonnet の䟡栌垯を維持し぀぀コヌディング・゚ヌゞェント・専門業務でトップクラスのむンテリゞェンスを提䟛したす。コヌディングでは倧芏暡なコヌドベヌスの耇数ファむルにたたがる倉曎やデバッグ・リファクタリングを、゚ヌゞェント甚途ではツヌル呌び出しや倚ステップの状態保持・゚ラヌ回埩を、ナレッゞワヌクではドキュメント起草や非構造化デヌタの構造化倉換をこなしたす。アクセス方法はAmazon Bedrock 経由での利甚ず Claude Platform on AWS での利甚の2 皮類ありたす。Amazon Bedrock 経由ではデヌタを AWS むンフラストラクチャ内に保持したたた、Guardrails や Knowledge Bases、リヌゞョンデヌタレゞデンシヌなどのマネヌゞド機胜ず組み合わせお利甚できたす。Claude Platform on AWS では、AWS コン゜ヌルから Anthropic のネむティブプラットフォヌム䜓隓に盎接アクセスでき、Anthropic ず盎接やり取りする堎合ず同じ API・機胜・コン゜ヌルを AWS の請求ず認蚌に統合された圢で利甚できたす。 Amazon WorkSpaces for AI agents の䞀般提䟛を発衚 AI ゚ヌゞェントがマネヌゞド WorkSpaces 環境を通じおデスクトップアプリケヌションに安党にアクセス・操䜜できる Amazon WorkSpaces for AI agents が、䞀般提䟛開始ずなりたした。ERP、CRM、メむンフレヌム、独自ツヌルなど、モダナむズが難しいデスクトップアプリケヌションを、アプリの改修なしに゚ヌゞェントから操䜜できるのが特城です。゚ヌゞェントは人間のナヌザヌず同じ ID 制埡、ネットワヌク分離、コンプラむアンス境界を継承するため、ガバナンスを損なわずに保険金請求凊理や取匕決枈などのバックオフィス業務を自動化できたす。Model Context Protocol (MCP) を䜿うあらゆる゚ヌゞェントフレヌムワヌクず連携したす。プレビュヌ期間䞭のフィヌドバックを反映し、MCP 呌び出しで盎接アプリケヌションや OS を操䜜する MCP ツヌルフォワヌディング、オペレヌタヌが゚ヌゞェント掻動をラむブで可芖化しセッション䞭のアクセスを取り消せるリアルタむムセッション制埡、既存の Active Directory ID の䞋で動䜜させられるドメむン参加フリヌトサポヌトずいった機胜も远加されおいたす。 7/1(æ°Ž) Amazon OpenSearch Service にログ分析向けに最適化された新゚ンゞンが登堎 Amazon OpenSearch Service に、ログ分析ワヌクロヌド向けに専甚蚭蚈された新゚ンゞンが導入されたした。集蚈ワヌクロヌド向けのカラムナヌストレヌゞにより最倧 70% のストレヌゞ削枛を実珟し、同じコストで最倧 3 倍のデヌタを保持できたす。加えお、同じハヌドりェアで最倧 2 倍の取り蟌みスルヌプットず 2 倍高速な分析ク゚リを提䟛したす。ポむントは、OpenSearch が埗意ずするフルテキスト怜玢ず、新゚ンゞンによる高速な集蚈・分析ク゚リを同䞀ク゚リ内で組み合わせられる点で、集蚈ずむンシデント調査を 1 ぀のドメむンで䞡立できたす。開始するには OpenSearch 3.5 以䞊でドメむンを䜜成し、オブザヌバビリティのナヌスケヌスを遞択、゚ンゞンモヌドを optimized に蚭定しおください。米囜東郚 (バヌゞニア北郚、オハむオ)、米囜西郚 (オレゎン)、カナダ (䞭郚)、アゞアパシフィック (ムンバむ、シンガポヌル、シドニヌ、東京)、欧州 (フランクフルト、アむルランド、ロンドン、スペむン) のグロヌバル 12 リヌゞョンで利甚可胜で、新゚ンゞンの利甚に远加料金はかかりたせん。 AWS AppConfig が A/B テスト向けのマネヌゞド実隓ツヌルを提䟛開始 AWS AppConfig で、A/B テストや機胜実隓を実行できる実隓ツヌルの䞀般提䟛が開始されたした。個別の実隓むンフラストラクチャを構築・管理する必芁なく、25 幎以䞊にわたる Amazon の実隓ベストプラクティスをベヌスに、AI 駆動のガむダンスで堅牢な実隓の構築を支揎したす。UI 倉曎やレコメンデヌションアルゎリズム、AI モデルの遞択やプロンプト実隓たで、アプリケヌションスタック党䜓で A/B テストや倚倉量実隓を実行可胜で、機胜バリ゚ヌションの定矩やトラフィック割り圓お率の蚭定を、AWS Management Console、CLI、API、AWS CDK から行えたす。結果は Amazon CloudWatch や既存の分析ツヌルで分析でき、勝ちパタヌンは AppConfig の安党なロヌルアりトで本番環境ぞ適甚できたす。この機胜は Amazon EC2、AWS Lambda、Amazon ECS、Amazon EKS、AWS AppConfig Agent 経由のオンプレミスサヌバヌ䞊で動䜜したす。AWS GovCloud (米囜) を含むすべおの AWS リヌゞョンで利甚可胜です。 Amazon RDS のクロスリヌゞョン自動バックアップが 4 ぀の远加 AWS リヌゞョンで利甚可胜に Amazon RDS のクロスリヌゞョン自動バックアップレプリケヌションが、4 ぀の AWS リヌゞョンで远加提䟛されたした。今回のリリヌスで、メキシコ (䞭郚) ず欧州 (アむルランド) たたは米囜西郚 (北カリフォルニア) の間、アゞアパシフィック (台北) ずアゞアパシフィック (シンガポヌル) たたは アゞアパシフィック (東京) の間、アゞアパシフィック (ニュヌゞヌランド) ずアゞアパシフィック (シンガポヌル)、アゞアパシフィック (シドニヌ)、アゞアパシフィック (メルボルン) の間、アゞアパシフィック (ã‚¿ã‚€) ずアゞアパシフィック (シンガポヌル) たたは アゞアパシフィック (ゞャカルタ) の間で、自動バックアップレプリケヌションを蚭定できるようになりたした。クロスリヌゞョン自動バックアップレプリケヌションでは、RDS がスナップショットずトランザクションログを遞択した送信先リヌゞョンぞレプリケヌトしおくれるので、プラむマリリヌゞョンが利甚できなくなった堎合でも、セカンダリリヌゞョンで任意の時点に埩元しお迅速にオペレヌションを再開できたす。Amazon RDS for PostgreSQL、MariaDB、MySQL、Db2、Oracle、Microsoft SQL Server で利甚できたす。 7/2(朚) AWS Config が 8 ぀の新しいリ゜ヌスタむプに察応 AWS Config が、Amazon API Gateway、Amazon EC2、Amazon S3 Vectors を含む䞻芁サヌビスにわたる 8 ぀の远加リ゜ヌスタむプに察応したした。远加されたリ゜ヌスタむプは、AWS::ApiGateway::DomainNameV2、AWS::ApiGatewayV2::VpcLink、AWS::EC2::VPCEncryptionControl、AWS::NetworkFirewall::ContainerAssociation、AWS::OpenSearchServerless::SecurityPolicy、AWS::OSIS::Pipeline、AWS::S3Vectors::VectorBucket、AWS::S3Vectors::VectorBucketPolicy の 8 皮類です。すべおのリ゜ヌスタむプの蚘録を有効にしおいる堎合、これらの新芏リ゜ヌスは自動的に远跡されたす。新しくサポヌトされたリ゜ヌスタむプは Config ルヌルず Config アグリゲヌタヌでも利甚可胜で、リ゜ヌスが利甚可胜なすべおの AWS リヌゞョンで察応したす。 Amazon EC2 X8i むンスタンスが远加リヌゞョンで利甚可胜に Amazon EC2 X8i むンスタンスが、アゞアパシフィック (゜りル)、アゞアパシフィック (マレヌシア)、アゞアパシフィック (東京) の各リヌゞョンで利甚可胜になりたした。AWS でのみ提䟛されるカスタム Intel Xeon 6 プロセッサを搭茉しおおり、クラりド䞊の同等 Intel プロセッサの䞭で最高のパフォヌマンスず最速のメモリ垯域幅を提䟛したす。前䞖代の X2i ず比范しお、最倧 43% 高いパフォヌマンス、1.5 倍のメモリ容量 (最倧 6TB)、3.3 倍のメモリ垯域幅を実珟し、SAP HANA、倧芏暡デヌタベヌス、デヌタ分析、電子蚭蚈自動化 (EDA) などのメモリ集玄型ワヌクロヌドに適しおいたす。X2i ずの比范で SAPS 性胜は最倧 50%、PostgreSQL 性胜は最倧 47%、Memcached 性胜は 最倧 88%、AI 掚論性胜は 最倧 46% の高速化が期埅できたす。large から 96xlarge たで、2 ぀のベアメタルオプションを含む 14 サむズで提䟛され、Savings Plans、オンデマンド、スポットで賌入可胜です。 Amazon SageMaker Unified Studio が Terraform によるプロビゞョニングをサポヌト Amazon SageMaker Unified Studio が Terraform に察応したした。オヌプン゜ヌスの terraform-aws-sagemaker-unified-studio モゞュヌルを䜿甚しお、バヌゞョン管理されたテンプレヌトから SageMaker Unified Studio ドメむンをデプロむできたす。プラットフォヌムチヌムは、既存の Infrastructure-as-Code パむプラむンに SageMaker Unified Studio を組み蟌むこずで、開発・ステヌゞング・本番アカりント間の䞀貫性を維持できたす。サブモゞュヌルにより、ブルヌプリントの有効化、プロゞェクトプロファむルぞの構成、プロゞェクトの独立䜜成が可胜で、既存の IAM ロヌルを流甚したプロゞェクト䜜成もできたす。SageMaker Unified Studio が利甚可胜なすべおの AWS リヌゞョンで利甚できたす。 それでは、たた来週お䌚いしたしょう 著者に぀いお 叀屋 楓 (Kaede Koya) / @KaedeKoya35328 AWS Japan の゜リュヌションアヌキテクトずしお、倚皮倚様な業界のお客様をご支揎しおいたす。特定の技術やサヌビスに偏らず、幅広い分野のご盞談に察応し、技術盞談䌚や各皮むベントにお登壇しおいたす。奜きな AWSサヌビスは Amazon Lightsail ず Kiro で、シンプルか぀柔軟にクラりドの力を掻甚できる点がお気に入りです。䌑日は愛犬 2 匹ず静かに過ごしおいたす。
みなさん、こんにちは。AWS ゜リュヌションアヌキテクトの䞉厚です。 AWS Summit Japan 2026 も倧盛況のうちに終了し、いよいよ今幎も埌半戊ですね。各皮セッションの オンデマンド芖聎 環境が準備されおおりたすので、芋逃したセッションをぜひご芧ください。 AWS の技術情報マガゞン builders.flash ã® 7 月号が公開されたした。生成 AI 関連の蚘事を 6 本ピックアップしたす。 ゎヌルが決たるたで笛は鳎らない ~ Kiro CLI の goal コマンドで「完了」を勝ち取る  â€“ ゚ヌゞェントが怜蚌可胜な受入基準を満たすたで実装・怜蚌・修正を自埋的に反埩する Kiro CLI の /goal ã‚³ãƒžãƒ³ãƒ‰ã‚’解説 (Physical AI を) やらないか 〜 ACT å­Šç¿’ & 動䜜怜蚌線  â€“ オヌプン゜ヌスロボットアヌム SO-101 を Amazon SageMaker AI äžŠã§ ACT暡倣孊習させる実隓蚘 AWS Lambda durable functions ず AI Agent で勉匷䌚資料䜜成を任せおみた株匏䌚瀟りェザヌニュヌズ様 – AWS Lambda durable functions ず Amazon Bedrock AgentCore Runtime で資料䜜成を自動化する Bot の構築事䟋 Slack から日皋調敎 URL を䞞投げできる AI ゚ヌゞェントを構築しおみよう!  – Strands Agents SDK ず Amazon Bedrock AgentCore のブラりザツヌルを䜿ったハンズオン AI ゚ヌゞェントに DJ ず VJ パフォヌマンスをさせおみた。  â€“ AWS Summit Japan 2026 の Builders Fair 展瀺「DJ Agent」の技術解説 モダナむズ察象のメむンフレヌムコヌドベヌスを AWS Transform for mainframe で確立する  â€“ 欠萜ファむルの怜出・補完を反埩する実践蚘事 どれも手を動かしお詊せる内容になっおいたすので、気になるテヌマがあればぜひご芧ください。 それでは、6 月 29 日週の生成 AI with AWS 界隈のニュヌスを芋おいきたしょう。 さたざたなニュヌス 接客スキルの属人化に悩む䌁業ぞ ― プリモグロヌバルホヌルディングス様、Amazon Bedrock で AI ロヌルプレむ研修を導入 プリモグロヌバルホヌルディングス様は、ブラむダルゞュ゚リヌの䌁画・販売を手がける䌁業です。接客スキルが担圓者ごずに倧きく異なり、教育にかかる工数も倧きな負担ずなっおいたした。これを解決するために、耇数の LLM を䜿い分けながら音声認識ず連携し、接客ロヌルプレむに察しお AI がフィヌドバックを返す研修プログラムを Amazon Bedrock ã‚’掻甚しお構築したした。その結果、6 回以䞊利甚した埓業員の満足床が 91% を超える結果ずなっおいたす。今埌は 2026 幎 4 月から新入瀟員研修ぞの本栌掻甚を予定しおいるそうです。 株匏䌚瀟ラクス様、䌝祚䜜成 AI ゚ヌゞェントの構築ず、品質を支える評䟡蚭蚈の取り組み 株匏䌚瀟ラクス様は、「楜楜粟算」などの SaaS を提䟛する IT サヌビス䌁業です。経費粟算業務では䌝祚䜜成が手䜜業に䟝存しおおり、担圓者の負荷が課題でした。これを解決するために、Amazon Bedrock ã‚’䞭心ずした䌝祚䜜成 AI ゚ヌゞェントを構築し、AWS Generative AI Innovation Center ず協業しおオフラむン・オンラむン双方の評䟡蚭蚈を敎えたした。その結果、品質を維持しながら゚ヌゞェントをリリヌスできる䜓制が敎ったそうです。今埌ぱピ゜ヌド蚘憶を掻甚した自己改善ルヌプの実珟を目指しおいたす。 ITbook 株匏䌚瀟様の AWS 生成 AI 掻甚事䟋提案曞のドラフト䜜成を十日から半日に短瞮 ITbook 株匏䌚瀟様は、自治䜓・囜向けのコンサルティングを行う䌁業です。芁件文曞からの提案曞䜜成には玄 10 日かかっおおり、担圓者の負荷が課題でした。これを解決するために、Amazon Bedrock AgentCore Runtime / Gateway ず Amazon OpenSearch Service によるベクトル怜玢を組み合わせ、芁件抜出・アりトラむン䜜成・本文生成を段階的に行う仕組みHuman-in-the-loopを構築したした。その結果、提案曞のドラフト䜜成期間を半日に短瞮し、担圓者が思考に䜿える時間を 2 倍以䞊に増やすこずができたそうです。今埌は民間䌁業ぞの展開も怜蚎しおいたす。 AWS Local Executive Roadshow 博倚線: 株匏䌚瀟オヌレックホヌルディングス様、生成 AI 利甚犁止から党瀟員の 4 割が掻甚する組織ぞ 株匏䌚瀟オヌレックホヌルディングス様は、犏岡県に拠点を眮く埓業員 580 名の蟲業機械メヌカヌです。圓初は情報挏えいなどのリスクを懞念しお生成 AI の利甚を犁止しおいたしたが、方針を転換し、AWS のオヌプン゜ヌス゜リュヌション「Generative AI Use Cases JPGenU」を導入したした。その結果、党瀟員の玄 40%200 名が日垞的に利甚するたでに広がり、特蚱調査や法什チェックずいった専門業務ぞの掻甚にも広がっおいるそうです。犁止から掻甚ぞの転換プロセスが語られおいる開催レポヌトです。 ブログ蚘事「【開催報告 & 資料公開】公共分野における AI 掻甚最新アップデヌト」を公開 2026 幎 4 月 28 日に開催された AWS 公共セミナヌの開催報告です。デゞタル庁の察話型怜玢システム「源内」や囜土亀通省の「RAPID」、぀くば垂、品川区、藀田医科倧孊、東北倧孊、東京科孊倧孊の Swallow プロゞェクトなど、Amazon Bedrock ã‚„ Amazon Bedrock AgentCore、Amazon SageMaker HyperPod、Kiro ã‚’掻甚した公共分野 8 事䟋が䞀挙に玹介されおいたす。公共機関における生成 AI 掻甚の最前線を知りたい方におすすめです。 【ブヌス展瀺報告】AWS Summit Japan 2026 䞍動産ブヌス 䞍動産業の未来を、生成 AI で切り拓く この蚘事では、AWS Summit Japan 2026 の䞍動産ブヌスで展瀺された 4 ぀の生成 AI ゜リュヌションを、開発・流通・管理・可芖化の芖点から玹介しおいたす。郜垂分析を行う AI ゚ヌゞェントや AI コンシェルゞュ、斜蚭管理向けデゞタルツむン、Amazon Quick ã‚’䜿ったデヌタ可芖化など、Amazon Bedrock AgentCore ã‚„ Amazon Connect Customer AI Agents を掻甚した展瀺の様子がたずめられおいたす。 ブログ蚘事「Kiro ずずもに医療情報システムのガむドラむン遵守開発に挑む」を公開 医療情報システムの開発では、倚数の業界ガむドラむンぞの準拠が求められたす。この蚘事では、AI を掻甚した IDE である Kiro ã«æ¥­ç•ŒçŸ¥è­˜ïŒˆAgent Skillsず開発暙準Agent Steeringを教え蟌み、いわば「チヌムの䞀員」ずしお育おおいくアプロヌチを、䌁画・準備・開発・改善の 4 フェヌズに分けお解説しおいたす。芏制の厳しい業界で AI コヌディング゚ヌゞェントを掻甚したい方の参考になる内容です。 ブログ蚘事「Kiro Web が GitLab ず GitHub をたたぐ倉曎を 1 セッションで調敎」を公開 ブラりザで動䜜する Kiro Web が GitLab に察応し、GitHub ず GitLab のリポゞトリを同䞀セッションにアタッチしお、1 回の指瀺でそれぞれにマヌゞリク゚ストずプルリク゚ストを生成できるようになりたした。合わせお、新しい実隓的ビュヌ「 Agent Focus 」も玹介されおおり、゚ヌゞェントパネル・チャットパネル・補助パネルの 3 パネル構成でチャットファヌストな䜜業ができるようになっおいたす。耇数のリポゞトリをたたいだ開発をされおいる方は芁チェックです。 ブログ蚘事「Kiro で OpenAPI / Swagger 仕様からテストスむヌトを数秒で生成する」を公開 この蚘事では、Kiro ã« OpenAPI / Swagger 仕様を枡すだけで、axios や Express モックを䜿った Node.js のテストスむヌトを数秒で生成する手法を玹介しおいたす。単玔なコヌド生成ツヌルずの違いずしお、削陀のラむフサむクル怜蚌や認蚌ぞの察応、CI/CD 䞊でのヘッドレスな再生成たで螏み蟌んで解説されおおり、API テストの自動化を怜蚎しおいる方の参考になりたす。 サヌビスアップデヌト Claude Sonnet 5 が AWS で利甚可胜に Anthropic の Claude Sonnet 5 が、Amazon Bedrock ず Claude Platform on AWS の䞡方で利甚可胜になりたした。前䞖代の Sonnet 4.6 から性胜が倧幅に向䞊し、コヌディングや長時間の゚ヌゞェント型タスクにおいお䞊䜍モデルの Opus 4.8 に迫る性胜を、Sonnet の䟡栌垯で利甚できたす。日々の開発ワヌクロヌドのコストパフォヌマンスを重芖する方におすすめのアップデヌトです。 AWS WAF が Amazon Bedrock AgentCore Gateway のサポヌトを远加 AWS WAF ãŒ Amazon Bedrock AgentCore Gateway をサポヌトし、䞀般提䟛が開始されたした。これにより、゚ヌゞェント型 AI ワヌクロヌドが受け取るリク゚ストに察しおも、Web アプリケヌションず同様の脆匱性察策を適甚できるようになりたす。゚ヌゞェントを本番運甚する䞊でのセキュリティ境界を匷化したい方に有甚な機胜です。 Amazon Bedrock AgentCore が 4 ぀の远加リヌゞョンで利甚可胜に、デフォルトのランタむムクォヌタも増加 Amazon Bedrock AgentCore ãŒã€ã‚¢ã‚žã‚¢ãƒ‘シフィックバンコク、アゞアパシフィックマレヌシア、欧州ミラノ、欧州スペむンの 4 リヌゞョンで新たに利甚可胜になりたした。あわせお、デフォルトのランタむムクォヌタも匕き䞊げられ、最倧 5,000 の同時セッションを申請なしで利甚できるようになっおいたす。グロヌバルに゚ヌゞェントを展開したい方、倧芏暡なトラフィックを芋蟌んでいる方の䞡方にずっお嬉しいアップデヌトです。 Amazon SageMaker AI が Gemma 4 のサヌバヌレスモデルカスタマむズに察応 Amazon SageMaker AI が、Google DeepMind のオヌプンりェむトモデル Gemma 4E4B / 31Bのサヌバヌレスなモデルカスタマむズに察応したした。むンフラのプロビゞョニングやクラスタヌ管理を SageMaker AI に任せながら、独自デヌタでのファむンチュヌニングが行えたす。アゞアパシフィック東京を含むリヌゞョンで利甚可胜です。 Amazon SageMaker AI のコンテナむメヌゞキャッシュで、スケヌルアりト時間を最倧半枛 Amazon SageMaker AI の掚論゚ンドポむントに、コンテナむメヌゞのキャッシュ機胜が远加されたした。スケヌルアりト時にコンテナむメヌゞのダりンロヌドを埅぀時間を短瞮でき、最倧で半分皋床たで起動時間を削枛できたす。トラフィックの急増に合わせお掚論むンフラを玠早く拡匵したい方に嬉しいアップデヌトです。 Amazon SageMaker Unified Studio が Terraform でのプロビゞョニングに察応 Amazon SageMaker Unified Studio のプロゞェクトやドメむンを、Terraform を䜿っおコヌドずしお管理・プロビゞョニングできるようになりたした。手動でのコン゜ヌル操䜜に代えお、IaCInfrastructure as Codeの運甚フロヌに組み蟌むこずができたす。デヌタ基盀の構築を Terraform で統䞀的に管理しおいるチヌムにずっお嬉しい機胜です。 Claude Sonnet 5 ãŒ Kiro で利甚可胜に AI を掻甚した IDE である Kiro ã§ã€Anthropic の Claude Sonnet 5 が利甚可胜になりたした。Claude Sonnet 4.6 から倧幅に匷化され、Sonnet の䟡栌垯で䞊䜍モデル Opus 4.8 に近い性胜を発揮したす。米囜東郚バヌゞニア北郚ず欧州フランクフルトから段階的に展開され、1M トヌクンのコンテキストりィンドりにも察応しおいたす。 Kiro IDE v1.0.89 ãŒå…¬é–‹ Kiro IDE の最新バヌゞョン v1.0.89 が公開されたした。セッションの自動埩元やアむドル時のリ゜ヌス消費削枛が行われ、プリペむドのクレゞットパックの残量をダッシュボヌドで確認できるようになりたした。あわせお暩限管理・hooks・steering に関する䞍具合修正も含たれおいたす。 Kiro の埓量課金overage察策が匷化 Kiro ã§ã€åŸ“量課金overageの予枬しづらさに察応する機胜が远加されたした。チヌム向けには AWS Service Quotas 経由でのキャップ蚭定が可胜になり、管理者が Kiro プロファむルごずの overage 䞊限を制埡できたす。個人向けには ã‚¯ãƒ¬ã‚žãƒƒãƒˆãƒ‘ックの事前賌入が远加され、1 クレゞット 0.04 ドルから 5 ドル〜100 ドルのパックを賌入できたす最倧 5 パックたで保有可胜、有効期限 12 カ月。予算管理をしながら Kiro を䜿いたい方に嬉しいアップデヌトです。 AWS Security Hub CSPM が AI Security のベストプラクティス暙準を発衚 AWS Security Hub CSPM に、AI Security Best Practices 暙準が远加されたした。Amazon Bedrock ã‚„ Amazon SageMaker AI などの AI ワヌクロヌドを察象ずした 31 のセキュリティコントロヌルが含たれおおり、蚭定の䞍備を継続的にチェックできたす。AI ワヌクロヌドのセキュリティ䜓制を可芖化したい方に圹立぀アップデヌトです。 Amazon WorkSpaces for AI agents が䞀般提䟛開始 Amazon WorkSpaces for AI agents が䞀般提䟛開始されたした。AI ゚ヌゞェントが Model Context ProtocolMCPを通じお仮想デスクトップ䞊のアプリケヌションを操䜜できるようになる機胜で、レガシヌなデスクトップアプリケヌションを含む既存のワヌクフロヌを自動化したい堎合に掻甚できたす。GUI 操䜜しか手段がない業務に゚ヌゞェントを組み蟌みたい方におすすめです。 AWS Security Agent がアゞアパシフィックの耇数リヌゞョンで利甚可胜に AWS Security Agent が、アゞアパシフィックムンバむ、アゞアパシフィックシンガポヌル、南米サンパりロの各リヌゞョンで利甚可胜になりたした。Kiro ã‚„ Claude Code ず連携したセキュリティレビュヌ機胜も含たれおおり、開発フロヌの䞭でセキュリティチェックを組み蟌みたいチヌムにずっお遞択肢が広がるアップデヌトです。 生成 AI を掻甚したビゞネス倉革に取り組むお客様を支揎する 生成 AI 実甚化掚進プログラム は匕き続き参加䌁業を募集しおいたす。ご興味のある方はぜひご芧ください。 今週は以䞊です。それでは、たた来週お䌚いしたしょう 著者に぀いお 䞉厚 航  (Wataru MIKURIYA) AWS Japan の゜リュヌションアヌキテクト (SA) ずしお、ヘルスケア・ハむテク補造業のお客様のクラりド掻甚を技術的な偎面・ビゞネス的な偎面の双方から支揎しおいたす。クラりドガバナンスや IaC 分野に興味があり、最近はそれらの分野の生成 AI 応甚にも興味がありたす。最近の趣味はカメラです。 週刊 AWS の新しいサムネむルを撮圱したので、是非ご芧ください。 a