APC 技術ブログ

株式会社エーピーコミュニケーションズの技術ブログです。

株式会社 エーピーコミュニケーションズの技術ブログです。

トップ > AWS > AWS Summit Japan 2024をRecapしてみる

AWS Summit Japan 2024をRecapしてみる

AWS AWS Summit AWS Summit Japan 2024
＜ techblogAPCについて（はじめにお読み下さい） ＞

こんにちは、クラウド事業部の山路です。

今回は先日AWS Summit Japanに参加したので、公開されている資料や録画を見つつ、ひとりRecapをしてみました。なおAWS Summit Japanのセッション資料は7月5日19時まで公開されているので、もし気になるセッションが見つかった方は早めにチェックいただくのがよさそうです。

AWS Summitとは

AWS Summit Japan公式ページでは、AWS Summitを以下のように紹介しています。

AWS Summit は、クラウドコンピューティングコミュニティが一堂に会して、アマゾン ウェブ サービス (AWS) に関して学習し、ベストプラクティスの共有や情報交換ができる、全てのクラウドでイノベーションを起こすことに興味がある皆様のためのイベントです。

aws.amazon.com

その他情報は以下の通りです。

  • 開催日: 2024年6月21/22日
  • セッション数: 150以上
  • 展示ブース: 250以上
  • 参加者: 52323人 (オンライン含む)

どんなテーマでの発表が多かったか

AWS Summit Japanには多くのセッションや展示ブースがありましたが、全体的にどんなテーマの発表が多かったのか気になりました。そこでまずは資料や録画の公開されている発表を対象に、各セッションがどんなテーマを含んだものかを調べてみました。各発表のテーマを集計し、グラフにしたものが以下になります。

なお、調査時にカウントしたテーマや基準などは厳密なものは設けていないため、正確な数値や分類とはなっていないと思います。また集計は私が資料と録画を目で見て数えた結果なので、数え漏れも多分に含むと思います。なので、「だいたいこんな感じだったんだなあ」程度に受け止めて頂けるとありがたいです。

さて、このグラフを見てみると、まずは生成AIの数がダントツで多いことが分かります。私はAWS Summit当日は2日間とも現地に参加しており、その時から生成AIの発表が多いと感じました。ですが、改めてデータにしてみると、全発表のおよそ半分に、何らかの形で生成AIが含まれていることが分かります。AWSは昨年の時点で生成AIにかなり力を入れていましたが、今年も引き続きやっていくぞ！という姿勢が見えます。

グラフに戻ると、生成AIの次に多かったのは「データ」「セキュリティ」「オンプレミス」でした。データについては生成AIとも関わりが深いこと、セキュリティは後述しますがAWSがもともと力を入れていることが影響していそうです。オンプレミスについても元から根強く関心を集め続けているテーマかと思いますし、今回はクラウドへの移行やハイブリッドクラウドの他、ガバメントクラウドに関する発表が数件あったのも要因かと思います。

ここからは件数の多かったテーマについて、傾向や気になる発表などを取り上げます。

ピックアップ1: 生成AI / データ

生成AIを本番環境に導入している事例が多く紹介された

最初に感じたのは、生成AIをすでに本番環境に導入している例が多く紹介されていたことでした。

AA-01: イノベーションを実現するAWSの生成AIサービス (Room K)

イノベーションを実現するAWSの生成AIサービス という発表では、AWSの生成AIに関連するサービスの全体像を紹介するほか、生成AIを戦略的に活用し続けるためのポイントについても紹介しています。冒頭ではAWSが生成AIとどう関わってきたか、ユーザーからどんな問い合わせが多かったかについて、「2023年は実証調査の年、2024年は実用化に向けた年」と説明しています。昨年ChatGPTをはじめとする生成AIが大きな注目を集め、国内外の企業の中にも生成AIの活用に向けて動き始めるところはいくつもありました。彼らがまず抱いた疑問は、「そもそも生成AIとは何か」「本当に安全か」といったベース部分の情報であり、そういった疑問を解消したうえでPoCの実施・検討などを行いました。それに対して2024年は、生成AIを本番環境で活用することに向けた、より実践的な疑問 (例えばコスト削減やカスタマイズ方法など) の問い合わせが多かったとのことです。

AWS-15: データ×生成 AI - 事例から学ぶビジネスインパクト創出の方程式 (Room C)

