How do I build shared file storage for app teams and ops?

A good way to build shared file storage for app teams and ops is to design it as a centralized, managed, access-controlled file service rather than a loose NFS share that everyone can write to.

1) Start with the use cases

Separate what the storage is for:

• App teams: application uploads, batch files, exports/imports, logs, artifacts
• Ops: backups, patches, installers, config bundles, runbooks, evidence files
• Cross-team: shared handoff areas, incident collections, reporting drops

Different use cases need different controls, performance, and retention.

2) Pick the right storage type

Usually you have three main options:

A. Managed network file storage

Examples: AWS EFS, Azure Files, Google Filestore, NetApp, Isilon/PowerScale

Best for:

• POSIX-like shared access
• Multiple servers or containers reading/writing the same files
• Existing apps that expect a mounted filesystem

Pros:

• Easy to mount
• Familiar to app teams
• Good for shared directories

Cons:

• Can become a “junk drawer” if governance is weak
• Performance and locking behavior can be tricky
• Not ideal for internet-facing uploads

B. Object storage with a file-access layer

Examples: S3 / Blob / GCS + app/API layer, sometimes with SFTP gateways or file transfer tools

Best for:

• New applications
• Large files
• Controlled upload/download workflows
• Audit and lifecycle management

Pros:

• Highly durable, scalable, cheap
• Strong access policies and auditability
• Easier retention/lifecycle management

Cons:

• Not a true shared filesystem
• Legacy apps may not work without changes

C. Hybrid

Use:

• Network file storage for legacy/shared app mounts
• Object storage for long-term archive, uploads, exports, and backups
• Transfer gateway/API for users and teams who need controlled access

This is often the best enterprise pattern.

3) Define the storage zones

Don’t make one giant share. Create zones by purpose and ownership:

• /team-a/
• /team-b/
• /ops/patches/
• /ops/backups/
• /shared/inbound/
• /shared/outbound/
• /archive/

Apply clear rules:

• Every folder has an owner
• Access is role-based
• Sharing happens by exception, not default
• Temporary folders have expiry dates

4) Use identity-based access control

Tie access to your identity provider:

• AD / LDAP / Entra ID / Okta / IAM groups

Use:

• Group-based permissions
• Least privilege
• Separate read/write/admin roles
• Service accounts only when needed
• No shared user accounts

A simple model:

• Team members: read/write in their own namespace
• Ops: admin on operational areas, read-only elsewhere unless approved
• Auditors: read-only to selected folders
• Automation: scoped service identities

5) Add quota and lifecycle controls

Without controls, shared storage grows uncontrolled.

Set:

• Quotas per team/project
• File size limits where appropriate
• Retention policies
• Archive policies
• Cleanup of temp folders
• Age-based deletion for staging areas

Examples:

• Temp upload folder expires in 7 days
• Export folder retained for 30 days
• Backup artifacts retained per policy
• Archive moved to cheaper storage after 90 days

6) Plan for audit and compliance

You want to know:

• Who accessed what
• Who changed what
• When files were created/deleted
• Whether sensitive data is present

Enable:

• File access auditing
• Admin action logging
• Integration with SIEM/SOC tools
• Malware scanning for uploads, if needed
• Encryption at rest and in transit

If regulated data may land there, classify it early:

• Public
• Internal
• Confidential
• Restricted

And set controls accordingly.

7) Make backup and DR explicit

Shared storage is often critical, so define:

• Backup frequency
• Recovery point objective (RPO)
• Recovery time objective (RTO)
• Cross-zone or cross-region replication
• Restore testing schedule

Also decide:

• What is backed up vs. just replicated
• Who can restore data
• How you prevent accidental restores over active data

8) Design for performance

Ask:

• Many small files or few large files?
• Read-heavy or write-heavy?
• Need locking?
• Need high concurrency?

This affects:

• Throughput sizing
• IOPS needs
• Mount options
• Directory structure
• File count limits

Tips:

• Avoid massive flat directories
• Use subfolders by date/team/app
• Don’t use shared storage as an application database
• Test with realistic workloads

9) Provide a simple operating model

Storage works best when there is a clear service model:

Ownership

• Platform/Ops owns the service
• Each folder/share has a business owner
• App teams own their data lifecycle

Request process

• New share or folder request
• Access request
• Temporary access approval
• Decommission process

Standards

• Naming conventions
• Folder ownership
• Data retention rules
• File transfer methods
• Incident response steps

10) Offer secure transfer methods

Users often need ways to get files in/out safely:

• Web portal
• SFTP/FTPS
• API upload/download
• Mounts for internal systems only
• Signed URLs for object storage

Avoid emailing files or using ad hoc personal shares.

11) Recommended reference architecture

A practical setup:

• Identity provider for groups and auth
• Managed file storage for legacy/shared mounts
• Object storage for long-term, scalable, less-structured use
• Transfer gateway for users and external partners
• Logging/auditing to SIEM
• Backup/replication for DR
• Quotas/retention by team and folder
• Malware scanning for inbound files if user uploads are allowed

12) Common mistakes to avoid

• One giant root share for everyone
• Permission sprawl and individual ACLs
• No owner for each directory
• No cleanup or retention
• Using shared storage as a messaging system
• No monitoring or restore testing
• Letting app teams bypass security for convenience

A simple rule of thumb

If the data is:

• legacy/shared filesystem dependent → use managed file storage
• new, scalable, auditable, or long-term → use object storage
• user-upload driven → use a controlled transfer service, not open shares

If you want, I can also give you:

1. a cloud-specific design for AWS/Azure/GCP,
2. a permission model template, or
3. a step-by-step implementation plan for a small or enterprise environment.