What’s new with Red Hat OpenShift Service on AWS

Customers have been able to deploy application workloads within Red Hat OpenShift on AWS for several years. AWS and Red Hat have continued to respond to customer feedback and reduce effort and help customers meet the agility requirements they desire.

Modernization does not stop at the evolution of applications, but touches on every aspect of the business, changing infrastructure, process, and mindset. But how do application platform and infrastructure teams gain greater agility when dealing products such as OpenShift on AWS? How do I procure and deploy Red Hat OpenShift into my AWS account according to recommended practice is the shortest possible time?

Red Hat OpenShift Service on AWS offers several benefits speed up customer deployment and migration to the cloud. First, how do I purchase the required subscriptions for Red Hat OpenShift on AWS, and second, how much effort and time is involved with deploying Red Hat OpenShift Service in to my AWS account?

I used to think that the purchasing or procurement process is not a critical concern. However based on customer feedback, and my own experiences this can be a challenge when running and migrating at scale. In the past, I would be going back and forth between an AWS account team and a Red Hat account. I would go through various discussions before having an understanding of the underlying components of my OpenShift on AWS implementation, including the number and sizing of EC2 instances, and how these relate to my application workloads. Then, I can go through the process of working with my Red Hat account team to purchase subscriptions. Then, I can move onto the provisioning of the product. I could log into to manage my subscriptions, but I would still be dealing will moving between two providers and various systems and I would be managing billing in two places. Many customers I engaged with felt that this was not ideal for them.

How does Red Hat OpenShift Service on AWS address procurement and billing challenges?

Customers are able to purchase the Red hat OpenShift Service on AWS subscription directly from within the AWS Management Console with a simple click of a button. This dramatically reduces time to purchase and any back and forth between vendors. This needs only to be completed once per AWS account. Red Hat OpenShift Service on AWS brings the consumption based (hourly) billing model customers are used to with other AWS services to OpenShift customers. This is a game changer for customers spinning OpenShift clusters up and down on a frequent basis or who have workloads that scale up and down. Now, customers are paying for the OpenShift subscription and underlying AWS resources on a “pay as you use” basis.

Provisioning Red Hat OpenShift Service on AWS:

Red Hat OpenShift Service on AWS takes a step away from having to deal with infrastructure as code templates and automation scripts to deploy OpenShift. It also does not require lengthy consultation with an SRE team to deploy into the AWS account. Instead Red Hat OpenShift Service for AWS has a simple API and CLI. The CLI can be downloaded directly from the AWS Management Console and allows customers to pass parameters regarding their cluster requirements. The provisioning of the OpenShift cluster takes around 40 minutes.

Let’s walk through provisioning an OpenShift cluster:

I am going to log into the console and look under Services, Red Hat OpenShift Service on AWS can now be found as an additional option along with Amazon Elastic Kubernetes service and Amazon Elastic Container Service. The landing page page for Red Hat OpenShift Service on AWS has a few very simple controls.

Subscription signup:
On the top Right click on the enable OpenShift button, This will enable the use of ROSA within this AWS account, from here on, any use of Red Hat OpenShift Service on AWS within this account will automatically bill for the OpenShift subscriptions. There is no need for having existing subscriptions or reaching out to another party. When looking at the billing reports, or AWS cost explorer, I can now see the the cost for the underlying AWS resources such as EC2 instances and I will see a line item for the OpenShift subscription.

AWS license manager can be used to create rules which span various AWS accounts within an organization. This allows teams in non payer accounts to be able to enable the ROSA service even if they are not able to sign up for AWS market place solutions. Once the ROSA service is enabled in a main payer account, the ROSA service can then be enabled across the entire organization.

Download the ROSA CLI:
Once the subscription has been enabled, next I need to download the ROSA CLI in order to provision by OpenShift cluster into my AWS account. The Red Hat OpenShift Service on AWS page will have download link to the right, but there is also a notification that pops up directly after enabling ROSA within the account. Once downloaded and installed it would be best to do a quick verification.

I made use of an AWS Cloud 9 developer IDE to see deploy my ROSA cluster. Cloud 9 provides developers with a complete environment, with the AWS CLI already installed and configured.

$ wget

The ROSA CLI can be used to create, delete, edit Red Hat OpenShift Service on AWS clusters within the AWS account.

The ROSA CLI can even be used to see if there any possible AWS limit concerns within a Region. The tool will query AWS APIs where possible.