また実際の導入企業として、Adobe / Pinterestといったグローバル企業はもちろん、国内企業の事例も多く紹介されており、AWSでは多くの事例をもとにしたプラクティスも多く発表されていました。データ×生成 AI - 事例から学ぶビジネスインパクト創出の方程式 という発表では、生成AIの導入のしやすさに対する価値創出の難しさを受け、データ×生成AIでどのようにビジネスの価値を最大化するか紹介しています。本セッションではAdobe / Pinterest / Amazon / エフピコ / 第一興商 / サイバーエージェントといった国内外の企業の生成AI事例の紹介、およびそれらの結果をもたらす背景の深掘りにより、生成AIでビジネスインパクトを創出するためには「顧客起点文化」「小規模チーム」「頻繁な実験」という3つが必要であると紹介しています。これらはアジャイル開発で目指す方向の一部とも一致しているため、これまでの開発で培った経験を生成AIにも活かせる、と言えるのではないかと思います。

例えばAmazonでは商品購入のあらゆるプロセスで機械学習を活用しており、Amazonの検索窓の入力に対しリアルタイムで候補を表示したり、海外ではレビューのサマリ機能なども提供しています。こういった生成AIの活用を支えるのがAmazon M5と呼ばれる基盤モデルであり、500のアプリケーションでの利用、50件以上のお客様による実利用などのインパクトをもたらしています。

こちらは国内で生成AIを本番の業務・サービスに組み込んでいる101社のロゴを集めたもの (ロゴウォール) です。これら企業の大半は2〜3か月という短期間で生成AIを実用につなげているとのことでした。中には入社1か月の社員1名が3週間で検証用プロダクトを用意した例もあるとのこと。

AWS-25: 金融ビジネスの価値を生成するAI (Room J)

金融ビジネスの価値を生成するAIという発表では、金融ビジネスという分野で生成AIを活用するための課題・ユースケースを取り上げています。実際に金融ビジネスのユーザーから問い合わせが来るものとして、「生成AI自体を安全に使えるか」「アップデートの激しい基盤モデルの中でどれを使えばいいか」「前例の少ない生成AIにおいて、コストを最適化できるのか」という3つが多いと紹介しています。またユースケースについては「顧客体験の向上」「ナレッジワーカーの生産性向上」「プロダクトのイノベーションとプロセス自動化」という3つが最も多く、それらの具体例としてNatWest / Verafin / ナウキャストの例を紹介しています。

NatWestは生成AIを活用して顧客に高度にパーソナライズしたブランド準拠コンテンツを配信し、200万人超の新規顧客の獲得や900％もの貯蓄口座・アプリ利用者増加率といった成果をもたらしています。ナウキャストでは決算短信からのデータ抽出にAmazon Bedrockを利用しており、S3に保存した決算短信のPDFデータをStreamlitで整形、これをClaude 2.1に渡してデータ抽出を実現しています。

これ以外にも、当日のブース展示などには多くの事例が紹介されていました。

生成AIは他分野とも多く関わっていた

生成AIを扱う発表が多かったのは上記の通りですが、生成AIだけに絞った発表というのは見当たらず、他のテーマも含んでいました。

こちらのグラフは生成AIをテーマに含む発表だけを取り出し、生成AI以外のテーマを集計したものです。

※なおこちらで集計したものは、あくまで1つの発表の中でどんなテーマを取り上げていたかだけを集計しており、発表の中で明示的に生成AIとその他の分野が組み合わさっていないものも含んでいます。

これを見ると、他のテーマとしてはデータ・セキュリティが多いことが分かりますが、それ以外にもIoT / コンタクトセンター / Platform Engineeringなど、様々な分野で生成AIが使われていることが窺える結果となりました。

AWS-16: 生成AIのセキュリティ対策と責任あるAIの実現 (Room C)

生成AIのセキュリティ対策と責任あるAIの実現という発表では、生成AIがもたらすリスクと課題の代表例を紹介しており、その中にはプロンプトインジェクションというものが含まれます。プロンプトインジェクションとは悪意あるユーザーが生成AIモデルに対し特定のプロンプトを実行し、システムの制御や個人・機密情報の出力といった行為を実現する攻撃のことで、OWASP Top 10 for Large Language Model Applicationsでも取り上げられています。発表ではプロンプトインジェクションに対し、具体的なAWSの構成図を出しながら、どこから攻撃されるか、攻撃に備えてどのような対策が必要か（バックエンドへのアクセスに対する最小権限原則の適用、信頼境界の確率など）を紹介しています。

