Resource Terminology


Clouds, users, teams and resources are all children of an organization. This top level entity allows us to scope and isolate access. In most installations there will be a single organization; however, in large deployments of DivvyCloud it is possible to have multiple. You typically see this within larger enterprises with multiple business units (BUs). It is sometimes desirable to have a separate organization per BU.

Organization Services

Organization services, also known as Clouds, are the most important piece of DivvyCloud. Without at least one of these active within the installation DivvyCloud’s capabilities are severely restricted. We support a variety of cloud technologies, both public and private, and new additions are coming in on a regular basis.

When working with organization services, you often need to filter selections to a particular cloud type. A mapping of clouds to the corresponding cloud_type_id is listed below for your reference.

Public Clouds

Cloud Provider
Cloud Type ID

Amazon Web Services


Digital Ocean


Google Compute Engine


Microsoft Azure






Private Clouds

Cloud Provider
Cloud Type ID






Regions are locations around the globe where compute resources reside. The name, format, and location of a region vary depending on the cloud provider. For a list of supported regions within our supported clouds, see the links below:

Availability Zones

An Availability Zone (AZ) is a child of a region. AZs are effectively separate datacenters loosely co-located within a particular region. As an example, the Amazon Web Services (AWS) region called us-east-1 has five AZs:

  • us-east-1a
  • us-east-1b
  • us-east-1c
  • us-east-1d
  • us-east-1e

Of note, us-east-1a is not a unique name for a specific datacenter. AWS rotates names among customers to distribute workloads so us-east-1a for one customer may be us-east-1b (or us-east-1c, etc.) for another.

Also, not all clouds support AZs, but for those that do there are some resource types in which operations cannot be executed unless the resources are in the same AZ. An example of this would be the relationship between an Instance and a Volume within AWS. Volumes can only be attached to instances within the same AZ.

Resource Groups

Resource groups are one of the most powerful features within DivvyCloud, and lots of advanced functionality is dependent on leveraging resource groups. Put simply, resource groups are a collection of resources. They can be used to apply granular permissions to a subset of your cloud footprint, to improve visibility and to help apply custom policy. Any resource type can be included within a resource group, including, but not limited to:

  • Instances
  • Volumes
  • Snapshots
  • Networks
  • Access Lists
  • Public IPs
  • Databaase Instances
  • Memcache Instances
  • Load Balancers
  • Hypervisors
  • Object Storage
  • DNS Zones
  • Images
  • Keypairs

You can even include other resource groups to set up nested groups. This can be allow for better organization of your resources for larger deployments.


User accounts allow access to DivvyCloud. When users execute write operations within the tool, their actions are recorded and can be accessed via Change History.

You can also set up different access levels and permissions for users so you can restrict what they can and cannot access. This can be very useful if you want to permit access to a subset of resources within your installation.

User Groups

User Groups are groups of user accounts which can be greatly reduce the overhead of managing permissions across clouds, resource groups and projects. You have complete control over the name and containing users within a User Group, and they can be changed on the fly with ease. Some examples of User Groups would be the following:

  • Power Users
  • Database Administrators
  • IT Department
  • Developers
  • Marketing

You can then apply permission policies to your resource groups, cloud accounts and projects using these User Groups. As an example, perhaps you want to give Power Users the “All” permission across all cloud accounts, but you only want the Marketing department to have “View” (read-only) permission to the resource group containing marketing compute resources. User Groups allows you to efficiently tackle this challenge.


A resource is a normalized, Divvy representation of a particular component of cloud computing. DivvyCloud supports over 50 resources today which range from instances to load balancers. You can do a variety of interesting things using resources. A few examples of how to interfact with resources are listed below.

Forming a resource

Resources are typically formed from resource ID objects. You can form a resource and get access to all of its functionality using the following code:

from DivvyResource.ResourceIds import ResourceId
from DivvyResource.Resources import Resource

