Capabilities, boundaries, and next steps

X2 combines several services in X2 Node. These summaries distinguish the storage API, identity, analytical services, AI access, and operational controls without claiming complete compatibility with unrelated products.

01

S3-compatible application access

X2 accepts AWS Signature Version 4 requests through its public HTTPS endpoint. Configure the endpoint, signing region, access key, secret key, and certificate trust explicitly. Use path-style addressing for IP endpoints or when wildcard bucket DNS and certificates are not configured.

Compatibility is operation-specific; “S3-compatible” does not mean every AWS service integration or optional S3 behavior is present. Start with the S3 client and SDK guide and validate the exact operations your application uses.

02

Versioning, Object Lock, lifecycle, replication, and healing

Bucket workflows expose versioning, Object Lock, lifecycle rules, replication, and storage healing. Object Lock decisions should be made before writing protected data, and lifecycle policies should be validated against retention requirements. Replication is a configured data-copy workflow; healing repairs the placement expected by the active cluster layout. Neither replaces an independently tested backup and recovery plan.

Use the Console for bucket policy and protection configuration, then monitor work through health and logs.

03

IAM, roles, policies, and STS

X2 includes account identities, access keys, policies, roles, and temporary STS credentials. Applications authenticate to S3 with access keys or temporary credentials; Console passwords are not S3 secrets. Keep authorization least-privilege and verify both the identity policy and the bucket or resource policy used by the target operation.

Create application credentials in the Console and keep secrets out of URLs, browser storage, command arguments, and logs.

04

Iceberg REST Catalog and Delta Sharing

The Iceberg REST Catalog manages table metadata and warehouse-backed object paths. Delta Sharing publishes governed shares through a separate protocol and authorization surface. They are complementary services, not two names for the same catalog, and enabling one does not automatically expose the other.

Plan warehouse prefixes and share authorization separately, and validate the endpoints enabled for the selected release before onboarding clients.

05

Vector features and MCP

Vector indexes provide vector-oriented storage and query workflows. MCP exposes governed tools to model clients through its own authentication and permission checks. MCP access does not bypass IAM: the effective permission is constrained by the authenticated identity and the allowed MCP tool surface.

Keep vector data design, model-client access, and S3 object authorization as separate decisions.

06

S3 Express directory buckets

S3 Express is a storage capability for directory-bucket operations and belongs with the S3 API, not the vector or MCP feature set. Directory buckets have distinct operation and naming rules; the Console identifies unsupported combinations such as bucket versioning on a directory bucket.

Test the exact directory-bucket operation set required by the client instead of assuming general-purpose bucket semantics.

07

Monitoring, maintenance, and recovery

Readiness, node health, logs, metrics, audit activity, scanner and healing state, and rolling-update controls form the operational surface. A healthy public endpoint is only the first check: inspect all required nodes and storage paths before declaring the cluster healthy.

Continue with the production runbooks, cluster expansion, and load-balancer trust boundaries.