10 minutes reading time

This is the fourth instalment in the series of posts relating to Vodafone’s Mult-access Edge Computing (MEC) and AWS Wavelength zones (WLZ). Here are the previous ones:

Fighting latency on video conferencing with 5G: provides an overview on 5G networks and how it can reduce latency.
Creating and accessing an AWS EC2 instance on AWS Wavelength: shows how to deploy AWS EC2 servers on the edge of Vodafone’s 5G network and benefit of AWS’s compute and storage services.
Deploying an Application to One of Vodafone's AWS Wavelength Zones: details the process to deploy an application to a server on the edge Vodafone’s 5G network.

The objective for this guide is to build up the architecture from past entries and add an AWS Application Load Balancer (ALB) before the application servers and serve traffic through HTTPS. To learn more about ALBs, you can go here.

Change of focus: security vs low latency
Prerequisites
Warning
Final Architecture
Coding
Drum roll!
Summary
Clean up (optional)

Change of focus: security vs low latency

In this article, the focus will switch from low latency and move to the improved security provided by MEC. By utilising WLZs and in turn, Vodafone’s 5G network, developers can be sure that they will have access to, among other benefits, the following:

End-to-end data security: Vodafone’s Edge network ensures that data is processed and stored close to its source, reducing risk of data breaches during transmission.
Regulatory compliance: as the data is processed locally, Vodafone’s Edge network helps businesses comply with data protection regulations, ensuring sensitive information remains within the required geographical boundaries.
Enhanced onsite security: this is provided by dedicated MEC solutions, making it ideal for industries that require stringent security measures.
Isolation and control: because the WLZs are integrated within Vodafone's 5G network, it ensures that the application traffic from 5G devices reaches the servers without leaving the telecommunications network, reducing exposure to external threads and enhancing data privacy.

Prerequisites

To complete this guide, you will need:

A device on Vodafone’s network (a mobile or a computer connected to a Vodafone 5G hotspot, for example).
- Attention: currently, Vodafone’s AWS Wavelength Zones are only available in England and Germany.
- The best way to experience the benefits of Multi Access Edge Computing (MEC) in the UK is by using an IoT SIM card, but a regular Vodafone SIM card will work as well. Information on how to acquire an IoT SIM card can be found here.
An active AWS account.
AWS CLI installed and configured. Here is the official installation/update guide for AWS CLI.
AWS Wavelength Zones are not automatically available and need to be opted in. This guide describes how to do that.

Warning

Not all of the AWS resources utilised during this exercise qualify for AWS’s Free-Tier, so be aware that there will be charges to your account. To reduce costs, it is strongly advised that any EC2 instances not being used are kept in a “STOPPED” state. Using three EC2 instances (two t3.medium at an AWS Wavelength Zone and a t2.micro at eu-central-1), two carrier IPs, one VPC and one Application Load Balancer would generate an approximate cost of 27.56USD per month. This cost is based on certain assumptions and might vary depending on your own usage and needs. A summary of this estimate can be found here. You can learn about pricing assumptions here.
EC2 instances deployed on WLZs have a few constraints. The main ones for this walkthrough are:
1. UDP traffic between the EC2 instance and the internet is not allowed and only outbound and the response is allowed for TCP. Between the EC2 instance and a device on the carrier network, all traffic is allowed.
2. Only the following instance types are supported:
  - t3.medium
  - t3.xlarge
  - r5.2xlarge
  - g4dn.2xlarge
3. EBS volumes must be gp2.
  A full list of the considerations can be found on this link.
AWS Application Load Balancers are only available on the AWS Wavelength Zones located in these AWS regions:
1. us-east-1
2. us-west-2
3. ap-northeast-1
4. eu-central-1
  For Vodafone AWS Wavelength Zone users, this means that the ALB are available only in Germany.

Final Architecture

As mentioned in the introduction, an AWS Application Load Balancer (ALB) will be added to the architecture deployed in the past. A new application server will also be added so the ALB has multiple targets. With these additions the architecture will look like this:

Figure 1: Final architecture

So, let’s get coding.

Coding

As you can gather form figure 1, an additional EC2 instance needs to be deployed, which will be done in a separate subnet as well. Here are the AWS CLI commands to create the new subnet and deploy the new instance:

export REGION=eu-central-1
export AZ=eu-central-1-wl1-dtm-wlz-1

export WL_SUBNET_ID2=$(aws ec2 create-subnet \
    --region $REGION \
    --cidr-block 10.0.0.128/26 \
    --availability-zone $AZ \
    --vpc-id $VPC_ID \
    --output text \
    --query 'Subnet.SubnetId') \
    && echo '\nWL_SUBNET_ID2-'$WL_SUBNET_ID2

aws ec2 associate-route-table \
    --region $REGION \
    --route-table-id $WL_RT \
    --subnet-id $WL_SUBNET_ID2

