ECSで満足していたのに、なぜEKSへ？：事例で学ぶ設計と運用の勘所

ECSで満足していたのに、なぜ EKSへ？ 事例で学ぶ設計と運用の勘所 2025.11.18 CloudNative Days Winter 2025 和⽥ 雄樹 1

⾃⼰紹介 和田 雄樹（Yuki Wada） ウェルスナビ株式会社 システム基盤チーム マネージャー 職歴 システムエンジニアとしての経験を経て、2018年にウェルスナビ入社。 2024年より同社のSREチームのマネージャーをつとめる。 ひとこと 好きなAWSサービスは ECS です。 2 @2025 WealthNavi Inc.

1. EKS採⽤の背景 採⽤技術の変遷 2. ECS と EKS の違い EKSでスモールスタートするには 3. EKS運⽤を⽀える仕組み ⼿間なくマルチテナント運⽤するための設計 4. EKS運⽤の落とし⽳と対策 ECSとの違いで学ぶ 3

1 EKS採⽤の背景 採⽤技術の変遷 © WealthNavi Inc. All Rights Reserved. 44

※ ⼀般社団法⼈⽇本投資顧問業協会「契約資産状況（最新版）（2025年3⽉末現在） 『ラップ業務』『投資⼀任業』」を基にネット専業業者を⽐較 ウエルスアドバイザー 社調べ（2025年6⽉時点） ※ 画⾯はイメージです。

今後のウェルスナビ 🤝 三菱UFJ銀⾏と国内最⼤規模のデジタルバンクを⽴ち上げ、⼀体運営する（26年下期開 業） ウェルスナビ MAP 保険 ロボアド MAP（Money Advisory Platform） デジタルバンク embed 新規 プロダクト 次世代アプリ AI コーポレートIT セキュリティ 情報‧システム統制 ⼈事制度‧採⽤などの管理機能全般 ※画面はイメージです 6 @2025 WealthNavi Inc.

