cloud recovery Archives

Reviewed: 13 September 2026 · Next review: 13 December 2026
Author: Ozlin Info Editorial Team · Human review: Lin (accountable human); Codex assisted

Moving a workload to AWS or Microsoft Azure changes who operates parts of the technology stack; it does not transfer every security decision to the cloud provider. Identity configuration, data access, workload code, logging, recovery and many network choices normally remain customer responsibilities.

Both AWS and Microsoft describe security as a shared-responsibility model. The exact boundary changes with the service. A virtual machine leaves the customer responsible for more operating-system and application work than a managed database or software-as-a-service product. The contract, architecture and configuration—not the word “cloud”—determine the real boundary (AWS — Shared responsibility model; Microsoft — Shared responsibility in the cloud).

1. Record the service and responsibility boundary

For each production service, maintain a short record of:

business owner and technical owner;
cloud account, subscription, project or tenant;
data classification and relevant people or jurisdictions;
service model and provider/customer responsibilities;
internet exposure and trust dependencies;
identity and privileged-access path;
logging destination and retention decision;
backup, restore and continuity design; and
critical supplier and exit dependencies.

Do not copy a generic responsibility diagram into a policy and assume the job is done. Confirm responsibilities for the precise service and support plan in use.

2. Separate environments and reduce root-level access

Use organisational structures, accounts, management groups, subscriptions or projects to separate production, development, security logging and shared services. Apply centrally governed controls where they are testable and appropriate, while maintaining an exception process for legitimate workloads.

Protect the highest-privilege identities:

avoid everyday use of AWS root or Microsoft tenant-wide administrative accounts;
require phishing-resistant MFA where supported, with controlled recovery methods;
use workforce federation and short-lived sessions rather than distributing long-lived access keys;
separate administrative and normal-user identities where risk justifies it;
maintain emergency-access procedures, monitoring and periodic tests; and
review effective permissions, not only group names.

AWS recommends federation and temporary credentials for human users and workloads where possible (AWS — IAM security best practices). In Azure, managed identities and other workload-identity patterns can reduce stored secrets; the correct design still depends on the workload and trust boundary (Microsoft — Secure service accounts).

3. Give workloads identities instead of embedded secrets

Static credentials copied into source repositories, container images, scripts or virtual-machine configuration are difficult to rotate and easy to leak. Prefer workload identities, instance or task roles, managed identities and short-lived tokens when supported.

Where a secret remains necessary:

store it in an approved secrets service;
restrict who and what may retrieve it;
rotate it according to risk and provider capability;
audit access and failed retrievals; and
define a revocation procedure that does not require rebuilding the entire environment.

Least privilege is an ongoing measurement problem. Start with a documented purpose, monitor use, remove unused permissions and review privilege escalation paths across identity, resource and key-management policies.

4. Build guardrails around change

Infrastructure as code can make cloud configuration reviewable and repeatable, but it can also reproduce a dangerous mistake quickly. Use version control, peer review, automated checks, separate deployment identities and tested rollback.

Useful guardrails may detect or prevent:

public storage or database exposure;
unrestricted administrative ports;
resources without accountable ownership or environment tags;
disabled or diverted audit logging;
overly broad identity or key policies;
unapproved regions or services; and
backups that do not meet the workload's recovery design.

Not every preventive policy is safe to deploy globally without testing. Roll out in stages, measure legitimate exceptions and ensure responders can diagnose policy-caused outages.

5. Design network boundaries around flows, not appearances

A virtual network is not automatically private merely because resources have private addresses. Map inbound, outbound and east–west flows, including provider control planes, managed-service endpoints, DNS, update sources and third-party APIs.

Where appropriate:

remove public endpoints that have no business requirement;
use private endpoints and explicit routing for sensitive services;
constrain administrative access through managed paths rather than open source ranges;
control outbound traffic where the operational benefit justifies the complexity;
protect internet applications with layered application, rate and abuse controls; and
verify that security groups, network-security groups, firewalls and load balancers express the intended path.

Network controls supplement identity and resource policy. They do not repair an over-privileged application identity or a public data policy.

6. Protect data with access control, encryption and lifecycle decisions

Cloud-provider encryption defaults are useful, but “encrypted” is not a complete security decision. Since January 2023, Amazon S3 automatically encrypts new object uploads with server-side encryption using Amazon S3 managed keys by default (AWS — Setting default server-side encryption behavior for Amazon S3 buckets). That does not decide who can read the bucket, whether a customer-managed key is required, how exports are controlled, or whether the design meets a legal or contractual obligation.

Record:

data classification and minimisation decisions;
resource and identity access paths;
key ownership, rotation, separation and recovery;
replication, backup and deletion behaviour;
snapshots, logs and non-production copies; and
what can be exported by users, services and administrators.

Microsoft Purview Information Protection can support classification and protection workflows in relevant Microsoft environments, but product deployment does not by itself establish a compliant information-governance programme (Microsoft — Learn about information protection).

7. Centralise evidence and protect the logging path

Enable the logs required to answer who changed what, from where, through which identity and with what result. Send security-relevant evidence to a location that a compromised workload administrator cannot silently rewrite.

Cover at least:

control-plane and identity activity;
workload, application and authentication events;
network and name-resolution evidence where justified;
key, secret and data-access events for sensitive resources;
changes to logging, monitoring and security controls; and
time synchronisation and asset context needed for investigation.

Test alerts with benign simulations. An enabled service that no one receives, can query or knows how to interpret is not an operational control.

8. Engineer and test recovery

High availability inside one service or region is not the same as recoverability. Define recovery time and recovery point objectives from business impact, then choose architecture and backups to meet them.

Test:

restoration into an isolated or clean environment;
dependencies, identities, secrets, DNS and certificates—not only data files;
recovery from malicious deletion or encryption;
provider-account lockout and emergency access;
cross-region or alternate-service assumptions where used; and
evidence that the restored application is complete and trustworthy.

Keep restoration authority and backup deletion paths appropriately separated. Record measured results rather than saying that a service is “fully redundant.”

9. Review location and cross-border disclosure separately

Choosing an Australian region can be relevant to latency, contractual commitments, resilience and information handling. It does not prove that all support, logs, backups, administrators or subprocessors remain in Australia.

For organisations covered by the Australian Privacy Act, APP 8 addresses cross-border disclosure of personal information and includes requirements and exceptions that depend on the circumstances (OAIC — APP 8). A region selection is not a substitute for mapping recipients, provider terms, access, subprocessors and applicable exceptions. Obtain qualified advice for legal conclusions.

A practical review sequence

Inventory production accounts, subscriptions, owners and critical data.
Protect root and tenant-wide identities and establish emergency access.
Remove unused credentials, public endpoints and broad permissions.
Centralise control-plane and identity logs, then test alerts.
Review infrastructure code and high-impact guardrails.
Map sensitive data, keys, copies, transfers and deletion paths.
Restore a critical workload and record the measured outcome.
Track exceptions and repeat the review after material changes.

Where Ozlin can help

Ozlin can help a small organisation inventory AWS or Azure resources, review identity and configuration, map exposed services, check logging and document a backup/restore exercise within a written scope. Ozlin does not certify an environment, guarantee breach prevention or provide legal compliance determinations.

See Cybersecurity services or contact Ozlin for a scoped review.

This article is general technical information, not legal advice, certification or a warranty that a particular cloud design is secure or compliant.

Limitations: Provider documentation does not prove the configured environment is secure. Actual exposure depends on services, regions, identities, network, workloads, data and recovery tests; no certification or security guarantee is made.

AI-assistance disclosure

AI tools assisted with source discovery, outlining and copyediting. A human reviewer must verify every source, platform statement, service claim and publication decision before release.