Vegeta Attack and Azure Container Instance
Published Oct 07 2020 07:46 AM 5,830 Views
Brass Contributor


This is common mistake and observation. Most of the time customers ignore Load testing for their web based applications keeping too much trust on cloud scale infrastructure and services. It is good to trust on cloud scale model however not every application problem can be solved by just scaling underlying cloud infrastructure to support growing volume.


Cloud scalability should be entrusted with proper testing framework for your application and this is where “load testing” performs an important role. Load testing is really important to understand “how your application is performing under the expected load, unexpected load, sudden spiked load”.


While working with few of the big organizations in recent times I have observed “Load testing” has been made too much of a complex thing to achieve. In reality it is simple if you do it in part and test individual components of the system. Most critical part of the today’s software systems is API layer.


In this post we will see how an Open Source Tool “Vegeta” combined with power of Azure Container Instance can help you to test your individual APIs or web app.


Let’s attack!


What is Vegeta?

Vegeta is a versatile HTTP load testing tool built out of a need to drill HTTP services with a constant request rate. It can be used both as a command line utility and a library.



It is written in Go language!


Vegeta seems to be quite popular and very active in OSS community. Github stars speak for itself! This tool have got stunning 15.5K github stars as of writing. That is impressive!


The usage manual is on Github and official docker image is also present here - Vegeta Docker Official Image


Why Azure Container Instance for load testing?

Most of the load testing tools I have seen uses VM based solution, or Kubernetes based solution in today’s world. Ideally load test may not be required to run 24x7x365. It is momentary to test the system and you will always want your infra to shutdown/ removed after testing is done. This is where Azure container instance fits perfectly. Below are few more benefits I see -

  1. When you use VM, some part of compute [cores] and memory [RAM] is still used with VM functioning [OS operations] and you don’t get full capacity of underlying VM for load testing. With container instance if you assign 1 core 2GB memory then complete capacity is used only for load testing.
  2. While you can automate VM shutdown/ start etc. if it is missed then cost is still incurred. Container instance is charged per second and as soon as it is terminated there is no charge. This makes very cost effective solution for incremental load testing.


Single URL testing with Vegeta and Azure Container Instance

Go to Azure portal and provision the Azure container Instance. Make sure you specify the docker URL of Vegeta as sown below –


Create Vegeta - specify vegeta docker imageCreate Vegeta - specify vegeta docker image


Keep the default setting on networking tab and move to Advanced tab. On the advanced tab we have an option to specify first commands to execute in container. The main purpose of this option is to provide defaults to an executing container.


This is more of docker feature than container instance.

This is where we will provide below command to start the Vegeta Attack to URL of our choice.




"sh", "-c", "echo 'GET' | vegeta attack -duration=10s -rate=10 | tee results.bin | vegeta report"




In above command we are hitting my personal blog for continuous 10 seconds, with 10 requests per second. storing the result in results.bin file.

Go ahead and create the container instance. Refer to screenshot below for command view –


Specify Vegeta command in advanced tabSpecify Vegeta command in advanced tab


The container is created and terminated after 10 seconds of execution. If we click on Log as directly see the output of results.bin file as shown below –


Vegeta output on shellVegeta output on shell


Important aspect to record from this load test result is min latency as 43.351 ms and max latency recorded was The total success rate is 100%. Means all the requests that were sent for testing all of them were successful. Similarly status code is 200. This is where you can see how many request were successful and how many of them were non 200. Also if any error is generated then error text is shown at the bottom. In our case there is no error received.


Need less to say, you are charged only for duration of 10 seconds along with CPU and memory consumed. Pretty cool!


Vegeta attack output in JSON on container instance

The above output we received in shell. Most of the time you may want to receive the output in JSON to consume into some other reporting systems. You can output the Vegeta attack in JSON as follows –




"sh", "-c", "echo 'GET' | vegeta attack -duration=10s -rate=10 | tee results.bin | vegeta report -type=json"




Vegeta json outputVegeta json output


Vegeta Attack, and authentication header on container instance

Vegeta attack can also be used to load test APIs which require an authentication token. Refer to below command that can be used with Azure container instance to load test APIS with authentication header –




"sh", "-c", "echo 'GET' | vegeta attack -header "authorization: Bearer <your-token-here>" -duration=10s -rate=10  | tee results.bin | vegeta report"




Use case

You have an api hosted behind Azure API management. You want to perform load test for your Azure API Management link which required subscription key in the header. This is where we can use Authentication header based Vegeta attack as below –




"sh", "-c", "echo 'GET' | vegeta attack -header " Ocp-Apim-Subscription-Key: <your-Azure API-Management-subscription-key-here>" -duration=10s -rate=10  | tee results.bin | vegeta report"




Similarly this can be used for load testing with Azure API Management configured with “Validate JWT” policy.



Vegeta attack with Azure Container instance is the most flexible way of load testing in my opinion. Above post just demonstrate the same. Hope you find this useful.


Version history
Last update:
‎Oct 13 2020 02:14 AM
Updated by: