TL;DR Worker Nodes created by Karpenter need to have service provider specific defaults as well as validations according to the guardrails of the service provider. 

Worker Nodes created by Karpenter using the default OpenShiftEC2NodeClass/EC2NodeClass in a customer created Node Pools seem to be accepting any available EC2 instance including micro and medium instances that are not supported by Cluster-as-a-service providers such as ROSA.

• Insufficient Resources: These either can not bring up the worker node because the resource requirements of running OpenShift. For e.g., t3.micro does not ever become a node.  
• Billing/ Chargeback: Billing is based on vCPUs for these service providers and some instance types do not meet the requirements of billing. For e.g., t3.medium with 2 vCPUs can not be used because the billing is in the multiples of 4 vCPUs.
• Unsupported Configurations: Service providers may and will choose to just not support all the configurations (API specifications of CRs such as NodePools). For e.g, a subnet available in a local zone could be discovered by Karpenter but the service provider like ROSA does not support Local Zones. Similarly, for root volumes, specific types of storage (EBS GP3 or IO1) with certain volume sizes (75GiB) etc will be supported. 

Acceptance Criteria:

1. Cluster owner/administrators can only create node pools referencing the instance types or availability zones.
2. Service Providers (e.g., ROSA SREs) can configure these in the hosting cluster so that each service provider can have custom set of configurations (over a range of hosted clusters hosting using a hub cluster).