AWS-18: AWS環境におけるセキュリティ調査の高度化と生成AI活用 (Room C)

AWS環境におけるセキュリティ調査の高度化と生成AI活用という発表では、セキュリティ向上のために生成AIを活用する方法について紹介しています。例えば自然言語による調査クエリの自動生成を活用することで、ログ分析でAWS Config / Amazon CloudWatch Logs Insightなどを使う際も、複雑なクエリを自分で用意する手間を省くことができます。またAmazon GuardDutyで脅威を検知した後の調査で検出結果グループを利用する際は、Amazon Bedrockにより発生事象の要約が出力されます。

AWS-11: ⽣成 AI が変える、データアナリティクス (Room B)

セキュリティ以外でも、⽣成 AI が変える、データアナリティクスという発表では、AWSのアナリティクスサービスの多くに生成AI機能が搭載されており、データ分析の効率化・高度化を推し進めると紹介しています。例えば生成AI・機械学習などに利用するデータに対し、データの概要や想定できるユースケースの提案 (AI recommendations for descriptions in Amazon DataZone) 、自然言語を用いたデータパイプライン・データSQLの開発 (Amazon Q data integration in AWS Glue / Amazon Q Generative SQL in Amazon Redshift クエリエディター) などを実現できます。

こういった変化はデータ分析の技術的なハードルを下げ、データアナリティクスに関わる人々に求められるものも変わるだろうと紹介しています。例えばデータアナリストには生成AIフレンドリーな能力 (生成AIへのインプット、共存する姿勢など) が求められるようになるかもしれません。

ピックアップ2: セキュリティ

セキュリティは生成AI・データに次いで多かったテーマです。AWSはセキュリティに以前から力を入れており、今回のAWS Summit Japanでも公式ページの「5つの注目トピックス」というコーナーでセキュリティを挙げています。

AA-02: AWS でセキュリティ対策を強化 (Room K)

AWS でセキュリティ対策を強化という発表では、現代のセキュリティはイノベーションの妨げとならないよう、迅速「かつ」安全性の確保が求められている、と紹介しています。一方でセキュリティは専門的な知識も必要ですし、常に新たな脅威が生まれてくる、変化の激しい分野でもあります。

AWSでは責任共有モデルという考え方をはじめ、IDとアクセス管理、検出と対応、ネットワークとアプリケーションの保護、データ保護といった分野で専用のサービスを多く提供しており、本発表では各項目の代表的なサービスの紹介もされています。

AWS-09: 安全とスピードを両立するために ~ DevSecOps とプラットフォームエンジニアリング~ (Room B)

安全とスピードを両立するために ~ DevSecOps とプラットフォームエンジニアリング~という発表では、現代のアプリケーション開発には安全とスピードが求められることを前提として、DevSecOpsについて紹介しています。セキュリティについてはShift-Leftという、開発プロセスの初期からセキュリティに取り組む動きを取り入れ、ローカル環境の開発から本番環境へのデプロイまで、ソフトウェア開発ライフサイクルの各ステップでセキュリティ対策を取り入れる例を紹介しています。

ただ、こういったセキュリティの対策を (自動化の仕組みの導入も含めて) 各チームが全て対応するのは難しい場合もあります。Amazonでは内部でBuild System / CLI / Policy Engineといったものを用意し、社内のセキュリティツールや仕組みの標準化を行っています。これらは現在ではPlatform Engineeringと呼ばれるプラクティスに相当するものです。

Platform EngineeringではTeam topologiesという組織モデルが良く取り上げられますが、ここではTeam topologiesの考えを用いて、DevSecOpsをいかにスケーリングする仕組みを作るかを紹介しています。例えばここではDecSecOps CoE (Community of Practice) がセキュリティを維持する仕組みやプラクティスを提供します。ただし仕組みを提供・案内するだけでは実践できない場合もあるため、Enabling teamがStream Aligned teamに入りスキルトランスファーなどを行います。1つのteamでDevSecOpsを整えたら、Enabling teamメンバーが他チームに移動したり、Platform / DevSecOpsチームにフィードバックしたりすることで、DevSecOpsをスケーリングします。ただ実際は組織によって適した進め方があるでしょうから、こちらのブログ等で案内している4つの運用モデルが参考になるでしょう。

