Hi @Otto Medin !
HTTP is basically US ASCII 7bit with some "handcrafted" extensions
- somehow "UTF 7.6" 
🤪 focussing on octets
it works for äöü  but NOT for €  (x20AC)  >>> in URL  %u20AC

for details: https://softwareengineering.stackexchange.com/questions/304419/what-encoding-are-the-http-status-and-header-lines

my hint: Try to avoid it in HTTP headers and stick with 7bit ASCII to be on the save side
browsers are less risk for problems but old applications are

Manipulating time values is a risky ground. See this simple example.
 

USER>write ?1%, $ZTZ," : ",$zdt($ZTS)," : ",$zdt($now())," : ",$zdt($h)
               -60 : 07/04/2024 16:03:42 : 07/04/2024 17:03:42 : 07/04/2024 18:03:42
  • $ZTZ  is the geographic offset to UTC in minutes
  • $ZTS is UTC time  (no daylight saving !)
  • $NOW() is UTC adjusted by $ZTZ   (no daylight saving  or special time zone adjustment)
  • $H is based on the time set in your server OS  

So for international applications using anything else than UTC is an open trap you might be caught in.

This was the original motivation to use UTC in ENSEMBLE and it's descendants and followers 

I just had a similar picture when my trial account was terminated.
see:
  https://community.intersystems.com/post/intersystems-iris-cloud-sql-and-intersystems-iris-cloud-integratedml-are-now-generally

To encourage experimentation and developer creativity, new subscribers automatically receive a $300 credit for running deployments of any size. Beyond this free credit, customers will be billed through their AWS account.

@Alexey Nechaev 
In my trial  file  SSLDefs.ini was placed into 
C:\Program Files (x86)\Common Files\InterSystems\IRIS\ 
whích required admin access rights
I also gave Full Access to Everyone for the file (to avoid conflicts with 👿 MS security)

in addition also my ip address was NUMERIC to match DSN
so your's should look like this

[My CloudSQL Server] 
Address=44.221.219.249
Port=443
SSLConfig=SampleSSLConfig