CodeNote.net

Search

Amazon WorkSpaces Personal on Simple AD at small scale — setup, cost, and scaling paths

#aws#workspaces#active-directory#security#infrastructure
Tadashi Shigeoka · Wed, July 15, 2026

We needed a dedicated Windows desktop for work that involves a browser and client certificates, so I stood up Amazon WorkSpaces Personal in the Tokyo region on Simple AD. The intended user base was small (a handful of people), and because the desktop is only used for a specific line of business a few hours a day, the AutoStop model with hourly billing was a natural fit.

Getting to a working configuration meant several passes through the AWS documentation. Simple AD closed to new customers as of July 30, 2026; Simple AD is free while attached to WorkSpaces, but only under specific conditions; where exactly AutoStop billing kicks in; how to migrate off Simple AD later when tighter authentication or management controls become necessary. None of these can be answered without reading the primary sources. This post walks through a minimum small-team setup, actual Tokyo-region costs, Simple AD’s limits, and the decision points for AWS Managed Microsoft AD and AD Connector. All AWS documentation was verified on 2026-07-15.

Why a dedicated Windows environment

There is only one reason: the everyday workstation is macOS. The line of business at hand required Windows, and macOS could not host it, physically or operationally.

An additional Windows machine on a desk was one option, but it comes with side effects: power stays on when nobody is using it, it is inaccessible from other locations, and a spare has to be ready for hardware failures. What we actually wanted was a Windows desktop we could spin up from the macOS in front of us with a single browser tab, one that stops itself when we are not using it. That is why we went with a cloud DaaS.

Why Amazon WorkSpaces

We also looked at Amazon AppStream 2.0 and just running Windows Server on EC2 with RDP, but converged on WorkSpaces for the following reasons.

  • We wanted a persistent Windows desktop assigned per user (AppStream 2.0 is oriented toward application streaming; a persistent per-user desktop is more natural on WorkSpaces)
  • Stop/start, user assignment, and directory integration all happen inside the WorkSpaces console
  • The Tokyo region offers Japanese Windows Server desktop bundles with the OS license included (WorkSpaces bundles)
  • The AutoStop billing mode charges per hour on top of a low monthly fixed cost, which fits low-utilization small-team use

Windows 10/11 client desktops on WorkSpaces require Bring Your Own License (BYOL), but Japanese Windows Server desktops are available as license-included public bundles. To skip the BYOL setup work I chose a Windows Server 2025 bundle.

Picking a directory

WorkSpaces Personal requires a directory (the identity and user-management backing) to be paired with it. The Manage directories page lists the following options.

  • Simple AD
  • AWS Managed Microsoft AD
  • AD Connector (proxy to an existing Active Directory)
  • Microsoft Entra ID (Windows 10/11 BYOL only, via IAM Identity Center)
  • Custom directory

Under our constraints (small team, single-purpose, no existing AD, no BYOL), the shortlist is effectively Simple AD versus AWS Managed Microsoft AD. It was here, reading the primary sources, that Simple AD’s availability change came into view.

The June 30, 2026 announcement, effective July 30, 2026

AWS published its Service Availability Updates on June 30, 2026, moving several services (Simple AD included) to maintenance mode. The effective date is July 30, 2026, from which new customers can no longer onboard to Simple AD. Existing customers are unaffected; AWS continues to operate and support the service.

The Directory Service documentation has a dedicated page, Simple AD availability changes, that spells out the boundary:

Only new customer onboarding to Simple AD is not permitted. Existing Simple AD customers retain full functionality. Your directories, users, computers, and integrated workloads are not affected, and you can continue to create new Simple AD directories.

Concretely:

  • New customers who first touch Simple AD on or after July 30, 2026 cannot use it
  • Existing customers are unaffected and can still create new Simple AD directories in their existing account
  • The AWS-recommended alternatives are AWS Managed Microsoft AD or AD Connector

“Simple AD can no longer be created” is a common shorthand that drops the qualifier and gets the fact wrong. The determinant is whether the AWS account counts as an existing Simple AD customer, and that’s decided at the account level. The WorkSpaces Personal tutorial Create a Simple AD directory for WorkSpaces Personal carries the same constraint, and I did not find any documentation treating Quick Setup as a carve-out for new customers.

