スタートアップにAmazon EKSは早すぎる？ マルチプロダクト戦略を加速する Platform Engineeringの実践 AWS Summit Japan 2026 2026年6月26日 株式会社ログラス 

自己紹介 中井 綾一 Ryoichi Nakai 株式会社ログラス SRE 株式会社ログラス 技術基盤部 クラウド基盤チームに所属。 前職では合同会社DMM.comで、Platform Engineeringに取り組んでいた。 2024年よりログラスのクラウド基盤チームに参画。 

No content

No content

No content

EKSを採用したのは1年前 • 当時エンジニア50名弱、リリース済みプロダクトは2つ • この規模でEKSの採用は早いと思われるかもしれない 本セッションで話す3つのこと • なぜEKSを選んだのか？ • どう活用しているのか？ • 1年間の実践による変化と得た学びは何か？ 本セッションについて 

なぜEKSを選んだのか？ 

なぜEKSを選んだのか？ • プロダクトの機能提供・ユーザへの価値創造が急務 • 運用の土台となる部分はSREが巻き取って、対応していた • アプリケーションインフラ(ECS)の構築・運用 • リリースパイプラインの構築・運用 • 可観測性の担保・パフォーマンス監視・アラート • 脆弱性管理・セキュリティ対応 • 依頼やトラブルがあれば、 都度、コミュニケーションをとって解決していた シングルプロダクト時代のSRE体制（2019〜2024年） 

なぜEKSを選んだのか？ • 経営管理領域のBtoB SaaSとして着実に成長してきた • お客様により大きな価値を届けるには、経営管理だけでない領域にもチャレンジが必要 • この方針のもと、マルチプロダクト戦略を開始。PoCを経て、いくつかのプロダクトをリリース • 最初の数プロダクトは、SREが人海戦術でECSベースのインフラ構築等、運用の土台となる部分を担当 マルチプロダクト戦略の開始（2024年〜2025年） 

なぜEKSを選んだのか？ 同時並行で以下のことが進んでいた • プロダクト数をさらに増やそうとする動き • 共通サブシステムの開発 (認証認可・テナント管理等) このまま進んでいった場合の未来 • 採用難易度が高いSREを プロダクトごとに人員を増やしていくのは現実的に難しい • 仮に採用できたとしても、 担当者ごとにインフラ構成・運用方針がばらつき、品質にブレが出る マルチプロダクト開始で見えた限界（2025年〜） 人海戦術で対応する構造そのものを変えないといけなかった 

なぜEKSを選んだのか？ 開発チームがSREに頼らずに、自律して開発を進めることができる体制 が理想 • SREの人海戦術ではリソース確保も品質維持も難しいため、開発効率が落ちてしまう • 開発者自身が運用まで意識して設計・開発することによって、ソフトウェア品質の向上につながる ただし、開発者が「運用の土台作りも含めて全て実践する」は現実的ではない • 開発チームの負担が増えてしまって、ユーザの価値提供に集中できなくなるのは、本末転倒である Platform Engineeringへの転換 開発チームが無理なく自走できる「仕組み(=プラットフォーム)」が必要だと判断 → Platform Engineeringの推進を決断 

なぜEKSを選んだのか？ なぜか → k8sがプラットフォーム運用の思想に沿っていた • Helm/ArgoCD等、強力なエコシステムを利用でき、開発チームに「型」に沿ったテンプレート提供が容易である • サービスディスカバリが標準的に備わっており、通信設計がシンプルにできる • DaemonSetを利用することで、o11y・セキュリティの設定を開発者の負荷なく一括適用できる プラットフォームとしてAmazon EKS (Elastic Kubernetes Service) を選択 EKS自体の運用は発生するが、開発チームの認知負荷をより減らすことができると判断 

なぜEKSを選んだのか？ プラットフォーム構築は1〜2年かかる投資 問題が顕在化してからでは遅い • リソースが足りず、目先の対応に追われ、中長期の整備に余裕がなくなる • 既存の仕組みを見直すコストが膨れ上がっていく → 事業戦略を考えると、これ以上先送りできないタイミングだった なぜこのタイミングだったのか？ 

どう活用しているのか？ — EKSの構成判断 

どう活用しているのか？ — EKSの構成判断 EKS構成判断の全体像 EKSを導入する際に考慮すべき論点 • EKS クラスタ構成 – シングルクラスタ/マルチクラスタ • AWSアカウント構成 – シングルアカウント/マルチアカウント • 実行モード – EKS on AWS Fargate / EKS Auto Mode / EKS on EC2 

どう活用しているのか？ — EKSの構成判断 クラスタ構成の判断 — シングルクラスタを採用 観点 シングルクラスタ マルチクラスタ o11y・セキュリティ統制 一元管理しやすい クラスタごとに設定が必要 アップデート運用 1クラスタのみ クラスタ数分の運用が発生 ノイジーネイバー namespaceレベルの分離のため 発生した場合、クラスタ全体に影響がある クラスタ間で完全分離のため 発生した場合、影響範囲はそのクラスタに閉じる 現在のSREの人数(4人)では、発生するかわからないノイジーネイバーよりも、 クラスタの運用コストを下げることを優先した 

