<p>We faced exactly the same choices for our live service that deploys a laravel API and multiple react apps. </p>

<p>There is no generic correct answer to a question "what tool/provider is better?" as it depends on your circumstances. Cost is a particularly tricky question. Are we just talking about the cost of getting something live, or the cost of running an elastically scalable service, or the cost of running a highly available elastic service that spans data centre availability zones such that it isn't taken down by an outage in a single data centre zone?  </p>

<p>Digital Ocean ("DO") is very highly promoted in the Laravel community so it was "the default" for the development team when I joined a startup about two months from go-live. When I asked "what about data centre availability zones" the answer at the time for Digital Ocean was that they didn't support it and we would have to set-up in two different DO data centres and work on our own mechanism (e.g. DNS) to switch between them if DO had a major outage in one place. Yet on AWS they have availability zones and also Elastic Load Balancer so its far easier to get a setup going that is "future ready" if you intend to be running a very successful large scale service a year after launch. </p>

<p>In the end we went live on openshift.com which is a shared kubernetes service running on AWS. So our live DNS points at the Elastic Load Balancer of a shared Kubernetes cluster were we rent space for our containers. The cluster we are on has containers by other companies and runs across many AWS EC2 virtual machines. Yet they are not dedicated to us so we only pay a small fraction of the costs. Yet if any one virtual machines crashes where our containers are running openshift kubernetes automatically starts a replacement container on another virtual machine. So we have automated high availability and crash recovery but only pay-as-we-go for the memory and CPU we currently use. We can scale up more containers anytime we want by using changing the replica count. Openshift has internal load balancing so that a single internal service IP with an internal DNS name automatically points at however many containers we want to run of a particular type. That solves discovery between our services. If you deploy a redis instance from the built-in catalog it is instantly available on a private IP with a DNS entry only viable in your project. That sort of ”discovery” feature is really important when you are running microservices at scale. </p>

<p>With our setup, we get a great low-cost price for a very professional, elastic, highly scalable, fully automated infrastructure-as-code setup, that has all the advantages of AWS ELB, and all the advanced features of kubernetes for microservices. </p>

<p><strong>Edit:</strong> I wrote a tutorial for my experiences running laravel backend with a reactjs frontend on openshif.com that is over at <a href="https://gist.github.com/simbo1905/d27ba7218a2fd71fcb4f0fcede82fd6d" rel="nofollow noreferrer">https://gist.github.com/simbo1905/d27ba7218a2fd71fcb4f0fcede82fd6d</a> </p>

CC BY-SA 4.0
2018-11-10T09:20:41.060Z
2018-11-10T18:53:14.357Z
2018-11-10T18:53:14.357Z
simbo1905
<p>I would suggest to use AWS as this platform is far more mature than DO. You start with one app, but I assume more apps will be deployed. If you deploy and investigate everything yourself it costs also a lot of money. Imagine that you want to deploy a HA postgres cluster in DO, good luck with that. In AWS it is just a matter of a couple of clicks.</p>

CC BY-SA 4.0
2019-01-12T16:21:43.083Z
2019-01-12T16:21:43.083Z
030
<p>This is kind of a subjective question but I will try to answer it as objectively as I can. Naturally you can list the advantages and disadvantages of the possible choices. Both choices offer about the same availability if I understand correctly. AWS is never cheapest in the price comparisons that I read. So that gives DigitalOcean an advantage. </p>

<p>For reasons from my management, I use AWS all the time but if I would start a project today then I would go for DigitalOcean because I also have seen price comparisons where AWS is never cheapest. Competition is good for everybody and therefore it is good to buy from competitors so that AWS feels a competition. </p>

<p>If features and pricing is your main concern and if DigitalOcean can do it, then you have convincing arguments to use DigitalOcean. </p>

<p>If complete automation with something like Cloudformation is your goal and if you already know AWS very well, then you might want to go with AWS instead because you already know it. </p>