resource_id = ResourceId.from_string('instance:10:us-east-1:i-6a8f369b:')
resource = Resource.from_resource_id(resource_id)
print dir(resource)
['CreateDatabaseAction', '_check_resource_group_auto_filters', '_db', '_db_obj', '_filter_supported_actions',
 '_insert_change_history', '_insert_default_history', '_insert_default_system_event', '_organization',
 '_organization_service', 'add_resource_to_user_group', 'bulk_load', 'clear_cached_db_object',
 'clone_db_object', 'contains_resource', 'create', 'db', 'deactivate_resource_backups', 'delete',
 'delete_db_object', 'delete_property', 'delete_setting', 'fill_cache', 'filter_collection_by_exact_match',
 'from_resource_id', 'get_attached_ips', 'get_attached_network_interfaces', 'get_attached_networks',
 'get_attached_private_ips', 'get_attached_public_ips', 'get_attached_volumes', 'get_availability_zone',
 'get_available_actions', 'get_backup_configurations', 'get_change_history', 'get_cloud_type',
 'get_containing_project', 'get_containing_project_resource_id', 'get_containing_resource_group_ids',
 'get_db_class', 'get_db_object', 'get_db_pk', 'get_db_pk_criteria', 'get_image', 'get_image_id',
 'get_image_name', 'get_instance_type', 'get_organization', 'get_organization_id',
 'get_organization_service', 'get_organization_service_added_time', 'get_organization_service_id',
 'get_organization_service_region', 'get_parent_resource_id', 'get_parent_resource_ops',
 'get_primary_network_interface_id', 'get_properties', 'get_property', 'get_resource_dependencies',
 'get_resource_name', 'get_resource_type', 'get_retained_backups', 'get_scheduled_events',
 'get_security_groups', 'get_service_type', 'get_setting', 'get_settings', 'get_supported_actions',
 'get_tag', 'handle_resource_child_added', 'handle_resource_child_removing', 'handle_resource_created',
 'handle_resource_destroyed', 'handle_resource_modified', 'instance', 'instance_id', 'is_action_supported',
 'list', 'list_with_permission_check', 'organization_service_id', 'region_name', 'resource_id',
 'set_property', 'set_setti

List instances within a cloud account

This example lists all instances within cloud account 10, which happens to be an AWS account:

from DivvyResource.Resources import Instance

instances = Instance.list(organization_service=10)
for instance in instances:
    print instance.instance_id,

i-a4c6b554 TestServer1
i-6a8f369b ElasticSearch
i-d67af975 LinuxTest
i-9d306358 MySQL-5.6
i-05dc8bd5 divvy-ami-test
i-8e9fbd5c Jenkins Tester
i-07e250d4 Build Server

Top Level Resources

As of this writing DivvyCloud supports over 50 different resource types, far too many to display in one unified view. We denote certain resources as “top level resources”, which simply means they are a resource we consider to be a first class citizen. These resource types are flagged as True when calling is_top_level_resource() against the resource ID. The code snippet below illustrates this concept:

from DivvyResource.ResourceIds import ResourceId
resource_id = ResourceId.from_string('instance:10:us-east-1:i-6a8f369b:')
print resource_id.is_top_level_resource()
>>> True

A list of our top level resources is included below for reference:

  • Instances
  • Volumes
  • Snapshots
  • Access Lists
  • Public IPs
  • Networks
  • Load Balancers
  • Database Instances
  • Cache Instances
  • Hypervisors
  • Object Storage
  • DNS Zones
  • Images

Resource ID

A resource ID is a Divvy specific, colon delimited primary key identifier, which denotes the type, organization service, region and cloud provider ID of a resource. As an example, let’s say that you had an instance within the us-east-1 region of Amazon Web Services (AWS) within organization service 10. The resource ID of this particular instance within the DivvyCloud system would look like this:


The format of the resource ID is as follows:


Forming a Resource ID

You can form a resource ID object from a string to gain access to a number of functions. Let’s go back to our earlier ID, instance:10:us-east-1:i-6a8f369b:. We can form an object using this string with the code below. The code also shows all of the functions available to you.

>>> from DivvyResource.ResourceIds import ResourceId
>>> resource_id = ResourceId.from_string('instance:10:us-east-1:i-6a8f369b:')
>>> print dir(resource_id)
['_get_id_fields', 'extra', 'from_string', 'from_string_or_none', 'from_type_location_id',
 'get_id', 'get_type', 'instance_id', 'is_billable_resource', 'is_top_level_resource',
 'organization_service_id', 'region', 'to_string']