In our case the AWS account qualified as an existing Simple AD customer, so Simple AD was still on the table. On a brand-new account it would not have been, and the choice would have been AWS Managed Microsoft AD or AD Connector from the start.

The Simple AD minimum setup we ended up with

Here is the actual configuration we deployed. Values are listed as-built.

  • Region: Tokyo (ap-northeast-1)
  • Service: Amazon WorkSpaces Personal
  • OS: Japanese Windows desktop based on Windows Server 2025
  • Bundle: Performance (2 vCPU, 8 GiB memory)
  • Root volume: 80 GB, User volume: 100 GB
  • Running mode: AutoStop (60-minute stop delay)
  • Protocol: DCV
  • Directory: Simple AD (Small)
  • VPC: dedicated VPC
  • Subnets: two, in different Availability Zones
  • Internet path: via an Internet Gateway
  • Users: small team (a handful)
  • Use case: browser plus client certificates for a specific line of business

Simple AD deploys two domain controllers across two Availability Zones automatically, so the two subnets must sit in different AZs. DCV is the newer of the WorkSpaces streaming protocols, Amazon DCV-based, and works from Web Access and native clients alike. AutoStop’s minimum stop delay is 60 minutes: once the WorkSpace has been disconnected for the configured window, it stops automatically and hourly billing pauses.

Network topology

VPC, subnets, and Internet Gateway itself do not incur charges. Rather than build a private subnet with a NAT Gateway, we routed the WorkSpaces subnets straight out through the Internet Gateway. WorkSpaces themselves do not carry a public IP by default and communicate with clients through the regional WorkSpaces endpoint, so we avoid NAT Gateway’s baseline cost (Tokyo: $0.062/hr, roughly $45.26 per month, plus $0.062/GB of processed data).

Drawn in Mermaid:

flowchart LR
  User[Windows/Mac<br/>WorkSpaces Client] -->|DCV/HTTPS| Endpoint[WorkSpaces<br/>regional endpoint]
  Endpoint --> WS
  subgraph VPC[dedicated VPC ap-northeast-1]
    subgraph AZ1[AZ-a]
      Subnet1[Subnet 1]
      SimpleAD1[Simple AD DC1]
      WS[WorkSpaces Personal<br/>Windows Server 2025<br/>2 vCPU / 8 GiB]
    end
    subgraph AZ2[AZ-c]
      Subnet2[Subnet 2]
      SimpleAD2[Simple AD DC2]
    end
    IGW[Internet Gateway]
  end
  WS -->|Web/certs| IGW --> Internet[Internet/business sites]

Client-to-WorkSpaces traffic enters through the AWS-managed regional endpoint, not through the Internet Gateway. Per the WorkSpaces port requirements, the VPC does not need to open any inbound ports toward the WorkSpace.

What it actually costs

Costs below are derived from the WorkSpaces pricing page and the Directory Service pricing page for the Tokyo region as of 2026-07-15. USD to JPY conversion is a rough $1 = 150 JPY; the market rate at publication time will differ.

Performance bundle unit prices

  • AutoStop: $19 per month fixed + $0.61 per hour of use
  • AlwaysOn: $65 per month fixed (no hourly charge)

Monthly cost with Simple AD (free while attached to WorkSpaces)

UsersAutoStop 20hAutoStop 80hAutoStop 160hAlwaysOn
3$93.6
(~14,000 JPY)		$203.4
(~30,500 JPY)		$349.8
(~52,500 JPY)		$195
(~29,300 JPY)
5$156
(~23,400 JPY)		$339
(~50,900 JPY)		$583
(~87,500 JPY)		$325
(~48,800 JPY)
10$312
(~46,800 JPY)		$678
(~101,700 JPY)		$1,166
(~174,900 JPY)		$650
(~97,500 JPY)

The Directory Service other directories pricing page notes that Simple AD is free while attached to WorkSpaces. The specific “not used for 30 consecutive days → automatically deregistered, Directory Service’s regular rates apply” wording lives on the WorkSpaces side, in Create a Simple AD directory for WorkSpaces Personal. As long as the WorkSpace sees any use each month, Simple AD stays at zero.

With AWS Managed Microsoft AD Standard (directory +$53.3/month)

