Categories
AWS Featured Networking

AWS Global Accelerator

Global Accelerator is a fully managed network traffic manager. Global Accelerator is a network layer service in which you create accelerators to improve availability and performance for internet applications used by a global audience. This network layer service is for a global customer using the Amazon network backend. As per Amazon documentation, customers have seen 60% network improvement while using this Global accelerator.

Global Accelerator provides “anycast” public IP from Amazon pool or you can provide one. With this static entry point, you will improve the availability and reliability of your application. Global Accelerator improves performance for all applications over TCP and UDP protocols by proxying packets at the edge. Accelerator ingress traffic to AWS closest to the end-user resulting in better performance.

Global Accelerator helps to create “Robust architecture“. It will help to increase network stability by using the AWS backend network. It provides health checking-based routing.

Traffic routing

Accelerator routes traffic to optimal AWS endpoint based on –

  • Endpoint Health (For Disaster recovery solution)
  • Client Location(Geo fencing)
  • User-configured weights(For active/active or active/passive) applications.

Endpoint Configuration

The accelerator can use a TCP/UDP-based protocol. It will use the following endpoint –

  • Application Load balancer
  • Network Load balancer
  • Elastic IP address

Use Cases

  • Gaming Industry (Use NLB instread of ALB)
  • IoT based data collection
  • Disaster recovery(Fast regional failover)
  • Voice over IP

Architecture for Disaster Recovery

I am using Global Accelerator for Disaster Recovery configuration. The same configuration can be used for Active/Active inter-regional application configuration.

The user will connect to Global Accelerator DNS address. Route 53 can easily be used for custom website links. Create DNS “A” record pointing to AWS Global Accelerator “Anycast” IP address. AWS global accelerator will transfer data user to appropriate Load balancer. In this blog, I am mainly focusing on the usage of AWS global accelerator, After ALB, you can create tiered software architecture. Take a look at my other Three-tier architecture blog for more details.

Source Code

If you like to have source code email me at info@cloudtechsavvy.com

Demonstration

I am using terraform to deploy my infrastructure. Following are the resources that will be deployed using terraform –

  • Working in two different region – “us-west-2(primary)” and “us-east-1(DR/secondary)”
  • Global Acceleretor with two endpoint each targeted to ALB of that region. Traffic distributed equally.
  • Application Load balancer (ALB) one at each region. Target group points to EC2.
  • Two EC2 instance with Apache installed on it. They will act as web/app server for my application. In production environment, auto-scaling will be used for better Elasticity.
  • one VPC per region
  • Two subnet per region in different AZ
  • Security group, Internet gateway, Route table, IAM role for instance profile etc.

Output from Terraform. This will create 46 resources total.

  • application_dns_name : Point this address to route 53 “A” record for customer website link
  • accelerator_static_ip_sets : anycast ip address
  • lb_dns_name : Load balaner IP for region 1
  • lb_dns_name_east : Load balaner IP for region 2
  • region1 : Region 1
  • region2_dr : Region 2
  • vpc_cidr : VPC CIDR Region 1
  • vpc_cidr_dr : VPC CIDR Region 2

I am pointing to “Application_dns_name” link that generated from terraform output. My webserver is connected to “us-west-2” region than “us-east-1” because “us-west-2” region is closed to me.

I am from Seattle so, I will point to “us-west-2b” region by default not “us-east-1”

Both Availability zones are used in nearly round-robin way.

The website will use both availability zone. Now request is coming from a different AZ.

AWS global accelerator instance is created with two static anycast IP address. You can point “Rote 53” to both IP addresses for redundancy.

Configured TCP port 80 listeners. That means this accelerator will listen on port 80. You can use licentner on any port with TCP and UDP protocol.

The endpoint group is per region. I have configured two regions one for “us-east-1” and “us-west-2”. Traffic dial determines how my load is distributed across regions.

For active/active configuration : use weight at same @ 100.

For Disaster recovery or “active/passive” configuration: use the first region as 100% and DR region uses 0%. Then DR region will not accept any traffic until the primary region is down.

