An Encrypted EVS Disk Backed Up by a Vault Whose Policy Is Applied
A backup on Huawei Cloud is a vault, a policy and a resource list that exist separately, so the common state is a policy with no vault or a vault with no disks; and a disk is encrypted only when a KMS key is given. The vault created with the policy applied and the disk as its resource (none by name), a key expected (none by name), attached to the instance you give.
Verification
Static-verifiedPassed: validated and lint-clean (provider-schema-validated for AWS/Azure/GCP; Terraform-language lint elsewhere).
Conformance
- Static validation (fmt · validate · tflint)
- No applicable security policies for this provider
- Plan tests (mocked: validation rules · outputs)
Provenance
- SHA-256 checksum
- Signature (pending)
Functional
- Live test pending (no cloud run yet)
Last verified 2026-09-14 · how we verify
Use it from the registry
terraform · opentofumodule "evs_disk" {
source = "www.iac-bazaar.com/iac-bazaar/huawei-evs-disk/huaweicloud"
version = "1.0.0"
}Needs a registry token from /account/tokens. The module itself is free; the account is what identifies you. Full setup: registry docs.
Inputs & outputs
Create a free account to read this module's contract
The declared contract - every input name, type, default and description, plus every output - is shown to signed-in accounts, not to anonymous visitors.
A free account sees the contract of every module in the catalogue. There is no subscription and nothing to buy - the modules are free to download, and they run under Vizier.
Documentation
huawei-evs-disk
An EVS data disk that is encrypted, attached, and backed up by a CBR vault
whose policy is applied. Works with Terraform and OpenTofu (>= 1.6),
huaweicloud provider >= 1.60, < 2.0.
A backup policy alone backs up nothing. Vault, policy and resource
are created together here; none needs accept_no_backup_schedule.
Encryption needs a key. kms_key_id expected; none needs
accept_unencrypted_disk.
Verification
Static validation runs tofu fmt, init, validate, tflint and checkov.
This module has not yet had a live test, so it is published as statically
validated with its live test pending and does not carry the live-tested mark.
Usage code & full reference need an account
The complete copy-paste usage, the full input/output reference, and operational notes are free with an account - shown here and bundled in the download. Sign in and this section fills in.
- Usage
Related modules
huawei-obs-bucket
Public access is two switches: a private ACL still leaves a bucket policy free to grant anonymous reads, and only Block Public Access refuses both; versioning and encryption are both off by default; abandoned uploads bill until a rule aborts them. Private ACL plus BPA with public by name, versioning on, encrypted with the region's key or yours, incomplete uploads freed after a week.
ibm-block-volume
VPC backup policies match volumes by user tag, so a volume created without the tag sits silently outside the policy; encryption is provider-managed unless a root key CRN is given; and an attachment can delete the volume with the instance. The policy created with its plan and the volume tagged with the tag it matches (none by name), your key when given, the volume kept on instance deletion.
oci-block-volume
Every tenancy ships Bronze, Silver and Gold policies and a volume follows one only through a separate assignment - the page reads Backup policy: none for the many never assigned. Assigns a policy to the volume it creates and refuses one without. Custom schedules add destination_region and retention lock, which Oracle policies lack: same-region backups are a copy of the failure.
do-volume
Droplet backups copy the boot disk and nothing attached to it, so a database whose data lives on a volume is an empty server to the backup; there is no snapshot schedule for volumes either. A formatted, attached, regional volume with two outputs that say exactly that, so whatever consumes the module cannot assume a copy exists.
scaleway-block-volume
iops is required, is the price per GB, and cannot change after creation; snapshots exist as a resource you take and nothing on the platform schedules one; the volume is zonal and attaches from the server side. The tier validated to the two that exist, a baseline snapshot when asked, and an output that says no schedule exists.
hetzner-volume
delete_protection defaults to off, a deleted volume is gone at once with no soft delete and nothing to restore from, and server snapshots do not include volumes. Protection on and off only by name, a filesystem so automount works, exactly one of server or location, and an output that says volume snapshots do not exist.