UsersAutoStop 20hAutoStop 80hAutoStop 160hAlwaysOn
3$146.9
(~22,000 JPY)		$256.7
(~38,500 JPY)		$403.1
(~60,500 JPY)		$248.3
(~37,200 JPY)
5$209.3
(~31,400 JPY)		$392.3
(~58,800 JPY)		$636.3
(~95,400 JPY)		$378.3
(~56,700 JPY)
10$365.3
(~54,800 JPY)		$731.3
(~109,700 JPY)		$1,219.3
(~182,900 JPY)		$703.3
(~105,500 JPY)

AWS Managed Microsoft AD Standard is $0.073 per hour in Tokyo, or roughly $53.3 per month over 730 hours. The WorkSpaces-attachment free tier that applies to Simple AD and AD Connector does not apply to AWS Managed Microsoft AD (it is billed hourly at all times).

With AD Connector Large (directory +$175.2/month, plus VPN/DX)

UsersAutoStop 20hAutoStop 80hAutoStop 160hAlwaysOn
3$268.8 + VPN/DX
(~40,300 JPY+)		$378.6 + VPN/DX
(~56,800 JPY+)		$525 + VPN/DX
(~78,800 JPY+)		$370.2 + VPN/DX
(~55,500 JPY+)
5$331.2 + VPN/DX
(~49,700 JPY+)		$514.2 + VPN/DX
(~77,100 JPY+)		$758.2 + VPN/DX
(~113,700 JPY+)		$500.2 + VPN/DX
(~75,000 JPY+)
10$487.2 + VPN/DX
(~73,100 JPY+)		$853.2 + VPN/DX
(~128,000 JPY+)		$1,341.2 + VPN/DX
(~201,200 JPY+)		$825.2 + VPN/DX
(~123,800 JPY+)

AD Connector Large is $0.24 per hour in Tokyo, or roughly $175.2 per month. The Directory Service pricing page does note that AD Connector is also free while attached to WorkSpaces, but in practice you will pay for the Site-to-Site VPN or Direct Connect link and for operating the on-premises AD itself.

ItemRateMonthly (730h)Note
Public IPv4 (EIP or auto-assign)$0.005/hr$3.65/IP
(~550 JPY)		WorkSpaces themselves do not carry a public IP, but you may need one for NAT-style paths
NAT Gateway$0.062/hr + $0.062/GB$45.26 baseline
(~6,800 JPY) + data		Only relevant if you route WorkSpaces through a private subnet with NAT
Internet Gateway itselfFree-Data transfer is billed separately
Data transfer out (from Tokyo)Tiered USD/GBSee pricing pageAll regions get 100 GB/month free

Items not included in these numbers

Additional storage beyond the default Root 80 GB / User 100 GB, per-tier data-transfer-out from Tokyo, AWS Private CA (needed for certificate-based authentication), CloudTrail data events, CloudWatch Logs retention, VPN or Direct Connect, RADIUS servers, and staff operating hours are all excluded. In particular, additional-storage per-GB pricing and per-tier data-transfer pricing for Tokyo could not be pinned down from primary sources at the time of writing; I recommend running numbers through the AWS Pricing Calculator. Prices and exchange rates move, so verify against the AWS pricing pages before publishing anything.

What Simple AD can and cannot do

Simple AD is a Samba 4-based Active Directory-compatible directory. The Simple AD overview enumerates its capabilities and limits clearly.

Simple AD supports:

  • Windows and Linux instance domain join
  • Basic user, group, and OU creation and management
  • Basic password policies
  • Kerberos-based single sign-on
  • Automatic daily snapshots plus manual snapshots
  • Two-DC redundancy across two AZs, provisioned automatically

Simple AD explicitly does not support:

  • Multi-factor authentication (MFA)
  • Trust relationships with other domains
  • Schema extensions
  • AD Administrative Center, PowerShell modules, AD Recycle Bin, gMSA
  • IAM Identity Center integration
  • Amazon FSx, Amazon RDS for SQL Server / Oracle, Amazon Chime, WorkSpaces Applications

The lack of MFA, trust relationships, and schema extensions are the constraints most likely to bite when the environment matures. RADIUS-based MFA in WorkSpaces is documented as a feature enabled through AD Connector or AWS Managed Microsoft AD (Enable multi-factor authentication for Amazon WorkSpaces), not Simple AD.