export APP_CIP_ALLOC_ID2=$(aws ec2 allocate-address \
    --region $REGION \
    --domain vpc \
    --network-border-group $AZ \
    --output text \
    --query 'AllocationId') \
&& echo '\nAPP_CIP_ALLOC_ID2='$APP_CIP_ALLOC_ID2

export APP_ENI_ID2=$(aws ec2 create-network-interface \
    --region $REGION \
    --subnet-id $WL_SUBNET_ID2 \
    --groups $INST_SG_ID \
    --output text \
    --query 'NetworkInterface.NetworkInterfaceId') \
&& echo '\nAPP_ENI_ID2='$APP_ENI_ID2

export ASSOC_ID2=$(aws ec2 associate-address \
    --region $REGION \
    --allocation-id $APP_CIP_ALLOC_ID2 \
    --network-interface-id $APP_ENI_ID2 \
    --output text \
    --query 'AssociationId') \
    && echo '\nASSOC_ID2='$ASSOC_ID2

export INST_ID2=$(aws ec2 run-instances \
    --region $REGION \
    --instance-type t3.medium \
    --network-interface '[{"DeviceIndex":0,"NetworkInterfaceId":"'$APP_ENI_ID2'"}]' \
    --image-id $AMI_ID_LINUX  \
    --key-name $KEY_NAME \
    --block-device-mappings '[{"DeviceName":"/dev/xvda","Ebs":{"Encrypted":false,"DeleteOnTermination":true,"VolumeSize":100,"VolumeType":"gp2"}}]' \
    --output text \
    --query 'Instances[0].InstanceId') \
&& echo '\nINST_ID2='$INST_ID2

Now that there are two instances running, let's get them set up for the ALB by installing Apache and creating a landing page. This is to ensure that when checking for the hosts health, the ALB gets HTTP 200 responses back:

# this will allow to ssh from the bastion server into the application servers without needing to move the key file:
eval "$(ssh-agent)" && ssh-add ./$KEY_NAME.pem

ssh -i ./$KEY_NAME.pem -A ec2-user@$BASTION_IP

# the private IP addresses saved as variables do not transfer to the bastion server, so make sure to make a note of those somewhere; 
#the variable name here is working just as stop gap 

# set up instance 1
ssh $INST_PRIV_IP1

# install apache
sudo dnf install httpd -y

# add an index.html so that the load balancer health checks get a HTTP 200 message back
echo 'this is instance 1' | sudo tee /var/www/html/index.html

# use the below for instance 2
echo 'this is instance 2' | sudo tee /var/www/html/index.html

# set up apache to run on startup and start the service
sudo systemctl enable httpd && sudo systemctl start httpd

exit

# repeat steps above for instance 2

# once complete, exit bastion server to deploy the Application Load Balancer
exit

Now, it's time to deploy the ALB. Notice that it is being created in the WL_SUBNET_ID1, which exists inside a Wavelength Zone.

export aLB_ARN=$(aws elbv2 create-load-balancer \
    --region $REGION \
    --name aLB-aLB  \
    --subnets $WL_SUBNET_ID1 \
    --security-groups $INST_SG_ID \
    --output text \
    --query 'LoadBalancers[0].LoadBalancerArn') \
    && echo '\naLB_ARN='$aLB_ARN

Next, we'll create a target group specifying the same VPC as the EC2 instances and register both application servers with the group. The traffic will be routed internally using HTTP:

export TGT_GRP_ARN=$(aws elbv2 create-target-group \
    --region $REGION \
    --name aLBTargets \
    --protocol HTTP \
    --port 80 \
    --vpc-id $VPC_ID \
    --ip-address-type ipv4 \
    --output text \
    --query 'TargetGroups[0].TargetGroupArn') \
    && echo '\nTGT_GRP_ARN='$TGT_GRP_ARN

aws elbv2 register-targets \
    --region $REGION \
    --target-group-arn $TGT_GRP_ARN  \
    --targets Id=$INST_ID1 Id=$INST_ID2

Finally, an HTTPS listener is needed, which brings additional security benefits such as:

Secure communication: it ensures that the communication between clients and the load balancer is encrypted using SSL/TLS, adding another layer on top of Vodafone's already secured 5G mobile network.
TLS termination: by using an HTTPS listener, the workload of TLS encryption/decryption is offloaded from the backend servers to the load balancers, allowing for improved performance.
Security policies: these can be specified to enforce specific SSL/TLS protocols and ciphers, ensuring compliance with security standards and best practices.

A prerequisite of HTTPS listeners is a SSL certificate, which is associated with the ALB, instead of the individual servers. This is because, per the configuration, the traffic after the ALB is routed to the servers using HTTP. SSL Certificates can be created or imported using AWS Certificate Manager (ACM). More information on how to request or import certificates can be found on the AWS Certificate Manager User Guide.

Here is how to create the listener:

