Back to Documentation

Resource Naming Logic

Understanding how CloudCanvas handles resource naming, locking, and organization format changes

📅 Last updated: December 8, 2025⏱️ 10 min read

Overview

This document explains how CloudCanvas handles resource naming, locking, and organization format changes in simple, non-technical terms. Understanding these concepts will help you work effectively with CloudCanvas and avoid common pitfalls when managing cloud resources.

Basic Concepts

What is a Resource Name?

A resource name is the actual name given to a cloud resource (like an S3 bucket, VM, or database) when it's deployed. For example: s3-myproject-dev-eastus-001

What is a Block Name?

A block name is CloudCanvas's internal identifier for a Terraform resource. It's like a stable ID that never changes, even if you delete and re-add a resource. For example: s3_bucket_001

Key Point: Block names are stable identifiers. Resource names can change based on organization format, but block names stay the same.

What is Organization Format?

The organization format is a template that defines how resource names should be structured. For example:

  • Format: {resource_prefix}-{project}-{env}-{location}-{sequence}
  • Results in: s3-myproject-dev-eastus-001

Name Generation Flow

1User Adds a Resource

When you drag and drop a resource onto the canvas:

  • System identifies the resource type (e.g., S3 Bucket, Virtual Machine)
  • System calculates a block name (e.g., s3_bucket_001)
  • Block name format: {resource_type}_{sequence}
  • Sequence is assigned based on how many of the same type exist
  • Example: First S3 bucket = s3_bucket_001, second = s3_bucket_002

2System Generates Resource Name

The system uses the organization format to generate the actual cloud resource name:

  • Reads organization format template
  • Fills in the template with actual values:
    • resource_prefix → s3 (short prefix for S3 bucket)
    • project → myproject (from architecture)
    • env → dev (from architecture)
    • location → eastus (from architecture)
    • sequence → 001 (from block name)
  • Result: s3-myproject-dev-eastus-001

3Name is Used in Terraform Code

The generated name appears in Terraform code:

  • Block name (s3_bucket_001) is used as the Terraform resource identifier
  • Resource name (s3-myproject-dev-eastus-001) is used as the actual cloud resource name

Block Names - The Stable Identifier

Why Block Names Matter

Block names are like permanent IDs that don't change, even when:

  • Organization format changes
  • Resources are deleted and re-added
  • Architecture is cloned or copied

Example

Architecture has:
- s3_bucket_001 → Resource name: "s3-proj-dev-001"
- s3_bucket_002 → Resource name: "s3-proj-dev-002"
- vm_instance_001 → Resource name: "vm-proj-dev-001"

If you delete s3_bucket_001 and add a new S3 bucket:
- New node might become s3_bucket_001 again (if it's the first S3 bucket)
- System can restore the old locked name "s3-proj-dev-001"

Organization Format Integration

How Organization Format is Applied

The organization format is a template with placeholders that get filled in:

Template Example:

{resource_prefix}-{project}-{env}-{location}-{zone}-{tier}-{purpose}-{sequence}

Placeholder Values:

  • {resource_prefix} → Short code for resource type (e.g., s3, vm, db)
  • {project} → Project name from architecture
  • {env} → Environment (dev, staging, prod)
  • {location} → Deployment region (eastus, us-east-1, etc.)
  • {zone} → User-defined zone (ez, iz, mz) - optional
  • {tier} → User-defined tier (web, app, db) - optional
  • {purpose} → User-defined purpose - optional
  • {sequence} → Three-digit number from block name

Example: Format Change

Before:

Format: {resource_prefix}-{project}-{env}-{location}-{sequence}

Result: s3-myproject-dev-eastus-001

After (Admin changes format):

Format: {resource_prefix}_{project}_{env}_{location}_{sequence}

Result: s3_myproject_dev_eastus_001

What happens:

  • Locked resources: Keep old name (s3-myproject-dev-eastus-001) ✅
  • New resources: Use new format (s3_myproject_dev_eastus_001) ✅

Name Locking Mechanism

When Names Get Locked

Resource names are automatically locked when architecture status changes to:

APPROVED

Architecture has been approved

REJECTED

Architecture was rejected (still locked to prevent changes)

DEPLOYED

Architecture is deployed to cloud

DESTROYED

Architecture was destroyed (locked for audit)

DECOMMISSIONED

Architecture is decommissioned

LOCKED

Manually locked by admin

What Happens After Locking

✅ Format Changes Don't Affect Locked Names

If organization format changes, locked resources keep their old names. This prevents Terraform from wanting to recreate resources.

✅ New Resources Use New Format

Resources added after locking use the current organization format. This allows gradual migration.

✅ Custom Names Can Override

Users can still set custom names. Custom names take precedence over locked names.

Key Principles

1. Stability First

  • • Block names never change (stable identifiers)
  • • Locked names prevent accidental resource recreation
  • • System prioritizes stability over format consistency

2. Flexibility When Needed

  • • Custom names can override locked names
  • • New resources use current format
  • • Users can always override if needed

3. Automatic Protection

  • • Names lock automatically when status changes
  • • No manual intervention required
  • • System handles edge cases (delete/re-add)

4. Clear Communication

  • • UI shows when names are locked
  • • Preview comments in code show locked names
  • • Users understand why names don't change

Summary

The system works like this:

  1. Block names = Permanent IDs that never change (s3_bucket_001)
  2. Resource names = Actual cloud names that follow organization format (s3-proj-dev-001)
  3. Locking = Automatic protection when architecture is deployed/approved
  4. Restoration = Automatic recovery of locked names when resources are re-added
  5. Custom names = User override that takes precedence over everything

🎯 The goal:

Prevent accidental resource recreation while allowing flexibility for new resources and user overrides.

Questions & Answers

Q: What if I want to change a locked name?

A: Use the "Use custom resource name" option in the properties panel. Custom names override locked names.

Q: What happens if I delete all resources and add them back?

A: The system will restore locked names if the block names match. However, if the sequence changes, new names will be generated.

Q: Can I unlock names?

A: Names unlock automatically if architecture status changes back to DRAFT or WIP. You can also use custom names to override.

Q: What if organization format has optional fields?

A: Empty optional fields are automatically removed. The system uses Terraform's compact() function to filter them out.

Q: How are block names assigned?

A: Block names are assigned based on resource type and sequence. Same resource types get sequential numbers (001, 002, 003...).

Related Documentation

→ Architecture Design Guide→ Project Creation Guide→ Terraform Push Guide