Keep the momentum going. Explore more insights to move your business forward.
Availability and security are inseparable pillars when building robust cloud infrastructures. Unfortunately, organizations that treat them as distinct concerns often discover the truth the hard way: A security breach can cripple availability just as much as a hardware failure, while systems designed for uptime without any security considerations become easy targets for attackers.
Despite this reality, many organizations struggle with silos between their site reliability engineering (SRE) and security teams.
While SREs focus on uptime, latency, and incident response (IR), security engineers concentrate on access controls and compliance frameworks. The two teams also often use different tools and measures for success. However, not resolving the silos between these teams creates blind spots in cloud architecture, e.g., secure systems that can’t support traffic surges or highly available systems that have vulnerabilities.
This article discusses how to implement resilient cloud architecture patterns that enhance both availability and security.
Note: SRE and security teams must collaborate closely to implement the practices below. Although one group might lead an implementation, the other will need to be consulted to ensure the end product meets both availability and security requirements.
Multi-AZ and multi-region redundancy
When implementing cloud infrastructure, geographic redundancy is always a key consideration. All major cloud providers offer multiple regions where you can run your services, with each region split into availability zones (AZs).
Achieving high availability (HA)
Companies can achieve high availability by distributing applications across multiple availability AZs. Some cloud providers even offer fault domains within one zone to ensure anti-affinity (i.e., ensuring your instances are not all on the same hardware in a single AZ).
Availability zones have their own power, cooling, and networking. Typically separated by a meaningful distance, they are connected by low-latency links, meaning that services in an AZ can easily connect and communicate quickly with services in another AZ in the same region.
Major cloud providers design their zones so that a problem in one AZ doesn’t affect others in the same region.
Advantages of maintaining high availability
From a security standpoint, HA brings many benefits.
Imagine a targeted DDoS attack that overwhelms your network in one AZ. Without HA, access to your application is no longer possible. With HA, your load balancer distributes traffic across zones, and your databases have synchronous replication enabled between AZs (a pretty typical DB service), allowing uninterrupted access to the app.
Also, instead of working to get your application back online, teams can find out how the DDoS attack happened in the first place and what protective measures are required to avoid it in the future.
Another major benefit of high availability is zero-downtime patching: You can easily update apps in one AZ while traffic flows to the other, eliminating the security vs. availability trade-off that comes with maintenance in general.
Implementing disaster recovery (DR)
DR takes high availability to the next level, spreading your applications not only across multiple AZs, but also across different regions.
While HA protects you against localized failures, DR protects you in the event of regional disasters like massive natural events (hurricanes, floods, earthquakes, etc.), widespread network outages, and even cyberattacks that target an entire region.
With DR in place, if an entire AWS region goes down, your applications can still serve traffic from other regions. This greatly improves recovery point objective (RPO) and recovery time objective (RTO), plus minimizes data loss.
Drawbacks of DR
Multi-region deployments do come with greater complexity than HA—and higher costs.
DR mandates that you replicate your entire setup across multiple regions. And given the distance between regions, data replication will typically happen asynchronously. This means that you’ll need to accept some lag and handle potential conflicts when the same data is modified in multiple regions at the same time.
Active-active vs. active-passive patterns
Whether you’re implementing HA or DR, you’ll need to decide on an active-active or active-passive pattern. Each one has different availability and security implications.
Active-active means that all the locations you’re using in HA or DR are serving production traffic simultaneously. For example, in AWS, if you have users in North America, they might hit your us-east-1 region, while users in Europe will hit eu-west-1. Depending on your implementation, traffic can also be distributed across all regions, regardless of user location. In this way, whenever there’s a failure at one location, traffic can simply shift to other regions.
This setup also translates into maximized resource utilization, as your resources will always be in use. Unfortunately, from a security perspective, active-active strategies increase your attack surface because all your locations are accessible.
Active-passive means that one of your locations is serving production traffic, while the other (or others, depending on how your app is distributed) is on standby, ready to take over in the event of a failure(s).
The biggest security advantage of active-passive is that it reduces your attack surface, as users have access to only a single region. The downside? You’ll have a slower RTO than with active-active since you first need to detect the failure and then decide which zone or region to fail over to.
Companies typically use active-active for stateless applications and active-passive for stateful components like databases.
Now that we have explored Multi-AZ and Multi-Region Redundancy, it’s important to note: HA and DR may keep your systems running in the event of failures, but they don’t protect them from being compromised in the first place. For that, companies need to design their architecture to be secure by default.
Secure design patterns in your architecture
Organizations typically want to deploy their applications as quickly as possible, often leaving security to be treated as a secondary concern. This is a mistake, as your infrastructure requires protection from the get-go.
This section reviews the cloud service components you need to do that.
Identity access management (IAM)
IAM is the first line of defence for cloud security. Even if identity breaches are rarely the end goal of an attack, they are the ones that lead to the most problems.
Every action you take in cloud environments requires authentication (proving who you are) and authorization (proving what you’re allowed to do).
To ensure IAM is secure, the following controls are a must.
Role-based access control (RBAC)
Companies must restric admin rights based on assigned tasks. Create distinct roles that your users can assume to perform their jobs, and ensure they have access to only those roles required to do their jobs.
If someone moves to another team in your organization, you can easily revoke their permissions for a particular role and grant them access to any new roles necessary.
RBAC isn’t solely for human users. It also applies to service accounts and applications, whereby they assume a service role with permissions granted solely for a given activity. This is extremely important, especially in microservice environments, as this prevents a compromised service from accessing resources beyond the scope of that role.
Principle of least privilege (PoLP)
Engineers are typically tempted to offer more privileges for a given role “just in case.” But permissions should always be kept to a minimum.
To achieve this, start with zero permissions, then grant them only as you discover what’s actually required; cloud providers have tools that can help with this.
From an availability perspective, PoLP reduces damage from any single compromise.
Multi-factor authorization (MFA)
MFA adds a second verification step beyond a password so that even if a password is compromised, you’ll still have a second layer of defense. If your company requires single sign-on (SSO), you might also need MFA at that level; this is a great security measure.
To take it a step further, you can implement a second MFA for assuming dangerous roles, like admin, or accessing important applications. This way, even if SSO and your first MFA are compromised, you’ll still have another layer of protection in place to stop attackers from moving laterally.
Bastion hosts
Bastion hosts are hardened servers that provide access to your private network. Instead of exposing all your servers to the internet or allowing VPN access to your entire network, you can expose only these hosts and use them to reach internal resources.
From a security perspective, you can enforce strict authentication on your bastion hosts (using keys and MFA) and log all sessions to them, turning them into a single auditable access point.
When it comes to availability, bastions prevent the most common cause of SSH-related outages: widespread credential leaks that lead to account lockouts.
Beyond traditional bastion hosts, modern implementations use ephemeral bastions, which are servers you create when you need them and then destroy after use.
Cloud provider solutions also let you leverage browser-based access to private instances, eliminating the need for bastion hosts entirely. This improves availability because there is no bastion infrastructure to maintain or fail over to. These solutions also increase security by logging all access and enforcing IAM policies.
Virtual private cloud (VPC) peering vs. transit gateway
When implementing DR, you’ll need more VPCs since they’re regional resources, as well as a way to connect them. To do that, you have two options: VPC peering and transit gateways.
With VPC peering, you connect your VPCs in a one-to-one relationship. Say you have three VPCs (VPC1, VPC2, VPC3) and you want to connect all of them. It’s not enough to connect VPC1 to VPC2 and VPC2 to VPC3. You also need to connect VPC1 to VPC3. This offers security advantages, such as network isolation, plus boosts availability, as the direct connection eliminates single points of failure.
With transit gateways, on the other hand, your VPCs connect to a central gateway that routes traffic between them. As your environment grows, it’s much easier to add another VPC via a transit gateway than to configure many one-to-one peerings.
There is one downside to transit gateway, however. Given that all routing and network policies are managed via a single central gateway, that gateway becomes a critical dependency. If it fails or becomes overloaded, inter-VPC communication simply stops. Cloud providers usually overcome this issue by implementing HA at the gateway level.
Choosing between VPC peerings and transit gateways usually comes down to environment size: VPC peerings are more suitable for smaller environments, while transit gateways are the better fit for larger ones.
Content delivery network (CDN) security
CDNs traditionally focused on availability by caching content at edge locations to reduce latency and reduce origin server load.
Modern CDNs, on the other hand, have become powerful security tools that also absorb traffic spikes and protect you against various attacks. CDNs today even come equipped with features like DDoS mitigation, web application firewalls (WAFs), and rate limiting, allowing companies to enforce security controls at the edge while preserving performance.
These attributes have made CDNs a core component of both availability and security.
DMZ and layered network design
When implementing defense in depth, you need to organize your infrastructure into layers and establish controlled access between them. The classic pattern is a demilitarized zone (DMZ) in which your network is divided into multiple security zones based on exposure and trust levels.
In cloud environments, this translates into a subnet design within your VPC. In a classic DMZ, you typically have three subnets:
- A public one for internet-facing resources like load balancers or web servers
- A private one for your application servers
- Another private one for your databases (which is the most protected)
For a public subnet, you’ll typically use an internet gateway to ensure your resources are accessible, while for a private subnet, you’ll leverage a NAT gateway to ensure your resources can initiate outbound connections.
Another best practice is to leverage network ACLs that operate at the subnet level to restrict certain ports and protocols, while at the same time using security groups at the instance level to do the same. This means that an attacker would have to breach both security group rules and network ACLs even if they’ve already breached your web server.
By implementing the DMZ principle using this layered design, you improve both security and availability by limiting blast radius. So, even if there is a failure or compromise, it will be contained within a single layer.
WAF protection
WAFs protect applications from common attacks, like cross-site scripting, SQL injection, and other OWASP top 10 vulnerabilities, by inspecting HTTP/HTTPS requests and blocking malicious patterns before they reach your applications.
In cloud providers, WAFs operate at the application level and integrates with load balancers, API gateways, or CDNs. They help you stop malicious requests at the entry point of your architectures, reducing both the blast radius and the load on your services.
When it comes to availability, WAFs protect your systems from being overwhelmed by ensuring that legitimate users can still access your applications during attacks.
DDoS resilience patterns
While CDNs provide significant protection, distributed denial-of-service (DDoS) resilience requires multiple architectural patterns working together. Engineers may be tempted to improve resilience against DDoS threats by over-provisioning their infrastructure to ensure it has enough capacity to absorb these attacks. This is, however, not a best practice.
To properly achieve DDoS resilience, implement:
- Rate limiting: A single client should only be allowed to make a certain number of requests within a given period of time.
- Geographic filtering: Restrict traffic from regions you don’t serve.
- DNS-based defense: Implement DNSSEC to prevent DNS spoofing.
- Blackhole routing: Intentionally drop traffic destined for a specific IP (only used as a last resort).
Encryption at rest and in transit
Safeguarding data from unauthorized access serves both security and compliance goals, making encryption a key part of resilient cloud architecture.
Implementing encryption at rest protects data against unauthorized access to storage systems such as block storage, object storage, and databases. Encryption in transit secures data moving between services, regions, or users; this protects data integrity against possible interception or tampering.
Together, both forms of encryption ensure that your data stays secure throughout its entire lifecycle, regardless of where you store it or how it is accessed. When it comes to availability, encryption enables secure recovery from failure without exposing sensitive data during the backup and restore process.
Failure isolation in microservices
As microservices distribute functionality across many small and independent services, you need to implement failure isolation patterns. This way, even if one microservice is compromised, the impact will not spread to others.
Circuit breakers
Circuit breakers (CBs) protect your services from cascading failures caused by unhealthy dependencies. A circuit breaker has three states:
A circuit breaker opens when a failure crosses a threshold, causing requests to fail immediately to avoid resources being exhausted.
From a security perspective, circuit breakers limit the blast radius during an attack. If a service is compromised and malfunctions, the CB limits lateral movement, preventing the breach and resulting malfunction from spreading to other services.
Service meshes like Istio and Linkerd provide transparent circuit breaking, without requiring you to change your application code.
Bulkhead pattern
The Bulkhead pattern isolates resources so that failures in one area don’t consume resources needed by others. In Kubernetes, bulkheads are implemented through resource limits on pods, preventing any single pod from consuming all the CPU and memory from the node.
This allows teams to prevent the noisy neighbor problem and contain compromised containers.
Zero Trust architecture
Every request must be authenticated, authorized, and encrypted to implement Zero Trust architecture.
Mutual TLS (mTLS) performs this function at the transport layer, where both the client and the server must prove their identities using certificates. Service meshes handle mTLS transparently, making them a great choice for implementing strong security by default.
To restrict resources and their parameters, you’ll need to leverage policy-as-code (PaC) tools, like Kyverno or Open Policy Agent. Also, expressing policies as code makes it easy to replicate them across environments, ensuring your organization’s policies are respected wherever you deploy.
Using tools like Trivy for vulnerability scanning and Falco for runtime behavior additionally enables continuous security enforcement throughout your application lifecycle.
Zero Trust forces malicious actors to reveal themselves during the initial steps of an attack. From an availability perspective, detecting compromises early prevents outages by catching security issues before they cause operational impact.
Building resilience requires security and availability
A resilient cloud architecture should deliver both security and availability.
That starts with geographic redundancy as the foundation, followed by secure design patterns (e.g., IAM and network segmentation), failure isolation with circuit breakers and bulkheads, and, finally, Zero Trust.
To implement everything presented in this article, you’ll need to ensure collaboration between your SRE and security teams. Achieving resilient cloud architecture is a two-way street. Security engineers must be included in SRE planning for multi-region migrations, and SREs must be involved in the design of Zero Trust architecture.
Even if a particular measure falls under the SRE team’s remit, the security team must be consulted to ensure alignment with security best practices and compliance requirements.
Looking for a partner to help you achieve security and high availability from day 1? Send a message to RapidScale to speak to one of our experts today.