開発組織とプロダクト数の推移 0→1フェーズ 1→10フェーズ 10→100フェーズ 専任SRE不在 急成⻑に伴い発⽣する問題の ⽕消しをしながらモダナイズ 開発組織拡大＆プロダクト増 … AI MAP データ基盤 ID基盤 ウェルスガイド 保険 ロボアド 2015 ~ 2017年 2018 ~ 2023年 2021年11月 2018年3月 開発者 : 約45名(3チー ム) SRE: 4名(シニア :1/ミドル :3) 開発者 : 約20名(2チーム） SRE: 2名(ミドル :1/ジュニア :1) 7 2024 ~ 2025年 2025年9月 開発者 : 100名以上 (10チーム ) SRE: 9名(シニア :2/ミドル :3/新卒 :4) @2025 WealthNavi Inc.

開発組織とプロダクト数の推移 0→1フェーズ 1→10フェーズ 10→100フェーズ 専任SRE不在 急成⻑に伴い発⽣する問題の ⽕消しをしながらモダナイズ 開発組織拡大＆プロダクト増 … AI map データ基盤 EKS ID基盤 （新規プロダクト） ウェルスガイド 保険 EC2 ECS ロボアド 2015 ~ 2017年 2018 ~ 2023年 2021年11月 2018年3月 開発者 : 約45名(3チー ム) SRE: 4名(シニア :1/ミドル :3) 開発者 : 約20名(2チーム） SRE: 2名(ミドル :1/ジュニア :1) 8 2024 ~ 2025年 2025年9月 開発者 : 100名以上 (10チーム ) SRE: 9名(シニア :2/ミドル :3/新卒 :4) @2025 WealthNavi Inc.

技術スタック ※2025年10⽉時点 新規プロダクト ロボアド フロントエンド / モバイル バックエンド インフラ 認証基盤 / データ基盤 モニタリング / セキュリティ 開発ツール AI 9 @2025 WealthNavi Inc.

ECS の利⽤状況 ※2025年10⽉時点 利⽤開始 タスク定義数 サービス数 2019年7⽉ 160 80 （dev/stg環境: 900） （dev/stg環境: 450） リリースパイプライン リリース回数 スタンドアロンタスク実⾏数 ShellScript + jsonnet + ecspresso + ecschedule 23/⽉ 131/⽇ （2025年10⽉） （1⽇に何度も実⾏されるものは集計除外） 利⽤機能 開発者数 ユーザー数 Fargate, ALB/NLB Integration, App Auto Scaling, Service Discovery, B/G Deploy 34名 / 6teams 45万⼈ （2025年10⽉） （2025年6⽉） 10 @2025 WealthNavi Inc.

複数チームで ECS を運⽤するための⼯夫点① ⚙ ライフサイクルやオーナーを意識し、3種類のリポジトリで構成を管理 インフラ アプリ リリース 変更頻度: ★ 低い 変更頻度: ★★★ ⾼い 変更頻度: ★★ ⾼い 参照 Infra Repo （monorepo） SRE AWS Resources 承認 App Repos （100 repos以上） ECR Release Repo （monorepo） ECS Scheduled Task 開発者 参照: タスク数100超え！モノレポとエスプレスタックで⽀えるECS管理の仕組み | WealthNavi Engineering Blog https://zenn.dev/wn_engineering/articles/13fc8c2d35c191 11 @2025 WealthNavi Inc.

• https://zenn.dev/wn_engineering/articles/13fc8c2d35c191

複数チームで ECS を運⽤するための⼯夫点② ⚙ ライフサイクルを意識し、汎⽤的なTerraformモジュールを提供 ECS Baseモジュール n 1 ECS Serviceモジュール 変更頻度: ★ 低い 変更頻度：★★ ⾼い ECS TaskDef(dummy) Route 53 Record IAM Role & Policy CloudWatch Log Group Firehose Stream Security Group ECS Service ELB Target Group ELB Listener Rule App Auto Scaling CodeDeploy Group(optional) (optional) モジュールの抽象度や集約度を高めると各リソースのライフサイクルの違いが障壁になる ○ 例えば、ECSサービスの設定の変更は、サービスの再作成が必要になる場合がある ○ 当社では、モジュールを別けることで ECS サービスを複数作り、無停止での設定変更を実現している 12 @2025 WealthNavi Inc.

複数チームで ECS を運⽤するための⼯夫点③ ⚙ DB や ECSサービスを、⽬的ごとに⽴ち上げられる仕組みを提供 稼働スケジュール 登録 開発者 データベース 稼働スケジュール 取得 desired count 変更 Release Repo （schedule trigger） ECS クラスタ複製 起動/停止/削除 Aurora Notionで必要な依存コンポーネントや稼働時間を指定するだけ 参照: 開発環境の稼働スケジュールをNotionとecspressoで管理してみた | WealthNavi Engineering Blog https://zenn.dev/wn_engineering/articles/9e5b6ee94e6b39 13 @2025 WealthNavi Inc.

• https://zenn.dev/wn_engineering/articles/9e5b6ee94e6b39

運⽤を⾒直すきっかけ ※2023年12⽉当時 😢 今後を⾒据えた際、独⾃に作り込まれた仕組みが⾜枷になる恐れ ● 事業 ○ ● 組織 ○ ● 開発者の急増に伴い、開発‧運⽤ツールに対する習熟度の格差が拡⼤ 技術 ○ ● シングルプロダクト → マルチプロダクトへの移⾏ ツールやパイプラインをマルチプロダクト対応するためには、⼤幅な修正が必要 コスト ○ Terraform向けCI/CDサービスのコスト増加（apply数 → リソース数課⾦に変更） 14 @2025 WealthNavi Inc.

プラットフォーム作りの落とし⽳ 🤔 意図せず Golden Cage 状態に近付いていないか？ Golden Path Golden Cage 目的 開発者が価値提供に集中できるよう、 認知負荷を下げる。 さらなる開発者負担の軽減。 実装 適切な抽象化を行い、開発者の意見と現場状 況を取り込みながら継続的に改善する。 仕組みが不透明になり、理解・変更が困難になる。 運用が特定の人に依存する。 効果 開発者体験の向上。 生産性向上と市場投入までの時間短縮。 短期では負担減に繋がるが、変化に追従できない 場合、技術負債や停滞の原因になる。 チェックリスト ○ ○ ○ 変更が必要になったとき、開発者は自分たちで改善できるか？ 異常時、開発者は自分たちで原因を追えるか？ 開発者による新しい試行が妨げられていないか？ 15 @2025 WealthNavi Inc.

まとめ 🏔 運⽤のスケーラビリティ向上のため、1から新規プロダクト向けの基盤を作ることに ● 成⻑を続ける環境の「⾃動化‧抽象化」は難しい ○ ● 事業、組織、技術、コスト変化のタイミングが重なった ○ ● 「使いやすさ」と「変化への適応⼒」が両⽴した状態を保ち続ける努⼒が必要 ⼤きく仕組みを変える好機だった 特定プロダクトに最適化された仕組みが量産されるのを防ぎたかった ○ 薄く抽象化し、開発チームの成熟度に応じて柔軟に拡張できる仕組みを提供したい → Kubernetes の可能性を模索することに 16 @2025 WealthNavi Inc.

2 1 ECS と EKS の違い EKSでスモールスタートするには © WealthNavi Inc. All Rights Reserved. 17

ECS と EKS の特徴 📍 シンプルさのECS、柔軟性のEKS ● ECS ○ ○ ○ ● AWSが開発したコンテナオーケストレーションサービス 最も⾼く評価されている点は、そのシンプルさ コンピューティング、ネットワーク、セキュリティ設定の意思決定を減らせる EKS ○ ○ ○ OSS（Kubernetes）ベースのコンテナオーケストレーションサービス エコシステムとコミュニティ、⼀貫性のあるオープンなAPI、柔軟性 上記を理由に、多くのチームがKubernetesを選択 参照: Amazon ECS vs Amazon EKS: making sense of AWS container services https://aws.amazon.com/jp/blogs/containers/amazon-ecs-vs-amazon-eks-making-sense-of-aws-container-services/ 18 @2025 WealthNavi Inc.

• https://aws.amazon.com/jp/blogs/containers/amazon-ecs-vs-amazon-eks-making-sense-of-aws-container-services/

ECS か EKS？ の議論が尽きない理由 🤔 AWSはどちらを使っても⼤丈夫と⾔っている ”特定のアプリケーションの要件や個々のチームの好みに合わせて選択してください。 すべてを網羅した決定を下す必要はありません。コンテナのポータビリティにより、 どのような決定を下しても、それが⼀⽅通⾏になることはありません。” 参照: Amazon ECS vs Amazon EKS: making sense of AWS container services https://aws.amazon.com/jp/blogs/containers/amazon-ecs-vs-amazon-eks-making-sense-of-aws-container-services/ 19 @2025 WealthNavi Inc.

• https://aws.amazon.com/jp/blogs/containers/amazon-ecs-vs-amazon-eks-making-sense-of-aws-container-services/

論点1：どのコンテナ実⾏基盤を選択するか？ 📍 当社が全⾯的に採⽤している Fargate を前提に話を進める（採⽤理由は後述） EC2 Managed Instances （Auto Mode） Fargate アプリケーション ユーザー管理 ユーザー管理 ユーザー管理 OS ユーザー管理 AWS管理 AWS管理 ・DaemonSet非対応 ・イメージキャッシュ非対応 ノード AWS管理 AWS管理 AWS管理 ・スケールの管理が必要 ・Pod単位のSG未対応 ・GPU非対応 ・16vCPU/120GBが上限 ・キャパシティ予約不可 ・eBPF非対応 20 @2025 WealthNavi Inc.

ECS と EKS の違い 📝 AWSサービスとの連携部分が⼤きく違う ECS 違い EKS Container Container なし Task + Service Pod + Deployment + Service なし Integration Controller ALB/NLB統合 SecretsManager統合（Taskからの参 照機能）など Load Balancer Controller External Secret Operatorなど あり （ECS/EKS以外のAWSサービスと の連携部分） Control plane Control plane なし（AWS管理のため） Data plane Data plane なし（Fargateのため） 21 @2025 WealthNavi Inc.

シンプルさのECS 👍 「シンプルさのECS」は「AWSサービスとの連携⽅法」にあり ● Integration（ECS） ○ ● ほぼ有効化するだけ ■ ALB/NLBとの連携：ALBとTGを指定 ■ SecretsManagerとの連携：Task定義でSecretsManagerキーのARNを指定 ■ BlueGreen Deploy：Built-in機能を設定するだけ Controller（EKS） ○ 連携するAWSサービスごとに専⽤ツール（Controller）が必要 ■ ALB/NLBとの連携：Load Balancer Controller ■ SecretsManagerとの連携：External Secrets Operator ■ BlueGreen Deploy：Argo Rollouts 22 @2025 WealthNavi Inc.

柔軟性のEKS 👍 「柔軟性のEKS」は「Controller」にあり 1. 定義を更新する 2. 期待状態になるようリソースを調整 開発者「コンテナ数を 1→2にしたい」 Controller1「コンテナを 2つにしよう」 Controller2「コンテナが増えたみたいだから、 LB に登録しよう」 コンテナ 期待する状態を 定義して登録 定義内容受 Kubernetes apiserver / etcd 開発者 Controller 期待した状態になるよう調整 （逸脱時は定義に沿うよう調整） ステータス更新 ロードバランサ コミュニティのControllerが豊富で、⾃作もできる 23 @2025 WealthNavi Inc.

論点2：どこまでをKubernetesで管理するか？ 🤔 正解はない。チームのケイパビリティ、コスト、オンプレ有無など観点は様々 ● A. Kubernetes内で完結させる ○ Pros: ポータビリティ向上+エコシステム恩恵 ○ ● Cons: 信頼性やスケーラビリティを確保するため、k8sやインフラの深い知識が必要 B. AWSマネージドサービスを積極活⽤（採⽤） ○ Pros: 信頼性やスケーラビリティを確保しやすい ○ ○ Cons: Terraform⽤のコードと、k8s⽤のコードを⾏き来する必要がある Cons: AWSリソースを管理するためのController/Operatorが増える 24 @2025 WealthNavi Inc.

まとめ 👍 引き返しやすい技術選定をすれば、安⼼してスモールスタートできる ● シンプルさのECS、柔軟性のEKS ○ ○ ● コミュニティのControllerで薄く抽象化でき、柔軟に拡張しやすいEKSを採⽤した EKSの柔軟性を活かすには、どこまでをKubernetesで管理するか？など⽅針決めも⼤切 ⼀⽅通⾏になることはないが、引き返す時の難易度が変わる ○ ○ 引き返しやすさを考慮し、AWSサービスに置き換えが容易な技術を選定する⽅針とした スモールスタートおよびガードレール⽬的で、⾃由度が低く、設計考慮点が少ない Fargateを採⽤した 25 @2025 WealthNavi Inc.

3 1 EKS運⽤を⽀える仕組み ⼿間なくマルチテナント運⽤するための設計 © WealthNavi Inc. All Rights Reserved. 26

論点3：EKSクラスターはマルチテナントにすべきか？ 📍 スモールスタートさせる⽬的でマルチテナント（共有）⽅式を採⽤ ● A. 複数プロダクトでクラスターを共有（採⽤） ○ ○ ○ ● Pros: 運⽤対象のクラスタが1つになるため管理が楽（導⼊初期フェーズでは） Cons: 権限設計やコード管理⽅針を整備しなければ闇が⽣まれやすい Cons: 依存性が⾼いコンポーネントの障害発⽣時の影響（CoreDNSなど） B. プロダクトごとにクラスターを分離 ○ ○ Pros: クラスタ障害の影響範囲を最⼩化できる Cons: ⼩規模なプロダクトを連続で⽴ち上げる場合のコスパの悪さ ■ ○ EKSクラスタ ‧監査ログ‧GuardDuty‧Detective料⾦など Cons: クラスタ運⽤を⾃動化しなければ運⽤コストが上がっていく 参照: マルチアカウント戦略 - Amazon EKS https://docs.aws.amazon.com/ja_jp/eks/latest/best-practices/multi-account-strategy.html 27 @2025 WealthNavi Inc.

• https://docs.aws.amazon.com/ja_jp/eks/latest/best-practices/multi-account-strategy.html

マルチテナントアーキテクチャ 共用リソース プロダクト毎のリソース 󰡇 NW、Manifest、リポジトリ、CI/CDなどを標準化‧テンプレ化して開発者に提供 push プロダクト用 EKS用 ECR用 参照 参照 App Cluster Ops Cluster App Repo App Imge Manifest Repo apply namespace Argo CD IRSA ネットワーク用 Helm Repo Helm/OCI RAMで VPC共有 28 @2025 WealthNavi Inc.

EKS の利⽤状況 ※2025年10⽉時点 利⽤開始 プロダクト数 アプリケーション数 2024年4⽉ 9 52 （⾮公開プロダクト含む） （dev/stg環境: 181） リリースパイプライン リリース回数 Workflow実⾏数 Argo CD + Argo Image Updater 37/⽉ 5/⽇ （2025年10⽉） （1⽇に何度も実⾏されるJobは集計除外） 利⽤ツール 開発者数 ユーザー数 LBC, ESO, Kyverno, Argo Workflows, Backstage, Spring Cloud Gateway 25名 / 6teams ⾮公開 （2025年10⽉） 29 @2025 WealthNavi Inc.

AWSアカウント設計 ⚙ AWSサービスクォータやデータガバナンスを考慮し、プロダクトで別ける⽅針に ● IAM Identity Center と AFT でAWSマルチアカウント管理を省⼒化 ○ AFT = AWS Control Tower Account Factory for Terraform AWSアカウント 作成定義を追加 account-request SRE terraform apply AFT 新規AWSアカウント （プロダクト x 環境単位） ログイン 開発者 外部IdP 標準で必要な IAM Roleなどの定義 account-customizations 30 @2025 WealthNavi Inc.

ネットワーク設計 ⚙ ネットワークは共有した⽅が運⽤‧AWSコスト観点でメリットがあると判断 ● VPCリソースを Resource Access Manager で共有 ○ VPC Subnet / VPC Endpoint / NAT Gateway / Network Firewall ● 既存プロダクト間の接続は SecurityGroup で制御 ○ TGW経由で接続元のSGIDを指定できる機能を採⽤（2024年9⽉リリース） 既存プロダクト プロダクト用 EKS用 ネットワーク用 RAMで VPC共有 31 @2025 WealthNavi Inc.

オブザーバビリティ設計 ⚙ Fargateの良さを活かし、マネージドな要素を組み合わせてDatadogに集約 ● ログ ○ ○ ○ ● EKS / Fargate Node Fluent Bitベースの組み込みLog Routerを利⽤する Firehoseでバッファリング KPIデータはBigQueryへ Pod App Container メトリクス‧トレース ○ メタデータ付与 S3 built-in Log Router BigQuery Data Transfer Service Firehose サイドカーのdd-agent経由で収集する dd-agent Sidecar Datadog 32 @2025 WealthNavi Inc.

CI/CD設計 ⚙ Argo CD（GitOps）を採⽤し、Manifest Repo経由以外の変更を禁⽌する 常にコードと実環境の同期が とれている状態を維持する 参照 push App Repo ECR App Imges apply 参照 Manifest Repo システムの期待する状態を定義 （監査のため Pull Request経由を強制） Argo CD （Controller） EKS 手動変更によるコードと実環境の ズレが発生することを防ぐ 開発者 33 @2025 WealthNavi Inc.

IaC設計 ⚙ 標準構成をHelmで抽象化し、開発者がマニフェストを書く負担を最⼩限に Helm Chart Deployment(app/datadog) Ingress / Service ServiceAccount / CRB Chart.yaml（Argo CD設定） values.yaml（Helmパラメーター） spec: source: path: helm/basic-app helm: valueFiles: - ../../app1/values.yaml basic-app: image: repository: <image uri> replicaCount: 2 … SecurityGroupPolicy 参照 push 参照 apply HorizontalPodAutoscaler PodDisruptionBudget Helm Repo ECR (Helm) Manifest Repo Argo CD EKS ECR (App) 34 @2025 WealthNavi Inc.

コスト管理設計 ⚙ 複数プロダクトのコスト按分が簡単にできる Datadog で可視化 ● Datadogにて eks.fargate.{cpu, memory}.capacity と aws.billing.estimated_charges メトリクスを元に、プロダクト毎のコストを算出 ● 分割コスト配分データ機能 により、CostExplorer でコスト内訳表⽰も可能 （ただし、以下の理由から不採⽤） ○ ○ ArgoCDなどの共有リソースの按分が簡単にできない RDSやS3などプロダクト毎に存在するAWSコストを含めた表⽰が簡単にできない 35 @2025 WealthNavi Inc.

論点4：クラスターのアップグレード⽅式はBlue/GreenかIn-Placeか？ 📍 即座に可⽤性に影響を与えるツールは採⽤していないため、In-Placeを採⽤ ● A. Blue/Green⽅式 ○ ○ ● Pros: 事前確認がしやすく、問題発⽣時の切り戻しが容易 Cons: 効率化を考えなければ運⽤⼯数が⾼い（In-Placeと⽐較して） B. In-Place（採⽤） ○ ○ Pros: ⼿軽（クラスタと各コンポーネントのアップグレード→kubectl rollout restart） Cons: ダウングレードできない 導入ツール 用途 停止時の影響 Load Balancer Controller ALB/NLBとの連携 オートスケール不可（dev/stg環境で容易に事前検証可能） External Secrets Operator SecretsManagerとの連携 DB接続などが不可（dev/stg環境で容易に事前検証可能） Argo CD GitOpsを実現するためのもの デプロイ不可 kyverno Manifestのポリシー管理 ポリシー違反のリソースをブロックできない 36 @2025 WealthNavi Inc.

まとめ 👍 マルチテナント運⽤に対応した EKS 環境を作れた ● 後で変更することが難しい点は何かを考える ○ ● 開発者の負担になる要因が何かを考える ○ ● ネットワークや、AWSアカウント分割など Manifestをテンプレート管理しないこと、パイプラインを組まないこと 提供価値と運⽤コストを天秤にかける ○ 特に問題発⽣時、即座に可⽤性に影響を与えるツールを導⼊する場合 37 @2025 WealthNavi Inc.

4 1 EKS運⽤の落とし⽳と対策 ECSとの違いで学ぶ © WealthNavi Inc. All Rights Reserved. 38

Fargateの落とし⽳（Fargate Pod Evictions） ⚠ ECS のようにノードのメンテナンス時に Rolling Update してくれない ● ● 隔週でFargate Pod の強制終了予告がくる（体感） ○ 再起動するだけではあるが、ECSと違いRolling Updateしてくれない ○ 2つPodが起動していても同時に落とされる可能性あり 対策 ○ PDB設定を入れて、Rolling Update相当の挙動を実現する ■ minAvailable: "50%" など最低稼働台数をHelm chartに定義しておく 39 @2025 WealthNavi Inc.

CoreDNSの落とし⽳ ⚠ ECS とは違い、k8s内部で利⽤するDNSサーバーのスケールを考慮する必要がある ● ● CoreDNS はデフォルトのままだと Pod数が 2 で固定されている ○ CoreDNSはEKSクラスタを構築すると自動で起動するコンポーネント ○ 停止するとPod間やクラスター外への通信に影響が生じる 対策 ○ EKSアドオンのオートスケール機能を利用する ■ スケールの上限値は2〜1,000で設定設定可能 参照: CoreDNS ポッドを⾼い DNS トラフィックにスケールする - Amazon EKS https://docs.aws.amazon.com/ja_jp/eks/latest/userguide/coredns-autoscaling.html 40 @2025 WealthNavi Inc.

• https://docs.aws.amazon.com/ja_jp/eks/latest/userguide/coredns-autoscaling.html

GitOps の落とし⽳ ⚠ 開発環境の夜間停⽌は GitOps との相性が悪い ● ● Argo CD が常にgitリポジトリと実環境の差分を同期し続ける（停止できない） ○ 夜間に起動数を0に変更しても、数分後にはArgo CDが起動数を戻してしまう ○ EKS on EC2 であればノードを停止すればPodは起動しない ○ ECS（CloudFormation）の場合はDesiredCountを明示しないことで回避できる 対策 ○ 同期設定を無効化＆replica=0に、翌朝元に戻すCronJobを定義する 参照: EKS Fargate Podsを⾃動停⽌する仕組みを実装してみる https://zenn.dev/wn_engineering/articles/eks-fargate-auto-scheduler 41 @2025 WealthNavi Inc.

• https://zenn.dev/wn_engineering/articles/eks-fargate-auto-scheduler

IaC境界の落とし⽳ ⚠ 使い込もうとすると、Manifest と Terraform の責務を理解する必要がある ● ● 学習コストの増加 ○ ECS は Terraform で完結させることができる ○ EKS は Manifest と Terraform の責務の境界を決め、理解する必要がある 対策 取り組み中 ○ BackstageのTemplate機能、AIなどを活用して負担を軽減する ○ AWS Controllers for Kubernetes（ACK）やCrossplaneで責務の境界を調整する 42 @2025 WealthNavi Inc.

5 1 さいごに © WealthNavi Inc. All Rights Reserved. 43

さいごに 󰢧 どのような決定を下しても、それが⼀⽅通⾏になることはありません ● ● ECS と同じくらいシンプルに EKS を使うという選択肢 ○ Fargateを使う、Helmで抽象化する、などの工夫次第で実現可能 ○ 組織やプロダクトのニーズに合わせ、FargateからAuto Modeへの移行も可能 成否は、顧客や開発者に価値を感じてもらえるラインまで走り続けられるか次第 ○ 提供価値と運用コストのバランスを考える ○ 前提が変わっていないか確認する 44 @2025 WealthNavi Inc.

イベントのおしらせ 3社のSREチームが集まって、それぞれの現場で実際にぶつかった課題や 試行錯誤の末にたどり着いた解決策などを、赤裸々にお話しします！ 45 @2025 WealthNavi Inc.

ご清聴ありがとうございました 46 @2025 WealthNavi Inc.

【重要な注意事項】 ● 本資料は、断定的判断を提供するものではなく、情報を提供することのみを⽬的としており、いか なる種類の商品も勧誘するものではありません。最終的な決定は、お客様⾃⾝で判断するものと し、当社はこれに⼀切関与せず、また、⼀切の責任を負いません。 ● 本資料には将来の出来事に関する予想が含まれている場合がありますが、それらは予想であり、ま た、本資料の内容の正確性、信頼性、完全性、適時性等を⼀切保証するものではありません。本資 料に基づいて被ったいかなる損害についても、当社は⼀切の責任を負いません。また、当社は、新 しい情報や将来の出来事その他の情報について、更新⼜は訂正する義務を負いません。 ● 本資料を利⽤することによりお客様に⽣じた直接的損害、間接的損害、派⽣的損害その他いかなる 損害についても、当社は⼀切の責任を負いません。 商号等：ウェルスナビ株式会社 金融商品取引業者 関東財務局長（金商） 第2884号 加入協会：日本証券業協会 一般社団法人日本投資顧問業協会 47 @2025 WealthNavi Inc.