DEV Community: Devam Parikh

Testing Application Resilience: How to Stop Amazon ElastiCache Cluster and Manage Traffic

Devam Parikh — Fri, 13 Oct 2023 06:02:29 +0000

Introduction

As developers, it is crucial to test the resiliency of our applications and understand how they handle failures or disruptions. In this blog post, we will explore a scenario where we need to stop an Amazon ElastiCache cluster to see how our application behaves when Redis is unavailable. Although ElastiCache clusters cannot be stopped, we will discuss alternative approaches to achieve our testing objective.

Understanding Amazon ElastiCache

Amazon ElastiCache for Redis is a powerful in-memory data structure service that provides real-time performance for modern applications. It serves as a cache or a data store, delivering high-speed access to data. ElastiCache uses a synchronous replication mechanism to maintain data consistency across its nodes.

Challenges with Stopping ElastiCache Cluster

Stopping an ElastiCache cluster is not possible due to the synchronous replication mechanism. If we stop a node, the cluster's redundancy is compromised, potentially leading to instability or complete failure. However, we can explore other methods to create scenarios where our application experiences Redis unavailability.

Blocking Incoming Traffic using Security Groups

To simulate Redis unavailability, we can block incoming traffic to the ElastiCache cluster. Security groups act as virtual firewalls, controlling inbound and outbound traffic. By removing all the inbound rules for the ElastiCache cluster, we can prevent any incoming requests from reaching it.

However, it is essential to understand that security groups are stateful[1]. This means that existing connections are not interrupted when security group rules are changed. Thus, our application may still be connected to the ElastiCache cluster.

Addressing the Issue

Two methods can be used to tackle this issue:

1. Restarting the Application: By restarting the application, existing connections will be terminated, forcing the application to establish new connections. This can validate the application's ability to handle Redis unavailability.

2. Using Network ACLs: Network Access Control Lists (ACLs)[2] operate at the subnet level and allow or deny specific inbound or outbound traffic. Unlike security groups, network ACLs are stateless, meaning they don't automatically allow response traffic. Introducing a network ACL that blocks traffic in either direction can break existing connections.

Network ACL in Depth

You can either use the default VPC network ACL or create a custom one with rules similar to security groups for extra VPC security at no extra cost.

The following diagram depicts a VPC with two subnets, each having its network ACL. When traffic enters the VPC (such as from a peered VPC, VPN connection, or the internet) the router directs it to its destination.

Network ACL A controls which traffic can enter subnet 1 and leaves it to destination outside subnet 1. Similarly, network ACL B regulates traffic entering and leaving subnet 2.

Creating a Custom Network ACL

As illustrated in the figure below, this is how I've configured the denial of incoming traffic from my application to the ElastiCache cluster.

A network ACL comprises both inbound and outbound rules, each capable of allowing or denying traffic. These rules are numbered from 1 to 32766.

When determining whether to allow or deny traffic, we evaluate the rules sequentially, starting with the lowest numbered rule. If a rule matches the traffic, it is applied, and no further rules are assessed.

Conclusion

Testing application resilience is essential to ensure smooth operation in challenging scenarios. While stopping an ElastiCache cluster is not feasible due to its replication mechanism, alternative approaches such as blocking incoming traffic using security groups or employing network ACLs can help simulate Redis unavailability. By understanding the statefulness of security groups and the statelessness of network ACLs, we can effectively test our application's behaviour when critical resources are not available.

In summary, remember these key points:

ElastiCache clusters cannot be stopped and rely on synchronous replication for real-time performance.
Security groups are stateful, meaning existing connections persist when rules are modified.
Network ACLs are stateless and can be used to block traffic, potentially breaking existing connections.

Reference:
[1] https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/security-group-connection-tracking.html
[2] https://docs.aws.amazon.com/vpc/latest/userguide/vpc-network-acls.html

Demystifying DDoS Attacks and CloudFront: A DevSecOps Guide

Devam Parikh — Fri, 21 Jul 2023 10:49:11 +0000

