AWS Security Intro – 3. Network

Our teams at Boldlink have Architected and Engineered many different network configurations delivering security, high availability, connectivity, and scalability. Let us break down the most common setups for a cloud-native platform.

AWS Shared Responsibility Model

Consider all traffic reaching your Platforms as your responsibility. AWS is responsible for all the infrastructure and API’s security and access available across its Regions and the Network Backbone connecting its Datacenters to the Internet availability, 

Make sure you understand AWS’s SLA’s to determine if you require a multi-region platform to deliver your SLA’s.
https://aws.amazon.com/compute/sla/ 

AWS Route53 is the service allowing you to direct traffic to your AWS platform, either using the AWS domain or your custom public domain.

This service is a Global service not tied to any specific Region making it highly available and integrated with AWS access systems with an API to manage and automate it.

Logs of AWS R53 API calls and DNS are available for monitoring and alerting integrated with Cloudwatch.

All traffic directed to your Platform has AWS Shield Standard enabled filtering your traffic which detects the most common SYN/UDP floods, reflection attacks, etc., this service comes enabled by default at no extra cost for all internet bound traffic.

AWS Advanced Shield enhanced protection guards your applications running on protected Amazon EC2, Elastic Load Balancing (ELB), Amazon CloudFront, AWS Global Accelerator, and Route 53 resources against more sophisticated and more significant attacks 24×7 support.

AWS Web Application Firewall will allow you to filter your traffic at the Application Layer (OSI Layer 7). AWS WAF will block attacks by interpreting the payload content sent to your Platform and stopping more sophisticated attacks from exploiting software vulnerabilities (ex. SQL Injection, XSS etc., or rate-limit traffic) before it reaches your actual Platform. The type of rule combinations is extensive and integrates with Amazon CloudFront; Application Load Balancer (ALB), Amazon API Gateway, and AWS AppSync.

AWS Certificate Manager comes in two “flavours”. The ACM Public and most commonly used feature allows you to create or import valid commercial SSL/TLS certificates that will be used mainly for the encryption in transit of your public traffic and a must for use on AWS Cloudfront; AWS Application Load Balancers or AWS, note that AWS generated certificates for the most cases can be automatically renewed but not the imported certificates.

The Private CA allows you to create your internal Root and Subsidiaries CA’s to use internally with your apps or encryption in transit. A strong use case is the security and automation they provide instead of the manual and cumbersome traditional management of Private CA’s tasks. 

AWS Cloudfront primary function is to handle your traffic workload performance through AWS global Content Distribution Network or CDN web cache and can distribute the traffic to different destinations such as AWS ELB/ALB; AWS Lambda; AWS API Gateway; AWS S3 bucket; MediaStore container; MediaPackage channel; AWS EC2 instance or your HTTP web servers.

AWS Cloudfront can deliver to one or many destinations. It is common to see a single AWS Cloudfront distribution routing traffic to AWS S3 Bucket, API Gateways and ALB’s.

The CDN service is global and allows you to cache your content to speed up your client’s application/site experience and handle large traffic loads for your static or dynamic content. Cloudfront has extensive cache policy capabilities for your dynamic content that can still help you speed up your dynamic content.

AWS Cognito, if your application/API requires authorisation and authentication, AWS Cognito will allow you to use many different integrations and methods to achieve this.

For Applications running in Ec2 and containers on ECS or EKS, AWS Load Balancers can provide you with the necessary traffic distribution and availability management. These also allow you to integrate with AWS Cognito to implement Auth/Auth if required.

AWS API Gateway for routing your serverless or event-driven applications HTTP requests based on the desired rules can also be configured to insert a prompt for Auth/Auth. One of the building blocks for scalable Serverless/Event-Driven architecture.

AWS Lambda, when we speak of Serverless or Event-driven Architecture, you will most likely use AWS API Gateways and Lambda functions together, ex. An HTTP request reaches the API Gateway, it is successfully authenticated by your AWS Cognito User Pool and executes the code on a specific AWS Lambda. This code is only executed when invoked, and you will be charged by the number of invocations and time the code takes to process, making Lambas significantly cost-effective. There are many Security recommendations for AWS Lambda but with a focus on networking, ensure you place Lambda Functions in Private Subnets on your AWS VPC and don’t allow anonymous code execution through API Gw unless it is the intended design.

