#CISCO ASAV ON AWS CODE#

Important: In the lambda function page, go to the configuration tab (above code source section), in general configuration, edit the default values for memory and timeout. For example, by default the handler is lambda_function.lambda_handler, you can just name your file lambda_function.py If you want to keep it simple, make sure you match the name of the python file with the lambda handler. Note: Make sure you use the correct handler to run the python code, if you have any doubts please follow this article: We will add a new code using boto3 library, this code will move all the routes pointing to the inside interface of the ASAvA to ASAvB once the lambda function is triggered by the CloudWatch event rule (instance state changed), this code will also swap the public EIP's from the outside interfaces of the ASAv's. Scroll down to code source section and remove the default python code there. Now we have the event rule created, we should see it in the lambda function page for the trigger option (Refresh the page otherwise). The target will be the lambda function we just created. Please make sure you specify the ASAvA instance id and enable it at the end. This event will be triggered any time the instance state changes from 'running' to anything else. There are many tools we can use to monitor configuration changes, but are not going to be covered in this article. We need to make sure that configuration are exactly the same in both devices, besides the private IP's over the interfaces, all the rules, NAT's, VPN's, users and versions need to match, so that when our automatic system makes the change, everything will continue flowing across the backup ASAv as a Cisco failover setup. ASAvB configured with inside and outside subnets in us-east-1b.ASAvA configured with inside and outside subnets in us-east-1a.The tools I used to come up with this workaround are the following:įirst we need to obviously have 2 Cisco ASAv instances configured in the same VPC and hopefully with subnets configured in different availability zones, for example: At that point, I didn't know about this limitation and eventually I was between a rock and a hard place, all the same, we are here so that means I discovered a way to implement it. Last year, I was working in a designing/migration project for a client, and we decided to go for the Cisco ASAv's, obviously using 2 per VPC for a highly available environment. There are actually some documents and forums since 2015 asking for solutions, workarounds or alternate implementations, and six long years have passed but there is still nothing documented about it. In order to properly configure Cisco ASAv's failover, we need layer 2 connectivity between instances and that's not possible in the current AWS environments, therefore, this is a limitation all network designers are facing since AWS's day one. If you are reading this, you are maybe wondering if AWS finally added this option for the ASAv's, but unfortunately that's not the case.

Cisco asav on aws