その他

なお、AWSはセキュリティに力を入れていると述べましたが、AWSのパートナーセッションでもセキュリティについて多くのセッションがありました。今回集計した結果、セキュリティに関するセッション数は28個でしたが、そのうちパートナーセッションのものは16個と、半分以上を占める結果となりました。パートナーセッションでは生成AIやマルチクラウド・ゼロトラストといった幅広いシチュエーションでのセキュリティ対策・事例が紹介されています。

ピックアップ3: オンプレミス

セキュリティの次に多かったものとして、オンプレミスを取り上げます。オンプレミスを扱ったセッションでは、主に「ハイブリッドクラウド」または「クラウド移行」のどちらかについて紹介しています。

AWS-29: ユースケースから深掘るハイブリッドアーキテクチャ (Room K)

ユースケースから深掘るハイブリッドアーキテクチャという発表では、ハイブリッドアーキテクチャを「完全にクラウド化する選択肢が取れないことに対する⼀つの解」としたうえで、よくある4つのシナリオと9つのユースケースを紹介しています。本セッションを見ると、オンプレミスに何らかの資産を持つ企業・チームではどこかで遭遇するであろうシナリオが網羅されていると感じます。ただしハイブリッドアーキテクチャを採用するには、実際に構築を始める前に押さえるべきポイントがあります。本セッションではそういったポイントも紹介しており、ハイブリッドクラウドを検討中の方は必見と言っていいでしょう。

国内初事例！明治が実行した AWS Mainframe Modernization で年間コスト 80% 削減 (Room N)

国内初事例！明治が実行した AWS Mainframe Modernization で年間コスト 80% 削減という発表では、30年以上にわたって利用してきたメインフレームからの脱却の一環にAWS Mainframe Modernizationを活用した例を紹介しています。本セッションの中で、メインフレームにあるシステムを「基幹システム」「その他」の2つに分け、前者はシステムを再構築、後者はAWS Mainframe Modernizationを利用して、開発言語の変換とAWSへのシステム移行を行いました。AWS Mainframe Modernizationは国内での事例がない中での選定でしたが、他社サービスと比較したときのメリットの大きさや企業文化が後押しとなり、今回採用したとのことでした。

AWS-48: 先行事例から分かってきた、自治体職員がガバメントクラウド利用をする上で考えておくこと (Room E)

またオンプレミスと関連するテーマとして、ガバメントクラウド（以降ガバクラ）に関する発表もいくつかありました。

先行事例から分かってきた、自治体職員がガバメントクラウド利用をする上で考えておくことという発表では、そもそもガバクラとは何か、という定義から始まり、ガバクラにおけるAWSやデジタル庁の役割、それまでの先行事例をうけて見えてきた課題や検討のポイントについて紹介しています。本セッションでは、様々な役割の事業者がガバクラの利用に関わるという特徴から、ガバクラを構成するネットワーク・クラウド管理・アプリケーションそれぞれ検討事項があること、そしてそれらのタスクをどの事業者に任せるかを整理しなければらないという課題があると述べており、それぞれどのように対応したかを紹介しています。

本セッションでの検討事項や観点はガバクラに限らず、複数の事業者が関わるような大規模なシステム設計などにも流用できる内容ではないかと感じました。特にIPアドレス管理や名前解決など、規模が大きくなるにつれて複雑化しやすいネットワーク周りは、観点や利用できるサービスなどもまとまっており参考になると思います。

リファレンスアーキテクチャによるガバメントクラウド活用と Amazon Bedrock を活用したモダン化アプリの例 (Room N)

リファレンスアーキテクチャによるガバメントクラウド活用と Amazon Bedrock を活用したモダン化アプリの例という発表では、「クラウドスマート」という原則やシステムのモダン化を求めているものの、スキルや期間・品質といった課題を抱える各省庁に向けて、リファレンスアーキテクチャ (以降RA) を提供する取り組みを紹介しています。本セッションではRAを「行政システムの特性に応じたクラウド最適な標準アーキテクチャ群」と定義しており、業務ブロック・非機能ブロック・代表システムパターンの3つで構成されたものをGCASガイドで提供しています。現時点ではシステム計画時にRAが活用され始め、約40件の移行案件で活用されていること、次期業務やシステム要求を整理後にRAを活用することが効果的であったと紹介しています。またRAが具体的に動く様子をイメージできるよう「動くRA」を作る中で、生成AIを使ったアプリケーションの開発も行ったとのことです。

