AWS vs. Azure - Object Storage Network Access
When cloud object storage services were originally released, they focused on the functionality of storing objects. At the time (and is frankly still good advice) the thought was that identity is the new boundary, and that traditional network security rules make cloud things complicated. The tag-phrase says something like “Identity is the new boundary”.
Over time, cloud service providers have realized that customers want to be able to take PaaS services and reduce the attack surface by limiting network access to those resources. Providers such as AWS and Azure have answered the call by enhancing their feature sets. As always, it is interesting to see the different approaches taken. From an AWS standpoint, restricting network access occurs (generally) as a condition of the authentication requests. In Azure, the network restriction is surfaced as more of a “firewall” setting on the service itself, and not necessarily tied to user access.
| AWS | Azure | |
|---|---|---|
| Internet IP | IP Condition | IP Rules |
| Deployed Network | VPCE Condition | Virtual Network Rules |
| Service | Service Principles | Network Exceptions |
Let’s talk a bit about AWS first. Network restrictions on connections are enforced via policy (usually at the bucket level). Another way to say this is that these network conditions are surfaced as attributes of the authenticated request. IP addresses and deployed networks are enforced via the condition statement in a policy (aws:SourceIP and aws:sourceVPC). Services are defined in policies as a principal.
In Azure, network restriction setup is surfaced more as a list of firewall rules with special conditions. You can add up to 100 network or IP rules to a given account. Service endpoints are required to enable private access from a virtual network to a storage account. Once enabled, the virtual network will appear in a list of eligible virtual networks for access. On the service side, Azure uses the concept of “exceptions” which allow network access from a list of approved Azure services (which you can control).
From a network response perspective, the two services tend to return different codes for different situations.
For example, accessing blobs that don’t exist in Azure result in a different 404 code depending on the access granted.
Here is an example of a return code when the file doesn’t exist but the container is publicly accessible:
And here is an example of when a file doesn’t exist and the blob is NOT accessible to the public.
Notice the difference? From an AWS perspective, you just get a cold/hard 403 in both cases.
About Shamir Charania
Shamir Charania, a seasoned cloud expert, possesses in-depth expertise in Amazon Web Services (AWS) and Microsoft Azure, complemented by his six-year tenure as a Microsoft MVP in Azure. At Keep Secure, Shamir provides strategic cloud guidance, with senior architecture-level decision-making to having the technical chops to back it all up. With a strong emphasis on cybersecurity, he develops robust global cloud strategies prioritizing data protection and resilience. Leveraging complexity theory, Shamir delivers innovative and elegant solutions to address complex requirements while driving business growth, positioning himself as a driving force in cloud transformation for organizations in the digital age.