Increased Cloud Security using AWS Shield,Route 53, Azure DDoS Protection and Google Cloud Armor

Recently glanced few key insights from 'DDoS Security Report' of Q1 2024-it has shared some vital numbers about worldwide impact on cloud security hence this article focuses on key problems in cloud security and how AWS Route 53 helps in preventing such risks.

Cloud Security Challenges

DDoS a.k.a Distributed Denial of Service is a wide known security challenge across cloud deployments in which DNS Flood and SYN Flood are two major types covering 67% of global DDoS vectors according to this recent report:

Affected Regions include IT sector and Internet being top impacted industry across the world:

USA based cloud services are impacted in ~40% of the cases when comparing to rest of the world:

Risk Mitigation via Cloud Security

After specialising in cloud security across Google Cloud and Azure, my focus was to look for cloud security measures in AWS in recent years. Both Amazon Shield and Route 53 got my focus while reading about DNS Flood reports (above).

Route 53

Amazon Route 53, a highly scalable and reliable Domain Name System (DNS) service provided by Amazon Web Services (AWS), offers various routing policies to help manage traffic efficiently.

What is Amazon Shield and Route 53 based protection?

AWS Shield has three important features for DDoS mitigation:

1. Alarms: Triggers an alarm when a DDoS attack is suspected, customized based on metrics such as total volume, error rates at the ALB, and response latency
2. Visibility: Provides top five important field values in real time, such as requesting client IPs, countries, user agents, referrer headers, and url routes to take action.
3. On-call support: Provides on-call support from the Shield Response team (SRT) to understand attack vectors and create AWS WAF rules based on insights.

Let us look at an example of famous B2B service that uses Amazon Shield along with Route 53:

Route 53 Routing Policies help preventing DDoS

1. Simple Routing

Simple routing policy is the most basic and straightforward routing policy. It directs traffic to a single resource, such as an IP address or an AWS resource, such as an Elastic Load Balancer (ELB) or an Amazon S3 bucket. Simple routing is ideal for scenarios where you have a single resource serving all traffic or when you want to perform a basic health check on a resource.

 // Create a Route 53 hosted zone
 hostedZone := awsroute53.NewHostedZone(stack, jsii.String("MyHostedZone"), &awsroute53.HostedZoneProps{
  ZoneName: jsii.String("example.com"),
 })

 // Create A record
 aRecord := awsroute53.NewARecord(stack, jsii.String("ARecord"), &awsroute53.ARecordProps{
  Zone:       hostedZone,
  RecordName: jsii.String("www"),
  Target:     awsroute53.RecordTarget_FromIpAddresses(jsii.String("1.2.3.4"), jsii.String("5.6.7.8")),
 })        

2. Weighted Routing

Weighted routing policy allows you to split traffic between multiple resources based on assigned weights. This enables you to perform A/B testing, gradually roll out updates, or distribute traffic across resources based on capacity or performance. Weighted routing is useful when you want to compare the performance of different versions of your application or gradually introduce new features to a subset of users.

 // Create a hosted zone
 hostedZone := awsroute53.NewHostedZone(stack, jsii.String("MyHostedZone"), &awsroute53.HostedZoneProps{
  ZoneName: jsii.String("example.com"), // Replace with your domain name
 })

 // Create a CNAME record
 awsroute53.NewCnameRecord(stack, jsii.String("MyCnameRecord"), &awsroute53.CnameRecordProps{
  Zone:       hostedZone,
  RecordName: jsii.String("sub.example.com"), // Subdomain
  Weight:     jsii.Number(50),
  DomainName: jsii.String("example.com"),
  Comment:    jsii.String("example cname record"),
 })

 // Create a CNAME record
 awsroute53.NewCnameRecord(stack, jsii.String("MyCnameRecord"), &awsroute53.CnameRecordProps{
  Zone:       hostedZone,
  RecordName: jsii.String("sub.example.com"), // Subdomain
  Weight:     jsii.Number(50),
  DomainName: jsii.String("example.com"),
  Comment:    jsii.String("example cname record"),
  Region:     jsii.String("eu-west-1"),
 })        

3. Latency-Based Routing

Latency-based routing policy directs traffic to the resource with the lowest latency for the end user. Route 53 measures latency between the user’s location and each resource and routes traffic to the resource with the lowest latency. Latency-based routing is beneficial for improving the user experience by directing users to the closest and fastest-performing resource.

4. Failover Routing

