VS Automation

Success story

Use case overview

Airbus has a large information system composed of a broad range of devices. Given the recent evolution of the automation landscape, the company has decided to embrace this culture to heavily transform its use of technology.

This use case focuses on the automation of a fleet of F5 BIG-IP application delivery controllers, with automatic configuration of the VSs (Virtual Servers) used to represent the applications living behind these traffic managers.

Rather than relying on fully manual creations, updates and deletions of VSs to operate large-scale changes across the fleet, the objective is to automate the process as much as possible by starting from the creation of a ticket in Airbus' ITSM solution to the actual interaction with the devices.

Another constraint to consider is the complexity of the Airbus information system. As the company needs to operate with tight security protocols and clear compliance rules, the solution needs to integrate gracefully within the scope of what's considered as internal best practices.

Business pain & challenges

Manual operations
Lack of integration with ITSM tools

Tech stack


  • API Gateway - Entry point to the automation system
  • Step Functions - Orchestrate the workflow between decoupled tasks
  • Lambda - Serverless runners for the various tasks
  • SNS - Used to notify the relevant teams of the status of each execution
  • SSM Parameter Store - Used for various purposes, including storing credentials for authentication to HashiCorp Vault, as well as for the implementation of a global semaphore.
  • Cognito - Used for authentication purposes on the API


  • Python - Main scripting language for the various Lambda functions
  • Serverless - Framework for deploying serverless workloads


  • HashiCorp Vault - Secure storage for secrets
  • F5 - Application delivery controllers for traffic management



Taking advantage of the serverless services provided by AWS made perfect sense for multiple reasons. Airbus is already a large customer of the platform and has oriented its technical direction towards the Cloud.

AWS Lambda seemed like an ideal candidate because of the ease of deployment and the expected workload that doesn't need to be running 24/7 on self-managed instances. Another selling point was that Step Functions could be leveraged as well, to represent the different steps of the process in a managed state machine. AWS API Gateway is used for interfacing with the state machines and Lambda functions.

F5’s Application Services 3 Extension (AS3) is used in order to apply the Infrastructure as Code approach to the fleet of traffic management devices.

High Level Overview

The solution consists of one main Step Function, which is orchestrating the main VS Automation process, as well as a few auxiliary Step Functions that serve supplementary functions.

VS Automation Step Function

The VS Automation Step Function handles requests for creation/update/deletion of F5 BIG-IP VSs. A request is submitted through Airbus’ ITSM solution, which triggers the VS Automation. Lambda functions that are part of this Step Function are responsible for manipulating the configurations, storing them in SCM and pushing them to the F5 BIG-IP devices. It is also responsible for communicating with various APIs in order to retrieve all the necessary information for the manipulation of the configurations.

High-Level diagram of the main Step Function

Drift Detection Step Function

The VS Automation project applies the Infrastructure as Code approach to configuration management on Airbus’s F5 traffic managers. As a direct consequence of applying that approach, the VS Automation must have a single source of truth. The SCM repository acts as that single source of truth. This means that configuration changes to VSs managed by the VS Automation must be exclusively made in the configurations (manifests) stored in that repository, and are then pushed to the respective traffic managers.

Any manual changes to configuration directly on the F5 traffic manager would result in inconsistency between the single source of truth and the actual configuration on the F5 devices. Since this would be highly undesirable, the Drift Detection Step Function acts as a countermeasure against source-of-truth inconsistencies, and specifically as a way of detecting drift. The Drift Detection process is run regularly (at a scheduled interval) and pushes all configurations to their relevant F5 device with the AS3 DryRun operation and detects differences between the configuration (as sourced from the SCM) and the configuration running on the F5. Any such changes are then reported via email, so that the necessary actions are taken by the responsible team to remedy the inconsistency.

High-Level diagram of the Drift Detection Step Function

Results & highlights

Uses managed AWS services, no infrastructure maintenance is required.
Integrates with the customer’s ITSM solution.
Integration with the customer’s IPAM/CDMB solution
Deploys automation over a fleet of application delivery controllers, covering thousands of Virtual Servers.
Very cost effective solution, as it uses managed AWS services and keeps the bill under a few dollars per month.