You are correct, only TCP and UDP connections are allowed to Azure virtual machines; they are also severely limited, as in "you can only open single ports and not whole port ranges", which effectively disallows the use of dynamic protocols.
You can work around the latter limitation by using an instance-level public IP, which allows all traffic on all ports to a VM (but be sure to turn on your firewall!); however, this will still only allow TCP and UDP traffic.
The only supported option (at the present time) for client VPN connections is to use Azure's built-in client VPN service, which BTW works fine, as long as you can get a client certificate to each of your clients.
Also, as you said, another option could be using HTTPS tunneling for your VPN server instead of IPSec; HTTPS VPNs (including Windows' SSTP) run on TCP port 443, thus they actually could work on Azure VMs; however, if you want to run a VPN server on an Azure VM, you could run into all sorts of networking issues, because Azure VMs really don't play nice when you try to do something not explicitly supported, especially when networking is involved.
Update
AWS would charge $3300 a month for 35TB of outbound bandwidth. Five of the largest Lightsail instances would cost a bit over $800 and would include 35GB of traffic. I assume that you can use the instance bandwidth if you use a load balancer. Their CDN pricing would get you to $2300 per month. You'd probably need another server as a web server, so the better part of $1000 a month.
Given your bandwidth needs I would rule out EC2 / CloudFront. You could consider Lightsail and a load balancer, after you verify load balancers effectively use the instance bandwidth. However, staying with a co-lo might be easier, though less flexible.
Previous Post
MLu gave you a good option, but rearchitecting a website can be difficult. Simply moving the image hosting to S3 with CloudFront (or CloudFlare) might be fairly simple and would be cheaper and faster than hosting it yourself.
Basic Suggestion
If you just want a VPS, work out the specs required in terms of CPU / RAM / disk and put it into the AWS Calculator. Ignore the warning to use the new calculator, the new one isn't very good.
LightSail is a cheap way into AWS - bandwidth is especially cheap. You can get 8 cores, 32GB RAM, and 7TB transfer for $160/month, which would cost about $330 for the server plus $600 for bandwidth. Combine a couple of them (or smaller instances) with a $16 Lightsail load balancer you get a lot of power for not a lot of money. Lightsail is a lot simpler than full AWS.
Architecture Suggestion
Your best option for your architecture is like:
- EC2 instance running Nginx / PHP
- AWS RDS for MySQL
- AWS ALB for load balancing
The difficult part here is sizing the resources. You can take a guess based on CPU usage while watching "top" if you like.
RDS
RDS you need to size for your peak load. Say you have a 4 core server now and MySQL looks to be taking two cores at peak then you probably need a two core RDS MySQL server.
To map that to instance type depends on your off-peak usage. T2 / T3 instances give you a fraction of a CPU, with a burst balance to use more sometimes. If you have a lot of time the website isn't busy it can build up CPU credits off-peak, use them on-peak. db.t2.medium gives you two cores and 4GB RAM, db.t3.medium gives you 2 cores, 8GB RAM, and more CPU credits. If the website is fairly busy most of the time you'll need dedicated CPUs, db.m5.large gives you two cores. You can change DB type fairly easily, but there will be some downtime if you don't have a multi-az instance (google that term to learn more).
EC2
EC2 can be more flexible as you can scale the number of instances based on load. You might choose an m5.large (or m5a for AMD, or m6g for ARM) as your base server, with 2 cores and 8GB RAM. Once it hits a threshold, say 60% CPU usage, AWS can spin up as many instances as are required to help cope with load, then take them down when not needed. You don't typically use t2 / t3 instances in load balancer as they can run out of CPU credits which makes things tricky.
Sizing and Price
Once you work out your architecture and sizing you can plug that into an AWS calculator. You'll need RDS instance, EC2 instances, account for egress bandwidth from the server, account for S3 storage of images and image bandwidth, EBS disk space and snapshots for backup, plus space for an AMI image to auto scale from. You probably then want services like Guard Duty to monitor your account (cheap), CloudTrail logs as audit logs which is just the storage price, and other bits and pieces. It can start to add up.
AWS bandwidth can be very expensive. Before you get into the detail of a calculation do a rough guess of maybe a db.m5.large RDS database, a couple of m5.large EC2 instance, 300GB EBS disk, and your outgoing bandwidth. If you use a lot of bandwidth that might cost more than your current co-lo. If most of your bandwidth is static resources an external CDN like CloudFlare can significantly reduce your costs, if you set up caching headers properly. I don't know how much of your 236GB they would cache, but they'd cache all the often used stuff. All of their 100+ data centers will download resources from your server though, so you'll still use a fair bit of bandwidth.
I have deliberately not explained every term I've used. AWS is complex and can be difficult to do well, securely. You'd really want to do some training to understand AWS before you start to use it. Once you understand AWS it's very powerful, but can be time consuming. Or just use Lightsail as mentioned above.
Best Answer
The newly announced Azure VM role does allow you deploy a Windows VM configured anyway you like and you can RDP to this, so in that respect yes you could do this.
However, Azure vm's do have some difference to ordinary Hyper-V or VMWare VM's. You can't just spawn a new VM in Azure, RDP into it and configure it the way you want. Instead with Azure you create your VM on you own Hyper-V server and configure it how you want, then you configure a Golden Image that you upload to Azure and get's deployed to your VM. At any point Azure can shutdown your VM and create a new one from your golden image. So you need to be in a position where you can create this golden VM how you want locally first.
There is an added complication in that unlike with the Web and Worker role, the VM role is not manager by MS but by you and so you will need to apply any updates patches etc yourself. Again this means you need to not only update your running VM, but your golden image.
Finally you cannot really store any data on your VM, as MS does not guarantee the safety of this data, if your VM gets recreated from you master image, all you get back is what is on the image. Hence you need to store all you data in something like an azure database.