A Private Db2 Deployment with a Standby and an Allow List That Is Not Empty
A Db2 deployment on a private endpoint with high availability on, disk encryption with a key you hold, and named ranges, because Db2 reads an absent allow list as any address rather than none. Autoscaling is off unless configured and its plan limit is the point: it is the difference between a slow hour and an unbounded invoice. Oracle compatibility is fixed at creation.
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-15 · how we verify
Use it from the registry
terraform · opentofumodule "db2" {
source = "www.iac-bazaar.com/iac-bazaar/ibm-db2/ibmcloud"
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
ibm-db2
A managed data warehouse on IBM Cloud Db2. Works with Terraform and OpenTofu
(>= 1.6), ibm provider >= 1.60, < 3.0.
The allow list is empty, which means any address - the opposite of how an empty allow list reads on most services.
high_availability is a string and "no" is the cheap answer: it decides whether there is a standby at all, not how good one is.
Autoscaling is off unless configured, and its limit is the point. allow_growth_past_plan is the difference between a slow hour and an unbounded invoice.
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
ibm-cloudant
A Cloudant instance on the standard plan with CORS off, and a wildcard origin together with allow_credentials refused outright because it would let any site make authenticated requests as the signed-in user. Legacy username-and-password auth is off, and data events are on, since without them the trail never records that anyone read a document.
ibm-databases-redis
An IBM Cloud Databases for Redis deployment on the private endpoint only (public by name), with deletion protection on, an allowlist of your ranges (empty by name), disk and backup encryption with Key Protect keys you hold (IBM's keys by name), and the two-member group that is the HA and cannot be reduced. Access is by service credential, a separate resource.
ibm-databases-elasticsearch
A Databases for Elasticsearch deployment on a private endpoint with deletion protection on, your Key Protect keys for both the data and the backups, and an allowlist that must name ranges because an empty one is read as any address. Three members, fixed rather than offered as a knob with one safe value. The plan, not the module, decides whether field-level security exists.
ibm-databases-postgresql
service_endpoints decides whether the deployment answers on the internet and public is the default; deletion_protection defaults to false; an empty allowlist means any address that can reach the endpoint; and disk and backup encryption use IBM's keys unless yours are given. Private with public by name, deletion protection on, ranges expected (empty by name), both key CRNs taken, two members.
tencent-clickhouse
A ClickHouse cluster with high availability on, since without it each shard has one replica and losing a data node is losing its data. A COS cold tier is set, because without one every partition stays on the most expensive storage the cluster has while the cluster reports healthy and the invoice is the only signal. Single-zone and PREPAID both have to be taken by name.
huawei-dws
A DWS cluster keeping its manual snapshots when it is deleted, since the default of zero deletes the backups along with the thing they were backing up and turns a mistaken delete into a permanent one. Disks are encrypted at creation because they cannot be later, audit logging to LTS is on, and there is no public endpoint unless you ask for one.