# the $CERT_ID variable contains the id for the certificate managed via ACM
export LTNR_HTTPS_ARN=$(aws elbv2 create-listener \
    --region $REGION \
    --load-balancer-arn $aLB_ARN \
    --protocol HTTPS \
    --port 443  \
    --certificates CertificateArn=$CERT_ID \
    --default-actions Type=forward,TargetGroupArn=$TGT_GRP_ARN \
    --output text \
    --query 'Listeners[0].ListenerArn') \
    && echo '\nLTNR_ARN='$LTNR_HTTPS_ARN

The following command is quite useful as it will only return to the command line once all the targets (two on this case) come back as healthy. Be aware that it might take a few minutes while the health checks take place.

aws elbv2 wait target-in-service \
    --region $REGION \
    --target-group-arn $TGT_GRP_ARN \
    --targets Id=$INST_ID1 Id=$INST_ID2

If more than 10 minutes have gone by and it hasn't returned yet, it means that there might be something wrong with the setup of the listener, load balancer, the servers or security groups.

Once you have access to the command line once again, you should be able to access the servers using the domain name associated with your SSL certificate. As we gave different content for the index.html pages, you can even tell which instance you are landing on.

Drum roll!

Now, using the following command, you can retrieve the ALB’s DNS name and get an URL that can be used to access the instances registered to the ALB:

export ALB_DNS=$(aws elbv2 describe-load-balancers \
    --region $REGION \
    --names aLB-aLB \
    --query 'LoadBalancers[0].DNSName' \
    --output text) && echo 'https://'$ALB_DNS

Just a reminder that the device being used for the test must be connected to Vodafone’s mobile network in the same country as of the $REGION. In this guide’s case, that would be Germany.

Here is an example of how it would look like using a mobile device:

Figure 2: screenshot of mobile accessing ALB’s DNS name

Summary

By adding an AWS Application Load Balancer to our topology and configuring HTTPS, we have now created and deployed a very reliable and secure architecture that allows traffic to be routed safely through Vodafone's mobile network. With environments similar as this one set up, new applications such as summoning self-driving vehicles and delivering content for live events, can be done entirely via Vodafone's 5G infrastructure, ensuring a safe and reliable connection.

By using the Simple Edge Discovery API, available only at Vodafone’s Developer Marketplace (DMP), developers can also ensure that end users are always accessing the closest Edge Computing platform, which provides the best possible experience for them.

Make sure you visit the blog section of DMP and check additional content on Edge, as well as other products. Also, don't forget to register your interest by filling out and submitting the form located here. That ensures you can stay up to date with the latest on Edge Computing capabilities and other APIs offerings. It is also a great way to get in touch with us.

Until next time!

Clean up (optional)

The following commands will remove the elements created for this blog post as well as the previous one in this series:

aws elbv2 delete-listener \
    --region $REGION \
    --listener-arn $LTNR_HTTPS_ARN
aws elbv2 delete-target-group \
    --region $REGION \
    --target-group-arn $TGT_GRP_ARN
aws elbv2 delete-load-balancer \
    --region $REGION \
    --load-balancer-arn $aLB_ARN
# wait until the output changes to "terminate" before cancelling the command moving forward
watch -n 10 aws ec2 terminate-instances \
    --region $REGION \
    --instance-ids $INST_ID2 \
    --output json \
    --query 'TerminatingInstances[*].CurrentState.Name'
aws ec2 delete-network-interface \
    --region $REGION \
    --network-interface-id $APP_ENI_ID2
aws ec2 delete-subnet \
    --region $REGION \
    --subnet-id $WL_SUBNET_ID2
aws ec2 delete-network-interface \
    --region $REGION \
    --network-interface-id $APP_ENI_ID2
aws ec2 delete-subnet \
    --region $REGION \
    --subnet-id $BST_SUBNET_ID
aws ec2 delete-subnet \
    --region $REGION \
    --subnet-id $WL_SUBNET_ID2
aws ec2 delete-route-table \
    --region $REGION \
    --route-table-id $BST_RT
aws ec2 delete-route-table \
    --region $REGION \
    --route-table-id $WL_RT_ID
aws ec2 delete-security-group \
    --region $REGION \
    --group-id $APP_SG_ID
aws ec2 delete-security-group \
    --region $REGION \
    --group-id $BASTION_SG_ID
aws ec2 delete-carrier-gateway \
    --region $REGION \
    --carrier-gateway-id $CAGW_ID > /dev/null 2>&1 && echo "carrier gateway deleted successfully" || echo "failed to delete carrier gateway"
aws ec2 detach-internet-gateway \
    --region $REGION \
    --internet-gateway-id $IGW_ID \
    --vpc-id $VPC_ID
aws ec2 delete-internet-gateway \
    --region $REGION \
    --internet-gateway-id $IGW_ID 
aws ec2 delete-vpc \
    --region $REGION \
    --vpc-id $VPC_ID

Remember that you need to manually release the carrier IP addresses from the URL https://console.aws.amazon.com/ec2. Make sure you are in the correct region!

Enhancing Security on Your MEC Application Deployment

Table of Contents