Beginning with AWS CloudFormation – Part 2

In this post we are going to build on the previous template and add the ability to take input and produce output.  Sometimes you want to strictly define inputs in your template, but sometimes you want the ability for people to give their own values instead of writing tons of very specific templates for unique workflows.  And we will also start looking at intrinsic functions as well, so plenty of good content here.

Input – Parameters

Inputs for templates in CloudFormation are called parameters.  Like resources they have their own section in the template.

Here is the AWS documentation on parameters for reference:

Back in the CloudFormation designer, load up your previously created VPC workflow (or just drag a VPC resource to the canvas).  Notice that with the VPC object selected, the bottom pane on the Components tab will show you specific items related to the VPC resource.  Instead, on the canvas, click anywhere on the blank canvas to deselect the VPC object.  You should see the bottom pane change and have several different tabs show up.  The first one should be Parameters.


Here we can add in any items we would like the user to put in.  Specifically, I want the user to be able to define a name for the VPC this workflow creates.  Again keeping it simple, I’ll add in a very basic parameter definition so my section will look like this:

"Parameters": {
    "VPCNameParameter" : {
       "Type": "String",
       "Description": "Enter a name for the VPC"

So I just named the parameter, gave it a type and a description.  You may have a lot of questions like what other types are there, what other fields are there.  I would encourage you to take a look at the previously linked AWS doc as this has a lot of important details you’ll be interested in.

But we can’t move on to deployment yet.  This will allow the user to input a value for the VPC name, but we aren’t actually doing anything with it.  Right now if we executed this template, the stack would have a VPC in it but still not have a name.  We solve this by modifying the VPC resource to reference the parameter.

Click on the VPC resource to bring that back up.  We need to answer 2 questions.  First, what actually is property for the name of the VPC, and how do we set it?  For this we reference the AWS CloudFormation VPC documentation:

You’ll notice that there is no property that is something like VPCName.  But if you look carefully at the Tags section, you’ll see that the VPC name is really just a Tag with a key value of Name.  So we can do something like this to reference the VPC name:

"TestVPC": {
    "Type": "AWS::EC2::VPC",
    "Properties": {
       "CidrBlock": "",
       "Tags": [
             "Key": "Name", 
             "Value": "VPCNameParameter"

So question #1 is answered.  This is a correctly formatted template which names the VPC, and you can use the Validate Template button if you don’t believe me.  However, this isn’t going to do what we want.  Feel free to deploy the stack yourself (save first!) but I’ll save you the trouble by showing you here.


Here I’m creating this stack.  You see here that I’m naming the stack but it is also prompting me for the parameter name in the template.  Success!  Kind of…

After proceeding through the stack deployment, there were no errors, and it did create a VPC.  However, here is my VPC output:


Well it named it, but not what I wanted.  I wanted it to be named MyTestVPC.  This is because our tag referenced the specific string “VPCNameParameter” but not the actual parameter VPCNameParameter.   In other words, the template did exactly what we told it to, but not what we wanted it to.  Certainly a common problem when coding!

To reference the parameter value, we need to use what is called an intrinsic function.  We will cover more of these in a later post, but this is a way to have dynamic functionality in your templates instead of having to hard code everything.  In our case we want to reference the value of the parameter, so we need to use the intrinsic function called Ref. (  Ref will return the value of a parameter when used on one, and will return a usable ID (say VPC ID) when used on a resource.  Intrinsic functions are key to writing good, reusable CloudFormation templates.

So a quick modification of our VPC resource gives us:

"TestVPC": {
   "Type": "AWS::EC2::VPC",
   "Properties": {
      "CidrBlock": "",
      "Tags": [
            "Key": "Name", 
            "Value": { "Ref": "VPCNameParameter" }

That should do it.  Now we’ll properly reference the VPCNameParameter input value.

Save your template and give the deployment a shot.  It should allow you to input a name, and then you should see that name referenced on the VPC.

Now I’m going to be bad for a minute.  Tags in AWS have a maximum value of 255 characters.  I’m going to deploy this template and use a reeeeeeeeeally absurdly long name value of 256 characters.  What will happen?


Well, the template will still validate no problem.

The deployment will also start, no problem either.  When you input the parameter, CloudFormation has no idea what you are using it for, so it being long or short or having weird characters doesn’t really bother it.


So notice here in our event log that the deployment failed and was rolled back.  Why?  It tells you right there, the value we tried to use for our tag exceeded the 255 character limit.

This is a kind of silly example as it is unlikely that someone would use a 256 character name for a VPC but it highlights a problem which is, whenever you allow users to input data, you have to be able to validate that data.  Sure we can modify the Description field and put “must be less than 255 characters, blah blah blah,” but this still allows a user to purposefully or accidentally put in the wrong data, and then they have to wait for the deploy to fail and do it all over again.  A better idea would be to actually do validation on the data.  And guess what?  You can do just that!

Back on the Parameters documentation you can find several options for limiting user input as well as an AllowedPattern property which even lets you use regular expressions for validation.  And there is a ConstraintDescription property which lets you give the user a message when they oops.  These are key when doing parameters in CloudFormation.

So in my template I will modify our parameter entry to:

"VPCNameParameter": {
   "Type": "String",
   "Description": "Enter a name for the VPC",
   "MaxLength": 255,
   "ConstraintDescription": "VPC Name must be less than 255 characters"

Now when I try to execute this template in CloudFormation with a 256 character tag, I get this error message:


Which tells me exactly what the problem is, and I can go back and modify my inputs to satisfy the parameters.

Additionally, obviously, you don’t have to conform your input validation to AWS maximums.  Maybe you only want VPC names to be 20 characters max.  Maybe you want VPC names to start with “vpc-“.  You can do all this and more with the input validation in CloudFormation.

This is a pretty simple example but definitely review the parameter documentation and see how they can help improve your templates.


Outputs in CloudFormation are actually called – wait for it – outputs! And they go in their own section as well.  Outputs are useful if you want to report some information back to the caller after they execute a template.

Here is the doc for outputs:

In our template, we don’t actually let the user define the VPC CIDR block so let’s report what the CIDR block is back to them after the resource is created.

In the designer again, click on the canvas to deselect the VPC object and you should see a few tabs again (Parameters being one).  The last one should be Outputs.  Click here and we can add in a section to do the output we want.

"Outputs": {
   "VPCCidrBlockOutput" : {
      "Description": "The Cidr Block of the VPC", 
      "Value" : { "Fn::GetAtt" : [ "TestVPC", "CidrBlock" ]}

This should look pretty familiar by now except Fn::GetAtt.  There is an identifier “VPCCidrBlockOutput,” and a description of what this is.  Then there is a value.

We need to use another intrinsic function as we want to dynamically get the CIDR block attribute from the resource after it has been created.  Sure we could just type in the CIDR block value, but what if later we altered our template to change the CIDR block, or maybe let the user enter it.  For the most part you will want your outputs to be dynamic.

This function is Fn::GetAttr ( and it gets an attribute of a resource.  In our case the resource is the logical ID of our VPC, or “TestVPC”, and the attribute we want is “CidrBlock”.  How do we know what the attributes are named?  Consult the CloudFormation VPC documentation and there is a section called Return Values that will tell you what Ref will return as well as what attributes you can return via Fn::GetAttr.

Now that we’ve got this output in place, all we need is to execute the template again.  Once my stack is created, I can see these values in the Outputs section of the console.


Again this value is the value from the resource itself, so if the template were to change in the future, the correct value will still be reported back to the user executing the stack.

I hope this has been another useful intro to CloudFormation and some of the ways you can leverage it to be more dynamic.  More to come!

Beginning with AWS CloudFormation – Part 1

One of my few new goals for this year is to get back to blogging regularly about stuff I’m learning or interested in.  Keep a look out here for (hopefully!) more content this year than previous years which might have had just a handful of posts.

AWS CloudFormation is a utility that allows you to define AWS “infrastructure” as code in text files called Templates.  You can use it to deploy almost anything via JSON or YAML scripts.  The deployed resources are collectively called stacks.  There are other IaC options here as well, like Terraform, but I think it is handy to know the native toolset as well.  Plus if you are going for AWS certifications you’ll need to be familiar with it.

Continue reading

Exploring Docker Networking – Bridge

Exploring Docker Networking – Bridge

If you have been under a rock (like I was for a while!), Docker is a container technology and containers are very cool.  Containers sparked my interest in the same way that virtualization did the first time I saw it.  I really regret not getting into it sooner but better late than never.  Seriously if you haven’t played with containers at all try it on a local system, VM, or use this really nifty site

Continue reading

VMware vRealize Automation 7.3 – Upgrade and Health Check

VMware vRealize Automation 7.3 – Upgrade and Health Check

As you may be aware, vRealize Automation 7.3 just released a few days ago.  I took some time to upgrade my lab and thought I would share my experience as well as a look at the new embedded health service.

First it goes without saying that this is a lab, not a production instance.  Obviously you should take care before any upgrade with standard checks like ensuring compatibility with any extras you have, ensuring you have good functional backups, etc.

Also my lab is a simple deployment, not a distributed one.  Again, do your homework to ensure that you are prepared for the entire upgrade scenario.

Ok let’s get to it!


You have the option of doing the upgrade by using an online repository.  I am never a fan of doing a major upgrade this way.  It is one thing to download minor patches but I would rather download the file and do my own checksum validation before applying it myself.

First, you will need to download the upgrade ISO from the VMware download site.  It is the same location where you get the vRA OVA, just a different download.  After the download completes, validate the checksum against the provided one to ensure that your download is good.

After it is downloaded, I uploaded it to a datastore I have for ISOs and then attached it to the vRA CDROM.  Make sure you actually connect it!  This still trips people up, including yours truly.


Next, login to the vRA VAMI (default :5480) as root.  Under Update > Settings, select Use CDROM Updates and save.


Back on the Status page, hit Check Updates which should show the 7.3 update.  If you don’t see it, you probably don’t have the CDROM connected.  Then just hit Install Updates.  Note that I’m actually jumping two versions here, 7.1 to 7.3.  This is OK but if you have an older one than 7.1 you’ll need to check the release notes on how to get to 7.3.  


You will see this message below for a while during the appliance update, but fear not – let it go and it will finish.


My only complaint about this process is I hate messages like this with no “update progress” messages (or even worse, progress bars that just constantly scroll and don’t actually indicate progress) but it is a minor fault.  The IAAS updates actually do provide some good progress indicators.

Once it completes it will let you know and you can reboot the appliance.


After the appliance reboot you can check the update screen again as the IAAS server components get upgraded next.


Once the IAAS updates finish, you are good to go.  Overall a very painless experience, so kudos to the vRA team for ensuring easier installs and upgrades!

Health Check

Next after I logged into my tenant and took a quick look around to make sure nothing looked awry, I gave the new health check feature a whirl.  As IAAS Admin, you’ll find the Health option under Administration.  Note that you can also see this as Tenant Admin but you can only view results, not configure or run tests!


Click New Configuration to create a new test.  Configuring the test is pretty straight forward aside from the fact that you will need to input vRA info as if the system doesn’t understand itself.  This is because you are not limited to monitoring the vRA instance you are logged into…as long as you can reach it and have credentials you can do a health check.


The only thing that caught me up was the naming for my tenant admin who is a domain user.  After trying domain\user in several iterations and failing miserably, I simply used user@domain and it worked like a charm.  So be careful if you are using domain accounts here.

After the test is configured, simply run it.


Test results are all green, and green is good!  If you click on the icon you’ll get a more detailed view of what tests were run and the results.


When I had the wrong user and some of the tests failed to run (the output was decidedly more yellowy-reddy than above), the detailed output actually did notify me of the problem and sometimes it will offer fixes as well.  As far as I was able to determine from the guide and my poking around, you can’t configure notifications for the health check which is kind of a bummer.  It would be great to be able to SMTP/SNMP if a health check issue arose.  Hopefully this can be added in the future unless I’m just missing it.

Look for more on vRA 7.3 over the coming weeks!

VMware vSphere – Guest clock, replication, and squirrels


That’s me blowing the cobwebs off of my blog. 🙂

Time marches on and things are always changing.  I too have recently made several changes both in my personal and professional life.  I am now a delivery engineer for CDI Southeast, though we are going through another transition period ourselves.  I am also doing a bit of retooling, attempting to become a little less storage focused and branching out into other areas.  Right now I’m trying to focus more on vSphere but also working with some DevOps stuff as well.  I also released a course on Pluralsight last October which I am very proud of.  If you are interested in hearing me talk to you about VNX for hours, I encourage you to check it out.

So, great things hopefully coming down the pipe for me in the future and I hope to continue to share with the community at large that has given so much to me.

In the meantime, here is a quick nugget that I turned up a couple of weeks ago.  I was doing a pretty straightforward implementation of vSphere replication (and I hope to do a series on that soon), but ran into an oddity which I initially wrote off as a squirrel.

A squirrel is a situation where I walk into your building to do an implementation, and shortly thereafter you (or your co-worker, or your boss) comes up to me and says, “you know ever since you got here, the squirrels have been going crazy outside.  What did you do?”

The squirrel can be anything really, but most of the time is comically unrelated to anything I’m actually working on. And sometimes it is just people messing around with me.  “Hey you know Exchange is down?  JUST KIDDING!”

Side note – I’ve been on site with a jokey client where something really did go down and it took us a minute or two to figure out that there was really a problem. 

I’m used to squirrels now.  Honestly they rarely have merit but I always take them seriously “just in case.”

In this case, in the midst of replicating VMs in the environment, an admin asked me if anything I was doing would mess with the clock on a guest server.  I racked my brain for a moment and replied that I wouldn’t think so.  The admin didn’t think so either so he went off to investigate more.  I did some more thinking, and then went back and got some more information.  What exactly was happening to the clock?

In this case the server had a purposefully mis-set clock.  As in, it wasn’t supposed to read current time but it kept getting set to the current time.  VMware tools dawned on me, because there is a clock sync built into tools that has to be disabled.  We double checked but it was disabled. It made sense because we didn’t do anything with tools (no new or updated tools install).

So later that night I was playing around in my lab.  I recreated the setup as best I could. Installed a guest with tools, disabled time sync, and set the clock back a year and some months.  Then I started replication.  And instantly, the clock was set forward.

So it turns out that even if you tell the guest “don’t sync the clock to the host,” it will STILL sync the clock to the host in certain situations.

While I understand the rationale (certain operations have the potential to skew the clock, ergo syncing the clock up after those will help prevent ongoing skew) I really feel like if time sync is disabled, it shouldn’t sync the clock.  Ever.  Or there should be another check box that says “No really, never sync the clock.”  Nevertheless, I don’t work for VMware so I can’t tell them how to run their product.

In this case the fix is pretty simple though it does require downtime.  Shutdown the guest and add some lines to the .vmx:

time.synchronize.continue = "0"
time.synchronize.restore = "0"
time.synchronize.resume.disk = "0"
time.synchronize.shrink = "0" = "0" = "0" = "0"

Now it will really, really never mess with the clock on the guest.

This might be common knowledge to VMware admins but I had no idea and I suppose I’ve never dealt with a purposefully skewed clock before.