CC BY-SA 4.0
2018-11-10T13:27:11.610Z
I've an experience with AWS of about a month, but I don't think it is much at all, since I've a free trial period of 12 month with AWS I think I should give it a try.
Talib Allauddin
CC BY-SA 4.0
2018-11-10T05:21:36.123Z
2018-11-10T05:21:36.123Z
Niklas Rosencrantz
<p>If your main concern is pricing, try Linode - an AWS alternative. Linode is a cloud service provider recently purchased by Akamai.</p>
<p>It has great support, docs and you can <a href="https://www.rokpoto.com/how-to-create-kubernetes-cluster-on-linode-using-cli/" rel="nofollow noreferrer">create Kubernetes cluster</a> there very fast comparing to other cloud providers, where you can deploy your Laravel app.</p>
<p>Disclaimer, I wrote the linked article.</p>

CC BY-SA 4.0
2023-02-01T17:42:37.117Z
2023-02-01T17:42:37.117Z
rokpoto.com
<p>There are a couple of additional  considerations to take into account when you compare your service between AWS and Digital Ocean.</p>

<p>If you know your service needs to be hosted on instances and you can estimate your performance needs well then you can buy reserved instances which give you between 30 and 50% off the listed price.</p>

<p>If you are in the early stages of a project you should also be able to run your service for free for 12 months. After that you should be able to estimate what reserved instances to use.</p>

<p>Keep in mind that various AWS services can significantly reduce your service costs while costing barely anything themselves such as API gateway caching, Cloudfront and Lambda@Edge.</p>

<p>Also AWS autoscaling features should allow you to use peaks and troughs in traffic to optimise your costs. You do need some basic scale for that though. </p>

<p>But more importantly Lambda should be your service of choice for microservices. It has a billing granularity of 100ms and 128Mb memory and a permanent free tier for a certain amount of "grains". It therefore can work like auto scaling, but with a startup and shutdown time of 100ms eliminating all costs where your service is actually not used. </p>

CC BY-SA 4.0
2018-11-10T08:53:06.873Z
lambda is 2x price of reserved instances and depending on what runtimes you are using its going to have lots of latency on your 99th percentile that depending on your app can cause you problems. your answer would be improved by removing the last paragraph.
simbo1905
CC BY-SA 4.0
2018-11-10T13:22:02.160Z
Yes, I'm at the early stage and also I can avail the 12 months free trial period. Thanks.
Talib Allauddin
CC BY-SA 4.0
2018-11-10T07:44:32.493Z
2018-11-10T07:44:32.493Z
jdog
<p>I'm working on a project based on Microservice architecture in Laravel, which means I'll have many small apps and Databases, I'm confused weather I should buy AWS EC2 or Digital Ocean's hosting. My concern is pricing, In numbers I'm having a 100% price difference and getting Digital Ocean's hosting in 50% of the price with more features then what I'm getting on AWS.</p>

<p>Please suggest me what would be the better option.</p>

<amazon-ec2><microservices>
Digital Ocean vs AWS EC2 for Laravel based application
Talib Allauddin
# Digital Ocean vs AWS EC2 for Laravel based application

(Asked by: username_0 on 2018-11-10)

I'm working on a project based on Microservice architecture in Laravel, which means I'll have many small apps and Databases, I'm confused weather I should buy AWS EC2 or Digital Ocean's hosting. My concern is pricing, In numbers I'm having a 100% price difference and getting Digital Ocean's hosting in 50% of the price with more features then what I'm getting on AWS.

Please suggest me what would be the better option.

**Tags:** amazon-ec2, microservices


---

## 5 answers

### Answer by username_1 on 2018-11-10. Score: 5

We faced exactly the same choices for our live service that deploys a laravel API and multiple react apps.

There is no generic correct answer to a question "what tool/provider is better?" as it depends on your circumstances. Cost is a particularly tricky question. Are we just talking about the cost of getting something live, or the cost of running an elastically scalable service, or the cost of running a highly available elastic service that spans data centre availability zones such that it isn't taken down by an outage in a single data centre zone?

Digital Ocean ("DO") is very highly promoted in the Laravel community so it was "the default" for the development team when I joined a startup about two months from go-live. When I asked "what about data centre availability zones" the answer at the time for Digital Ocean was that they didn't support it and we would have to set-up in two different DO data centres and work on our own mechanism (e.g. DNS) to switch between them if DO had a major outage in one place. Yet on AWS they have availability zones and also Elastic Load Balancer so its far easier to get a setup going that is "future ready" if you intend to be running a very successful large scale service a year after launch.