For WorkSpaces-specific Group Policy (clipboard, USB, printing, drive redirection, and so on), the Manage your Windows WorkSpaces with Group Policy page reads as though AD Connector or AWS Managed Microsoft AD is the assumed baseline. Simple AD’s own docs claim you can “create and apply group policies,” but I could not find explicit language confirming full support for the WorkSpaces ADMX templates on Simple AD. For small-team, single-purpose use this rarely bites; for organization-wide redirection lockdown, the difference matters.

Breaking down “more secure” by requirement

“Picking anything other than Simple AD automatically makes it more secure” is not accurate. The table below splits the security posture by requirement, separating what Simple AD can do from what it cannot.

ConcernSimple AD supportsDifficult or unsupported on Simple AD
Password policyBasic policyFine-Grained Password Policy
MFANot at the directory layer (only workable via IdP MFA on a SAML path)Directory-side RADIUS MFA
User lifecycleAD user create/deleteIAM Identity Center or HR-system integration
Admin role separationDomain Admins-level splitsFine-grained RBAC and privileged access management
Group PolicyBasic GPOsFull WorkSpaces ADMX support (not explicitly documented)
Endpoint control (USB, clipboard, printing)Some via GPORich redirection lockdown is aimed at AWS Managed Microsoft AD / AD Connector
Network isolationVPC, security groups, IP Access Control Groups-
Internet egress controlNAT, firewall, proxy-
CloudTrail / CloudWatchYes-
Directory audit loggingLimited (Samba-based)Detailed event logs on AWS Managed Microsoft AD
Directory backupAutomatic daily plus manual snapshots-
WorkSpace backupOne 12-hour snapshot generationPoint-in-time recovery or external generational backup requires separate machinery
RedundancyTwo DCs across two AZs, automatic-
Certificate-based authentication (CBA)Not supported (requires SAML 2.0 plus AWS Private CA)Supported on AWS Managed Microsoft AD
IAM Identity Center integrationNot supportedSupported on AWS Managed Microsoft AD

The pieces provided by AWS common services (network isolation, egress control, CloudTrail auditing, snapshot-based redundancy) are equally available on Simple AD. What breaks the ceiling is directory-native functionality: MFA, detailed audit logs, trust relationships, schema extensions, CBA, IAM Identity Center integration. Once any of those become a hard requirement, you are moving off Simple AD.

IP Access Control Groups is a WorkSpaces feature (IP access control groups) that lets you restrict source CIDRs for the WorkSpaces streaming connection. It attaches to the directory but is available regardless of directory type, including on Simple AD.

Alternatives to Simple AD

Three practical alternatives when Simple AD becomes insufficient.

AWS Managed Microsoft AD for tighter management

AWS Managed Microsoft AD runs real Windows Server Active Directory on AWS, not a Samba implementation. You get GPO, trusts, schema extensions, Kerberos, LDAPS, and CBA.

What improves compared to Simple AD:

  • Directory-side MFA (RADIUS)
  • Fine-Grained Password Policy
  • Trust relationships with other domains (share users with an existing on-premises AD)
  • Schema extensions and third-party tool compatibility
  • Detailed audit event logs forwarded to CloudWatch Logs
  • Up to 30,000 objects on Standard, 500,000 on Enterprise
  • Multi-Region replication for wider redundancy
  • Certificate-based authentication (paired with AWS Private CA)
  • IAM Identity Center integration

The downsides are cost and operational surface. In Tokyo, Standard is $0.073/hr
($53.3/month) billed continuously, Enterprise is $0.2225/hr
($162.4/month). The WorkSpaces-attachment free tier does not apply. Troubleshooting draws on real AD skills. For a small-team single-purpose workload that will not exercise any of these features, the +$53.3/month is hard to justify.

AD Connector to your existing organizational directory

If you already run Active Directory in-house, AD Connector lets WorkSpaces authenticate against it directly. AD Connector holds no replica in AWS; it is a proxy from AWS to your existing AD.

Improvements over Simple AD:

  • User lifecycle stays entirely in the existing AD (joins, moves, leavers all go through one process)
  • Password policy, account lockout, and logon restrictions all inherit from the existing AD
  • If you have an existing RADIUS backend, MFA reuses that backend
  • GPOs continue to be managed from the existing AD

