Earlier today we announced that the Barracuda Email Security Gateway (BESG) is available as a product in the Amazon Web Services (AWS) Marketplace. This is pretty cool for a handful of reasons. Amazon can now offer our best-of-breed Barracuda Email Security Gateway to their security offerings, and Barracuda can celebrate the expansion of our security suite in the Amazon cloud. Most importantly, customers can migrate their email security to AWS with confidence, because Barracuda and Amazon are working together to provide a secure and reliable infrastructure.
This isn’t our first product to be added to the AWS Marketplace. The Barracuda NG Firewall and Barracuda Web Application Firewall are both available under hourly and Bring Your Own License options, and SignNow is available through the marketplace as well. The Barracuda product teams have been working hard to make sure that our products are available wherever our customers want to go, and this is no small task for them. I asked Blair Hankins to give me a rundown on what it takes to prepare a product for the AWS Marketplace. I’m not going to lie to you: this hurt my head.
It all starts with an existing virtual product (Vx), such as the Barracuda Email Security Gateway, Barracuda NG Firewall, and the Barracuda Web Application Firewall. We take the virtual appliance and use that to create two Amazon Machine Images (AMIs). These AMIs are necessary for the two licensing options in the AWS Marketplace:
- BYOL (Bring Your own License) AMI: The customer acquires a license token from Barracuda or reseller and uses that license to provision the image they locate in the Marketplace.
- Hourly AMI: The customer launches the AMI directly from the Marketplace and Amazon charges for both Barracuda software usage and their resources to run the instance in AWS
We’ll get back to that licensing stuff in a minute.
There are a bunch of other tasks that need to be performed on each AMI, but we’ll stick to the big stuff that takes place in order to make these AMIs ready for the AWS Marketplace. We’ll run through all of them, but first let’s look at the two things that will probably stand out to the experienced Barracuda admin.
Since there is no support for console access in an AWS Marketplace product, we implement a pre-boot user interface in the AMI. This allows the customer to enter the license token for the Bring Your Own License deployment. Customers who are used to a physical or virtual Barracuda appliance will find this to be a little different, but the interface is similar and still easy to navigate. Customers who use the hourly option for Barracuda products will not see this step.
The AMIs are configured to use DHCP for IP assignment. Normally these appliances are set to use a manually assigned IP, but the Amazon cloud requires DHCP in this case. Once the AMI is running, the customer can associate an AWS elastic IP with the appliance. This is similar to setting the IP manually at startup. Customers still maintain control over the IP assignment, but first have to boot to DHCP.
These two changes as well as a handful of cosmetic changes are the ones that the customers can see. There are still a lot of things going on in the background that were put there specifically for AWS.
Let’s start with the Hourly AMI that we mentioned earlier. Because this is an hourly service, there is no requirement to purchase a license from Barracuda and enter the information on pre-boot. This means that the engineers provide “silent provisioning,” which is a mechanism that allows customers to launch and provision the device entirely from the AWS Marketplace, with no interaction with Barracuda licensing. This allows customers to run an On-Demand Instance (ODI) of our products through AWS. ODIs allow customers to pay for what they need on an hourly basis, so there is no long term commitment and no need to buy extra capacity for planning purposes. The option for On-Demand Instance is an important feature in the AWS Marketplace and in the Barracuda security suite in AWS.
The next few things get a little technical. Barracuda appliances run a custom kernel developed in-house by our engineering team. This kernel has to be tuned to support Xen paravirtualization required by AWS. This paravirtualization differs from full virtualization in that there is another virtualization layer between the hardware and the VMI. This provides increased efficiencies and scalability to the VMI.
The engineers also change the file partition layout in order to support PV-GRUB. AWS uses PV-GRUB as the boot manager due to its support for paravirtual environments. AWS offers more information on PV-GRUB here.
The AMIs are built on the Amazon Elastic Block Storage (EBS), which is the block level storage system used by AWS. Our custom-built AMIs are engineered to scale along with the Amazon EBS volumes, which replicate as needed in order to provide high availability. One of the benefits of moving to a public cloud is the consistency in performance. Amazon EBS and Barracuda Amazon Machine Images give you the reliable performance that you require from your infrastructure.
All of these engineering changes are designed to complement each other and leverage the advantages of the AWS infrastructure. None of this would happen without tons of quality assurance checks and testing by our engineers. Amazon then steps in with their own quality checks and other requirements. As you can see, one does not simply put a virtual machine into the AWS Marketplace. It’s a big deal.
If you would like more information on the Barracuda Email Security Gateway on AWS, visit our Barracuda on Amazon Web Services Marketplace page. For more information on the Barracuda Email Security Gateway, you can visit these resources:
- Barracuda Email Security Gateway product page
- Barracuda Technical Library – product documentation
- Live demo
- Product blogs
- Customer testimonial video