Cloud Security Guides

If you run internet-facing workloads on AWS, getting your WAF configuration right is no longer optional. It is table stakes for FCA-regulated services, GDPR compliance, and the NCSC’s Cyber Essentials Plus framework. What has changed in 2026 is the scope of what WAF now needs to protect: not just your ALBs and CloudFront distributions, but agentic AI workloads running on Amazon Bedrock AgentCore Gateway, and APIs that attract a growing volume of automated traffic. Two disclosures in the last 72 hours make this more pressing than usual. One is a major capability release, the other a critical vulnerability bulletin. Both require your attention now. ...

Compliance in cloud environments is widely misunderstood and frequently mishandled. The misunderstanding takes two forms: organisations that treat cloud compliance as a mapping exercise — draw lines between framework controls and AWS services, tick boxes, file the report — and organisations that treat cloud as a compliance risk and avoid it entirely. Both miss the point. Cloud platforms, when correctly configured, can make compliance significantly more achievable than traditional data centre environments. But “correctly configured” is doing enormous work in that sentence. ...

AWS Security Hub is the centralised security posture management service within AWS, functioning as both a findings aggregator and a compliance evaluation engine across your entire AWS organisation. Findings from native services — GuardDuty, Amazon Inspector, Amazon Macie, IAM Access Analyzer, and AWS Config — are ingested alongside findings from over 60 third-party security products, all normalised into the Amazon Security Finding Format (ASFF). Security Hub continuously evaluates account configuration against security standards including the AWS Foundational Security Best Practices (FSBP), CIS AWS Foundations Benchmark, and PCI DSS, generating PASS or FAIL findings for each evaluated resource across every member account. ...

AI systems running in cloud environments introduce a threat model that most security teams are not yet equipped to handle. The underlying risk is not that AI is inherently dangerous — it is that AI components are being wired into cloud infrastructure with the same access patterns as any other service, without the same scrutiny applied to the novel attack surfaces they introduce. An LLM with access to a database, a file system, or a set of API credentials is a new kind of principal with new kinds of attack vectors. Security architects who understand cloud IAM, network controls, and vulnerability management need to extend that understanding to cover AI-specific threats before organisations learn about them the hard way. ...

The AWS Well-Architected Security Pillar is a structured framework for evaluating and improving the security posture of workloads running on AWS. It defines eleven security questions — organised across seven best practice areas — that cover the full range of security decisions an architect must make: identity, detection, network protection, data security, incident response, and application security. A workload that answers all eleven questions with evidence-backed “yes” responses is, by definition, a well-secured workload. ...

Cloud identity and access management (IAM) is the system of controls that determines who can access what in a cloud environment — governing authentication, authorisation, and privilege for every human user, workload, and service that interacts with cloud resources. It is not a supporting discipline within cloud security; it is the foundation on which everything else rests. There is no network boundary to cross, no physical server room to enter. The only thing standing between an attacker and your cloud resources is whether they can obtain and use valid credentials. ...

Cloud incident response is the organised process of detecting, containing, investigating, and recovering from security incidents in cloud environments — and then learning from them. It differs from traditional incident response in important ways: there are no physical servers to seize, logs are ephemeral unless explicitly preserved, infrastructure can be destroyed and rebuilt in minutes, and the blast radius of a compromised cloud identity is global rather than local. These differences make cloud IR both more powerful in some respects and more dangerous in others. More powerful because automation can contain incidents faster than any human response. More dangerous because evidence disappears and attackers can move at machine speed. ...

Cloud network security is the set of controls that govern how traffic moves into, out of, and between resources in a cloud environment — covering ingress and egress filtering, network segmentation, private connectivity, traffic inspection, and detection of anomalous network behaviour. It is structurally different from traditional network security: there is no physical perimeter, no hardware firewall appliance to configure, and no cable you can pull. Instead, the network itself is software-defined, provisioned via API, and controlled through policies attached to virtual constructs. That shift eliminates some traditional attack vectors and introduces entirely new ones. ...

Cloud threat detection is not a product you buy — it is a discipline you build. The cloud gives you access to more security signal than any on-premises environment could generate, but that abundance is also the problem. Without deliberate architecture, you drown in logs while the attacks that matter go undetected. This guide covers what cloud threat detection actually requires: the signal sources, the threat categories worth instrumenting, the native and third-party tooling landscape, and the architectural decisions that determine whether your detection programme catches real attacks or generates expensive noise. ...

DevSecOps is the integration of security practices into the software development and delivery lifecycle — shifting security left from a deployment-gate activity into the development process itself, so that vulnerabilities, misconfigurations, and policy violations are caught at the point where they are cheapest to fix. In a cloud-native environment, where infrastructure is code, the same shift-left principle applies to the configuration of cloud resources: a misconfigured S3 bucket in a Terraform file is a security defect, and like all defects, it is orders of magnitude cheaper to fix in code review than in production. ...