HUAWEI CLOUD OBS → STACKIT OBJECT STORAGE · TUTORIAL
Huawei OBS to STACKIT Object Storage, worked through
An OBS bucket becomes a STACKIT Object Storage bucket with an S3 API: clients change endpoint and credentials, and lifecycle, replication and access settings are reviewed. This tutorial runs StackToIT on three buckets and an encryption key, shows what the run names and orders, and then goes through each OBS setting of the demo against what the STACKIT documentation lists, so you know where the real work is before the first byte is copied.
Three buckets and a key, as input
A small Huawei Cloud estate written for this page and assessed by StackToIT on 4 November 2026. Left: the media bucket with versioning, CORS, lifecycle rules and server-side encryption. Right: a public website bucket and a log bucket.
resource "huaweicloud_obs_bucket" "media" {
bucket = "acme-media"
storage_class = "STANDARD"
acl = "private"
versioning = true
encryption = true
sse_algorithm = "kms"
kms_key_id = huaweicloud_kms_key.obs.id
cors_rule {
allowed_origins = ["https://www.acme.example"]
allowed_methods = ["GET", "HEAD"]
allowed_headers = ["*"]
expose_headers = ["ETag"]
max_age_seconds = 3000
}
lifecycle_rule {
name = "archive-originals"
prefix = "originals/"
enabled = true
transition {
days = 60
storage_class = "WARM"
}
transition {
days = 180
storage_class = "COLD"
}
expiration {
days = 1095
}
}
lifecycle_rule {
name = "old-versions"
enabled = true
noncurrent_version_expiration {
days = 90
}
}
tags = {
team = "web"
}
}resource "huaweicloud_obs_bucket" "site" {
bucket = "acme-site"
acl = "public-read"
website {
index_document = "index.html"
error_document = "error.html"
}
}
resource "huaweicloud_obs_bucket" "logs" {
bucket = "acme-logs"
storage_class = "WARM"
acl = "log-delivery-write"
}What the run recorded
Excerpts of assessment.json with the values exactly as the run wrote them. The media bucket on the left, the encryption key it depends on on the right.
{
"id": "huaweicloud_obs_bucket.media",
"result": {
"class": "RECONFIGURE",
"confidence": "MEDIUM",
"target": {
"service": "STACKIT Object Storage",
"resources": [
"stackit_objectstorage_bucket",
"stackit_objectstorage_credentials_group",
"stackit_objectstorage_credential"
]
},
"reason": "An OBS bucket becomes a STACKIT Object Storage bucket with an S3 API. Clients change endpoint and credentials; lifecycle, replication and access settings need review."
}
}{
"id": "huaweicloud_kms_key.obs",
"result": {
"class": "RECONFIGURE",
"confidence": "MEDIUM",
"target": {
"service": "STACKIT KMS",
"resources": [
"stackit_kms_keyring",
"stackit_kms_key"
]
},
"reason": "A KMS key becomes a STACKIT KMS key. Key material of the source does not move, so data encrypted with it is re-encrypted."
}
}Same reason for every bucket
The website bucket and the log bucket receive the same class, target and reason as the media bucket. The run does not judge individual bucket settings; it names them.
Settings named, not judged
The media bucket carries 20 settings the run lists for your architects, among them acl, versioning, encryption, kms_key_id, cors_rule.allowed_origins, lifecycle_rule.transition.storage_class and tags. The website bucket carries 4, including website.index_document; the log bucket 3.
Three STACKIT objects per bucket
The target for a bucket is a bucket, a credentials group and a credential. The credentials are new: nothing about the OBS access keys carries over.
The key does not move
Key material of the source does not move, so data encrypted with it is re-encrypted on the target. The key is a unit of its own with STACKIT KMS as target.
The order and the open data decision
From technical-sequencing.md and data-movement.md of the same run. The media bucket waits for the key; the other two buckets do not depend on anything.
## Wave 1 — 3 unit(s)
| Unit | Class | Target |
|---|---|---|
| `huaweicloud_kms_key.obs` | RECONFIGURE / MEDIUM | STACKIT KMS |
| `huaweicloud_obs_bucket.logs` | RECONFIGURE / MEDIUM | STACKIT Object Storage |
| `huaweicloud_obs_bucket.site` | RECONFIGURE / MEDIUM | STACKIT Object Storage |
## Wave 2 — 1 unit(s)
| Unit | Class | Target |
|---|---|---|
| `huaweicloud_obs_bucket.media` | RECONFIGURE / MEDIUM | STACKIT Object Storage || Unit | Source service | Target service | Application | Mechanism | State | Data class | RPO | Downtime tolerance |
|---|---|---|---|---|---|---|---|---|
| huaweicloud_obs_bucket.logs | huaweicloud_obs_bucket | STACKIT Object Storage | | UNKNOWN | DECISION_REQUIRED | NOT_PROVIDED | NOT_PROVIDED | NOT_PROVIDED |
| huaweicloud_obs_bucket.media | huaweicloud_obs_bucket | STACKIT Object Storage | | UNKNOWN | DECISION_REQUIRED | NOT_PROVIDED | NOT_PROVIDED | NOT_PROVIDED |
| huaweicloud_obs_bucket.site | huaweicloud_obs_bucket | STACKIT Object Storage | | UNKNOWN | DECISION_REQUIRED | NOT_PROVIDED | NOT_PROVIDED | NOT_PROVIDED |Mechanism undecided, on purpose
The run lists the three buckets as stateful units and records the mechanism as UNKNOWN with the state DECISION REQUIRED. Size, change rate, tolerated downtime and recovery point are not in the Terraform, so they are marked not known.
The key is not a data unit
The encryption key is not listed as stateful. The data it protects is re-encrypted when the media bucket is copied, so plan that step with the media bucket.
Owners
The three buckets form one work package owned by the Storage Architect; the key is a package of its own whose owner the run leaves unstated.
How the estate maps
| Huawei Cloud resource | STACKIT target | Migration class |
|---|---|---|
| OBS bucket (media, website, logs) | STACKIT Object Storage: bucket, credentials group, credential | Reconfigure |
| KMS key | STACKIT KMS: key ring and key | Reconfigure |
Classes as the run decided them, all with confidence MEDIUM. The KMS key and two of the buckets move in wave 1, the media bucket in wave 2.
What each OBS setting needs on STACKIT
The run names these settings; this table reads them against the STACKIT pages listed under the sources. "Listed" means the page lists the operation, and an operation that is not listed is a question for STACKIT, not an answer.
| OBS setting in the demo | What the STACKIT documentation lists | What to decide |
|---|---|---|
| versioning = true | Versioning is listed (get and put). A single object can have at most 1,000 versions. | Enable versioning on the new bucket before the copy. Check whether your copy tool moves older versions or only current ones. |
| lifecycle_rule with expiration days and noncurrent_version_expiration | Lifecycle is listed. The reference describes expiration of current versions (days or date) and expiration of noncurrent versions. | Recreate these rules; they have a direct counterpart. |
| lifecycle_rule transitions to WARM and COLD | The lifecycle reference lists no transition action. | Decide whether the data stays in one class, or is expired or archived another way. This is the largest design change in the demo. |
| storage_class STANDARD, WARM, COLD (Huawei: Standard, Infrequent Access, Archive) | The pages read for this guide describe no storage classes. | Drop the setting and re-cost the data that lived in the cheaper classes. |
| cors_rule | CORS is listed (get, put, delete), and the documentation has a CORS how-to. | Recreate the rule with the origins that apply after the move. |
| acl = public-read and the website block | Bucket ACLs are listed as get only, and no website configuration operation is listed. Bucket policies are listed (get, put, delete), with a how-to. | Confirm with STACKIT how a public static site is served before relying on it; otherwise serve the site from another front end and keep the bucket private. |
| acl = log-delivery-write | No bucket logging operation is listed. | Choose another way to collect access logs, for example at the front end or in the application. |
| encryption = true with sse_algorithm = kms and kms_key_id | Encryption is listed (get, put, delete). The encryption how-to states that all stored data is encrypted at rest with AES256, and describes per-object server-side encryption with keys managed by the storage backend or with a key you provide (SSE-C); it does not mention STACKIT KMS. | Decide the encryption model first: the OBS key does not move, so the data is re-encrypted on the way in. |
| bucket names | 3 to 63 characters; letters, numbers and hyphens; unique across the whole system, not only your project; dots are discouraged. | Check each name is free. STACKIT recommends avoiding dots, so give dotted names, common for website buckets, a new name. |
Source side: the Terraform provider documentation for huaweicloud_obs_bucket (storage classes, ACL values, website, logging, lifecycle). Target side: the STACKIT pages in the source list.
Moving one bucket, in order
The run fixes the order between units; this is the order inside a bucket. Steps 1 to 4 are preparation, 5 and 6 move data, 7 closes the move.
Enable Object Storage in the target project
The credentials group and credential the run names are created here. As a general practice, use one credentials group per application so a key can be withdrawn without touching others.
Create the buckets
Use the names you checked. The project allows up to 1,000 buckets.
Recreate versioning, lifecycle, CORS, policy and encryption
Use the table above as the checklist. Do it before the first copy so the objects arrive under the final rules.
Agree the transfer window
Quota and rate are per project: the documented ceiling is 500 MB/s of up and download. As arithmetic, 10 TB at that rate takes at least about 5.6 hours; treat it as a lower bound.
Run the first copy while the source stays live
The STACKIT rclone tutorial copies with rclone copy between two S3 remotes and the STACKIT endpoint for eu01. rclone also has a Huawei OBS provider whose endpoints follow obs.<region>.myhuaweicloud.com. These are examples of widely used tooling; the engine does not run them.
Repeat the copy, then cut over
Run the copy again to pick up changes, stop writers, run it a last time and switch clients to the new endpoint and the new credentials. This sequence is general practice, not something the run plans for you.
Verify and retire
Compare object counts and sizes, keep the source read-only until the application owner accepts, then retire the source bucket and the OBS keys.
Decisions the architects own
Public website
Whether the site bucket stays an object-storage site or moves behind another front end.
Cheaper classes
What replaces WARM and COLD, and what that does to the cost of the media archive.
Encryption model
Rely on encryption at rest, add server-side encryption with backend-managed keys, or use SSE-C with a key you hold, for example in Secrets Manager. The how-to read for this page does not describe STACKIT KMS keys for buckets; ask STACKIT before planning on them.
Cutover method
Big-bang or by prefix; what clients can tolerate while the endpoint changes.
Questions storage teams ask
Does StackToIT copy the objects?
No. It reads Terraform, classifies the buckets and lists them as stateful units whose data mechanism you decide. Nothing in the run moves data or connects to a cloud account.
Do our applications need code changes?
Usually a configuration change: the target is an S3 API, so clients change endpoint, credentials and, where they use them, bucket names. Anything that relies on OBS-specific behaviour or on features the table above lists as open needs a closer look.
Why does the media bucket move after the website bucket?
It references the KMS key, so the run places it one wave later. The website and log buckets reference nothing, so they sit in wave 1 next to the key.
Is a lifecycle transition to an archive class available on STACKIT?
The lifecycle reference describes expiration of current and noncurrent versions and lists no transition action. Check the current page and ask STACKIT if archiving by lifecycle is a requirement.
Sources
Your next move: STACKIT.
Tell us about your estate. We show you what StackToIT delivers for it: target architecture, Terraform artifacts and a structured migration plan.