Modern application workloads, logs, media libraries, machine learning training data, backups, static web assets, and analytical data lakes converge on a single requirement: durable, scalable, and economical object storage. As volumes grow from gigabytes to petabytes, the question shifts from where to put files to how to maintain consistent access latency, predictable cost, and verifiable durability across workloads with very different access patterns.
Alibaba Cloud Object Storage Service (OSS) addresses this with twelve-nines designed durability, five storage classes with lifecycle automation, and native integration with downstream compute, analytics, and content delivery services. The sections below cover the configuration decisions that determine how an OSS deployment behaves under production load.

Figure 1: Architecture Overview of Alibaba Cloud Object Storage Services (OSS)
A bucket is the unit at which region, access control, versioning, and replication are scoped, and the region is fixed at creation. Each region exposes three endpoints: the public endpoint (oss-.aliyuncs.com) for internet access, the internal endpoint (oss--internal.aliyuncs.com) reachable only from same-region Alibaba Cloud services with no traffic charge, and the transfer acceleration endpoint (oss-accelerate.aliyuncs.com) for cross-region client access. HTTPS on port 443 should be enforced through bucket policy for any non-public content. Separating workloads' logs, user media, datasets, and backups into distinct buckets isolates access policy and lifecycle scope; bucket count is not a billed dimension.
OSS exposes five storage classes differentiated by per-gigabyte cost, retrieval cost, minimum billable duration, and first-byte latency. Standard has no minimum and millisecond access; Infrequent Access carries a 30-day minimum and a retrieval fee; Archive requires a restore operation with roughly one-minute latency and a 60-day minimum; Cold Archive and Deep Cold Archive extend this to 180-day minimums with restore latencies in hours. Lifecycle rules automate transitions by object age, and tag a common log-archive pattern moves objects to IA at 30 days, Archive at 90, and Cold Archive or deletion at 365. Rules evaluate asynchronously and may execute up to 24 hours after the threshold. For objects under 64 KB, per-object metadata overhead can exceed the storage saving from tiering, so small objects should be aggregated before transition.
Request throughput is bounded by internal keyspace partitioning rather than by a per-bucket quota. Keys sharing a leading prefix map to the same partition, so sequential keys timestamps or monotonic IDs as the prefix concentrate traffic and bottleneck request rate. A hash prefix, reversed timestamp, or UUID prefix distributes load across partitions. For large objects, single-request PUT is capped at 5 GB; multipart upload handles objects up to 48.8 TB across up to 10,000 parts of 5 MB to 5 GB each, with parallel throughput and per-part retry. Incomplete multipart uploads remain billable but invisible in the standard object listing, so a lifecycle rule to abort incomplete uploads after 7 days should be a default on any bucket receiving large objects.
Access control comprises four mechanisms: bucket ACLs, bucket policies, RAM user and role policies, and Security Token Service (STS) temporary credentials. The recommended production posture is bucket ACL set to private, account-level Block Public Access enabled, and access granted exclusively through RAM policies attached to specific identities. For end-user upload and download flows, STS issues short-lived credentials typically 15-minute to 1-hour expiry, scoped to specific bucket-and-prefix combinations and specific OSS actions. Encryption is configured at the bucket level: SSE-OSS uses AES-256 with service-managed keys; SSE-KMS integrates with Key Management Service for customer-managed rotation, key access logging, and revocation by key disable; client-side encryption is supported where plaintext is prohibited in the cloud control plane.
OSS is designed for 99.9999999999% annual durability through synchronous replication across multiple devices within the region, protecting against device failure but not operator error. Versioning addresses the second risk: every PUT and DELETE creates a new version, with a DELETE placing a marker on the version stack while prior versions remain recoverable until purged. Versioning cannot be disabled once enabled, only suspended. Cross-Region Replication (CRR) replicates new writes asynchronously to a bucket in another region for geographic disaster recovery, typically within minutes for megabyte-range objects; historical data requires a separate backfill. Audit and observability are provided by server access logging (request-level records), ActionTrail (control-plane API audit), and Cloud Monitor (per-bucket request, error, and storage metrics). For regulated workloads, Bucket Retention Policy enforces Write Once Read Many semantics in compliance mode; retention cannot be shortened or removed by any identity, including the root account.
A production OSS architecture is the composition of independent decisions, bucket placement, storage class economics, key design, access control, encryption, replication, and audit into a system whose behaviour is predictable under load and recoverable under failure. Each is configurable independently, allowing evolution without disruptive migration. Engineers extending the architecture should evaluate OSS Select and Data Lake Analytics for in-place SQL queries against CSV, JSON, and Parquet objects; Function Compute triggered by OSS event notifications for event-driven processing such as thumbnail generation or format conversion; and OSS-HDFS for Hadoop-compatible filesystem semantics on EMR, Spark, or Presto clusters.
Disclaimer: The views expressed herein are for reference only and don’t necessarily represent the official views of Alibaba Cloud.
Designing Production API Infrastructure with Alibaba Cloud API Gateway
96 posts | 2 followers
FollowDella Wardhani - March 29, 2026
淘系技术 - April 14, 2020
JDP - April 1, 2021
Wenson - August 4, 2020
Alibaba Clouder - August 14, 2018
Alibaba Clouder - October 1, 2019
96 posts | 2 followers
Follow
Application High Availability Service
Application High Available Service is a SaaS-based service that helps you improve the availability of your applications.
Learn More
Security Center
A unified security management system that identifies, analyzes, and notifies you of security threats in real time
Learn More
Elastic High Performance Computing
A HPCaaS cloud platform providing an all-in-one high-performance public computing service
Learn MoreMore Posts by PM - C2C_Yuan