Downsides: AD Connector Large is $0.24/hr
(~$175.2/month), higher than Simple AD; you need a Site-to-Site VPN or Direct Connect back to the existing AD; and AD Connector itself has no snapshot capability (backup is the existing AD’s responsibility). The prerequisites are “you do not need to stand up a new AD, but you do need connectivity and an operating model for the existing one.”

WorkSpaces Pools for shared, non-persistent use

For some workloads you want WorkSpaces Pools instead of Personal (non-persistent desktops assigned from a pool, on a session-hour billing model).

Pools require SAML 2.0 authentication with an IAM SAML federation role and a relay-state URL. Active Directory join is optional; joining an AD only unlocks smart card, CBA, and domain-joined use. Pools does not fit our “persistent, single-purpose workstation” case, but it becomes an option for call centers or time-limited training environments where you want a clean, identical environment each session.

Is AWS Managed Microsoft AD too heavy for small use

For small teams, the deciding factor is less about cost and more about whether authentication or management requirements are likely to change in the next 12 to 24 months.

If you start on Simple AD and later switch to AWS Managed Microsoft AD, note that Migrate WorkSpaces covers bundle-to-bundle migration only. I could not find an official procedure for moving an existing WorkSpace to a different directory. In practice, you rebuild: create WorkSpaces under the new directory, migrate user data, and retire the old ones. Doing this while the team is small keeps the blast radius small; doing it after growth is disruptive.

Rules of thumb:

  • Small team, no near-term need for MFA, GPO endpoint lockdown, or trust relationships: Simple AD is fine
  • Any of MFA, detailed GPO, IAM Identity Center integration, or CBA becoming a requirement within six months: go with AWS Managed Microsoft AD Standard from the start
  • Existing on-premises AD available: go with AD Connector (skip Simple AD entirely)

Integrating with an existing organizational identity

“Integrate with the existing organizational identity” packages several distinct things. Separating them out helps.

  • Sign-in to the WorkSpaces client (how the session is launched): SAML 2.0 integration with an IdP puts this at the IdP’s MFA and conditional access controls. But WorkSpaces Personal’s SAML 2.0 authentication documentation states that Simple AD, AD Connector, or AWS Managed Microsoft AD is required behind the scenes. SAML alone does not eliminate the need for a directory
  • Logon to the Windows desktop: even with a SAML session, the Windows OS layer still requires AD credentials (only CBA replaces that with a certificate)
  • User lifecycle: AD Connector delegates to the existing AD; AWS Managed Microsoft AD needs its own operating model
  • MFA: not available on Simple AD alone. RADIUS MFA works with AD Connector and AWS Managed Microsoft AD. On a SAML path, the IdP’s MFA is available
  • Windows endpoint policy: GPOs work with AD Connector and AWS Managed Microsoft AD. If you want CBA, the certificate issuance and trust design combines SAML with AWS Private CA

Microsoft Entra ID native join is a distinct case in WorkSpaces. Access with Microsoft Entra ID restricts it to Windows 10 or 11 BYOL WorkSpaces, enrolled into Microsoft Intune through Windows Autopilot, with IAM Identity Center as the identity broker to the Entra ID tenant. It is not available on Windows Server bundles. Conversely, if you already have Windows 10/11 BYOL licenses and an Intune environment, going straight to Entra ID skips setting up an AD entirely.

Third-party IdP setup and pricing are out of scope for this post, but AWS documentation lists ADFS, Azure AD, Duo, Okta, PingFederate, and PingOne as examples. Keep the general principle in view (SAML 2.0-capable IdPs can be integrated) and defer product-specific selection until requirements are clearer.

Backup and restore

WorkSpaces backup and restore is not what the phrase “generational backup you can roll back to any point” implies, so calibrate expectations early.

  • Automatic snapshots are taken every 12 hours. Restore a WorkSpace reads “the date and time of the snapshots used for the operation are shown”. The console and API expose only the most recent snapshot, and you cannot pick an arbitrary earlier point
  • Rebuild a WorkSpace rebuilds the root volume from the bundle’s latest image and the user volume from the latest snapshot. The primary ENI is recreated, so the private IP changes
  • Restore returns both root and user volumes to the same snapshot point
  • Delete a WorkSpace is destructive: “the WorkSpace user’s data does not persist and is destroyed.” Data must be exported before termination

