Managing AIOZ Storage Buckets with Terraform, Step by Step

Managing AIOZ Storage buckets with Terraform works because the Terraform AWS provider was built to be pointed at any S3-compatible endpoint, not just AWS's own. HashiCorp's own provider documentation lays out the exact pattern for this: a provider "aws" block with a custom endpoints setting and a handful of validation-skipping flags, the same general approach services like CoreWeave document for their own S3-compatible object storage. This article covers the exact provider configuration AIOZ Storage needs, what each setting actually does, and what to check before you trust it in a real Terraform workflow.

TL;DR:

• The Terraform AWS provider supports custom S3-compatible endpoints natively through an endpoints { s3 = "..." } block, per HashiCorp's own provider documentation.
• s3_use_path_style = true is required for AIOZ Storage, the same path-style requirement every SDK and CLI in this series needs, plus skip_credentials_validation, skip_metadata_api_check, and skip_requesting_account_id to stop Terraform from trying to validate against real AWS infrastructure.
• Once the provider is configured, aws_s3_bucket and related resources work against AIOZ Storage the same way they'd work against real AWS S3, since Terraform never distinguishes the target beyond the endpoint you gave it.

Why the AWS Provider Works Against AIOZ Storage at All

Terraform's AWS provider doesn't hardcode AWS's own endpoints into every resource, it reads them from your provider configuration, which is exactly the flexibility that makes pointing it at a different S3-compatible service possible. HashiCorp's own custom-service-endpoints guide documents this directly, showing a provider block that swaps out the S3 endpoint for a different service entirely, in HashiCorp's own example, a local test server. The same mechanism applies to any real, external S3-compatible endpoint, AIOZ Storage's included.

The Provider Configuration AIOZ Storage Needs

Here's the provider block, adapted from HashiCorp's own documented pattern to AIOZ Storage's specific requirements:

provider "aws" {
  access_key                  = "<your-aioz-storage-access-key>"
  secret_key                  = "<your-aioz-storage-secret-key>"
  region                      = "us-east-1"
  s3_use_path_style           = true
  skip_credentials_validation = true
  skip_metadata_api_check     = true
  skip_requesting_account_id  = true

  endpoints {
    s3 = "https://s3.aiozstorage.network"
  }
}

Each setting is doing real work, not boilerplate. region is a placeholder, us-east-1 here, required because the provider expects a region value even though AIOZ Storage isn't actually region-partitioned. s3_use_path_style = true is the same requirement every SDK and CLI in this series needs, without it, requests resolve to virtual-hosted-style URLs that don't work against AIOZ Storage's single endpoint. The three skip_* flags exist because, left unset, the provider tries to validate your credentials and account against real AWS infrastructure, which will fail immediately against a non-AWS access key, skip_credentials_validation, skip_metadata_api_check, and skip_requesting_account_id each turn off one specific AWS-only validation step.

Managing a Bucket Once the Provider Is Configured

With that provider block in place, standard Terraform AWS resources work against AIOZ Storage the same way they would against real S3, since Terraform's resource logic never distinguishes the target beyond the endpoint the provider gave it:

resource "aws_s3_bucket" "example" {
  bucket = "my-aioz-storage-bucket"
}

Applying that creates a bucket on AIOZ Storage through the same aws_s3_bucket resource type used for real AWS buckets everywhere else in a Terraform codebase, no separate provider or resource type required. That's the practical payoff of the custom-endpoint pattern: teams already managing AWS infrastructure with Terraform can bring AIOZ Storage into the same codebase, the same state file, and the same terraform plan/apply workflow, rather than reaching for a separate tool just for one storage provider.

What to Verify Before You Trust This in Production

Two things are worth checking directly rather than assuming from this pattern alone. First, AIOZ Storage's own documented account limits, 100 buckets and a 100 request-per-second rate limit per account, apply regardless of whether you're creating buckets through the console, the CLI, or Terraform, a terraform apply that tries to create dozens of buckets in one run could hit that rate limit if it's not the only thing your account is doing at the time. Second, Terraform's state file tracks buckets it created, but a bucket created outside Terraform, through AIOZ's dashboard, say, won't be tracked unless you explicitly terraform import it, the usual Terraform discipline of treating the state file as the source of truth applies here exactly as it would managing real AWS resources.

Frequently Asked Questions

Can Terraform manage AIOZ Storage buckets directly?
Yes, through the standard Terraform AWS provider configured with a custom endpoint. AIOZ Storage doesn't need its own Terraform provider, since it's S3-compatible and the AWS provider supports pointing at any S3-compatible endpoint.

What Terraform provider settings does AIOZ Storage require?
s3_use_path_style = true, plus skip_credentials_validation, skip_metadata_api_check, and skip_requesting_account_id set to true, alongside an endpoints { s3 = "https://s3.aiozstorage.network" } block and a placeholder region like us-east-1.

Why does the provider need a region if AIOZ Storage isn't region-partitioned?
Because the Terraform AWS provider's configuration schema requires a region value regardless of target, it's a provider-level requirement, not something AIOZ Storage itself needs. Any placeholder value like us-east-1 satisfies it.

Why do the skip_* settings need to be true?
Without them, the Terraform AWS provider tries to validate your credentials and account against real AWS infrastructure, checks that will fail immediately against AIOZ Storage credentials, since they were never issued by AWS in the first place.

Do AIOZ Storage's account limits still apply when using Terraform?
Yes. The 100-bucket and 100-request-per-second limits apply regardless of how a request reaches AIOZ Storage's API, the console, CLI, an SDK, or Terraform's own provider, all count against the same account-level limits.

What happens if a bucket is created outside Terraform?
It won't appear in Terraform's state file unless explicitly imported with terraform import. Same discipline as managing real AWS resources: Terraform only tracks what it created or what you've told it to track.

Related Reading

• How to Use AIOZ Storage Effectively: A Practical Checklist - the path-style addressing requirement and account limits this Terraform config depends on.
• AIOZ Storage CLI Quickstart: AWS CLI with a Custom Endpoint - the same custom-endpoint pattern applied to the AWS CLI instead of Terraform.
• How AIOZ Storage Pricing Works - the account limits (buckets, rate limit) that apply regardless of how you manage AIOZ Storage.
• AIOZ Storage Explained: S3-Compatible Decentralized Storage - what AIOZ Storage is overall, including why it isn't region-partitioned.
• AIOZ Storage Developer Platform: SDKs, CLI, and Migrations - where Terraform fits alongside the SDKs, CLI, and migration guides on AIOZ Storage.

References

• HashiCorp: Terraform AWS Provider, Custom Service Endpoints Guide
• CoreWeave: Managing Object Storage with Terraform