Failover routing policy is used to create active-passive failover configurations. Route 53 automatically redirects traffic from an unhealthy or unavailable primary resource to a standby resource. Failover routing is essential for high availability and disaster recovery scenarios, ensuring minimal downtime in the event of resource failures.

 cfnHealthCheck := awsroute53.NewCfnHealthCheck(stack, jsii.String("MyCfnHealthCheck"), &awsroute53.CfnHealthCheckProps{
  HealthCheckConfig: &awsroute53.CfnHealthCheck_HealthCheckConfigProperty{
   Type: jsii.String("type"),

   // the properties below are optional
   AlarmIdentifier: &awsroute53.CfnHealthCheck_AlarmIdentifierProperty{
    Name:   jsii.String("name"),
    Region: jsii.String("region"),
   },
   ChildHealthChecks: &[]*string{
    jsii.String("childHealthChecks"),
   },
   EnableSni:                    jsii.Bool(false),
   FailureThreshold:             jsii.Number(123),
   FullyQualifiedDomainName:     jsii.String("fullyQualifiedDomainName"),
   HealthThreshold:              jsii.Number(123),
   InsufficientDataHealthStatus: jsii.String("insufficientDataHealthStatus"),
   Inverted:                     jsii.Bool(false),
   IpAddress:                    jsii.String("ipAddress"),
   MeasureLatency:               jsii.Bool(false),
   Port:                         jsii.Number(123),
   Regions: &[]*string{
    jsii.String("regions"),
   },
   RequestInterval:   jsii.Number(123),
   ResourcePath:      jsii.String("resourcePath"),
   RoutingControlArn: jsii.String("routingControlArn"),
   SearchString:      jsii.String("searchString"),
  },

  // the properties below are optional
  HealthCheckTags: []interface{}{
   &awsroute53.CfnHealthCheck_HealthCheckTagProperty{
    Key:   jsii.String("key"),
    Value: jsii.String("value"),
   },
  },
 })        

5. Geolocation Routing

Geolocation routing policy allows you to route traffic based on the geographic location of the end user. You can define routing rules to direct traffic to specific resources based on the continent, country, or region from which the request originates. Geolocation routing is useful for serving localized content, complying with data privacy regulations, or restricting access to resources based on geographic boundaries.

 // Create a hosted zone
 hostedZone := awsroute53.NewHostedZone(stack, jsii.String("MyHostedZone"), &awsroute53.HostedZoneProps{
  ZoneName: jsii.String("example.com"), // Replace with your domain name
 })


 // Create a CNAME record
 awsroute53.NewCnameRecord(stack, jsii.String("MyCnameRecord"), &awsroute53.CnameRecordProps{
  Zone:        hostedZone,
  RecordName:  jsii.String("sub.example.com"), // Subdomain
  GeoLocation: awsroute53.GeoLocation_Continent(awsroute53.Continent_EUROPE),
  DomainName:  jsii.String("example.com"),
  Comment:     jsii.String("example cname record"),
  Region:      jsii.String("eu-west-1"),
 })
}

 // continent
 awsroute53.NewARecord(stack, jsii.String("ARecordGeoLocationContinent"), &awsroute53.ARecordProps{
  Zone:        hostedZone,
  Target:      awsroute53.RecordTarget_FromIpAddresses(jsii.String("1.2.3.0"), jsii.String("5.6.7.0")),
  GeoLocation: awsroute53.GeoLocation_Continent(awsroute53.Continent_EUROPE),
 })

 // country
 // country
 awsroute53.NewARecord(stack, jsii.String("ARecordGeoLocationCountry"), &awsroute53.ARecordProps{
  Zone:        hostedZone,
  Target:      awsroute53.RecordTarget_FromIpAddresses(jsii.String("1.2.3.1"), jsii.String("5.6.7.1")),
  GeoLocation: awsroute53.GeoLocation_Country(jsii.String("DE")),
 })

 // subdivision
 // subdivision
 awsroute53.NewARecord(stack, jsii.String("ARecordGeoLocationSubDividion"), &awsroute53.ARecordProps{
  Zone:        hostedZone,
  Target:      awsroute53.RecordTarget_FromIpAddresses(jsii.String("1.2.3.2"), jsii.String("5.6.7.2")),
  GeoLocation: awsroute53.GeoLocation_Subdivision(jsii.String("Subdivision Code"), jsii.String("WA")),
 })

 // default (wildcard record if no specific record is found)
 // default (wildcard record if no specific record is found)
 awsroute53.NewARecord(stack, jsii.String("ARecordGeoLocationDefault"), &awsroute53.ARecordProps{
  Zone:        hostedZone,
  Target:      awsroute53.RecordTarget_FromIpAddresses(jsii.String("1.2.3.3"), jsii.String("5.6.7.3")),
  GeoLocation: awsroute53.GeoLocation_Default(),
 })        

Implementing A/B Testing with Route 53

A/B testing, also known as split testing, involves comparing two or more versions of a web page or application to determine which performs better. Route 53’s weighted routing policy is well-suited for implementing A/B testing. Here’s how you can do it:

1. Create multiple resource records for each version of your application, assigning different weights to each record.
2. Configure Route 53 to distribute traffic based on the assigned weights.
3. Monitor and analyze metrics, such as user engagement, conversion rates, and performance, to determine the effectiveness of each version.

By gradually adjusting the weights assigned to different versions, you can optimize your application based on user feedback and analytics.

Leveraging Geo-Location Routing for Global Reach

Geo-location routing enables you to deliver a localized experience to users based on their geographic location. Here’s how you can leverage geo-location routing with Route 53:

