1. Enterprise Hybrid Cloud
Connecting and Using Amazon Web Services

2. Introduction
A hybrid-cloud operating model typically entails some workloads being hosted onsite using an organization's own infrastructure resources, and other workloads deployed into one or more offsite environments, which can be either private-cloud infrastructure in other locations, or based on public-cloud platforms such as Amazon Web Services (AWS).
With Enterprise Hybrid Cloud's native support for connecting to AWS as a remote endpoint, AWS-based VMs and applications can be deployed and managed directly from the vRealize Automation (vRA) self- service portal.
In this demo, we’ll show how to:
Add AWS to vRealize Automation as a managed endpoint
Create a Fabric Group
Create a Reservation
Create a Blueprint
Provision and manage an AWS virtual machine

3. The Infrastructure tab of vRealize Automation is used to manage all cloud resources, including compute and storage, reservations, and 'endpoints', which are resource targets that vRA uses to complete its provisioning processes. These can be sites, such as remote vSphere clusters that are privately owned and maintained, or public-cloud resources such as Rackspace, vCloud Air, and Amazon Web Services.
To start, we'd click the Endpoints category in the navigation widget on the left...

4. ...and then continue on to the Credentials category page.

5. Before configuring the endpoint, we'll need to create a login credential, which vRA will use when connecting to the AWS instance, by clicking the New button.

6. vRA allows credentials to be created and managed separately from the resources for which they're used. This enables separation of duties as a security best practice, in which the person responsible for maintaining security accounts does not need to share this information with the person responsible for endpoint management.
We'll need to provide a unique name for vRA, along with the AWS account's username and password.

7. Clicking the green checkmark button to the left of the row will save the credential as a new entry in vRA, which we can use in the next step while creating the endpoint.

8. You'll see that the new AWS credential has been successfully created and is ready to use.
Next, you'll click the Endpoints category...

9. ...and click the New button to add a new endpoint to vRA, selecting the Cloud > Amazon EC2 option.

10. First, we'll need to provide a name for the new endpoint.

11. Next, you'll use the Credentials button to assign the AWS credential that was created earlier. vRealize Automation will connect and authenticate to AWS using that information.

12. Then, click to select the AWS credential from the list and click OK to continue.

13. Now, clicking the OK button will create the new endpoint with the defined settings.

14. Now that the endpoint has been created, the next step is to run a Data Collection operation, which will connect to AWS and discover the available sites, resources, and templates available for vRA to use.

15. Once requested, a data collection operation normally takes no more than a few minutes to complete. Clicking the Refresh button will update the status once it's complete.

16. Success - vRealize Automation was able to connect to AWS using the provided credentials, and to determine what resources are available for use.
To continue to the next procedure, in which we'll create a fabric group, we'd click the Fabric Groups category.

17. vRealize Automation uses Fabric Groups to organize cloud compute resources and endpoints into logical clusters, which can then be made available for use by cloud tenants.
Now we'll create a Fabric Group to enable users to access resources on the new AWS endpoint, by clicking the New button.

18. To create a fabric group, we'd provide a group Name, assign one or more Fabric administrators, and then assign Compute resources from the list of available sites that were discovered during the earlier data collection operation when the AWS endpoint was added to vRA.

19. Success.
The next step is to add a new Reservation in vRA, using the new AWS endpoint and Fabric Group.
We'll start by returning to the Infrastructure page...

20. ...and then continuing to the Reservations category...

21. ...and on to the Reservations subcategory.

22. vRealize Automation (vRA) uses Reservations to manage access to Fabric Groups, which consist of Compute and storage resources. Reservations can include either an entire Fabric Group, or a percentage of a Fabric Group, for shared access across multiple tenant lines of business.
To start the process, we'd click the New button...

23. ...and select Amazon from the drop-down menu to create a new Amazon Reservation pool.

24. On the General tab, we'd provide a Name and designate the Business group to use the reservation pool.

25. Next, we'd assign a Priority to the pool
Next, we'd assign a Priority to the pool. If a business group has access to more than one reservation pool, this setting determines which pool to consume first.
Then, we'd open the Resources tab and configure the resources that will be used in the Reservation pool.

26. When the Fabric Group was created, the AWS-us-west-2 (AWB) site was assigned as the target resource.
In this step, that target is assigned to the reservation pool.

27. Key pairs are used to encrypt/decrypt Windows passwords or to log in to a Linux machine, and are required when provisioning with AWS.
We'd set the Key pair value to Auto-Generated per machine to require a unique key pair to be generated with each new VM.

28. In each Reservation pool, AWS users can create a Virtual Private Cloud (VPC) that isolates all VMs associated with the Reservation in a private section of the AWS cloud.
We'd check the box to enable this feature...

29. ...and then choose the vpc-57a89130 virtual private cloud to host all our AWS VMs...

30. ...and then choose a single subnet for all AWS VMs in this Reservation pool.
A Security group acts as a firewall to control access to AWS cloud VMs. Multiple security groups can be created to manage access protocols, such as SSH, RDP, and/or other application-specific ports. We'll click to enable the Default security group.
Finally, we'll Save the VPC setting.

31. Reservation pools can also be configured with custom Properties that can apply to all VMs created using the Reservation pool, and with Alerts to notify administrators/managers when Reservation resource consumption reaches a target threshold (e.g. 80% of VM quota).
Clicking OK at this point will create the Reservation pool with the settings that have been provided.

32. Success!

33. Now, we'd click the Design tab at the top of the page to create a new Blueprint that will provision a VM in the new AWS space.

