本記事は 2026 年 8 月 27 日 に公開された「 A year of expanding choice for VMware customers on AWS 」を翻訳したものです。 Amazon EVS が一般提供 (GA) を開始してから 1 年以上が経ちました。人材やツール、運用ワークフローへの既存の投資を維持しながらクラウドでより多くの選択肢を求めていた VMware ワークロードのお客様にとって、Amazon EVS の GA 開始は大きな節目でした。Amazon EVS を使用すると、AWS 環境と統合された Amazon EC2 ベアメタルインスタンス上で VMware Cloud Foundation (VCF) を実行できます。チームは VMware のソリューションを継続して使用しながら、AWS の機能とグローバルな展開力を活用できます。 この 1 年間で新しい VCF バージョンのサポートを追加し、デプロイの自動化機能をリリースし、新しい EC2 インスタンスへの対応も拡大してきました。VCF 9 の Memory Tiering や NSX Federation の設定に関するガイダンスも公開し、新しい Windows Server ライセンスの権利オプションも導入しました。これらの機能追加により AWS で稼働する VMware ワークロードのデプロイ、運用、スケーリング、保護をお客様がより細かく制御できるように取り組んでいます。 ここからは最初の 1 年間でお届けした内容を詳しく紹介します。 VCF 9 を思い通りにデプロイ 今年に入って Amazon EVS での VCF 9.0 および 9.1 のサポート を発表しました。VCF 9 では Amazon EVS が VPC 内に EC2 ベアメタルインフラストラクチャをプロビジョニングし、アーキテクチャや設定はネイティブの VCF Installer でお客様自身が管理します。この制御レベルは VCF のライフサイクル全体に及ぶため、オンプレミスと同じ VCF の機能を Amazon EVS でも利用できます。 自動インストールを好むチーム向けには Solutions for Amazon EVS GitHub リポジトリ で Amazon EVS Deployment Orchestrator を公開しました。Amazon EVS Deployment Orchestrator には Amazon EVS 上に完全に構成された VCF 9 環境をデプロイするためのエンドツーエンドの自動化が含まれています。今後も計画、デプロイ、移行、運用のための新しいソリューションを追加していきます。 新しい i7i.metal-48xl、AWS リージョンの拡大、より大規模な環境でスケール 4 月には i7i.metal-24xl のサポート を追加して EC2 インスタンスの選択肢を拡大し、本日 i7i.metal-48xl のサポート を発表します。この新しいインスタンスは物理コア 96 個、メモリ 1.5 TB、ローカル NVMe ストレージ 45 TB を備え、負荷の高い VMware ワークロードに対応する大きなキャパシティを提供します。 第 5 世代 Intel Xeon Scalable プロセッサーを搭載した i7i インスタンスは、i4i インスタンスと比べてコンピューティング性能が最大 23% 向上し、料金性能比も 10% 以上向上しています。i7i.metal-48xl はコア数とメモリ容量が増えているため、ホストあたりでより多くの VM を実行でき、少ないホスト数でも環境を拡張できます。 また Amazon EVS の対応リージョンを 22 の AWS リージョンに拡大し、エンドユーザーの近くにワークロードを配置したり、ビジネス目標やデータ主権の要件に合わせたデプロイができるようになりました。さらに環境の最大サイズを 16 ホストから 32 ホストに増やしました。1 つの環境内で大規模な単一クラスターを構築することも、複数の小規模クラスターに分けることも、要件に合わせて自由に組み合わせることもできます。 Memory Tiering でクラスター密度を向上 VCF 9 は、ホストがローカル NVMe ストレージを追加メモリとして利用できる Memory Tiering を導入しました。同じホスト数でもクラスターが実質的に最大 2 倍のメモリを扱えるようになり、VM の密度を高めながらハードウェアとライセンスのコストを削減できます。Memory Tiering は i4i および i7i の両インスタンスファミリーに対応しています。 Memory Tiering の詳細解説 ではこの機能の仕組みや、Amazon EVS でのサイジングと有効化について説明しています。 Windows Server のライセンスをシンプルに Windows Server のライセンスは VMware の移行を計画する際に障壁となることがあります。 Amazon EVS Windows Server Licensing では Windows VM を実行するための 2 つの選択肢を用意しています。対象となる Windows Server ライセンスと移行権を持つお客様は、そのライセンスをそのまま Amazon EVS に持ち込めます。移行権のない VM については、Amazon EVS で Windows Server ライセンスの権利を追加し、使用した分だけ vCPU 時間単位で料金を支払えます。権利は環境の変化に応じて追加・削除できるため、個々の VM 単位でライセンスを付与し、ホスト全体にライセンスを付与するコストを回避できます。 Amazon EVS で VMware ワークロードを保護・復旧 Amazon EVS を使うと、チームが既に使い慣れた VMware のツールとプロセスのまま、AWS 上で VMware ワークロードを柔軟に保護・復旧できます。オンデマンドで復旧環境をデプロイし、ワークロードを変更せずに稼働させ、復旧目標に合わせてキャパシティをスケールできます。 Amazon EVS における VMware ワークロードの災害復旧ガイド では復旧方法と保護オプションを比較しており、ワークロードごとに復旧時間、復旧時点、コスト、運用要件のバランスを取れます。 サイト間でネットワークとセキュリティを拡張 またオンプレミスの NSX 環境と Amazon EVS 環境を単一のコントロールプレーンで管理できる NSX Federation のサポートも発表しました。NSX Federation により拠点をまたいでネットワークセグメントとセキュリティポリシーを拡張し、データセンターと AWS の間で統一されたネットワーキング基盤を構築できます。大規模なレイヤー 2 拡張、統一された Distributed Firewall ポリシー、簡素化された災害復旧のフェイルオーバーを必要とするお客様にとって、NSX Federation は HCX の移行ワークフローを補完する長期的なネットワーキングと復旧の基盤となります。 NSX Federation の詳細解説 では両方の技術がどのように連携し、それぞれがどのような場面に適しているかを説明しています。 より広い選択肢を提供した 1 年間 今年リリースしたすべての機能はチームが使い慣れた VMware のツールと運用ワークフローを維持しながら、Amazon EVS でより多くの制御、選択肢、柔軟性を提供するという目標を支えるものです。VMware を利用している組織であれば、Amazon EVS を VMware ベースのワークロードを実行する世界最高の場所にしたいと考えています。 次のステップ: VMware Explore 2026 で Amazon EVS をご覧ください 最新の取り組みを実際にご覧になりたい方は、8 月 31 日から 9 月 3 日までラスベガスの The Venetian で開催される VMware Explore 2026 にぜひお越しください。 今すぐセッションをスケジュールに追加してください 。 ブレイクアウトセッション [CLOB2172LVS] Amazon EVS with VCF 9: Expanding choice and flexibility for VMware on AWS – 9 月 2 日(水) | 午後 3:15 – 午後 4:00 | Level 3, San Polo 3505 20 分間シアターセッション [CLOQT2319LVS] 20-minute guide to running VMware Cloud Foundation 9 on Amazon EVS – 8 月 31 日(月) | 午後 5:30 – 午後 5:50 | The Hub Theater VMware Explore にご参加の有無を問わず、皆様が取り組んでいる内容についてぜひお聞かせください。 Amazon EVS の製品ページ にアクセスして利用を開始するか、AWS のアカウントチームに連絡して次のステップを検討してください。 著者について Bianca Velasco AWS のプロダクトマーケティングマネージャーとして、VMware ベースのワークロードの AWS への移行とトランスフォーメーションを担当しています。マーケティングとテクノロジー分野で7年以上の経験を持ち、複雑な技術を分かりやすく伝えるストーリーづくりに情熱を注いでいます。AWS の業務以外では、ボランティア活動、ダンス、ボルダリングを楽しんでいます。 Andy Reedy EC2 Commercial Applications のシニアプロダクトマネジメントマネージャーとして、VMware、SAP、Red Hat OpenShift のワークロードを担当するチームを率いています。IT インフラストラクチャ、ネットワーキング、セキュリティ、クラウド戦略、エンタープライズソフトウェアの分野で25年以上の経験を持ち、お客様のビジネスクリティカルなアプリケーションの移行とモダナイゼーションを支援することに情熱を注いでいます。 Spiros Tsitsonis AWS のシニアテクニカルプロダクトマネージャーとして、インフラストラクチャの移行と Amazon Elastic VMware Service を担当しています。以前は Amazon Elastic Container Service とサーバーレスの Fargate チームを管理しており、AWS のサービスを活用してお客様がビジネス成果を達成することを支援することに情熱を注いでいます。プライベートでは、旅行を通じて様々な場所や人々、文化に触れることを楽しんでいます。 翻訳はパートナーソリューションアーキテクト 豊田が担当しました。原文は こちら です。