どう活用しているのか？ — EKSの構成判断 シングルクラスタ構成 

どう活用しているのか？ — EKSの構成判断 アカウント構成の判断 — マルチアカウントを採用 観点 シングルアカウント マルチアカウント リソース分離 他チームのリソースに影響が出やすい チームごとにAWSリソースの 影響を完全分離 管理コスト アカウントが1つでシンプル アカウント数分の管理が必要 セキュリティ境界 AWS IAMで細かく制御する必要がある アカウント境界で自然に分離 シングルアカウントの場合、プロダクトごとのリソースの権限設計・管理が複雑になりやすい → アカウント境界で権限を分離する方がシンプルと判断した 

どう活用しているのか？ — EKSの構成判断 シングルクラスタ・マルチアカウント構成 

どう活用しているのか？ — EKSの構成判断 EKSモードの判断 — EKS on EC2を採用 項目 EKS on AWS Fargate EKS Auto Mode EKS on EC2 概要 Nodeを意識せずに利用できる 最適なNodeをAWS側で提供 Nodeも含めて、全てユーザ管理 Node管理 AWS管理 AWS管理 ユーザ管理 Managed Addon管理 ユーザ管理 AWS管理 ユーザ管理 DaemonSet 非対応 対応 対応 Security Group for Pod 非対応 非対応 対応 EKS on AWS Fargate: DaemonSetを使えず、 o11y・セキュリティの設定を一括適用したいという我々の要件と合わなかった EKS Auto Mode: シングルクラスタ構成では複数アカウントのRDSへの経路が共存するため、Security Group for Podによるアクセス制御が必須 

どう活用しているのか？ — 開発者体験の設計 

どう活用しているのか？ — 開発者体験の設計 Helm で テンプレート と 設定値(Values) を分離し、SREと開発チームの責務を明確化 1. SREチーム • Helm Template Repoの管理に責務を持つ • k8s/AWSを知らない開発者でも、 簡単にインフラを構築できるように抽象化 • o11yやセキュリティ(PSA/PSS等)の設定を組み込んでいる 2. 開発チーム • Services Repoの自チームのリソースの管理に責務を持つ • Helm Template Repoで公開したvaluesのみを編集可能 k8sマニフェストの構成管理 開発者は簡単にインフラ構築可能 ＋ セキュリティ/可観測性は「標準」として強制 → チーム・サービスが増えても、組織全体の信頼性が一定ラインで揃う 

どう活用しているのか？ — 開発者体験の設計 提供しているHelm Chart Helm Chart 役割 base 環境/Service等、グローバルな設定を管理 一部AWSのリソースもここで管理 (後述) stateless Deployment等のStateless用のWorkloadの設定 events SQS等のイベントをArgo Eventsに連携 workflow Argo Workflowsの設定を管理 Argo Eventsとの連携も可能 migration Argo CD PreSync で Migrationを実行できる Workflow を管理 Services Repoのディレクトリ構成 

どう活用しているのか？ — 開発者体験の設計 ユースケースごとのWorkload Template 利用できるChartだけだと、どう活用すれば良いのかがわかりにくい → 開発チームが使いそうなユースケースごとのサンプル定義 やドキュメントを完備 テンプレート 利用するChart どのような状況で利用するか Web App stateless 単純なWebアプリケーションを動かす 単発実行Job workflow 初期データ投入や不整合解消等の ワンショット実行 定期実行Job events + workflow 定期的に必要なジョブを実行 SQS + Worker base + stateless 短時間向けの非同期処理 KEDAでSQSメッセージごとにスケール可能 SQS + Event + Workflow base + events + workflow 長時間向けの非同期処理 SQS → Argo Events → Argo Workflows 

どう活用しているのか？ — 開発者体験の設計 どれだけk8sリソースの定義を簡易化しても、クラスタ外の AWS リソース（RDS/S3等）の管理は避けて通れない • 従来は k8s マニフェスト＋ 別IaC（Terraform / AWS CloudFormation等）で管理 • 開発者はこの2つの世界を行き来する必要があった ACK（AWS Controllers for Kubernetes）で解決 • ACKを導入すると、各AWSリソースごとのCRを利用でき、 k8sマニフェストだけでAWSリソース管理も可能になる → 別のIaCを利用することによる開発チームのキャッチアップ・運用コストを抑えることができる ACK（AWS Controllers for Kubernetes）の活用 https://aws-controllers-k8s.github.io/docs/intro 

