github
Codespaces: Policies for Cost Control
Summary
Organizations can manage Codespaces costs with spending limits today, but this is a cap once usage has already occurred. In order to reduce costs throughout, many organizations want to limit the types of usage that is allowed. These include (1) machine type policies to only allow for certain core and RAM configuration, (2) retention policies to reduce how long unused codespaces are preserved, and (3) timeout policies to manage how long until codespaces are automatically suspended without activity.
Intended Outcome
As organizations start scaling with Codespaces, enable enterprise and organization admins will be able to customize Codespaces for their organizations to prevent unnecessary spend.
How will it work?
Policy on machine types
If a given organization is mainly focusing on PR reviews, light editing, web client, or small applications, the 2 core or 4 core machine types can often be enough. Organizations requiring more robust support will want to set different defaults for different projects/repos. We plan to support policies at enterprise and org level.
Policy on Codespaces retention
Many codespaces are used for a specific task and once that task is complete, users don't always delete their codespaces. In order to help reduce storage costs that can come from buildup of unused Codespaces, an archive and data retention policy will be introduced.
Archive Policy
Policy on when to archive a codespace with the max period of unuse being 30 days.
Data Retention
Policy on the time period for which archived codespaces are retained before being permanently deleted.
Policy on default timeout
While the 30 minute default suspend timeout makes sense in many cases, some cost conscious companies may want to lower this while others may want to increase it to minimize developer startup impact so developers would only experience a wait once or twice a day. This feature will enable enterprise and org admins set a default timeout policy for org owned codespaces.