その他

その他で気になったテーマを2つほど取り上げます。

AWS-05: AWS コスト管理の最前線 (Room A)

1つ目のテーマは「コスト」です。AWSに限らずクラウドを利用するときのコストは、利用者にとって関心の高いテーマです。去年から今年にかけてAWSコストに関する書籍も多数出版されています。

AWS コスト管理の最前線という発表では、AWSコスト管理のベストプラクティスやユースケースごとのコスト最適化のプロセスなどを紹介しています。本セッションではCFM (Cloud Financial Management) のフレームワークを取り上げており、CFMでは「可視化」「最適化」「計画・予測」の3つのステップを継続的に実施します。ここではあるユースケースに沿った形で、それぞれのステップで具体的にどのAWSサービスを、どのように利用し、Finopsを実践するか紹介しています。

コスト最適化に取り組み始めた方や検討中の方は、本セッションを見ることで具体的な作業をイメージできるのではないかと思います。

AWS-53: SaaS 開発とプラットフォームエンジニアリングの未来 (Room J)

2つ目のテーマは「Platform Engineering」です。Platform Engineeringはここ数年で注目を集めており、弊社ブログでもこれまで数多くのブログを通じてPlatform Engineeringを紹介しています。

techblog.ap-com.co.jp

SaaS 開発とプラットフォームエンジニアリングの未来 という発表では、SaaSビジネスを支える開発組織の規模拡大に伴う開発生産性の低下という課題の解決策として、Platform Engineeringを紹介しています。本セッションでは、SaaSが成長を続けるためには開発組織の規模拡大が必要であり、組織の規模拡大をしながらも開発生産性の向上を続けなければなりません。しかし開発組織が拡大すると、チームの構成に依らず、開発チーム、もしくはインフラチームの負担が増加し、新機能やプロダクトの提供スピードが低下します。これを解決する手段としてPlatform Engineeringを利用し、開発チームの認知負荷軽減、そして開発生産性の向上を目指します。

本セッションではPlatform Engineeringの実装例としてリポジトリテンプレート・IaCテンプレートといったゴールデンパス、Backstageを利用したセルフサービスを紹介しています。AWS上でPlatform Engineeringの実現を目指す方にとって、とても参考になるセッションだと思います。

個人的に面白かった発表

最後はテーマとは関係なしに、個人的に面白いと感じた発表について紹介します。

AWS-33: チームのつながりを Infrastructure as Code でデザインする (Room A)

チームのつながりを Infrastructure as Code でデザインする という発表では、ソフトウェアの変更に沿ったチームを構成・維持するうえでIaCが役立つと提案しており、IaCによってチーム作りの5つの障壁を乗り越えられると紹介しています。本セッションでは、開発フローを効率的なものに変えるには組織文化の変革が必要であり、組織文化を変えるには「関係者の言動、つまり皆が何をどう⾏うかを変えること」が必要です。IaCはチームの行動を変えるためのきっかけであり、DevOpsの第一歩にすることができると紹介しており、具体的にはAWS CDKでアプリ全体をコードで定義し、チームの共通言語とすることを勧めています。

AWS CDKは、アプリエンジニア・インフラエンジニアどちらにとっても互いの分野に近づくきっかけとなり、チームメンバーの役割を職能で限定せず、全員がソフトウェアエンジニアとなることにつながります。またメンバーの役割を職能に制限しないことで、スキルの拡張・転換にもつながり、よりよい選択肢を実装することができます。

また本セッションではPlatform Engineeringにも触れています。Platform Engineeringでは最小限のPlatformを目指すことが推奨されるので、初めはWikiページのリストから始め、次によくある構成パターン・アーキテクチャをCDK Constructでモジュール化して共有する、次に中央集権型のPlatformを提供・運用する、など、徐々にPlatformを拡張・発展することがよいでしょう。

なお、これまで職能でチームが分かれていた場合、協働するためのベースとなる知識を身に付ける必要があります。「そこから教えないといけないのかあ。。」と言われてしまわないよう、最低限の知識は必要です。これを聞いた時は思わず「仰る通りです！」と土下座したくなりました。がんばります。