どう活用しているのか？ — 開発者体験の設計 ACK単体の課題: リソース間に依存関係がある場合、作成順序の制御ができない • 例: IAM Policy / IAM Roleを同時にapplyした場合 → IAM Policyがない状態でIAM Roleを作ってしまい、参照するリソースが存在しないためエラーになってしまう kro（Kube Resource Orchestrator）で解決 • AWSを含む複数のパブリッククラウドベンダーが合同で推進しているOSS • 複数リソース間の依存関係を解決し、作成・更新・削除の順序を自動で制御できる ACKとkroの組み合わせは、AWSの記事としても公開されている • Simplify Kubernetes cluster management using ACK, kro and Amazon EKS • AWS at KubeCon EU 2026: Open Source Leadership Meets Production Innovation kro（Kube Resource Orchestrator）との併用 

どう活用しているのか？ — 開発者体験の設計 具体例: Security Groupの自動作成 & Podへの自動付与 従来: 事前にSecurity Groupを作成 + SecurityGroupPolicy でPodに付与 → ACK / kroでvaluesの編集のみで自動的に付与 

どう活用しているのか？ — 開発者体験の設計 • ACK/kroは導入したばかりなので、現在はEKSアカウント内のリソースに絞って提供 • 他アカウントのリソースはSREが作ったTerraformの Module Template を参考に実装してもらっている • 将来的には、RDS・SQS・S3等も含め、開発者はvaluesの修正だけでインフラ設定を完結できる世界を目指す ACK/kro活用の展望 As Is To Be 

1年間の実践による変化と得た学び 

1年間の実践による変化と得た学び 1年間の実績 • EKSを利用しているチーム : 5チーム • EKS上で稼働しているサービス数 : 約20サービス 現在は、新規で作成するサービスを対象にしているが、今後既存のECSで動いているサービスも載せていく方針 1年間でどこまで進んだか 

1年間の実践による変化と得た学び SREと開発チームのコミュニケーションの変化 必要なものはセルフサービスで実現でき、組織としてのスケールが容易に Before After 

1年間の実践による変化と得た学び 開発チームからのフィードバック アンケート結果 • 「プラットフォーム導入により、開発の進めやすさは向上したか？」 → 開発チーム視点でもプラットフォーム導入は大枠よさそうな結果に ポジティブなフィードバック (抜粋) • 「開発者がPRを出して進められるようになった」 • 「構築に時間がかかる非同期処理のアプリケーションを 2日で立ち上げることができた」 

1年間の実践による変化と得た学び • 一方、アンケートでは「トラブルシューティングができる自信がない」という声も多かった • 抽象度の高さとトラブルシューティングの難易度はトレードオフ • 抽象化を高めるほど、初期キャッチアップコストは下がる • 一方で、運用時の自走の難易度は上がってしまう • ログラスでは先述の開発文化だったこともあり、抽象度を高くする方針に倒しているが対処は必要 → 対応方針 • SREによるプラットフォーム周りのイネーブリング強化 • トラブルシューティングパスの整理 および Coding AgentのSkill化による自走支援 悩ましいのは抽象化の度合い 

1年間の実践による変化と得た学び • 正直、EKS導入時にはこの問いに明確な解を出せなかった • Coding Agentが前提となる時代では、開発者が認知負荷となる部分を乗り越えられるのではないか？ • プラットフォームを構築して、変に抽象化してしまうと、むしろ使いにくくなってしまうのでは？ • EKSプラットフォームの構築・運用はSREにとっても難易度が高い、やらない方がマシかも • 1年間やってみた結論 → むしろAI時代だからこそ、EKSによるプラットフォームを構築する価値がある AI時代にEKSプラットフォームを整備する必要はあるのか？ 

1年間の実践による変化と得た学び AI時代だからこそEKSプラットフォームに価値がある理由 開発効率面 • 開発チーム : テンプレートやサンプル実装をCoding Agentに読ませることで、効率よく必要なリソースを用意できる • SREチーム : 設計・実装やトラブルシューティングにCoding Agentを活用することで、構築・運用難易度が低下 品質・統制面 • Namespace 分離・RBAC により、チーム/サービスごとの権限境界を明確化しやすい • Coding Agent も 自分の Namespace で 許可された操作 しか実行できない • Helm への組み込み / Admission Controller (API レベルでのポリシー強制) で、以下を防ぐ仕組みを構築しやす い • セキュリティリスク • 運用負担になるワークアラウンド → Coding Agent が高速に変更を生んでも、人間がレビューをすることなく、品質・統制を機械的に担保できる 

• スタートアップにAmazon EKSは早すぎるのか？ • 「今の規模にあうか」で判断すると、EKSはまだ早いのでは？となってしまう • そうではなく「数年後の事業にフィットするか」で判断する • EKSプラットフォームの構築には時間を要する。必要な時期から逆算して取り組むべき • ログラスの歩みと現在地 • マルチプロダクト戦略でSRE体制の限界に直面し、Platform Engineeringへ舵を切った • EKS + Helm + ACK + ArgoCDで「開発者が自走でき、統制も効く」プラットフォームを構築した • 1年間で約20のサービスが稼働し、セルフサービス化が進んだ • トラブルシューティング周りのしやすさ等、まだまだ課題は多いが、徐々に組織の構造が変わりつつある まとめ