Each endpoint is grouped together with different endpoints. One can use NLB, ALB, or Elastic IP endpoint as different endoiint. Weight will be defined as a priority. In my case, I am pointing my request to ALB. Those ALB intern transfer request to EC2 instance for web application. Both group are pointed to its own ALB from a its region.

Disaster Simulation

To simulate disaster in a region, I am deleting my ALB from “us-west-2” region(which is closest to me).

After deleting I am ALB, I am not able to access the website momentarily.

Endpoint configuration detected that “us-west-2” endpoint is unhealthy.

I have constantly, set my ping to “anycast” IP address. I am still able to get a response. Since I cant simulate region failover, I cant test anycast IP availability.

After “Ten Sec“, My website was redirected to the east region. Unfortunately, this could be better but I have not tested very well.

RPO = 10 sec

RTO will be different for different customers.

Both AZs are taking part into website service. In case of disaster recovery, you may just need one AZ.

Fallback

To simulate AWS region recovery, I am running my terraform environment again. This will create ALB and request listeners.

Accelerator was able to detect that “us-west-2” region Endpoint become healthy again.

My new traffic is diverted back to “us-west-2” region

Both DR Region failover and fallback worked successfully.

Conclusion

I am very impressed with the way the global accelerator worked. The multi-region complication was reduced. Failover and Failback were seamless. If you have a multi-region database like “AWS Aurora” this will be a very great option to reduce “RPO” and increase redundancy. This will definitely increase the user experience.

The next Step, for me to do testing on performance and user experience features for AWS Global Accelerator.

Categories
Application AWS Database Featured Terraform

Three Tier Architecture with AWS

In this story, I am planning to create three-tier architecture with the help of AWS resources. First-tier Load Balancer, Second tier(webserver) considered as application logic and last tier Database. I am using Dynamodb for the NoSQL database.

Architecture

An auto-scaling group is created with a minimum of 2 instances. ASG has two subnets both in a different availability zone. This auto-scaling group will be used as a target group for application Load Balancer. In my configuration, instances are not reached directly via there public address over port 80 will only application load balancer will be forwarding a request to EC2 instance. Session get terminated at the application load balancer.

Two buckets are needed, the first S3 bucket used to store userdata and AWS Dynamodb script in S3. The second bucket will be used for ALB to store logs. IAM roles.

Configuration list

  • data.aws_ssm_parameter.s3bucket: S3 bucket information to storage scripts
  • aws_vpc.app_vpc: VPC for environment
  • aws_eip.lb_eip: Elastic IP address for Load balancer
  • aws_iam_role.app_s3_dynamodb_access_role: Role for EC2 instnace profile
  • data.aws_availability_zones.azs: To get list of all availability zones
  • data.aws_ssm_parameter.accesslogbucket: S3 bucketname to storage ALB logs
  • aws_dynamodb_table.app-dynamodb-table: Dynamoddb Table resource
  • aws_iam_role_policy.app_s3_dynamodb_access_role_policy: Policy to attach on role “app_s3_dynamodb_access_role”. Dynamodb full access is granted please grant appropriate access for your application need
  • aws_iam_instance_profile.app_instance_profile: EC2 instance profile to access S3 storage and Dynamodb table
  • aws_subnet.app_subnets: Multiple subnets are created with VPC per Availability zone in region
  • aws_lb_target_group.app-lb-tg: Target group for ALB
  • aws_security_group.app_sg_allow_public: Security group for LB. Port 80 open from all world.
  • aws_internet_gateway.app_ig: Internet gateway
  • aws_lb.app-lb: Application load balancer
  • app_s3_dynamodb_access_role : To access Dynamodb and S3 account from Lambda function
  • aws_route_table.app_rt: Route table
  • aws_security_group.app_sg_allow_localip: Security group to allow ssh access from “localip” from variables file and ALB to access EC2 instance over port 80
  • aws_instance.app-web: This is template instance will be used for AMI creation used for Launch configuration and Autoscaling group (ASG)
  • aws_lb_listener.app-lb_listner: ALB Listner for healthcheck
  • aws_ami_from_instance.app-ami: AMI resource will create ami from “app-web” instance. Will use this ami to create launch configuration.
  • aws_launch_configuration.app-launch-config: EC2 instnace launch configuration used to create Autoscalling group.
  • aws_autoscaling_group.app-asg: Autoscaling group used create two instance in different availability zone. ALB will send request on these ASG.