$ rosa verify quota --region=us-west-2

I: Validating AWS quota...
E: Insufficient AWS quotas
E: Service ec2 quota code L-0263D0A3 Number of EIPs - VPC EIPs not valid, expected quota of at least 5, but got 2

Looking at the above you can see I do not have enough EIPs in this region. Now, I can reach out to AWS Premium Support and request a service limit increase or I could make use of another AWS Region. Most of the AWS service limits which are needed for ROSA cluster deployments will cater for auto approval which reduces time to resolution. I was able to request additional EIPs and additional EC2 instance limited and within 10 minutes these were approved and applied to the AWS account.

The Rosa CLI can also be used to check of the account has been enabled for ROSA, check if the AWS CLI, IAM permissions and OpenShift CLI oc are all in place. In fact this can all be done with a single command

Cluster creation:

In order to provision a ROSA cluster, some parameters will need to be passed to the CLI installer, these would include: the AWS Region, will this be multi-AZ, how many of each kind of OpenShift node do I wish the cluster to have.

Using the interactive mode is a good way to get a sense of what information is needed.

$ rosa create cluster --interactive
  • The AWS Region you have configured for the AWS CLI
  • The most recent version of OpenShift available to ROSA
  • A single Availability Zone
  • Public cluster (Public API)
  • Master nodes: 3
  • Infra nodes: 2
  • Compute nodes: 2 (m5.xlarge instance types)

Here is a high level look the resources which will be created within the AWS account during the ROSA cluster create:

The cluster will be provisioned into the AWS account out of band, so we will see a pending state if we list the clusters.

Once the cluster is in an active, ready state, the CLI can be used to describe the cluster and get the details needed to access OpenShift.

The API endpoint will be used for connecting to OpenShift using command line developer and administrator tools such as the OC tool set. The console URL will provide a web base console.

Console URL:

The ROSA CLI can be used to create additional admins within OpenShift

$ rosa create admin -c testcluster

Once users login to the cluster via either the OC CLI or the console, there is a consistent experience with any other flavor of OpenShift. Developers can create projects, deploy applications, and make use of templates or operators via the operator hub.

OpenShift clusters are visible within the Red Hat OpenShift Cluster manager via this console will show you all OpenShift clusters, self managed OpenShift Container Platform clusters running on-premises or on AWS, and fully managed Red Hat OpenShift Services clusters running on AWS. configuration of Identify providers, assigning users as dedicated-admins or cluster-admins, defining maintenance windows can all be controlled from the cluster console.

Auto scaling and auto healing of worker or compute nodes has been available for some time now via machine sets. These have been updated to support newer AWS EC2 instance types. Red Hat OpenShift Service on AWS now supports machine pools, which expands the concept of a machine set to multi-AZ. Instead of having one machine set per Availability Zone, and having to create and manage three sets, I can now define a single machine pool that spans more than one Availability Zone.

Given that ROSA is a fully managed service, I did have some questions regarding how maintenance and patch management would be performed and how that would impact workloads. A new console user interface has been added to the cluster manager in which maintenance windows can now be defined. This also has settings for how upgrades should be processed. Customers familiar with other AWS managed services such as Amazon Relational Database Service will find this familiar.

ROSA log forwarding:
OpenShift has had rich logging and monitoring support via partners such as Splunk and Dynatrace. Thanks to joint engineering of AWS and Red Hat, it is now possible to enable log forwarding to Amazon CloudWatch directly from within OpenShift. Log forwarding will include the forwarding of cluster-level logs for the various layers of OpenShift, providing insight at the Kubernetes level as well as the OS level. At the application level, data collected from the build in Prometheus and Grafana layers can also be forwarded to Amazon CloudWatch. This integration will extend the log forwarding options available in previous versions of OpenShift.

In summary, AWS and Red Hat collaborating to offer Red Hat OpenShift Service on AWS simplifies many challenges highlighted by customers. Customers can now focus more on what is important to them, their application workloads, and their customers, and less on purchasing , procurement, provisioning, and managing the day to day operation side of running OpenShift.

See the Red Hat OpenShift Service on AWS product page for more information and news from our partners!

Ryan Niksch

Ryan Niksch

Ryan Niksch is a Partner Solutions Architect focusing on application platforms, hybrid application solutions, and modernization. Ryan has worn many hats in his life and has a passion for tinkering and a desire to leave everything he touches a little better than when he found it.