Azure Resources

Access to Resources

• Log in at portal.azure.com:

  • If you’ve been assigned a Unity ID (<____>@ncsu.edu), log in using that. If you’re a partner at another institution, check with Brian that you’ve been granted guess access through OIT to use your existing email.

• Always make sure to put new resource groups and resources in the CALS - PSA subscription, not the similar and easily missed CALS subscription.

• Resources should be stored within dedicated resource groups per project. There can be multiple services for a particular project within the RG, but there shouldn’t be resources that aren’t logically linked within the same RG.

  • Some resources spawn many sub-services when you create them, like VMs, which create a resource for the VM itself, a disk, and networking all named similarly. Be mindful of clutter when you’re documenting the lifecycle of a resource.

  • For example: A single database and an API to access it that’s running as a serverless function should be in an RG named <proj_name>-<db_type>-api.

• Document the creation or migration of an RG and resources in this page <link to be added> so that we can track ownership and when orphaned resources can be culled.

Naming Convention for Azure Resources

All resources should follow the following naming convention

<app-name>-<environment suffix>-<dbtype>

• Virtual machines

  • Type abbreviation: vm

  • Example: tech-dashboard-production-vm

• Databases

  • type abbreviations: Postgres → pgsql, MySQL → mysql

  • Example: crown-production-pgsql

• Azure functions

  • type abbreviation: func

  • Example: corrections-api-develop-func

• App service plans

  • type abbreviation: plan

  • Example: ssurgo-api-stage-plan

• Storage accounts

  • type abbreviation: st

  • Example: weeds-image-repo-production-st

• Container registry

  • type abbreviation: cr

  • Example: db-copies-production-cr

Useful Links

1. https://docs.microsoft.com/en-us/azure/cloud-adoption-framework/ready/azure-best-practices/resource-abbreviations