Procure

Services

The decision worth arguing about

The non-obvious decision sits on the supplier document upload path, which is the one place in this system where unauthenticated external parties put arbitrary files into your infrastructure. Suppliers upload insurance certificates, W-9s and bank letters through a public portal, and those files then get opened by someone in finance. The choice is between GuardDuty Malware Protection for S3, which scans objects on upload and bills per gigabyte scanned plus a per-object charge, and running our own ClamAV scanner as a Fargate service triggered by an S3 event. We use GuardDuty, and the reasoning is not that it is cheaper — at the reference org's volume of a few thousand documents a year it costs single-digit dollars a month, so cost is not the deciding factor either way. It is that ClamAV's value is entirely in its signature freshness, which means a cron job pulling definitions, a container image rebuild cadence, and a silent failure mode where the scanner keeps returning clean because its database is four months stale and nobody noticed. That is a maintenance liability we would be handing to the customer at handover, on the security-critical path, forever. GuardDuty's trade-off is honest and worth stating: it is an AWS-managed detection engine we do not control, it adds a few seconds of latency before a document is marked usable, and it charges by volume — so an onboarding campaign that ingests ten thousand supplier documents in a week costs real money in a way a fixed-size ClamAV task would not. We accept that because the alternative failure mode is worse. The supplier portal itself runs as its own Fargate service on its own ALB with its own Cognito pool and no network route to internal services; it reaches the core only through EventBridge, which means a supplier's view of their own onboarding status lags the internal record by a second or two. We consider that an acceptable price for a hard boundary.

Services

The decision worth arguing about

Azure's equivalent of the upload-scanning decision has a trap in it that AWS does not. Defender for Storage offers on-upload malware scanning per storage account, and by default it applies a monthly scanning cap — a configurable ceiling on gigabytes scanned per account per month, which exists to stop a runaway bill. The failure mode is the important part: when a storage account hits its cap, scanning stops for the rest of the month and uploads continue to succeed. Files land unscanned and nothing about the upload flow tells the user. If you onboard suppliers in campaigns rather than steadily — and everyone does, because onboarding follows procurement cycles — you can breach a default cap in a single week and spend three weeks accepting unscanned documents from external parties. So the Azure deployment does two things: it isolates supplier uploads into a dedicated storage account so the cap is not shared with anything else, and it wires the cap-reached signal from Defender into the same alert path as a production incident, with the application refusing to mark documents usable when the scan result is absent rather than defaulting to allow. The second Azure difference is identity. Suppliers must never appear in the corporate directory — a supplier contact with an object in your employee tenant is a governance problem that surfaces in every access review afterwards — so we use Entra External ID as a genuinely separate identity boundary, which is cleaner than the two-Cognito-pool arrangement on AWS but requires its own tenant configuration and its own branded sign-in experience.