The IT industry is currently facing the worst crisis in its history, with numerous factors affecting its stability. One significant factor that demands attention is the rising number of DDoS attacks. According to the reports available to me, there was a 150% increase in DDoS attacks in 2022 compared to 2021. Moreover, experts predict a continued upward trend in the upcoming years.

Attacks such as DDoS can have a significant impact on organizations, causing service disruptions, financial losses, reputation damage, data loss, increased vulnerability to other attacks, and more.

In today's digital landscape, understanding and mitigating DDoS attacks is crucial for DevSecOps professionals. In this blog post, we'll explore the intricacies of DDoS attacks and how CloudFront, Amazon Web Services' (AWS) content delivery network (CDN) service, can be a valuable tool in protecting your applications and infrastructure. By answering key questions along the way, we'll unravel the mysteries surrounding DDoS attacks and equip you with the knowledge to fortify your systems.

What do you need to know about DDoS attackt as DevSecOps?

A DDoS attack, or distributed denial-of-service attack, is a cyber-attack that targets a website or server by flooding it with so much traffic that it becomes unavailable to legitimate users. The goal of a DDoS attack is to disrupt the targeted website or server's services, making it inaccessible to users.

There are two main types of DDoS attacks: volume-based attacks and application-layer attacks. Volume-based attacks flood the target with a large amount of traffic, overwhelming its resources and making it unable to handle legitimate requests. Application-layer attacks exploit vulnerabilities in the targeted website or server's applications, causing them to crash or malfunction.

To launch a DDoS attack, the attacker first identifies the target website or server. Then, they gather a large number of infected computers, called "zombies," to flood the target with traffic. This overwhelms the website or server, making it unable to handle legitimate requests. As a result, users are unable to access the website or server.

How can CloudFront help with hosting and DDoS attackts?

CloudFront is a content delivery network (CDN) service that speeds up the delivery of your content to users all over the world by caching your content in edge locations. These edge locations are servers that are located close to your users. When a user requests your content, CloudFront delivers it from the edge location that is closest to them, which reduces latency and improves performance.

As most requests are answered by the edge location (from the cache), this significantly reduces the load on the origin server. The edge location acts as an absorbing agent, preventing requests from reaching the origin server directly, as they only need to pass through the edge location.

Why do you need to have WAF protection enabled for CloudFront distribution?

As discussed above, DDoS attacks rely on "zombies" to attack. Therefore, blocking the requests from IP addresses of zombie machines can help us to stop DDoS attacks.

A web application firewall (WAF) serves as a protective layer in front of web applications, shielding them from common web exploits. WAFs function by inspecting HTTP requests and blocking those that match known attack patterns.

CloudFront has a built-in integration with WAF, which implies that if WAF is enabled for any CloudFront distribution, AWS will automatically create and handle the WAF Rules for you. These rules include the following:

Protect against the most common vulnerabilities found in web applications.
Protect against malicious actors discovering application vulnerabilities.
Block IP addresses from potential threats based on Amazon internal threat intelligence.

After enabling WAF for a CloudFront distribution, it would appear similar to the below image.

How to setup logging for CloudFront?

Before delving into the process of setting up logging, let's first understand why logging is crucial. Logging plays a pivotal role in enabling you to identify the source of an attack, mitigate the attack, and prevent future attacks.

You can easily set up logging with just one click to send your logs to CloudWatch, S3, or Kinesis Data Firehose. Among these options, S3 is the most cost-effective choice.

Bonus

Utilize Athena to query data from any S3 bucket. It is recommended to use separate S3 buckets for different environments as this will enhance Athena's performance.

Conclusion

By delving into the above subtopics, we've gained a comprehensive understanding of DDoS attacks and how CloudFront can fortify your DevSecOps practices. Armed with this knowledge, you're better equipped to protect your applications and infrastructure against potential threats. Stay vigilant, stay informed, and leverage the power of CloudFront to bolster your defenses.