A Primer On F5 AWS CloudFormation Templates
If there was a magic button for application deployment we'd all use it. For those of us in the real world we use templates. AWS CloudFormation Templates (CFT) serve as a guide for creating and deploying resources into your ecosystem. Please key in on the word template. As with any other guide, you provide the additional details to graduate a template into a functional and living configuration. F5 provides several supported CFTs to accommodate BIG-IP and BIG-IQ deployment scenarios. Multiple interfaces, disaster recovery options, and VPC design flexibilities provide a lot of options to digest. And with options comes questions and potential complexity. We'll discuss the CFTs offered and how they can add benefit without extending complexity to you and your team. On Choosing Templates It seems initially easier to take an on-premises design and apply it to your cloud migration strategy. Don't. This is the time to reevaluate architectural decisions made over the years and it's also the time to evaluate how each cloud provider offers infrastructure. AWS provides a familiar network-centric model compartmentalized within virtual private networks (VPC). Taking advantage of these cloud methodologies may sway architectural decisions a little. You may even find starting over is quicker than shoe-horning in legacy designs. Regardless of your application and architecture needs, we probably have a templateto help along your deployments. F5 AWS CloudFormation Templates are available at F5's Github page and are grouped by availability model, followed by NIC count, and lastly licensing model. The master readme file within the AWS CloudFormation Template repository provides ample documentation to help you chose. We have two preliminary CFT branches for the adventurous; supported and experimental. Supported - If you're new to AWS CloudFormation Templates, start here. With a bit of tweaking you can get BIG-IP up and running in no time. You'll supply your environment variables or you can use the templates to walk through the EC2 options during BIG-IP deployment. It's your call. They're easy to integrate into your architecture designs and you can contact support with questions. Win win. Experimental - There's no support and they're work's in progress but for the hardened CloudFormation Alchemist, you can turn our works-in-progress into your gold. These are for people curious what were working on and ok experimenting themselves with different deployment options. On Availability Models Understanding how each cloud provider offers redundant infrastructure should be reflected in your cloud design. Amazon AWS offers availability zones within a specific regions to provide redundancy. In an AWS Virtual Private Cloud (VPC), a subnet may only resides within a single availability zone so if you need hardware and site redundancy you must to configure multiple subnets deployed against different availability zones. F5 provides several availability models depending on what your needs. Our AWS CFTs provide guidance for: Standalone - In relation to BIG-IP in a disaster recovery environment, Standalone denotes running BIG-IP with no secondary device to receive traffic in the event of a system, EC2 virtual machine, or availability zone failure. System outages or network issues would create a potential service disruption. But you play fast and loose so you're not worried right...? Failover Models Layer 2 access isn't available in AWS (or any major cloud provider technically) so we cannot rely on our good ol' gratuitous ARP for failover communication. Instead we rely on AWS API calls to migrate the public elastic IP across private IPs;between active and standby BIG-IP instances. Using API services instead of L2does create multi-second delays for traffic failover but most cloud applications are much more session resilient than their on-premises counterparts. There are two primary types of active-passive failover models. Same-Net - BIG-IP is deployed within the same subnet. This offers redundancy for the BIG-IP systems from any software issues or AMI instance failures. Because both BIG-IPs are deployed on the same subnet, you're in the same availability zone and still at risk if the zone experiences a failure. Across-Net - BIG-IP is deployed across subnets and thusly can be deployed across multiple availability zones. This provides BIG-IP redundancy in the event of an availability zone failure. Providing failover redundancy for BIG-IP devices requires two or more interfaces. Single interface config sync across availability zones provides configuration changes across devices but does not facilitate the API-based traffic failover in the event of a failure. For more information on this read Amazon Web Services: Single NIC config sync across Availability Zones. Autoscale BIG-IP can autoscale within AWS to mirror application traffic fluctuations. F5 autoscales viaBIG-IQ (using Per-App VE), via BIG-IP DNS, or by using AWS Elastic Load Balancer (ELB). Since we're talking about templates, we'll focus on the CFTs offering Autoscale via BIG-IP DNS and via ELB. Via DNS - Autoscaling BIG-IP using DNS is done with BIG-IP DNS (formerly BIG-IP GTM). BIG-IP DNS can talk natively to globally deployed BIG-IP instances through an XML protocol called iQuery to provide multiple traffic failover methodologies going beyond basic connection thresholds or DNS round robin load balancing. For this to work, the BIG-IP management interfaces must be able to communicate over publicly routable networks. This connection can be secured with firewall/VPC ACLs and VPC security groups. Via ELB - Using Amazon's native Elastic Load Balancer configuration, BIG-IP's are deployed into a AWS Auto Scaling Group. As BIG-IP's are dynamically deployed, ELB services discover them and add them to the pool. You'll need to use hourly licensing for BIG-IP in this scenario as you'll not be able to manually license automaticallyspun up and torn down BIG-IPs. Each BIG-IP is deployed as a standalone system responsible only for it's own traffic and does not communicate with other BIG-IP systems. If an instance is taken offline, AWS ELB services will redistribute the connections to other online BIG-IP defined within your ELB configuration. I know it sounds weird to load balance "load balancers" but if you're only using BIG-IP for basic L3 load balancing in AWS you're missing out on most of BIG-IP'sL3 through L7 traffic and security services. When deployed with ELB services, you're complimenting BIG-IP feature sets, not taking away. This goes back to being creative with your cloud architecture. On Interfaces And AMIs AWS CloudFormation Templates help reduce the need to "future proof" your architecture. It simplifies managing multiple designs because one size does not fit all. That'll becomes very apparent when determining what Amazon Machine Images (AMI) to use when deploying BIG-IP. The maximum number of interfaces a single BIG-IP can use is determined by the AMI selected during deployment. This is where using templates and later discussed cloud-init configs can help reduce the stress if you run into an AMI limitation. A great independent web site to help you evaluate Amazon's current AMI offerings is EC2Instances.info. Amazon's always adding new (and sometimes deprecating old) instances to meet the ever growing needs of it's end users so it's good to stay current. Example - The m4.large is a good 2vCPU 8GB RAM AMI. And while it allows for up to 20 IPs to be assigned, it only allows 2 interfaces. This is fine for many systems but you may have a design where BIG-IP needs 3 or more interfaces. That means you're going to need the m5.large which has 3 available interfaces, better networking performance, and a slightly higher hourly cost. This example illustrates the need to pay attention when chosing instances to define in your templates but then again, templates make it easy to update your designs. On Cloud-Init CloudFormation templates complete the tasks needed to deploy EC2 resources BIG-IP will use but there's still more configuration to do in order to successfully pass traffic. In Alex Applebaum's F5 in AWS Part 5 - Cloud-init, Single-NIC, and Auto Scale Out in BIG-IP he discusses how Cloud-Init can provision configurations within anoperating system once the CFT templates have completed their job. Introduced in BIG-IP virtual edition v13, Cloud-Init provides youa way you to build and complete the bootstrapping process to get BIG-IP up and running without user interaction. Check out Alex's article! On What's Next This article is an primer. It's here to get you familiar with the templates we offer for Amazon Web Services. Coming soon we'll dive into one of the more complicated templates and dissect it down so you can understand not only how they work but maybe give you an idea of how you can use them better. A lot of people still manually configure their AWS VPC's and while that's perfectly fine.There are other ways, and maybe better ways, to complete the same tasks. Lastly, what do you want to learn about? If there are any topics that may interest you, let us know and we'll see if we can either write an article, create a lightboard lesson, or start a discussion in Q&A. Thanks for reading and happy admining. Additional Resources: Get Started with BIG-IP VE In AWS F5 Github CloudFormation Template Home F5 In AWS Part 1 : AWS Networking Basics F5 In AWS Part 2: Running BIG-IP in an EC2 Virtual Private Cloud F5 In AWS Part 3: Advanced Topologies and More on Highly-Available Services F5 In AWS Part 4: Orchestrating BIG-IP Application Services with Open-Source Tools F5 In AWS Part 5: Cloud-init, Single-NIC, and Auto Scale Out of BIG-IP in v12
