- 1 Specifically, Microsoft Azure Blob Storage is robust for unstructured data that includes documents, images and videos so that data can be easily managed.
- 2 This guide attempts to describe the process of creating an Azure container and uploading files and show how it can be done through Azure Storage Explorer as well as Azure Blob Storage REST API in order to provide all necessary details of the process.
- 3 There is also a tool called Azure Storage Explorer used for working with Storage in the graphical user environment, and there is also the REST API, which enables working with Storage programmatically, which expands the possibilities of working with secure, flexible, and efficient data in the cloud.
Introduction to upload Files to Azure
Microsoft Azure offers a powerful cloud storage solution that allows you to store and manage your data in the cloud. One of the key features of Azure Storage is Azure Blob Storage, which is designed for storing massive amounts of unstructured data, such as documents, images, videos, and more. In this guide, we will walk you through the process of uploading files to Azure Containers, a fundamental concept in Azure Blob Storage.
In this blog, we will guide you through each step, starting with the creation of an Azure container and concluding with the process of uploading files to it.
A container is empty until you put blobs in it. The storage account is the parent. If the account name or the container name is wrong, the upload fails even when the SAS looks fine. Same idea as a bucket and a prefix, only Azure calls them account and container.
Unstructured files (scans, exports, video) do not belong in a SQL row. Blob Storage is the usual place. You will still have a database. It holds the blob name and the container, not the file bytes.
Prerequisites
Before you get started with uploading files to Azure Containers, you’ll need a few things:
Azure Account: You need an active Azure account. If you don’t have one, you can sign up for a free trial.
For new work pick a general-purpose v2 account. The account name is global, lowercase, no spaces. If Create fails, the name is taken. Put the account in a region close to the app that will read the files. Moving blobs later works, but you pay for the copy and the time.
Azure Storage Account: Create an Azure Storage account if you don’t already have one. This account will serve as the root for your storage resources.
Azure Storage Explorer (Optional): Although not required, Azure Storage Explorer is a handy tool for managing your Azure Storage resources. You can download it from the Azure portal.
Keep the portal open. You will jump between Containers, Access keys, and Shared access signature more than once on the first day.
Step 1: Create an Azure Container
Container names have to be lowercase letters, numbers, and hyphens only , no spaces and no uppercase. If Create fails, that is usually the reason. Access level is not a later setting you can ignore: private means every download needs a key or a SAS, blob-public means anyone with the exact URL can fetch that one file, and container-public also lets people list what is in the folder. Pick private unless the files are meant to sit on a public site or a CDN.
An Azure Container is a logical grouping of objects in Azure Blob Storage. You can think of it as a folder where you will store your files. To create a container:
There are no real nested folders. A name like reports/2024/q1.pdf is still one blob. The slashes are part of the name. Explorer shows them like folders. The API sees one string.
- Log in to the Azure portal.
- Navigate to your Azure Storage account.
- In the left-hand menu, under the “Data storage” section, select “Containers.”
- Click the “+ Container” button.
- Provide a unique name for your container, choose the access level (either private, public, or container), and click “Create.”
Names are lowercase letters, numbers, and hyphens only. PatientFiles fails. patient-files works. Private should be the default. Blob-public lets anyone with the exact URL fetch that one file. Container-public also lets them list the folder. Use public only for files you would put on a CDN anyway.
If the new container does not show up, refresh, then check you are still in the same storage account. Sandbox and prod accounts with similar names catch people all the time.
Step 2: Uploading Files to Azure Containers
There are several ways to upload files to Azure Containers. Here, we’ll cover two common methods: using Azure Storage Explorer and using Azure Blob Storage’s REST API.
The portal can upload one file at a time. Fine for a test. Slow for a batch. AzCopy and the SDKs are later in this article if these two methods start to feel small.
Method 1: Using Azure Storage Explorer
- Open Azure Storage Explorer.
- Connect to your Azure account by clicking on the “Connect to Azure” button and signing in.
- In the left panel, expand your Storage Account, then Containers.
- Right-click on the container you created earlier and select “Upload.”
- Browse to the files you want to upload, select them, and click “Open” to start the upload process.
- Wait for the files to upload. You can monitor the progress in the bottom panel.
If it sits on queued, the sign-in is stale or you cannot write to that container. Sign out, sign in, try one file again. When the panel says complete, refresh. The blob name you see (including the extension) is the name you put on the REST URL. Azure does not lowercase scan.PDF for you.
Explorer is for a person moving a few files. It is the wrong tool when a browser has to upload into your product. That path needs a short SAS and your API.
Method 2: Using Azure Blob Storage’s REST API
If you prefer a programmatic approach, you can use Azure Blob Storage’s REST API.
- To make Rest API calls, We would need a valid Access Token.
- To generate an access token, navigate to the “Shared Access Signature” option in the left sidebar navigation of your storage account. Choose the desired start and expiry date time, check “Container” for Allowed resource types and then click the “Generate SAS Token and connection string” button.
- Copy the entire URL of “Blob service SAS URL”.
- The copied URL should resemble this format: https://{storage_Account_name}.blob.core.windows.net/{container_name}. To include the file name for your specific file, simply append it after the container name, resulting in a URL like this: https://{storage_Account_name}.blob.core.windows.net/{container_name}/{file.jpeg}.
- Now, Add the following header to your API request:
X-ms-blob-type: BlockBlob
- Upload the file in binary format.
- Send the API request as PUT method, expect a 201 Created status in the API response.
Set the start time a few minutes in the past so clock skew does not kill the first call. Expiry should match the job. An hour for a browser test. A day for a night job. Do not mint a year-long SAS and put it in an app.
Copy the whole Blob service SAS URL, query string included. If you trim sig, you get 403. PUT the raw file bytes, not a JSON wrapper. PUT again to the same name overwrites. There is no recycle bin unless soft delete is on.
403 is usually expiry, no write permission, or a URL that stops at the container and never adds the blob name. 400 on blob type means the x-ms-blob-type header is missing.
Delete files from container using Rest API
For deleting a file from Azure containers, you will utilize the same “Blob service SAS URL” previously generated. Follow the straightforward steps outlined below:
- Within the URL, you’ll need to append the file name you wish to delete, just as you did when uploading the file.
- Now, submit an API request with the DELETE method, and upon successful execution, receive a 202 Accepted response.
If Explorer still shows the blob, refresh. Soft delete keeps it for the retention days you set. Check Data protection on the account before you rewrite the client. DELETE 403 means that SAS was created without delete. Generate one that includes delete. An upload-only token will not do it.
What kind of blob you are creating
Block blobs are what the REST steps above use. Documents, images, most backups. One PUT is fine under about 100 MB. Bigger files should go up as blocks, then you commit the list. The SDKs do that split. Raw REST means you do.
Append blobs are for logs. You only add to the end. Page blobs are for VHDs and a few disks. For a website or API upload, stay on block blobs. Send BlockBlob. Do not switch the header unless you know you need a page blob.
Hot, cool, and archive
A new blob usually lands in hot. That is right while people still download it. Cool is cheaper to store and more expensive to read. Archive is cheap to leave alone and slow to bring back. Do not archive a file the app fetches on every page load.
You can change a blob’s tier later. Lifecycle rules can move anything older than N days, or delete it. Try the rule on a test container first. A delete-after-30-days rule will actually delete.
Content-Type, CORS, and the 403s that are not the SAS
If you skip Content-Type, many clients store application/octet-stream. Browsers then download a PDF instead of opening it. Send Content-Type on the PUT when you know the type. Explorer can edit properties after.
If a browser PUTs straight to the blob URL, set CORS on the storage account. Wrong origin or missing PUT and the browser fails while curl on your machine works.
If Firewalls and virtual networks is set to selected networks, a SAS from your laptop can 403 at home. Check that before you rewrite token code.
HTTPS only. A SAS on http is how the token leaks.
AzCopy, CLI, and SDKs
AzCopy resumes and can copy a folder. That is the usual tool for a real migration. The Azure CLI can upload one file after az login, no SAS on the command line. Official SDKs (Java, .NET, Python, JS, Go) wrap the same REST. In a product, use the SDK once you understand the container and the SAS. Otherwise the SDK errors look random.
Private files (including healthcare)
Keep those containers private. Short SAS. No long-lived token in the client. The conclusion below is about healthcare software for a reason. This is the upload path, not a full compliance list. If the file has a person in it, start private and stay private.
Conclusion:
Uploading files to Azure Containers is a fundamental step in managing your data in Azure Blob Storage, particularly for healthcare custom software development. Whether you opt for a graphical tool like Azure Storage Explorer or harness Azure Blob Storage’s REST API for programmatic control, Azure offers you the flexibility to efficiently and securely handle healthcare data in the cloud.
