aws provider vs vsphere provider

In a previous post we talked about the vsphere provider and what is needed to define a connection to create a virtual machine. In this blog we will start to look at what is needed to setup a similar environment to do the same thing in AWS EC2. Think of it as a design challenge. Your client comes to you and says “I want a LAMP or WAMP stack or Tomcat Server that I can play with. I want one local as well as one in the cloud. Can you make that happen?”. You look around and find out that they do have a vSphere server and figure out how to log into it and create a Linux instance to build a LAMP stack and a Windows instance to create a WAMP stack then want to repeat this same configuration in AWS, Azure, and/or Google GCP. Simple, right?

If you remember, to create a vSphere provider declaration in Terraform you basically need a username, password, and IP address of the vSphere server.

provider “vsphere” {
user = var.vsphere_user
password = var.vsphere_password
vsphere_server = var.vsphere_server
version = “1.12.0”

allow_unverified_ssl = true

The allow_unverified_ssl is to get around that most vSphere installations in a lab don’t have a certified certificate but a self-signed certificate and the version is to help us keep control of syntax changes in our IaC definitions that will soon follow.

The assumptions that you are making when connecting to a vSphere server when you create a virtual machine are

  1. Networking is setup for you. You can connect to a pre-defined network interface from vSphere but you really can’t change your network configuration beyond what is defined in your vSphere instance.
  2. Firewalls, subnets, and routing is all defined by a network administrator and you really don’t have control over the configuration inside Terraform unless you manage your switches and routers from Terraform as well. The network is what it is and you can’t really change it. To change routing rules and blocked or open ports on a network typically requires reconfiguration of a switch or network device.
  3. Disks, memory, and CPUs are limited by server configurations. In my home lab, for example, I have two 24 core servers with 48 GB of RAM on one system and 72 GB of RAM on the other. One system has just under 4 TB of disk while the other has just over 600 GB of disk available.
  4. Your CPU selection is limited to what is in your lab or datacenter. You might have more than just an x86 processer here and there but the assumption is that everything is x86 based and not Sparc or PowerPC. There might be an ARM processor as an option but not many datacenters have access to this unless they are developing for single board computers or robotics projects. There might be more advanced processors like a GPU or Nvidia graphics accelerated processor but again, these are rare in most small to midsize datacenters.

Declaring a vsphere provider gives you access to all of these assumptions. If you declare an aws or azure provider these assumptions are not true anymore. You have to define your network. You can define your subnet and firewall configurations. You have access to almost unlimited CPU, memory, and disk combinations. You have access to more than just an x86 processor and you have access to multiple datacenters that span the globe rather than just a single cluster of computers that are inside your datacenter.

The key difference between declaring a vsphere provider and an aws provider is that you can declare multiple aws providers and use multiple credentials as well as different regions.

provider “aws” {
version = “> 2”
profile = “default”
region = “us-east-1”
alias = “aws”

Note we don’t connect to a server. We don’t have a username or password. We do define a version and have three different parameters that we pass in. So the big question becomes how do we connect and authenticate? Where is this done if not in the provider connection? We could have gotten by with just provider “aws” {} and that would have worked as well.

To authenticate using the Hashicorp aws provider declaration you need to

  • declare the access_key and secret_key in the declaration (not advised)
  • declare the AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY_ID as environment variables
  • or point to a configuration file with the shared_credentials_file declaration or AWS_SHARED_CREDENTIALS_FILE environment variable leveraging the profile declaration or PROFILE environment variable.
  • automatic loading of the ~/.aws/credentials or ~/.aws/config files

The drawback to using the environment variables is that you can only have one login into your aws console but can connect to multiple regions with the same credentials. If you have multiple accounts you need to declare the access_key and secret_key or the more preferred method of using the shared_credentials_file declaration.

For the aws provider, all parameters are optional. The provider is flexible enough to make some assumptions and connect to AWS based on environment variables and optional parameters defined. If something is defined with a parameter it is used over the environment variable. If you define both a key and a shared_credentials_file, Terraform will throw an error. If you have environment variables define and a ~/.aws/credentials file, the environment variables will be used first.

If we dive a little deeper into our vsphere file we note that we need to run a script or manually generate the declarations for vsphere_datacenter, vsphere_host, and vsphere_resource_pool prior to defining a virtual machine. With the aws provider we only need to define the region to define all of these elements. Unfortunately, we also need to define the networking connections, subnet definitions, and potential firewall exceptions to be able to access our new virtual machine. It would be nice if we could take our simple vsphere virtual machine definition defined in our vsphere file and translate it directly into an aws_instance declaration. Unfortunately, there is very little that we can translate from one environment to the other.

The aws provider and aws_instance declaration does not allow us to clone an existing instance. We need to go outside of Terraform and create an AMI to use as a reference for aws_instance creation. We don’t pick a datacenter and resource_pool but select a region to run our instance. We don’t need to define a datastore to host the virtual machine disks but we do need to define the disk type and if it is a high speed (higher cost) or spinning disk (lower cost) to host the operating system or data.

We can’t really take our existing code and run it through a scrubber and spit out aws ready code unfortunately. We need to know how to find a LAMP, WAMP, and Tomcat AMI and reference it. We need to know the network configurations and configure connections to another server like a database or load balancer front end. We also need to know what region to deploy this into and if we can run these services using low cost options like spot instances or can shut off the running instance during times of the day to save money given that a cloud instance charges by the minute or hour and a vsphere instance is just consuming resources that you have already paid for.

One of the nice things about an aws provider declaration is that you can define multiple providers in the same file which generated an error for a vsphere provider. You can reference different regions using an alias. In the declaration shown above we would reference the provider with

provider =

If we wanted to declare that the east was our production site and the west was our dev site we could use the declaration

provider “aws” {
version = “> 2”
profile = “default”
region = “us-east-1”
alias = “east”
provider “aws” {
version = “> 2”
profile = “default”
region = “us-west-1”
alias = “west”

If we add a declaration of a network component (aws_vpc) we can populate our state file and see that the changes were pushed to our aws account.

We get the .terraform tree populated for our Windows desktop environment as well as the terraform.tfstate created. Looking at our AWS VPC console we see that Prod-1 was created in US-East-1 (and we could verify that Dev-1 was created in US-West-1 if we wanted).

Note that the CIDR block was correctly defined as as desired. If we run the terraform destroy command to clean up this vpc will be destroyed since it was created and is controlled by our terraform declaration.

Looking at our terraform state file we can see that we did create two VPC instances in AWS and the VPC ID should correspond to what we see in the AWS console.

In summary, using Terraform to provision and manage resources in Amazon AWS is somewhat easier and somewhat harder than provisioning resources in a vSphere environment. Unfortunately, you can’t take a or declaration from vSphere and massage it to become a AWS definition. The code needs to be rewritten and created using different questions and parameters. You don’t need to get down to the SCSI target level with AWS but you do need to define the network connection and where and how the resource will be declared with a finer resolution. You can’t clone an existing machine inside of Terraform but you can do it leveraging private AMI declarations in AWS similar to the way that templates are created in vSphere. Overall an AWS managed state with Terraform is easy to start and allows you to create a similar environment to an on-premises environment as long as you understand the differences and cost implications between the two. Note that the aws provider declaration is much simpler and cleaner than the vsphere provider. Less is needed to define the foundation but more is needed as far as networking and how to create a virtual instance with AMIs rather than cloning.

The and terraform.state files are available on github to review.

155 thoughts on “aws provider vs vsphere provider”

  1. Привет друзья!

    Предлагаем Вашему вниманию замечательный сайт

    Из [url=]последних новостей шоу бизнеса[/url] узнал, что:[url=]Знаменитости из России[/url] Лобода и Константин Меладзе поселились в Латвии, а детей пристроили в элитные школы.

    А певец Николай Басков впервые высказался по [url=]политической[/url] теме, осудив бежавших звезд из России.

    Рэпер Тимати посетил военный госпиталь, и привез около полусотни средств реабилитации для раненных военнослужащих, чтобы те быстрее возвращались к обычной [url=]жизни[/url].


  2. Здравствуйте дамы и господа!
    Есть такой замечательный сайт
    Чтобы оформить деньги в долг, вам не нужен специальный пакет документов, достаточно только паспорта. Это выгодно отличает микрофинансовые компании от банков в, которые требуют собрать несколько бумаг, на подготовку которых уходит пара дней.В заключение стоит сказать, что взять средства в МФО — простой и быстрый способ решения денежных проблем. Компании предоставляют множество заемных линий для людей с разными возможностями, поэтому вы обязательно найдете подходящий вариант. Главное — грамотно распорядиться займом и не тратить деньги на ненужные вещи.

  3. Thanks for your own hard work on this site. Kim enjoys conducting research and it’s really simple to grasp why. My partner and i know all concerning the dynamic mode you provide valuable thoughts by means of your web blog and even cause response from other individuals on that idea while our own princess is in fact being taught a lot. Have fun with the remaining portion of the new year. You have been conducting a stunning job.

  4. I have to express some appreciation to the writer for bailing me out of this type of condition. Just after looking out through the online world and meeting strategies which are not pleasant, I thought my entire life was gone. Being alive devoid of the answers to the problems you’ve sorted out by means of your good post is a critical case, and the kind that would have negatively damaged my career if I hadn’t encountered your web blog. Your main know-how and kindness in controlling all the details was tremendous. I don’t know what I would’ve done if I hadn’t discovered such a stuff like this. It’s possible to at this time look ahead to my future. Thank you so much for the specialized and amazing guide. I won’t hesitate to recommend the sites to any individual who wants and needs counselling about this problem.

  5. Здравствуйте дамы и господа!
    Предлагаем Вашему вниманию замечательный сайт
    Займ на карту онлайн – популярная микрофинансовая услуга. Ее основными достоинствами, по сравнению с обычным банковским кредитом, выступают: оперативность выдачи денег на карточку и доступность большей части потенциальных заемщиков, включая проблемных, то есть имеющих плохую кредитную историю, текущие долги и непогашенные финансовые обязательства.Займы на карту стали реальной возможностью получить деньги не в банке, что требует много времени и доступно далеко не всем. Важным дополнением становится минимум формальностей при получении займа и лояльность со стороны МФО по отношению к потенциальным клиентам. Получить быстрый займ на карту онлайн можно в случае острой нехватки денежных средств, например, при задержке зарплаты, при обнаружении болезни и т.д.

  6. I precisely wanted to appreciate you again. I am not sure the things that I could possibly have taken care of without the actual creative concepts documented by you on that field. Completely was a real difficult circumstance for me, but understanding a new skilled fashion you resolved that took me to cry for happiness. I am happy for your help as well as hope that you recognize what a powerful job you’re carrying out training others through your blog post. I’m certain you have never met any of us.

  7. I’m commenting to make you be aware of of the perfect discovery my cousin’s daughter found reading your web page. She came to understand numerous details, most notably how it is like to possess an incredible coaching mood to get other folks without hassle master several hard to do matters. You really exceeded visitors’ expectations. Thank you for delivering these good, dependable, informative and in addition fun thoughts on your topic to Emily.

  8. Thanks a lot for providing individuals with an extraordinarily marvellous possiblity to check tips from this blog. It is often so kind plus full of a great time for me personally and my office fellow workers to search your website not less than three times every week to see the new items you have got. And indeed, I am at all times contented concerning the attractive advice served by you. Certain two points in this post are ultimately the very best we’ve ever had.

  9. Thank you a lot for giving everyone an exceptionally wonderful opportunity to check tips from this site. It really is so terrific and as well , jam-packed with a great time for me personally and my office colleagues to search your blog particularly three times weekly to read the latest issues you have got. And indeed, I’m also usually happy considering the magnificent ideas you give. Some 4 facts in this post are completely the most effective we’ve ever had.

  10. I and also my buddies appeared to be looking at the excellent tactics located on your web site then quickly I had an awful suspicion I never thanked you for those tips. All the guys came certainly excited to study them and have in effect surely been loving these things. Many thanks for actually being simply thoughtful and then for opting for this sort of superb subject matter most people are really eager to be aware of. My very own sincere regret for not expressing gratitude to you sooner.

  11. [url=]doxycycline south africa[/url] where can i buy doxycycline online

  12. штабелеры с электроподъемом

Leave a Reply

Your email address will not be published. Required fields are marked *