Source code

Please download source code from my GitHub Repo —

https://github.com/yogeshagrawal11/cloud/tree/master/aws/3%20Tier%20app

  • aws-userdata-script.sh : This will will run during userdata is executed. File will get information list instance-id, Publicip, lcoal ip and Availability zone name from metadata server and copy that to “/var/www/html/index.html” file.
  • nps_parks.csv : Is input file to copy data from S3 and add into dynamodb table
  • dynamodb.py : file used above input file and create new table and insert a record into the table. This table now used to sorting and output is store again in “/var/www/html/index.html” for future view. Objecting is to ensure instances from different availability zones able to comminited to Database our 3rd layer.
  • user_data.tpl : Userdata template file used by terraform
  • terraform.tfvars : Terraform varible file
  • main.tf : Terraform program file

PS. I don’t want to use this story to create a full-blown application.

Prerequisites

Download all files from the Github repository.

Download “terraform” software and copy at same downloaded location

Create S3 bucket to store scripts. Create “userdata” directory in bucket toplevel and upload “aws-userdata-script.sh”, “nps_parks.csv” and “dynamodb.py” file at that location. script “EC2 instance will copy these script using user-data template file.

Create key pair for EC2 instance.

Create the following parameter —

accesslogbucket : <buckname for ALB logs> You can use same bucket name as userdata.

ec2_keyname : <Key pair name>

s3bucket : s3://<bucketname>. Please ensure to prefix “s3://” before bucket name in value parameter.

Image for post
image -2

Configuration Output

Starting running terraform template you will see below output

The output is the Load balancer output link. You can add this output to DNS records for future access. For this exercise, we will use this address directly to access our application.

Image for post
image -3

Load balancer configuration. DNS name to access your ALB endpoint. VPc, Availability zone, and security group configuration. The public security group will be used to get traffic from world to ALB on port 80. image-5 has information about S3 location where ALB will going to save logs.

Image for post
image — 4
Image for post
image — 5

ALB target group configuration and health check details. Healthcheck is performed on “/” parent page. This can be changed as per different application endpoints. Image-7 has information about instances registered to the target group via the Autoscaling group.

Image for post
image — 6
Image for post
image — 7

I am first creating a sample instance “ya-web”. Using this application to create “golden-ami”. This AMI is been used for launch configuration and to create the Autoscaling Group(ASG). Normally golden AMI already created. That AMI information can be inputted as a variable in “terraform.tfvars” files. image — 9 is the Autoscaling group configuration. Minimum/maximum capacity can be altered as part of input as well.

Image for post
image — 8
Image for post
image — 9

Instance information. “ya-web” is a template vm. Other two vis are part of autoscaling group.

Image for post
image — 10

Accessing application with a Load Balancer. LB transferred the request to the first instance in AZ “us-west-2a”. Instance able to pull data from DynamoDB using boto API and because of instance profile, we created in our resource file. The image-12 request is transferred to a 2nd instance for different AZ “us-west-2b”. I am using stickiness for 20sec. This can be managed via cookies as well. My idea of the application is make it a simple kind of “hello world” application to get the bare minimum configuration.

Image for post
ALB transferring request to First instance, image-11
Image for post
ALB transferring request to First instance, image-12

Instance public IPs are not able to access from outside world(image — 13). Only ssh and ping(icmp) are allowed from localip defined variables file.

Image for post
image-13(a)
Image for post
image — 13(b)

Disclaimer

Network security and Identity security needed to be improved for production use.