In the end we went live on openshift.com which is a shared kubernetes service running on AWS. So our live DNS points at the Elastic Load Balancer of a shared Kubernetes cluster were we rent space for our containers. The cluster we are on has containers by other companies and runs across many AWS EC2 virtual machines. Yet they are not dedicated to us so we only pay a small fraction of the costs. Yet if any one virtual machines crashes where our containers are running openshift kubernetes automatically starts a replacement container on another virtual machine. So we have automated high availability and crash recovery but only pay-as-we-go for the memory and CPU we currently use. We can scale up more containers anytime we want by using changing the replica count. Openshift has internal load balancing so that a single internal service IP with an internal DNS name automatically points at however many containers we want to run of a particular type. That solves discovery between our services. If you deploy a redis instance from the built-in catalog it is instantly available on a private IP with a DNS entry only viable in your project. That sort of ”discovery” feature is really important when you are running microservices at scale.

With our setup, we get a great low-cost price for a very professional, elastic, highly scalable, fully automated infrastructure-as-code setup, that has all the advantages of AWS ELB, and all the advanced features of kubernetes for microservices.

**Edit:** I wrote a tutorial for my experiences running laravel backend with a reactjs frontend on openshif.com that is over at <https://gist.github.com/username_1/d27ba7218a2fd71fcb4f0fcede82fd6d>


---

### Answer by username_5 on 2018-11-10. Score: 1

There are a couple of additional considerations to take into account when you compare your service between AWS and Digital Ocean.

If you know your service needs to be hosted on instances and you can estimate your performance needs well then you can buy reserved instances which give you between 30 and 50% off the listed price.

If you are in the early stages of a project you should also be able to run your service for free for 12 months. After that you should be able to estimate what reserved instances to use.

Keep in mind that various AWS services can significantly reduce your service costs while costing barely anything themselves such as API gateway caching, Cloudfront and Lambda@Edge.

Also AWS autoscaling features should allow you to use peaks and troughs in traffic to optimise your costs. You do need some basic scale for that though.

But more importantly Lambda should be your service of choice for microservices. It has a billing granularity of 100ms and 128Mb memory and a permanent free tier for a certain amount of "grains". It therefore can work like auto scaling, but with a startup and shutdown time of 100ms eliminating all costs where your service is actually not used.

> **Comments:**
> **username_1**: lambda is 2x price of reserved instances and depending on what runtimes you are using its going to have lots of latency on your 99th percentile that depending on your app can cause you problems. your answer would be improved by removing the last paragraph.  
> **username_0**: Yes, I'm at the early stage and also I can avail the 12 months free trial period. Thanks.  

---

### Answer by username_2 on 2019-01-12. Score: 0

I would suggest to use AWS as this platform is far more mature than DO. You start with one app, but I assume more apps will be deployed. If you deploy and investigate everything yourself it costs also a lot of money. Imagine that you want to deploy a HA postgres cluster in DO, good luck with that. In AWS it is just a matter of a couple of clicks.


---

### Answer by username_3 on 2018-11-10. Score: 0

This is kind of a subjective question but I will try to answer it as objectively as I can. Naturally you can list the advantages and disadvantages of the possible choices. Both choices offer about the same availability if I understand correctly. AWS is never cheapest in the price comparisons that I read. So that gives DigitalOcean an advantage.

For reasons from my management, I use AWS all the time but if I would start a project today then I would go for DigitalOcean because I also have seen price comparisons where AWS is never cheapest. Competition is good for everybody and therefore it is good to buy from competitors so that AWS feels a competition.

If features and pricing is your main concern and if DigitalOcean can do it, then you have convincing arguments to use DigitalOcean.

If complete automation with something like Cloudformation is your goal and if you already know AWS very well, then you might want to go with AWS instead because you already know it.

> **Comments:**
> **username_0**: I've an experience with AWS of about a month, but I don't think it is much at all, since I've a free trial period of 12 month with AWS I think I should give it a try.  

---

### Answer by username_4 on 2023-02-01. Score: 0

If your main concern is pricing, try Linode - an AWS alternative. Linode is a cloud service provider recently purchased by Akamai.

It has great support, docs and you can [create Kubernetes cluster](https://www.username_4/how-to-create-kubernetes-cluster-on-linode-using-cli/) there very fast comparing to other cloud providers, where you can deploy your Laravel app.

Disclaimer, I wrote the linked article.


---