34. Now that we've added an AWS endpoint to vRA, complete with Fabric Group and Reservation pool, we can create a Blueprint that can be published to the Service Catalog, enabling users to provision VMs directly into AWS.
We'd begin by clicking the New button at the top of the page.

35. For the new blueprint, we'd assign a Name and Description, which will be visible to users when the new blueprint appears in vRA as a catalog item.
Then we'd click OK...

36. ... and continue on to the Design Canvas to configure the blueprint's VM settings.
vRealize Automation supports native Amazon Machine templates, meaning that AWS workloads can be automated and provisioned using AWS blueprints.
To add an AWS template to the blueprint, we'd click-and-drag an Amazon Machine onto the Design Canvas page.

37. Once the VM template has been added to the blueprint by dropping it onto the Design Canvas, we can configure its specific build settings.

38. The Machine prefix value determines the naming scheme for VMs deployed from this blueprint.

39. Next, we'd configure the VM's deployment settings by opening the Build Information tab.

40. When the AWS endpoint was created and the data-collection operation initiated, vRA gathered the inventory of available resources, including Amazon machine images, which can be used for workload deployments.
To assign one of these images to the blueprint, where it will serve as a template for all VMs deployed using this blueprint, we'd click the ellipsis button next to the Amazon machine image field.

41. We'll use the topmost Ubuntu machine template for this blueprint, by clicking to highlight the ubuntu-image-us-west-2-daily/yakkety image, then clicking OK to return to the blueprint.

42. Key pairs are used to provision and connect to AWS VMs, and can be generated per business group or per-VM, as determined by the blueprint.
To configure this setting, we'd click the Key pair drop-down button...

43. ...and select Auto-Generated per machine to set the key pair assignment.

44. Next, to enable users to choose whether or not to provision VMs from this blueprint into a Virtual Private Cloud, we'd check the Enable Amazon network options on machine box.

45. The Instance types setting determines what VM size options will be presented to the user during deployment.
Selecting the t2 - Micro Instance as the only available option means users can only deploy a 1-CPU VM with 1024MB of memory and 0 storage. Since billing on AWS is tied to resource consumption, this also minimizes the cost that the business will incur per AWS VM instance.
At this point, we've provided all the configuration settings necessary to create AWS virtual machines. Clicking Finish will save the new blueprint and return to the Design page.

46. The new Ubuntu on AWS blueprint has been created and added to the vRA Blueprints inventory.

47. The next step is to Publish the blueprint in vRealize Automation, which will enable us to add it to the service catalog.

48. Now that the blueprint is published, in order to add it to the service catalog, we'd open the Administration tab...

49. ...and continue to the Catalog Management category page...

50. ...and finally to the Catalog Items category page.

51. On the Catalog Items page, we can see the Ubuntu on AWS line item, corresponding to the blueprint we just created.
To edit the item's configuration info - e.g. add an icon, assign a service catetory - we'd click the hyperlink in the Ubuntu on AWS item's name.

52. From here, if we don't want to use the default catalog item icon that vRA assigns to all new items, we can use our own.
To change the icon, we'd click the Browse... button....

53. and select the awsubuntu
...and select the awsubuntu.png image file from our library of staged icons.

54. Next, we'd assign the catalog item to the Virtual Servers service category. This assignment determines both where the item appears in the catalog, and which users are entitled to see and use the catalog item.
To adjust this setting, we'd click the Service drop-down menu...

55. ...and choose Virtual Servers.
Then, clicking OK will save the new settings and return us to the Catalog Items management page.

56. All done!
To confirm the addition of the Ubuntu on AWS blueprint to vRA as a new catalog item, we'd click the Catalog tab.

57. You can see that the Ubuntu on AWS tile now appears in the service catalog, in the Virtual Servers service category, just as we configured.
From here, clicking the item's Request button will let us deploy a new virtual machine directly onto AWS, using our new blueprint.

58. As always, we'd provide a Description for the new VM request, and then click the Submit button to create the VM....

59. ...and then click the OK button to continue on to the Requests page.

60. Here on the Requests page, we can see that the VM's deployment is currently In progress, and we can update the status by clicking the Reload button.

61. Success!
To find the new VM in our inventory, we'd open the Items tab...

62. ...where we'd find our new VM.
Even though the virtual machine has been deployed to a remote, public cloud-based location, we can still view, access, and manage the VM using the vRealize Automation self-service portal.
To see the VM itself, we'd expand the deployment...

63. ...and if we click on the AWS-UBU03 virtual machine item, we'd see its Details page.

64. From this Details page, we can see and manage the VM: connect via SSH, manage its power state, or reconfigure the VM with more compute and/or storage.
To change its power state, we'd click the Power Off action link.

65. And just like a locally-hosted VM, vRA will ask for confirmation before submitting the command.

66. Once the request has been submitted, we can click OK to return to the VM's Item Details page...

67. ...and Close to return to the Deployments page of the Items tab.

68. As with any other VM managed by vRA, we can also delete VMs from the AWS site using the same procedure as we'd see in local deployments, by highlighting the target deployment and choosing Destroy from the drop- down Actions menu.

69. From here, we can either Cancel to return to the VM in its present state, or we can confirm the request with the Submit button.

70. Clicking OK now will return us to the Items page.

71. After we've submitted the request and returned to the Items page, we can use the Reload button to see our current VMs inventory. Once the AWS VM has been deleted, it will disappear from this list.

72. After we've submitted the request and returned to the Items page, we can use the Reload button to see our current VMs inventory. Once the AWS VM has been deleted, it will disappear from this list.