はじめに こんにちは、コーポレートエンジニアリング部ITサービスブロックの高塩です。2026年2月に入社し、社内の共通システムやIdP、SaaSの管理、日々のオペレーション自動化などを担当しています。 ZOZOでは入社者のマスタデータをkintoneで管理しています。入社のたびに、Active Directory（以下、AD）を起点にMicrosoft 365・Google Workspace・Boxなどでアカウントを作成し、利用できる状態まで整えています。この作業は長らく手作業で運用してきましたが、工数や属人化、そしてCSVの受け渡しに課題を抱えていました。 オンプレADやLDAPサーバーを長く運用してきた組織では、それが自動化の足枷になっているケースも少なくないと思います。かといって、すべてをクラウドへすぐに寄せられるとも限りません。本記事では、この一連のアカウント作成を、kintoneを起点にGitHub Actions（self-hosted runner）で自動化した取り組みを紹介します。閉域にあるオンプレADの操作までGitHub Actionsに載せ、コードレビュー・実行ログ・再現性といったCI/CDの利点をアカウント運用に持ち込みました。 目次 はじめに 目次 背景：手作業時代のフローと課題 全体アーキテクチャ オンプレADをGitHub Actionsから操作する kintoneから翌月の入社予定者を取得し、業務ロジックで判定してADに作成する 同期待ちを能動的に潰して即時反映する AD → Entra ID：デルタ同期を要求して完了までポーリング Entra ID → SaaS：Graph APIのオンデマンドプロビジョニング 運用：前日にdry-runで予定を流し、翌日に本番で作成する 導入の効果 まとめ 背景：手作業時代のフローと課題 自動化前のアカウント作成は、おおよそ次のような流れでした。 GASでkintoneから入社者のレコードを取得する スプレッドシートに転記し、関数で表示名やグループなどの値を加工する 加工した結果をCSVでエクスポートし、オンプレミスの作業サーバーへ手動で転送する 作業サーバー上で複数のPowerShellスクリプトにCSVを読み込ませ、順次実行してアカウントを作成する 途中、Microsoft Entra Connectのデルタ同期を手動で実行し、各SaaSへの反映を待つ 反映後、各SaaSの個別設定を、設定用スクリプトの実行や手作業で投入する 一見すると回っているように見えますが、運用を続けるうちに次のような課題が積み重なっていました。 業務ロジックが散在している ：誰が・どの雇用形態で・どのグループに入るのか、その判断ロジックがスプレッドシートの関数と作業サーバー上のスクリプトに分散していました。そのため全体像の把握が困難でした。 手作業でのCSV転送 ：スプレッドシートからCSVをエクスポートし、作業サーバーへ人手で転送していました。 ログの視認性が低い ：実行は作業サーバーのコンソールで行うため、いつ・誰が・何を流したのかが後から追いにくい状態でした。 スクリプトのドリフト ：Gitリポジトリ上のスクリプトと、作業サーバーに置かれた実際に動くスクリプトが少しずつ乖離していき、「リポジトリのコード＝実際に動いているコード」と言い切れなくなっていました。 これらをまとめて解決するために、フロー全体を作り直すことにしました。 全体アーキテクチャ 新しい仕組みでは、データはkintoneから直接取り、全工程をGitHub Actionsから動かすことにしました。 手作業のころから大きく変えたのは、次の3つです。 CSVの受け渡しをやめ、kintone APIを直接呼び出す ：人の手によるエクスポートと加工を排除しました。 散在していた業務ロジックをコードに集約する ：判断ロジックをすべてPowerShellスクリプトにまとめ、Gitリポジトリで管理するようにしました。 オンプレADの操作にself-hosted runnerを使う ：GitHub Actionsの仕組みに乗りながら、オンプレミスのADコマンドレットをそのまま実行できるようにしました。 ワークフローは schedule によるcron実行で動きます。kintoneからはデフォルトで翌月の入社者を取得するので、毎月決まった日に翌月分の作成予定をSlackへ自動投稿し、その翌日にまとめて作成する、という運用にしました。 ここからは、土台となるself-hosted runner、kintoneからのアカウント作成、クラウドへの即時反映を、順に見ていきます。 オンプレADをGitHub Actionsから操作する この仕組みで一番頭を悩ませたのが、オンプレミスのADをどう自動化に組み込むかでした。 ADはオンプレミスの閉じたネットワークの中にあります。操作するには、次の3つが必要です。 ドメインコントローラへ通信できるネットワーク（オンプレ内）にいること リモート サーバー管理ツール（ RSAT ）の ActiveDirectory モジュールが入った実行環境 対象OUでユーザー作成とグループ追加ができるドメイン権限 最初に検討したのは、この処理を自前でオーケストレーションせず、Entra ID Governanceのようなマネージド機能に寄せる形でした。たとえばオンプレADへのユーザー作成は、 API 駆動型インバウンド プロビジョニング に任せられます。 ただ、今回の要件には合いませんでした。アカウント作成にはオンプレADのグループ操作が含まれますが、属性ベースの動的グループが扱うのはクラウドのグループで、オンプレADのグループメンバーシップまでは管理しません。ここはマネージド機能だけでは実現できません。 さらに、出し分けの業務ロジックは、手作業時代のPowerShellスクリプトへある程度作り込まれていました。これを一から組み直すより、既存の資産をそのまま流用したい事情もありました。そこで今回は、自前でオーケストレーションする方針にしました。 自前で組むなら、ADを操作する方法はいくつかあります。検討した選択肢の長所と短所を、次の表にまとめました。 実行方式 長所 短所・見送り理由 タスクスケジューラ＋スクリプト 追加インフラが不要 時刻起動のみ・コードがサーバーに残りドリフト再発・ログやSecrets、レビューが弱い 自前でAPIを建てる オンデマンド実行・自由度が高い 着信ポートの開放が必要・認証や可用性、監視を自前運用 Azure Automation（Hybrid Runbook Worker） Power Automate/Microsoft Formsから起動しやすい・Azure/M365中心の組織に馴染む GitのPR/CIと一体化しにくい・別基盤の学習/運用コスト self-hosted runner（採用） 既存のGitHub・PR・CIにそのまま乗る・チェックアウトでドリフトなし・手動/定期の両対応 runnerの保守が必要・信頼できるコードのみ実行する配慮が要る 自前API以外の3方式は、オンプレからのアウトバウンド通信だけで動作し、外部に着信ポートを開ける必要がありません。 最終的に self-hosted runner を選びました。ADドメインに参加したWindows Server上でrunnerを動かし、PowerShellを実行しています。 コード・トリガー・ログがすべてGitHub側へ移り、サーバー上では実行時にチェックアウトされた最新のスクリプトが動くだけです。背景で挙げたドリフトは、これで自然に消えます。 ほぼ同じ仕組みは、AzureのHybrid Runbook Workerでも実現できます。私たちはGitHubを使った業務フローが根付いていたため、self-hosted runnerを選びました。 ただし、この構成では強い権限を持つrunner自体が攻撃対象になります。runnerを侵害させないことと、万一侵害されても被害を広げないことの両方に注意を払う必要があります。 runnerに任意のコードを実行させる入口はGitHubなので、次のような基本的な制御を入れています。 リポジトリをprivateにし、権限は必要なメンバーだけに限定する ログインはSSOを必須とし、MFAの登録を義務づける mainはbranch protection ruleでCODEOWNERのレビュー承認を必須にする 認証は原則OIDC（Workload Identity連携）を使い、やむを得ずシークレットを使う場合もEnvironmentシークレットに置いてmainのワークフローからのみ参照できるようにする self-hosted runnerのサービスを動かすアカウントに過剰な権限を与えないことも重要です。runnerはオンプレADからクラウドまで触れる強い実行主体なので、万一侵害されたときの影響範囲を抑えるため、アクセスできるOUを絞るなど、必要最低限の権限だけを与えています。 kintoneから翌月の入社予定者を取得し、業務ロジックで判定してADに作成する 土台ができたら、次はアカウントを作る処理です。 まず取得です。kintoneの Cursor API を使い、クエリで対象者を絞り込みます。条件は3つで、入社月・入社区分（中途や新卒など）・雇用形態（社員やアルバイトなど）です。対象月は、定期実行では NEXT_MONTH() で翌月分を自動的に対象にします。 # 入社区分・雇用形態・入社月で対象者を絞り込む $categoryFilter = 'Category in ("中途", "新卒", "社員登用", ...)' $contractFilter = 'Contract in ("社員", "出向", "CSアルバイト", ...)' $query = " $categoryFilter and $contractFilter and Date = NEXT_MONTH() order by Date desc" # カーソルを作成し、レコードを取得し切るまで繰り返す $cursorId = ( Invoke-RestMethod -Uri $cursorEndpoint -Method Post -Headers $headers -Body $utf8Body ).id $nextCursorId = $cursorId while ( $nextCursorId ) { $res = Invoke-RestMethod -Uri " $cursorEndpoint `? id= $nextCursorId " -Method Get -Headers $getHeaders $allRecords += $res .records $nextCursorId = $res .next } CSVのエクスポートと手動転送がなくなり、「どんな条件で対象者を抽出しているか」がクエリを見れば分かるようになりました。 ただ、取得したデータをそのままADに流し込めるわけではありません。雇用形態や所属によって、どのOUに作り、どのグループに入れるかが変わります。以前はこの出し分けがスプレッドシートの関数に埋もれていましたが、今回コード側の分岐に移しました。判定しているのは、たとえば次のような内容です。 雇用形態に応じた、アカウントの配置先OUの決定 所属に応じた、各種グループへの追加 その他のユーザーアカウント属性の設定 判定が終わったら、self-hosted runnerの上で ActiveDirectory モジュールのコマンドレットを実行し、ADにアカウントを作成します。あとは次に述べる同期で、クラウド側へ反映されていきます。 同期待ちを能動的に潰して即時反映する ADにユーザーを作っただけでは、クラウド側のアカウントはすぐには使えません。間に2つの同期が挟まるためです。 1つ目はAD → Entra IDです。オンプレADのユーザーは、Microsoft Entra Connectが同期して初めてEntra ID側に現れます。この同期は通常、30分間隔のサイクルでしか走りません。 2つ目はEntra ID → 各SaaSです。Entra IDからGoogle WorkspaceやBoxへは、エンタープライズアプリのプロビジョニングで連携されます。この自動プロビジョニングのサイクルは最大40分待つことがあります。 手作業のころは、この待ちを人がこなしていました。同期サイクルが回るのを待つか、待ちきれなければデルタ同期を手動で叩き、クラウドにアカウントが現れたのを確認してから次の設定に進む、という具合です。 ところが、これをそのまま自動化に持ち込むと厄介でした。AD作成の先には、Entra IDのライセンスやグループ設定、Google WorkspaceやBoxへのプロビジョニング、その後の各SaaS個別の設定が続きます。どれも前の結果を前提にした処理です。定期サイクル任せだと全部終わるまでに1時間近くかかるうえ、まだ存在しないアカウントを触って空振りするステップも出てきます。 そこで、2つの同期をワークフローから自分でトリガーし、完了を見届けてから次へ進むようにしました。 AD → Entra ID：デルタ同期を要求して完了までポーリング 1つ目の同期は、Microsoft Entra Connectの同期サーバーに対してデルタ同期を要求し、完了するまで待ちます。runnerから Invoke-Command で同期サーバーに入り、 Start-ADSyncSyncCycle でデルタ同期を開始したあと、同期が進行中でなくなるまでポーリングします。 Invoke-Command -ComputerName $syncServer -ScriptBlock { Import-Module ADSync Start-ADSyncSyncCycle -PolicyType Delta | Out-Null # 同期が完了するまで待つ do { Start-Sleep -Seconds 10 $inProgress = ( Get-ADSyncScheduler ).SyncCycleInProgress } while ( $inProgress ) } ポーリングで完了を待つので、後続の処理に進む時点では、新入社員が必ずEntra ID側に存在します。 この Invoke-Command によるPowerShell Remotingは、runnerが侵害されたときに同期サーバーへの横移動の足がかりになりかねません。そこで、同期サーバーへ接続できる元をrunnerに限定し、接続に使うアカウントの権限も同期の実行に必要な分だけに絞っています。 Entra ID → SaaS：Graph APIのオンデマンドプロビジョニング 2つ目の同期は、Entra IDの自動プロビジョニングのサイクルを待たず、Graph APIの provisionOnDemand を使ってユーザー単位で即座にプロビジョニングをトリガーします。 このリクエストには、対象アプリのサービスプリンシパルID（ $spId ）・同期ジョブID（ $jobId ）・同期ルールID（ $ruleId ）の3つが必要です。ただ、こちらで用意するのは1つ目だけです。 $spId はエンタープライズアプリの「オブジェクトID」で、Entra管理センターのアプリのプロパティ画面に表示されます。 残りの $jobId と $ruleId は、実行時に $spId からGraphで取得します。ユーザーの同期ルールはアプリごとに1つしかないので、同期ジョブのスキーマを覗けば、それがそのまま使うルールです。IDを手で管理する必要はありません。 # $spId から同期ジョブを取得（Quarantine以外を優先） $jobs = Invoke-MgGraphRequest -Method GET ` -Uri "https://graph.microsoft.com/v1.0/servicePrincipals/ $spId /synchronization/jobs" $jobId = ( $jobs .value | Where-Object { $_ .status.code -ne "Quarantine" } | Select-Object -First 1 ).id # ジョブのスキーマから、ユーザーが対象の同期ルールを選ぶ $schema = Invoke-MgGraphRequest -Method GET ` -Uri "https://graph.microsoft.com/v1.0/servicePrincipals/ $spId /synchronization/jobs/ $jobId /schema" $ruleId = ( $schema .synchronizationRules | Where-Object { $_ .objectMappings.sourceObjectName -contains "User" } | Select-Object -First 1 ).id あとは、取得した $jobId と $ruleId 、そしてプロビジョニング対象のユーザーを指定してリクエストを投げます。 $body = @{ parameters = @( @{ ruleId = $ruleId subjects = @(@{ objectId = $userObjectId ; objectTypeName = "User" }) } ) } Invoke-MgGraphRequest -Method POST ` -Uri "https://graph.microsoft.com/v1.0/servicePrincipals/ $spId /synchronization/jobs/ $jobId /provisionOnDemand" ` -Body ( $body | ConvertTo-Json -Depth 10 ) ` -ContentType "application/json" この2つで同期待ちを潰すと、AD作成・各SaaSへのプロビジョニング・その後のSaaSごとの設定までが一本につながります。プロビジョニングのサイクルを待たずに済むので、後続の設定も同じ実行の中で流し込めます。終わった時点で、結果がSlackとジョブログに残ります。 運用：前日にdry-runで予定を流し、翌日に本番で作成する 毎月の作成は、dry-runと本番の2段階で回しています。 前日に走るのはdry-runです。AD作成やプロビジョニングといった変更は実際には行わず、「何をするか」（翌月入社者の作成予定）をSlackに流します。チームはこの通知で対象者を確認できるので、kintoneのデータに不備があっても、本番の前に気づけます。 翌日に本番が走ります。処理の開始から各ステップ、完了までを1本のSlackスレッドに流し、完了サマリーと、失敗したときのエラーだけはチャンネルにもブロードキャストして気づけるようにしています。作業サーバーのコンソールを覗かなくても、SlackとGitHub Actionsのログだけで実行状況を追えます。手作業時代に困っていた「ログの視認性の低さ」は、これで解消しました。 もう1つ効いているのが冪等性です。アカウント作成は既存ユーザーをスキップし、グループ追加も「すでにメンバー」を無視します。途中のステップが失敗しても、直して同じワークフローを流し直せば、できているところはそのまま、足りないところだけが埋まります。 また、プロビジョニングの後に各SaaSで行う個別の設定は、SaaS側の状態によっては失敗することがあります。これらは失敗しても全体を止めず、結果をSlackに残して先へ進む設定にしています。気づいたら、その部分だけ後で流し直せば済みます。 導入の効果 一番大きいのは、毎月の新入社員アカウント作成がほぼ無人で回るようになったことです。これまで人がCSVを受け渡し、スクリプトを手で実行し、同期を待っていた一連の作業が、1回のワークフロー実行にまとまりました。 業務ロジックもコードに集まり、「どの条件で何が付与されるか」をリポジトリで追えます。リポジトリのコードと実際に動くコードが一致するので、ドリフトも起きません。 まとめ 本記事では、新入社員のアカウント作成を、kintoneを起点にGitHub Actionsで自動化した取り組みを紹介しました。オンプレADの操作はself-hosted runnerで担い、散らばっていた業務ロジックはコードにまとめ、同期待ちはGraph APIのオンデマンドプロビジョニングで潰しました。手作業で属人化していた運用を、コード化して実行を追える形にできました。 オンプレミスとクラウドが混在する環境でアカウント運用を自動化したい方の参考になれば幸いです。今後は、退職時のアカウント無効化など、入社から退職までのライフサイクル全体へ自動化を広げていく予定です。 ZOZOでは、一緒にサービスを作り上げてくれる方を募集中です。ご興味のある方は、以下のリンクからぜひご応募ください。 corp.zozo.com

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 サービスを使用してお客様がビジネス成果を達成できるよう支援することに情熱を注いでいます。休日は、旅行やさまざまな場所、人々、文化を体験することを楽しんでいます。 翻訳はソリューションアーキテクト齋藤が担当しました。原文は こちら です。