azure-storage-account-application-assets

An Azure storage account contains all of your Azure Storage data objects, including blobs, file shares, queues, tables, and disks. The storage account provides a unique namespace for your Azure Storage data that’s accessible from anywhere in the world over HTTP or HTTPS. Data in your storage account is durable and highly available, secure, and massively scalable.

Use Cases

Users or client applications can access objects in Blob Storage via HTTP/HTTPS, from anywhere in the world. Objects in Blob Storage are accessible via the Azure Storage REST API, Azure PowerShell, Azure CLI, or an Azure Storage client library. Client libraries are available for different languages, including:

• .NET
• Java
• Node.js
• Python
• Go
• PHP
• Ruby

Cloud applications

Web, mobile, gaming, and IoT application that handle massive amounts of data, reads, and writes at a global scale with near-real response times for various data will benefit from Azure Cosmos DB. Azure Cosmos DB’s guaranteed high availability, high throughput, low latency, and tunable consistency are huge advantages when building these types of applications.

99.999% SLA

Guarantee business continuity, 99.999% availability, and enterprise-level security for every application.

Multiple languages with SDKs

Build apps on API for NoSQL using the languages of your choice with SDKs for .NET, Java, Node.js and Python. Or your choice of drivers for any of the other database APIs.

Configuration Presets

Development

The development preset enables data protection for 7 days.

Production

The production preset enables data protection for 365 days.

Design

Our bundle includes the following design choices to help simplify your deployment:

Redundancy

Azure Storage always stores multiple copies of your data so that it’s protected from planned and unplanned events, including transient hardware failures, network or power outages, and massive natural disasters. Redundancy ensures that your storage account meets its availability and durability targets even in the face of failures.

• Locally redundant storage (LRS) copies your data synchronously three times within a single physical location in the primary region. LRS is the least expensive replication option, but isn’t recommended for applications requiring high availability or durability.
• Zone-redundant storage (ZRS) copies your data synchronously across three Azure availability zones in the primary region. For applications requiring high availability, Microsoft recommends using ZRS in the primary region, and also replicating to a secondary region.

Best Practices

The bundle includes a number of best practices without needing any additional work on your part.

TLS 1.2

Enforcement of TLS 1.2 on public HTTPS endpoints is standard best practice.

Data retention policy

A time-based retention policy stores blob data in a Write-Once, Read-Many (WORM) format for a specified interval. When a time-based retention policy is set, clients can create and read blobs, but can’t modify or delete them. After the retention interval has expired, blobs can be deleted but not overwritten.

Security

In order to improve security, we implement a few key safeguards.

Data encrypted in transit

By default, all data in transit will be encrypted with Secure Sockets Layer and Transport Layer Security (SSL/TLS).

Data encrypted at rest

Azure Storage uses service-side encryption (SSE) to automatically encrypt your data when it is persisted to the cloud. Azure Storage encryption protects your data and to help you to meet your organizational security and compliance commitments.

Observability

Massdriver provides you with visibility into the health of your systems. By default, storage accounts will be created with alarms connected to Massdriver to alert you when performance drops below a key threshold or fails completely. You will be notified when the availability, end-to-end latency, or server latency reaches certain thresholds.

Trade-offs

• CMKs are not currently supported