Storage accounts
The Azure storage account is the basic block of the storage service. It manages access to the storage resources and provides a unique namespace for them; it also defines how your data will be replicated and made redundant. In order to create a storage account you need a valid Azure. There are various ways to create storage accounts; the easiest way is from the Azure portal (Azure provides a management portal that we will discuss in later chapters). Following very simple steps, you will be asked to provide a URL, choose a desired location for your data, and a replication option. Another option to create a storage account is to do it programmatically by using one of the client libraries.
Tip
For a step-by-step tutorial on creating storage accounts from the portal, see https://azure.microsoft.com/en-us/documentation/articles/storage-create-storage-account/#create-a-storage-account.
In the following sections we shall discuss the basic and essential features of storage accounts. The following figure illustrates Microsoft Azure Storage concepts:
The namespaces and endpoints
As mentioned earlier, each storage account has a unique global namespace, which allows clients to address the service resources. The storage account is a part of this namespace that represents a URI that can be called via simple HTTP and HTTPS requests.
Thus, all data is accessible via the following endpoints:
- Blob service:
http(s)://<account-name>.blob.core.windows.net - Table service:
http(s)://<account-name>.table.core.windows.net - Queue service:
http(s)://<account-name>.queue.core.windows.net - File service:
http(s)://<account-name>.file.core.windows.net
The account name <account-name> is selected by the user creating it and should be unique among all other storage accounts. This name will be used by the platform to locate where the data is stored in order to route incoming requests.
Storage account security
By default, and for the security of your data, all requests to the storage service must be authenticated. To do this, the platform generates two access keys for each account that should be supplied for authentication. The owner of the subscription can regenerate any key at any time. By having two access keys, the user can use the second key to authenticate while generating a new one, so that no downtime or interruption will occur to the service.
It is recommended you do not share the access keys with other users; they should be kept safe. In order to allow other users to access your data, you can create Shared Access Signatures (SAS). These signatures can be generated for a specific set of resources with a specific access permission for a definite amount of time.
Tip
To gain full understanding of how shared access signatures work, have a look at the following link:
You can also give public read access to blob storage in containers. When a container is set to public, anyone can read the data without authenticating the request. This is perfect for public media files such as images, documents, or videos on websites. (Users will still need valid storage access keys to write or delete data, however.)
Tip
Downloading the example code
You can download the example code fies from your account at http://www.packtpub.com for all the Packt Publishing books you have purchased. If you purchased this book elsewhere, you can visit http://www.packtpub.com/support and register to have the fies e-mailed directly to you.
