Cloud Security Best Practices for SaaS Applications in 2026

The Shared Responsibility Model

Understanding the shared responsibility model is the first step in cloud security. The cloud provider is responsible for the security of the cloud — physical data centre security, hypervisor isolation, network fabric, and the availability of managed services. You are responsible for security in the cloud — your data, your IAM configuration, your application code, your network configuration, your operating system (for IaaS), and your encryption choices.

For SaaS on managed services (ECS, RDS, Lambda), the provider takes on more responsibility — OS patching for managed services is handled by AWS, for example. For IaaS (EC2, self-managed databases), you carry more of the responsibility. Understanding exactly where the boundary sits for each service you use is essential for audit and compliance purposes.

Identity and Access Management (IAM)

Least Privilege

Every IAM entity (user, role, service account) should have only the permissions required for its specific function — nothing more. This is the single most impactful IAM control. Start by auditing existing roles using AWS IAM Access Analyzer, which identifies permissions granted but not used in the last 90 days. Remove unused permissions. Never grant AdministratorAccess to service roles.

MFA Enforcement

Enforce MFA for all human IAM users and for the AWS root account (which should have no access keys and be used only for account-level tasks). Use Service Control Policies (SCPs) in AWS Organizations to deny API calls from users without MFA — this prevents MFA bypass even if a policy is misconfigured at the account level.

Service Account Security

Applications running on EC2, ECS, Lambda, or Kubernetes should use IAM roles — not access keys. Roles are automatically rotated and never need to be stored as secrets. If you must use access keys (e.g., for a CI/CD pipeline that can't use OIDC), rotate them every 90 days, store them in Secrets Manager, and set up CloudWatch alerts for their use outside expected patterns.

Network Security

VPC Design

A secure VPC design separates public and private subnets. Load balancers and bastion hosts live in public subnets (with internet access). Application servers and databases live in private subnets with no direct internet access. Database servers should be in a dedicated, more restricted private subnet tier — not the same subnet as application servers.

Security Groups

Security groups are the primary network-level control in AWS. Rules: never allow SSH (port 22) or RDP (port 3389) from 0.0.0.0/0 — use AWS Systems Manager Session Manager for shell access instead. Never allow database ports (5432, 3306, 1433) from 0.0.0.0/0 or even from the whole VPC CIDR — only from the application server security group. Use security group references (SG-to-SG rules) rather than IP CIDR ranges wherever possible.

WAF and DDoS Protection

AWS WAF (Web Application Firewall) sits in front of your Application Load Balancer or CloudFront distribution and blocks common web attacks: SQL injection, XSS, rate limiting, bad bots, and the OWASP Top 10. Enable AWS Shield Standard (free) for all internet-facing resources. For high-value targets, AWS Shield Advanced provides enhanced DDoS protection and 24/7 DDoS response team access.

Data Security

Encryption at Rest

Enable encryption for all storage: RDS (enable at-rest encryption with AWS KMS at creation time — cannot be added after), S3 (server-side encryption with SSE-S3 or SSE-KMS), EBS volumes, ElastiCache (enable in-transit and at-rest encryption), and DynamoDB (encryption at rest is enabled by default but verify KMS key usage). Use customer-managed KMS keys (CMKs) for sensitive data — this gives you key rotation control and audit logs of all decryption events.

Encryption in Transit

Enforce TLS 1.2 minimum (TLS 1.3 preferred) for all external and internal traffic. On ALB, configure an HTTPS listener with a minimum TLS 1.2 security policy and redirect HTTP to HTTPS. For internal service-to-service communication, use mutual TLS (mTLS) with AWS Private Certificate Authority or a service mesh (AWS App Mesh) for microservices architectures.

Secrets Management

Never store database passwords, API keys, or other credentials in environment variables, source code, config files, or AMI images. Use AWS Secrets Manager for all secrets — it provides automatic rotation for supported services (RDS passwords rotate automatically without application changes), fine-grained IAM access control, and CloudTrail audit logging of every secret access. The cost is £0.40/secret/month plus retrieval costs — negligible compared to the cost of a breach.

Application Security

The OWASP Top 10 vulnerabilities remain the dominant source of application-level cloud breaches. In the cloud context, the most critical items are: injection (SQL, command), broken access control (ensure your application enforces per-tenant isolation — a SaaS critical concern), cryptographic failures (use Secrets Manager, not application-layer encryption of passwords), and insecure design (tenant data leakage between SaaS customers).

Container security: scan all Docker images for vulnerabilities using Amazon ECR image scanning (uses Snyk under the hood in advanced mode) or integrate Trivy into your CI pipeline. Never run containers as root. Use read-only root filesystems where possible. Set resource limits (CPU/memory) on all containers to prevent resource exhaustion attacks.

Monitoring and Threat Detection

CloudTrail: enable AWS CloudTrail in all regions and send logs to a dedicated, locked-down S3 bucket in a separate security account. CloudTrail records every API call in your AWS account — who did what, when, from where. This is your audit log and incident investigation foundation. Enable log file integrity validation so logs cannot be tampered with.

Amazon GuardDuty: GuardDuty is AWS's managed threat detection service. It analyses CloudTrail, VPC Flow Logs, and DNS logs using machine learning to detect threats: compromised instances making unusual API calls, credential theft, cryptocurrency mining, data exfiltration patterns, and unusual network behaviour. Enable it in all regions with a single click. Cost is typically £50 to £200/month for mid-market accounts — cheap insurance.

CloudWatch Alerts: configure alerts for: root account activity (any action from root should alert immediately), failed console login attempts, security group changes, changes to IAM policies, and GuardDuty findings of high severity. Route alerts to your security team via SNS → email and a dedicated Slack channel.

GDPR and Cloud Data Residency

For UK SaaS companies, GDPR (and UK GDPR post-Brexit) requires that personal data of EU and UK subjects is processed lawfully and securely. In the cloud, this means: data must stay in approved regions (use SCPs to deny resource creation outside eu-west-2/eu-west-1), all personal data must be encrypted at rest and in transit, you must be able to respond to subject access requests and right-to-erasure requests (implement soft-delete + data export in your application), and you must have a Data Processing Agreement with your cloud provider (all three major providers offer standard DPA agreements).

Security Controls by Layer

Infrastructure-as-Code Security Scanning

Shift-left security means catching misconfigurations before they reach production. Integrate Checkov or tfsec into your GitHub Actions or GitLab CI pipeline to scan every Terraform pull request. These tools check for: open security groups, unencrypted storage, missing access logging, public S3 buckets, missing MFA enforcement on IAM, missing KMS encryption, and hundreds of other rules mapped to CIS and NIST frameworks.

AWS CloudFormation Guard and AWS CDK Security Aspects provide similar capabilities for CloudFormation and CDK users. Amazon Inspector provides continuous vulnerability scanning for EC2 instances, container images in ECR, and Lambda function code — find and remediate CVEs before attackers do.