|
| 1 | +--- |
| 2 | +title: aws-eusc-partition |
| 3 | +authors: |
| 4 | + - "@patrickdillon" |
| 5 | +reviewers: # Include a comment about what domain expertise a reviewer is expected to bring and what area of the enhancement you expect them to focus on. For example: - "@networkguru, for networking aspects, please look at IP bootstrapping aspect" |
| 6 | + - "@tthvo" |
| 7 | +approvers: # This should be a single approver. The role of the approver is to raise important questions, ensure the enhancement receives reviews from all applicable areas/SMEs, and determine when consensus is achieved such that the EP can move forward to implementation. Having multiple approvers makes it difficult to determine who is responsible for the actual approval. Team leads and staff engineers often make good approvers. |
| 8 | + - "@sadasu" |
| 9 | +api-approvers: # In case of new or modified APIs or API extensions (CRDs, aggregated apiservers, webhooks, finalizers). If there is no API change, use "None". Once your EP is published, ask in #forum-api-review to be assigned an API approver. |
| 10 | + - "@everettraven" |
| 11 | +creation-date: 2026-03-03 |
| 12 | +last-updated: 2026-03-03 |
| 13 | +status: implementable |
| 14 | +tracking-link: # link to the tracking ticket (for example: Jira Feature or Epic ticket) that corresponds to this enhancement |
| 15 | + - https://issues.redhat.com/browse/CORS-4356 |
| 16 | +see-also: |
| 17 | +replaces: |
| 18 | +superseded-by: |
| 19 | +--- |
| 20 | + |
| 21 | +# AWS European Sovereign Cloud (EUSC) Partition |
| 22 | + |
| 23 | +## Summary |
| 24 | + |
| 25 | +AWS has introduced a new partition (a separate collection of regions) called |
| 26 | +European Sovereign Cloud. The data centers comprising this partition are isolated |
| 27 | +entirely within the European geography. OpenShift should support this partition |
| 28 | +with feature parity to the standard `aws` partition, with any [identified differences |
| 29 | +documented][eusc-diff]. |
| 30 | + |
| 31 | +Ideally partitions and regions would be a transparent consideration, utilizing the AWS |
| 32 | +API to determine validity. Certain limitations, specficially RHCOS AMI publication, |
| 33 | +openshift/API regex-based validations, and pending adoption of v2 of the aws sdk by |
| 34 | +many components need to be addressed to make progress toward that goal. |
| 35 | + |
| 36 | +## Motivation |
| 37 | + |
| 38 | +We want to improve the user experience of installing to EUSC in order to increase |
| 39 | +adoption of OpenShift, specifically for users and businesses looking for |
| 40 | +geographical isolation of data. |
| 41 | + |
| 42 | +### User Stories |
| 43 | + |
| 44 | +* As an administrator, I want to be able to install a fully functional OpenShift cluster |
| 45 | +to a region in the EUSC. |
| 46 | + |
| 47 | +### Goals |
| 48 | + |
| 49 | +Add support for EUSC. |
| 50 | + |
| 51 | +### Non-Goals |
| 52 | + |
| 53 | +In the future, we should make the addition of any future partitions |
| 54 | +and regions transparent, but we're not there yet. |
| 55 | + |
| 56 | +## Proposal |
| 57 | + |
| 58 | +* Publish RHCOS AMI in any EUSC regions, until then users |
| 59 | +can upload their own AMI and provide it in the install config, which is existing functionality in the installer |
| 60 | +* Add `aws-eusc` to the hard-coded lists of AWS partitions in components such as |
| 61 | +the installer and openshift/api validation regexes. |
| 62 | +* Installer will automatically populate service endpoints when users |
| 63 | +install to the EUSC region for any operators that have not upgraded |
| 64 | +to aws-sdk-go-v2 (and are currently using V1, which is past EOL) |
| 65 | + |
| 66 | +### Workflow Description |
| 67 | + |
| 68 | +Users should be able to install to the EUSC partition just like any region |
| 69 | +in the standard `aws` commercial partition, by supplying valid credentials |
| 70 | +(as specified by the aws sdk) and a EUSC region in the install config. |
| 71 | + |
| 72 | +Currently, users need to supply their own AMI and [service endpoints][endpoints], so |
| 73 | +for illustration the install config looks like: |
| 74 | + |
| 75 | +```yaml |
| 76 | +platform: |
| 77 | + aws: |
| 78 | + region: eusc-de-east-1 |
| 79 | + defaultMachinePlatform: |
| 80 | + # Build and use a custom AMI as public RHCOS AMI is not available in this region |
| 81 | + amiID: ami-1234567890 |
| 82 | + serviceEndpoints: |
| 83 | + - name: ec2 |
| 84 | + url: https://ec2.eusc-de-east-1.amazonaws.eu |
| 85 | + - name: elasticloadbalancing |
| 86 | + url: https://elasticloadbalancing.eusc-de-east-1.amazonaws.eu |
| 87 | + - name: s3 |
| 88 | + url: https://s3.eusc-de-east-1.amazonaws.eu |
| 89 | + - name: route53 |
| 90 | + url: https://route53.amazonaws.eu |
| 91 | + - name: iam |
| 92 | + url: https://iam.eusc-de-east-1.amazonaws.eu |
| 93 | + - name: sts |
| 94 | + url: https://sts.eusc-de-east-1.amazonaws.eu |
| 95 | + - name: tagging |
| 96 | + url: https://tagging.eusc-de-east-1.amazonaws.eu |
| 97 | +``` |
| 98 | +
|
| 99 | +Once an AMI is published in the region, and the installer is updated to |
| 100 | +automatically populate these endpoints when `eusc-de-east-1` is set, the install config |
| 101 | +will be simply: |
| 102 | + |
| 103 | +```yaml |
| 104 | +platform: |
| 105 | + aws: |
| 106 | + region: eusc-de-east-1 |
| 107 | +``` |
| 108 | + |
| 109 | +Note that once operators have updated to AWS SDK V2, it will not be necessary for the installer to provide endpoints. As the V1 SDK |
| 110 | +is already EOL, ideally the updates will happen before any further regions are rolled out. |
| 111 | + |
| 112 | +### API Extensions |
| 113 | + |
| 114 | +Regex validation in openshift/api will be updated to include `aws-eusc`. |
| 115 | + |
| 116 | +### Topology Considerations |
| 117 | + |
| 118 | +#### Hypershift / Hosted Control Planes |
| 119 | + |
| 120 | +Hypershift will gain the same benefit from updating the regexes. The installer |
| 121 | +cannot populate the service endpoints for hypershift, so hypershift will need |
| 122 | +to depend on users supplying the endpoints until cluster operators are updated. |
| 123 | + |
| 124 | +#### Standalone Clusters |
| 125 | + |
| 126 | +Already covered above. |
| 127 | + |
| 128 | +#### Single-node Deployments or MicroShift |
| 129 | + |
| 130 | +n/a |
| 131 | + |
| 132 | +#### OpenShift Kubernetes Engine |
| 133 | + |
| 134 | +n/a |
| 135 | + |
| 136 | +### Implementation Details/Notes/Constraints |
| 137 | + |
| 138 | + |
| 139 | +### Risks and Mitigations |
| 140 | + |
| 141 | +None |
| 142 | + |
| 143 | +### Drawbacks |
| 144 | + |
| 145 | +None |
| 146 | + |
| 147 | +## Alternatives (Not Implemented) |
| 148 | + |
| 149 | +N/A |
| 150 | + |
| 151 | +## Open Questions [optional] |
| 152 | + |
| 153 | +None |
| 154 | + |
| 155 | +## Test Plan |
| 156 | + |
| 157 | +New cluster profile is created for EUSC partition. Presubmits and periodics will |
| 158 | +be created for the initial region. Standard QE testing patterns will be applied |
| 159 | +for additional regions. |
| 160 | + |
| 161 | +## Graduation Criteria |
| 162 | + |
| 163 | +### Dev Preview -> Tech Preview |
| 164 | + |
| 165 | +- Ability to utilize the enhancement end to end |
| 166 | + |
| 167 | +### Tech Preview -> GA |
| 168 | + |
| 169 | +- Document & validate any feature disparity between standard commercial partition & EUSC |
| 170 | + |
| 171 | +### Removing a deprecated feature |
| 172 | + |
| 173 | +n/a |
| 174 | + |
| 175 | +## Upgrade / Downgrade Strategy |
| 176 | + |
| 177 | +n/a |
| 178 | + |
| 179 | + |
| 180 | +## Version Skew Strategy |
| 181 | + |
| 182 | +n/a |
| 183 | + |
| 184 | +## Operational Aspects of API Extensions |
| 185 | + |
| 186 | +n/a |
| 187 | + |
| 188 | +## Support Procedures |
| 189 | + |
| 190 | +SOP for any region |
| 191 | + |
| 192 | +## Infrastructure Needed [optional] |
| 193 | + |
| 194 | +PGE Cloud Ops has supplied relevant AWS accounts. |
| 195 | + |
| 196 | +[eusc-diff]: https://docs.aws.eu/esc/latest/userguide/services.html |
| 197 | +[endpoints]: https://docs.aws.eu/general/latest/gr/endpoints.html |
0 commit comments