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.
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:
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:
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.