Enterprise
Secure Vendor Integration Platform
Cross-account S3 file distribution platform — partner onboarding time cut from days to hours.
Customer
Fortune 500 Industrial Manufacturing Enterprise — Parts & Pricing Division, external vendor/dealer partners
Timeline
2025
Status
Shipped — running in production
Capability
Stack
Outcome
Customer Context
Who they are and what world they live in
The parts & pricing division distributes files — price lists, parts catalogs, compliance documents — to a network of external vendor and dealer partners. Before this system, delivery was ad-hoc: email attachments, shared drives, manual SFTP credentials managed in spreadsheets. Partners had inconsistent access, IT had no audit trail, and onboarding a new partner took days of back-and-forth across teams.
The Problem
The fuzzy ask, translated
The stated ask was 'we need a better way to share files with partners.' The real problem was threefold: (1) the ad-hoc delivery model was a security risk — no isolation between partners, no encryption guarantee, no audit trail; (2) partner onboarding required manual intervention from multiple teams each time; (3) there was no reusable pattern — every new partner was a one-off configuration.
The Constraints
Time · Budget · Regulatory · Technical · Organizational
Partners use SFTP — they have existing tooling and cannot be asked to adopt a new protocol
Cross-account access — partner AWS accounts must be able to pull from the distribution bucket without holding long-lived credentials in the enterprise account
Per-partner data isolation — no partner can see another partner's files; home-directory isolation is required
KMS encryption at rest — enterprise security policy
Automated file generation — the pricing pipeline that generates source files must push to the distribution system without manual steps
Architecture Decisions
What I chose. What I rejected. Why.
SFTP delivery
Chosen
AWS Transfer Family (managed SFTP)
Rejected
Self-managed SFTP server on EC2
Why
Managed service eliminates the operational burden of patching, scaling, and monitoring an SFTP server. Transfer Family integrates natively with S3, IAM, and CloudWatch — the audit trail and access control are first-class, not bolted on.
Partner isolation
Chosen
Home-directory isolation per partner via Transfer Family logical directories, backed by IAM roles scoped to partner-specific S3 prefixes
Rejected
Separate S3 buckets per partner
Why
One bucket with prefix-scoped IAM is operationally simpler. Adding a partner is an IAM role and a Transfer Family user — not a bucket, policy, replication rule, and KMS key per partner.
Onboarding documentation
Chosen
Reusable onboarding runbook: IAM role template, KMS key policy, bucket policy, Transfer Family configuration — parameterized, reviewed, versioned
Rejected
Case-by-case configuration
Why
Generalization is a deliverable. The runbook turned partner onboarding from a multi-day multi-team coordination into a half-day task that any engineer on the team could execute.
The Hard Problem
The one thing that almost broke the deployment
Cross-account IAM trust relationships are deceptively simple to get wrong. The initial configuration allowed the partner IAM role to assume access but the S3 bucket policy wasn't scoped tightly enough — a misconfigured partner could have listed prefixes they shouldn't see. The trust relationship had to be explicit in both directions: the enterprise account bucket policy and the partner account role trust policy, with condition keys on the S3 prefix.
The Fix
Added explicit S3 condition keys on every bucket policy statement: `s3:prefix` conditions scoped to the partner's home directory prefix, with `StringLike` (not `StringEquals`) to allow recursive access within the prefix. Tested cross-account access from a sandbox partner account before any production configuration. Every new partner configuration follows the same test procedure before going live.
Production Reality
What I had to fix in week 2
The automated file generation pipeline ran on a schedule that didn't account for Transfer Family's eventual consistency on new user creation. New partners added within 30 minutes of a scheduled file push sometimes didn't receive the file. Added a 5-minute wait gate in the Lambda orchestration and a fallback manual trigger for same-day onboarding cases.
Lessons Carried Forward
What this taught me that I apply to every deployment
Cross-account IAM condition keys must be explicit in both directions — a trust relationship that works in one direction is not the same as one that works correctly
Test cross-account access from a real sandbox account before any production configuration — the IAM policy simulator does not catch all cross-account edge cases
Generalization is a deliverable — the onboarding runbook reduced partner integration time as much as the platform itself
Scheduled automation needs to account for eventual consistency in managed services — adding a wait gate is cheaper than debugging a missed file
Related Deployments