1. Define geolocation-based routing rules to direct users to the nearest or most relevant resources based on their location.
2. Create resource records for each geographic region or country, specifying the corresponding resources for each location.
3. Route 53 automatically directs users to the appropriate resources based on their geographic location, optimizing latency and user experience.

By tailoring content and services to specific geographic regions, you can enhance performance, comply with local regulations, and provide a personalized experience to users worldwide.

Enforcing Geographic Traffic Restrictions with Route 53

Route 53’s geolocation routing policy can also be used to restrict traffic to specific geographic locations while denying access from others. Here’s how to enforce geographic traffic restrictions:

1. Create geolocation routing rules to allow traffic from authorized geographic locations and deny traffic from unauthorized locations.
2. Define resource records for permitted geographic regions, specifying the corresponding resources for each location.
3. Route 53 routes incoming requests based on the configured rules, allowing access only to authorized users while blocking requests from restricted regions.

This approach is useful for enforcing compliance with regulatory requirements, protecting against unauthorized access, and safeguarding sensitive data.

My favourite-Blue Green Deployments

I was fascinated about this model of Blue Green deployments to AWS. It allows you to split the traffic based on different weights assigned. This approach is heavily used in Blue Green Deployments

Blue Green Deployment: You can use this approach while bringing a software product from the final stage of testing to live production. This is also known as the “cut over”. With this approach, it ensures you have two production environments as identical as possible. At any given point you can switch the traffic to one of the endpoints depending on your requirement.

In order to test this approach, you can use the same EC2 instance and the S3 bucket that you have used in the “fail-over” routing policy.

An advantage of this approach is that it's the same basic mechanism as you need to get a hot-standby working. Hence this allows you to test your disaster-recovery procedure on every release.

In comparison with Azure DDoS Protection

Azure DDoS Protection, combined with application design best practices, provides enhanced DDoS mitigation features to defend against DDoS attacks. It's automatically tuned to help protect your specific Azure resources in a virtual network. Protection is simple to enable on any new or existing virtual network, and it requires no application or resource changes.

Azure DDoS Protection protects at layer 3 and layer 4 network layers. For web applications protection at layer 7, you need to add protection at the application layer using a WAF offering. For more information, see Application DDoS protection.

In Comparison with Google Cloud Armor

Use Google Cloud Armor security policies to protect applications running behind a load balancer from distributed denial-of-service (DDoS) and other web-based attacks, whether the applications are deployed on Google Cloud, in a hybrid deployment, or in a multi-cloud architecture.

With Cloud Armor custom rules, you can now create rules with advanced match conditions to filter incoming traffic across a variety of attributes and parameters from Layers 3 through 7.

Geo-based access controls There are times when you may need to limit access to an application to certain countries—whether it is for regulatory compliance, copyright licensing, or another business need.

Pre-configured WAF rules (SQLi & XSS) Google Cloud Armor now includes pre-configured WAF rules to protect applications from the web’s most common attack (e.g. OWASP Top 10 Risks), making it easier for you to configure and operate a web application firewall and meet your compliance and security needs.

Surfacing findings in the Cloud Security Command Center Google Cloud Armor now automatically sends findings to Cloud SCC to alert you to suspicious Layer 7 traffic patterns. Organizations with Cloud SCC enabled will now receive real-time notifications of two events:

1. Allowed Traffic Spike: A sudden increase in the volume of Layer 7 requests being allowed through an existing Google Cloud Armor security policy on a per backend service basis.
2. Increasing Deny Ratio: A sudden increase in the ratio of traffic that is being denied compared to the total traffic targeting a particular backend service.

Together these findings can alert application owners and incident responders of potential Layer?7 attacks while they are still ramping up. With early notice, incident responders can begin to investigate and triage earlier, deploying mitigating controls sooner to protect against an attack before it impacts the availability of your application.?

Summary

There is a great comparison available across top three cloud providers on cloud security but DNS Flood remains a leading challenge to address across cloud security and internet based on recent statistics! Hope this article brought some insights across top three cloud based security strategies.

Sources:

https://aws.amazon.com/blogs/architecture/mitigating-ddos-with-data-science-using-aws-shield-advanced-and-aws-waf/

https://aws.amazon.com/blogs/architecture/mitigating-ddos-with-data-science-using-aws-shield-advanced-and-aws-waf/

https://medium.com/@nagarjun_nagesh/aws-route-53-routing-strategies-and-best-practices-abc23c226af1

https://crishantha.medium.com/aws-route-53-and-routing-policies-b7dc67e74516

https://martinfowler.com/bliki/BlueGreenDeployment.html

https://learn.microsoft.com/en-us/azure/ddos-protection/ddos-protection-overview

https://cloud.google.com/security/products/armor?hl=en#documentation

Disclaimer: Contents, posts and media used in this account of the author do not represent any organisation of any sort. Under no circumstances will the author be held responsible or liable in any way for any claims, loss, expenses or liabilities whatsoever.        

Like this article? Subscribe to Engineering Leadership , Digital Accessibility and Digital Payments Hub to enjoy reading useful articles. Press SHARE and REPOST button to help sharing the content with your network.