Resource aviatrix_vpc creates a VPC/vNet/VCN in various cloud types. For Aviatrix Transit VPC, there would be various different subnets created for the purpose of integrating with SDWan appliances, insertion of Firewalls, integration with AWS TGW (Aviatrix Orchestrated), or utilizing AWS Gateway Load Balancer etc.
An example of subnets created in AWS for Aviatrix Transit VPC with High-Performance Encryption, TGW-O integration, and Firewall integration with GWLB.
In our last blog, “AWS Hybrid Architecture and Edge 2.0,” we covered the workflow of registering an Edge 2.0 gateway, attaching it to Aviatrix Transit, and forming a BGP peering with on-premise devices. Now, let’s take a closer look at the features of the Edge 2.0 gateway. By leveraging Edge 2.0, enterprises gain high throughput and intelligent packet processing capabilities at the edge of their network. Edge 2.0 provides a robust set of features, including intelligent packet routing to streamline network traffic and advanced security features, such as network segmentation, to provide an added layer of protection to your network.
One of our customers approached Aviatrix in search of a high-performance encryption solution for their on-premise data centers and AWS. They were impressed with Aviatrix’s features, including visibility, a dedicated data plane, high-throughput encryption, and Terraform capability. However, they also had sister business entities still using AWS TGW, and didn’t want to spend too much time trying to convince them to switch to Aviatrix. That’s when they turned to us for a hybrid architecture solution.
When customers are migrating to Aviatrix Transit from AWS TGW, we would build BGP connectivity between AWS TGW with Aviatrix Transit. In the past, we have to use IPSec, which would be limited to 1.25G per tunnel connection speed, for customer’s that doesn’t require end to end encryption during the migration, with AWS TGW Connect, now we can build GRE tunnels between AWS TGW and Aviatrix Transit.
git repository is distributed in nature, also there are tons of repositories not using terraform. You have just created a killer terraform solution and cannot wait to share with world, instead of trying to send people the git repo link, how about publish it to terraform registry, and now everyone can search and simply use it as a module? After all, let’s keep it DRY (Don’t repeat yourself) as much as possible.
If you run it, you may find resources gets created in the default account : AccountA, where Terraform-User is resided. How do we make the resource create in AccountB instead?
Think of module a mini block of terraform code that also require it’s own provider block. If you don’t specify anything in /modules/app/providers.tf, it will implicitly have this block, basically it’s looking for a provider called aws
This is telling within the module, provider.aws is equal to root provider.aws.account_b.
If you rerun terraform apply. you will notice:
Resources created in AccountA remains
New resources get created in AccountB now
Warning: Provider aws is undefined
│ on main.tf line 8, in module "app1":
│ 8: aws = aws.account_b
│ Module module.app1 does not declare a provider named aws.
│ If you wish to specify a provider configuration for the module, add an entry for aws in the required_providers block within the module.
To make Terraform happy, add following lines in /modules/app/providers.tf