Mount point limits and behavior
Capacity, quotas, and scale
EFS and S3 Files are elastic. There is no provisioned size. The storage value on the volume is required by Kubernetes but ignored, so do not promise users a per-Mount-Point size quota.
| Limit | Value |
|---|---|
| Access points per EFS file system | About 10,000. A default that AWS Support can increase. |
| Access points per S3 Files file system | 25,000. Cannot be increased. |
| Mount targets per Availability Zone |
|
| Mount Points created per file system, per region | 1,000. Enforced by SecurSpaces and not configurable. |
Every Create New Mount Point consumes one access point, and the ceiling is shared across all projects on that file system. An access point you create by hand occupies a slot from the moment you create it, so count pre-created access points into the same budget.
When the 1,000 limit is reached, new requests are rejected with a message that the file system storage limit has been reached. The limit is compiled into the product. It is not a settings, Helm, or environment value. It is also approximate: a burst of simultaneous creates can push a file system slightly over, and during a datastore outage it is not enforced. Treat it as a leading indicator and the AWS ceiling as the real backstop.
Prefer a file system dedicated to SecurSpaces Mount Points. On a shared file system SecurSpaces counts only its own access points, so the real total can approach the AWS ceiling while SecurSpaces still believes there is room.
Isolation between Mount Points is directory and POSIX identity on a shared file system. Access points on one file system share one encryption key and one throughput pool. Put a tenant that needs its own key, throughput pool, and failure domain on a separate file system.
Note
A separate file system is not by itself an access boundary. Who may mount is decided by IAM and the network. To make the split real, scope the node role’s client permissions to named file systems and keep the file system’s mount targets closed to other clusters’ nodes.
Deletion and data protection
What a delete removes depends on how the Mount Point was created:
| Mode | What SecurSpaces removes | Backing data |
|---|---|---|
| Create New | The claim. The StorageClass reclaim policy then removes the volume. | Destroyed. The access point is removed. |
| Attach Existing, SecurSpaces-built volume | The claim and the volume. | Retained. |
| Attach Existing, volume you authored | Only the claim. | Retained. |
Deleting a Create New Mount Point removes the access point but leaves its directory and files on the file system. Plan periodic cleanup of these orphaned directories, and never attach a file-system-root volume over such a file system.
A Mount Point cannot be deleted while a live workspace or workspace template uses it. It also cannot be deleted while a deleted workspace in the recycling bin still uses it, because that workspace can be restored. Detaching does not help in that case. Either permanently delete the named workspaces from Deleted Workspaces, wait for the retention period to expire, or restore the workspace and remove the Mount Point from it.
Updates are metadata-only. Only the name and mount path can be changed. The file system id, access point, and subpath are fixed when the Mount Point is created, AWS Mount Points cannot be resized, and the read-write or read-only setting cannot be changed after creation.
Warning
A Mount Point is collaborative read-write storage with no undo. Every workspace that mounts it can delete any file, and the access point squashes all activity to a single POSIX identity, so file ownership gives no per-user protection. SecurSpaces does not create, schedule, verify, or monitor backups. Backup and recovery of Mount Point data are entirely the responsibility of the AWS account owner.
For Amazon EFS, the only recovery path is an AWS Backup recovery point that existed before the loss. Backups are per file system, not per Mount Point, so a restore brings back every project’s directory on that file system together.
For Amazon S3 Files, bucket versioning is the recovery path: a file deleted through the file system becomes a non-current object version. Pair it with a lifecycle rule that keeps non-current versions long enough to be useful.
Warning
Never let a lifecycle rule move live data into an archive tier. Objects in Glacier Flexible Retrieval or Deep Archive cannot be read through the file system at all. Apply transition rules only to non-current versions.
A restore never puts files back where they were. AWS Backup writes into a new directory off the file system root,
named aws-backup-restore_<datetime>. Because every Mount Point is rooted inside an access point directory, that
directory sits above the mount root and is invisible from every workspace. An operator must mount the file system
without an access point from an administrative host, copy the files back into the access point directory preserving
ownership, and then delete the recovery directory, which is billed as file system storage.
Rehearse the whole procedure, not just the restore job. A restore that reports success proves nothing about whether developers get their files back. Confirm from inside a workspace that the files and their ownership appear at the mount path.
Note
Keep your StorageClass and volume manifests in source control. If you lose the cluster, the volumes, claims, and StorageClasses are gone, while the Mount Point records survive and still report as ready.
Amazon S3 Files behavior to plan around
-
No hardlinks. One file is one S3 object key, and an attempt returns
Too many links. Tools that deduplicate using hardlinks fail or fall back. Symlinks work. - Export is asynchronous, taking roughly 60 to 72 seconds. A file written in a workspace appears as an object after a sync, not instantly. Within the file system, reads, writes, and locking are immediately consistent.
- Conflicting writes discard the workspace’s version. If the same file changes both in a workspace and directly in S3, the bucket wins. No error is returned to whoever wrote the file. Partition the bucket by writer, or keep external processes read-only.
- Displaced files land where workspaces cannot see them, in a lost-and-found directory in the file system root. Only an operator can recover them, and AWS keeps and bills for them indefinitely.
-
A path longer than the 1,024-byte S3 key limit never reaches the bucket. Export fails terminally, so no
object version exists to restore and bucket versioning does not cover it. Alarm on the CloudWatch
ExportFailuresmetric in theAWS/S3/Filesnamespace.
Use Amazon EFS for latency-sensitive work such as git trees and build caches. Use Amazon S3 Files for large, mostly immutable datasets, where it is substantially cheaper.
Files are owned by the access point identity rather than the workspace user, so ownership-sensitive tools such as
git’s safe.directory check may warn. This is normal access point behavior.
Multi-region
Mount Points are not supported in multi-region configurations. A Mount Point is always created against the primary region, and the workspace Resources step prevents adding a Mount Point to a workspace in any other region.
Note
Workspace templates are not covered by that block. The template editor allows a Mount Point to be attached regardless of region, so a template can be saved carrying storage that workspaces outside the primary region cannot use. Do not treat this as a supported way to use Mount Points in a secondary region.
Timeouts
Provisioning is subject to two fixed timeouts. Neither is configurable.
| Timeout | Value |
|---|---|
| Volume bind | 3 minutes |
| Overall provisioning call | 5 minutes |
Exceeding either moves the Mount Point to an error state, from which it can be deleted and re-created.
Metrics
SecurSpaces publishes these Prometheus metrics for Mount Points on the /metrics endpoint.
| Metric | Labels | What it records |
|---|---|---|
sds_mountpoint_create_total |
type, result, reason
|
Terminal outcome of a mount point create |
sds_mountpoint_create_rejected_total |
reason |
Creates rejected at the front door, excluding the soft-quota reject counted separately |
sds_mountpoint_quota_gate_total |
outcome |
Decisions of the per-file-system soft quota gate on Create New |
sds_mountpoint_attach_admit_total |
sub_mode, decision, reason
|
Attach Existing admission decisions |
sds_mountpoint_readback_total |
provider, mount_point_type, result
|
Outcome of the volume handle read-back after bind |
sds_mountpoint_state_write_total |
outcome, state
|
Mount point state writes |
sds_mountpoint_stranded_recovered_total |
state |
Rows re-admitted after being stranded in a transient state |
sds_mountpoint_enable_flag_failopen_total |
cause |
Times the enable-flag check failed open, allowing a create despite an unreadable or absent configuration |
sds_mountpoint_picker_classes_hidden |
region |
StorageClasses currently hidden from the Create New picker for missing the tls mount option |
Two are worth alerting on:
-
sds_mountpoint_readback_totalwith aresultother thanresolved. A Mount Point became ready without the key used for correlation, quota counting, and orphan detection. Aresultofno_access_pointwithmount_point_type="create_new"means a whole-file-system handle, which exposes every project’s data on that file system. -
sds_mountpoint_enable_flag_failopen_total. Any non-zero value means a create was allowed while the configuration could not be read.
Warning
Do not rename these metrics to match the product name. They kept their original spelling deliberately, and renaming one silently breaks every dashboard and alert built on it.