AWS-28: 大規模クラウドインフラ設計・構築案件の歩き方 (Room K)

大規模クラウドインフラ設計・構築案件の歩き方という発表では、大規模なインフラを設計・構築する案件は他と何が違うのか、それらを考慮したときに設計・構築をどう進めるのがよいか紹介しています。構築するインフラの規模が大きくなると、それにかかわる関係者が増えます。関係者が増えると効率的に進めるにはルールや責任範囲を明確に定める必要があります。設計担当者は最初に設計書の一覧を作成して各設計書の主担当を明確に記述すること、設計の進捗の定義を設定して完了条件を明確にすること、といった取り組みが必要です。またアプリとインフラを別のチームが担当する場合は、どこに分界点を設定するか、開発方針とガバナンスを軸にして検討する必要があります。

規模が大きくなると想定外の事態も増加します。構築作業中に何らかの理由で不要なコストが残存しており無駄なコストが発生する、構築作業中にIaC以外の部分で大きく時間を取られる、なども発生します。こういった事態を出来る限り防ぐため、担当者は構築初期段階からコスト管理を始める、構築のクリティカルパスとなる点 (具体的には社内調整や申請など) を早めに確認しておく、といった取り組みが必要です。

私もこれまでいくつか大規模案件と呼ばれるような規模の案件に関わったことがありますが、本発表のような「どこに気を付けるべきか」「どんな困難が待っていると予想できるか」といったノウハウを言語化できておらず、今後の案件をやるうえでも参考とさせていただくセッションでした。

Nintendo Switch™ 向けプッシュ通知システムのリプレイス事例 (Room O)

Nintendo Switch™ 向けプッシュ通知システムのリプレイス事例という発表では、2024年にリプレイスしたプッシュ通知システムについて紹介しており、同時接続数1億を超える環境でいかにスケーラビリティを確保するか紹介しています。Nintendo Switchのユーザー数は年々増え続けており、今後も長期にわたる運用が必要と考えられます。長期運用を想定すると既存のアーキテクチャにはいくつかの課題が考えられ、本セッションではこのうち「開発運用の効率を高めたい」「運用工数を削減したい」という課題に対し、クラスタ構成からシンプルなアーキテクチャの採用、サーバレスサービスの利用という打ち手を取りました。

新しいプッシュ通知システムには、性能要件として常時1億以上のスケーラビリティが求められており、これを実現するためAWSサービス (AWS NLB / Amazon ECS on Fargate) の機能に加え独自処理も実装しています。例えば常時接続サーバ向けの独自のデプロイツールでは、Task入れ替え時に発生する常時接続開始処理の負荷を分散するため、「全てのAZに均等にTaskを配置する」「全てのTaskがNLBから接続を受け始めるタイミングを揃える」「接続処理のタイミングをずらし負荷を軽減する」という要件を満たすよう実装されています。これらの処理はGitHub Actionsによってすべて自動化されており、約30分で更新を完了します。新しいシステムへの移行はサービス無停止で実現し、現在まで大きな問題も起こらず移行が進んでいます。

本セッションでは大規模に利用されているサービスならではの厳しい要件をどのようにクリアしているかが明快に説明されています。特に性能要件を満たすうえで必要な要素を明確にし、それを実現するための技術選定、実装する中で直面した新たな課題への対応など、どれも興味深く視聴させていただきました。

さいごに

今回はAWS Summit Japan 2024のRecapと称して様々なセッションの内容を紹介しました。参加当日は様々なセッションや展示を見ているのが楽しかったですが、改めて一通りのセッションを眺めてみるのはとても楽しかったです。早くも来年のAWS Summit Japanが楽しみになってきました。

こちらのリンク先 (PDFファイル) には、当日のセッションのタイムテーブルが記載されているので、気になるセッションがあるかをご確認いただくのもよいかと思います。

なお繰り返しですが、AWS Summitの資料・録画は7月5日19時までが公開期間となっているので、気になるセッションがあれば早めに見ることをおすすめします。

また弊社からも参加レポートが投稿されていますので、良ければそちらもご覧ください。

最後に、弊社はAWSアドバンスドティアサービスパートナー認定を受けております。また以下のようにAWSの活用を支援するサービスも行っているので、何かご相談したいことがあればお気軽にご連絡ください。

www.ap-com.co.jp