Directory-side snapshots differ between Simple AD and AWS Managed Microsoft AD.

  • Simple AD: automatic daily plus manual snapshots
  • AWS Managed Microsoft AD: automatic daily plus manual snapshots
  • AD Connector: no snapshot capability (backup is the existing AD’s responsibility)

For client certificates and private keys, treat portability as unreliable. Rebuild recreates the root volume (C:) from the bundle image, so the LocalMachine certificate store and any machine-specific data on C: are lost. User certificate stores under the user profile (typically mapped to D:) are theoretically covered by the user-volume snapshot, but I could not find explicit language in WorkSpaces documentation guaranteeing that certificates survive Rebuild intact. DPAPI-protected private keys are bound to machine keys and SIDs and generally cannot be decrypted on a different machine. If certificates are in play, keep the reissue procedure as part of standard operations.

Security settings and day-to-day operations

Baselines that work on Simple AD too:

  • Do not grant persistent local administrator rights; expose the admin credential only when installing software
  • Keep the business WorkSpace separate from the primary workstation (do not mix browser extensions, sign-in state, or history)
  • Automate Windows Update and browser auto-update, then eyeball state on a monthly basis
  • Install the organization’s antivirus and EDR on the WorkSpace (not all bundles preinstall these)
  • Lock down clipboard, drive, USB, printing, and file-transfer redirection through GPO to the minimum required
  • Use IP Access Control Groups to restrict source IPs for WorkSpaces client connections
  • Enable CloudTrail in all regions to record WorkSpaces and Directory Service API activity
  • Monitor connection events via CloudWatch metrics (ConnectionAttempt, ConnectionSuccess, ConnectionFailure, SessionLaunchTime, UserConnected)
  • Restrict internet egress to the minimum required domains (network ACLs and firewalls in front of a NAT Gateway when applicable)
  • Handle client-certificate private keys inside the WorkSpace only; mark them non-exportable or otherwise prevent extraction from the OS keystore
  • Export user data before terminating a WorkSpace; use organization-sanctioned cloud storage as the destination (Amazon S3, OneDrive, Google Drive, or similar)
  • Disable departing users promptly in the directory and detach the WorkSpace assignment
  • Document a bare-minimum incident procedure covering how much Rebuild recovers, where user data lives for export, and whether certificates need reissue

CloudTrail, CloudWatch metrics, and IP Access Control Groups do not depend on the directory type. That leaves room to satisfy audit requirements later without swapping the directory.

Growth and migration paths

If you migrate off Simple AD later, as noted above, the practical path is rebuild rather than in-place migration.

  1. Stand up the new directory (AWS Managed Microsoft AD or AD Connector) in a separate or shared VPC
  2. Create new WorkSpaces under the new directory and validate
  3. Migrate user data via cloud storage to the new WorkSpaces
  4. Reissue client certificates on the new WorkSpaces (do not assume private-key portability)
  5. Before terminating the old WorkSpaces, confirm data export is complete
  6. Deregister the old Simple AD

“Start on Simple AD, migrate later” is realistic only while the team is small. Past about 10 users, secondary work (certificate reissue, browser re-setup, business-system re-registration) scales roughly linearly. If growth to that size is visible within six to twelve months, choosing AWS Managed Microsoft AD or AD Connector up front is usually cheaper end-to-end.

A quick reverse lookup:

  • Small team, single-purpose, no existing AD, no BYOL, no MFA requirement, existing AWS account still eligible for Simple AD: Simple AD + WorkSpaces Personal (AutoStop)
  • Small team but on a new AWS account that cannot use Simple AD: AWS Managed Microsoft AD Standard + WorkSpaces Personal (AutoStop)
  • Small to mid-sized team with MFA, GPO endpoint control, IAM Identity Center integration, or CBA as a requirement: AWS Managed Microsoft AD Standard + WorkSpaces Personal
  • Existing on-premises AD: AD Connector + WorkSpaces Personal + Site-to-Site VPN or Direct Connect
  • Windows 10/11 BYOL and Intune already in place: Microsoft Entra ID native join + WorkSpaces Personal
  • Non-persistent, shared use (call centers, time-limited environments): WorkSpaces Pools + SAML 2.0
  • Large-scale, global: AWS Managed Microsoft AD Enterprise + Multi-Region

That’s all from mapping out a WorkSpaces Personal minimum setup and its scaling paths in the wake of Simple AD closing to new customers, from the Gemba.

References