AWS ALB ELB & NLB are used to distribute traffic on your platform containers or EC2 instances. It comes in two main categories: Public Load Balancers, as the name implies, are accessible from the internet, and a public range of IPs is assigned. Public-facing Load Balancers are placed on Public Subnets in your VPC, and, with no surprise, Internal or Private Load Balancers will be positioned on your private subnets.

AWS as provided the three types of Load Balancers, classic; application and network, our take on them from a pure network standpoint:

• Application Load Balancers are ideal for most HTTP/HTTPS applications, but the SSL/TLS termination ends on the ALB, not the Ec2/container instance. You can change this default behaviour with private/self-signed SSL/TLS certificates at the instance duplicating the nr of certificates you will require and maintain.
• Classic Load Balancers can terminate the SSL/TLS traffic at the destination (Ec2/container) but are legacy Load Balancers. Still widely used but lacking in the ALB or NLB functionality, this Load Balancer will not support path routing or SSL/TLS SNI more recent certificates functionalities out of the box.
• Network Load Balancer is used for any traffic other than HTTP/HTTPS, ex. you have a database with a specific port. Bear in mind that NLB operates as the ALB when it comes to SSL/TLS.
• About SSL/TLS, all certificates must be available on AWS ACM; if you generate them or import them doesn’t matter, they must be there to be configured on your Load Balancer.
• Load Balancers are created on your AWS VPC Network and configured by you to your specifications but managed by AWS.
• Load Balancers are region-centric. If you have platforms across different regions, you will have multiple Load Balancers per region.

All Boldlink clients' solutions using Containers or Ec2 most likely will require a load balancer. We have found AWS Load Balancers always delivered the requirements for all the needs and eliminated a large chunk of technical Debt and operational overhead.

AWS Virtual Private Cloud (VPC) is the centrepiece of your AWS network, you must get it right, which means configuring using it right, otherwise, you will expose your platforms and data to your detriment, some of our recommendations:

• Always use a minimum of 3+ pairs of subnets, one per each Availability Zone, this is the minimum to create highly available platforms.
• On Public Subnets, use them for your Load Balancers, VPN/Bastion endpoints, or, any other endpoint which must be accessed directly from the internet.
• Private subnets can be of two types, with or without outgoing access to the internet. 
  • For Private Subnets with outbound internet access, they are for Platforms that require access to download only or are behind a public endpoint, for example, AWS Eks Ec2 Nodes, or an Ec2 instance behind an ALB, by default access to AWS API’s is done using the public endpoints so Platforms will be able to access these here or through VPC Private Link. 
  • Your Private Subnets without internet access is ideal for Platforms that require higher levels of isolation, ex. PCI/DSS environments AWS RDS Database/Cluster, the public endpoints of all AWS services will be unavailable, and that is why you can access them through AWS VPC PrivateLink.
• AWS API Services endpoints by default are public, but this presented limitations from a security and networking perspective. As an alternative, AWS provides AWS VPC PrivateLink allowing access to many AWS services even if your systems are completely isolated from the internet, ex, AWS S3 private link or an endpoint on another VPC in a different region. You should enable them on your VPC’s independently if your VPC has or does not have Internet connectivity.
• Enable VPC Flow Logs, and these will be useful to troubleshoot networking or extend your platform's Observability.
• Encrypt your traffic end-to-end, and understand that the physical AWS infrastructure is shared with all their customers and isolated through software, not hardware. You cannot trust it. You have to ensure traffic from your client through the load balancers to your backend is encrypted, with no exceptions.

Networking is extensive and specific to your solution and needs, we hope to have the chance to discuss it with you more in detail, while here we stick to generalisations we hope are helpful.

Take a peek at our AWS Shared Responsibility Model in the article below.