Amazon EC2 vs Amazon S3: What are the differences?
Amazon EC2: Scalable, pay-as-you-go compute capacity in the cloud. Amazon Elastic Compute Cloud (Amazon EC2) is a web service that provides resizable compute capacity in the cloud. It is designed to make web-scale computing easier for developers; Amazon S3: Store and retrieve any amount of data, at any time, from anywhere on the web. Amazon Simple Storage Service provides a fully redundant data storage infrastructure for storing and retrieving any amount of data, at any time, from anywhere on the web.
Amazon EC2 can be classified as a tool in the "Cloud Hosting" category, while Amazon S3 is grouped under "Cloud Storage".
Some of the features offered by Amazon EC2 are:
- Elastic – Amazon EC2 enables you to increase or decrease capacity within minutes, not hours or days. You can commission one, hundreds or even thousands of server instances simultaneously.
- Completely Controlled – You have complete control of your instances. You have root access to each one, and you can interact with them as you would any machine.
- Flexible – You have the choice of multiple instance types, operating systems, and software packages. Amazon EC2 allows you to select a configuration of memory, CPU, instance storage, and the boot partition size that is optimal for your choice of operating system and application.
On the other hand, Amazon S3 provides the following key features:
- Write, read, and delete objects containing from 1 byte to 5 terabytes of data each. The number of objects you can store is unlimited.
- Each object is stored in a bucket and retrieved via a unique, developer-assigned key.
- A bucket can be stored in one of several Regions. You can choose a Region to optimize for latency, minimize costs, or address regulatory requirements. Amazon S3 is currently available in the US Standard, US West (Oregon), US West (Northern California), EU (Ireland), Asia Pacific (Singapore), Asia Pacific (Tokyo), Asia Pacific (Sydney), South America (Sao Paulo), and GovCloud (US) Regions. The US Standard Region automatically routes requests to facilities in Northern Virginia or the Pacific Northwest using network maps.
"Quick and reliable cloud servers", "Scalability" and "Easy management" are the key factors why developers consider Amazon EC2; whereas "Reliable", "Scalable" and "Cheap" are the primary reasons why Amazon S3 is favored.
Airbnb, Uber Technologies, and Netflix are some of the popular companies that use Amazon EC2, whereas Amazon S3 is used by Airbnb, Spotify, and Netflix. Amazon EC2 has a broader approval, being mentioned in 3607 company stacks & 1618 developers stacks; compared to Amazon S3, which is listed in 3235 company stacks and 1615 developer stacks.
What is Amazon EC2?
What is Amazon S3?
Need advice about which tool to choose?Ask the StackShare community!
Sign up to add, upvote and see more prosMake informed product decisions
Sign up to get full access to all the companiesMake informed product decisions
Sign up to get full access to all the tool integrationsMake informed product decisions
We chose AWS because, at the time, it was really the only cloud provider to choose from.
We tend to use their basic building blocks (EC2, ELB, Amazon S3, Amazon RDS) rather than vendor specific components like databases and queuing. We deliberately decided to do this to ensure we could provide multi-cloud support or potentially move to another cloud provider if the offering was better for our customers.
We’ve utilized c3.large nodes for both the Node.js deployment and then for the .NET Core deployment. Both sit as backends behind an nginx instance and are managed using scaling groups in Amazon EC2 sitting behind a standard AWS Elastic Load Balancing (ELB).
While we’re satisfied with AWS, we do review our decision each year and have looked at Azure and Google Cloud offerings.
#CloudHosting #WebServers #CloudStorage #LoadBalancerReverseProxy
Stitch is run entirely on AWS. All of our transactional databases are run with Amazon RDS, and we rely on Amazon S3 for data persistence in various stages of our pipeline. Our product integrates with Amazon Redshift as a data destination, and we also use Redshift as an internal data warehouse (powered by Stitch, of course).
The majority of our services run on stateless Amazon EC2 instances that are managed by AWS OpsWorks. We recently introduced Kubernetes into our infrastructure to run the scheduled jobs that execute Singer code to extract data from various sources. Although we tend to be wary of shiny new toys, Kubernetes has proven to be a good fit for this problem, and its stability, strong community and helpful tooling have made it easy for us to incorporate into our operations.
CodeFactor being a #SAAS product, our goal was to run on a cloud-native infrastructure since day one. We wanted to stay product focused, rather than having to work on the infrastructure that supports the application. We needed a cloud-hosting provider that would be reliable, economical and most efficient for our product.
CodeFactor.io aims to provide an automated and frictionless code review service for software developers. That requires agility, instant provisioning, autoscaling, security, availability and compliance management features. We looked at the top three #IAAS providers that take up the majority of market share: Amazon's Amazon EC2 , Microsoft's Microsoft Azure, and Google Compute Engine.
AWS has been available since 2006 and has developed the most extensive services ant tools variety at a massive scale. Azure and GCP are about half the AWS age, but also satisfied our technical requirements.
It is worth noting that even though all three providers support Docker containerization services, GCP has the most robust offering due to their investments in Kubernetes. Also, if you are a Microsoft shop, and develop in .NET - Visual Studio Azure shines at integration there and all your existing .NET code works seamlessly on Azure. All three providers have serverless computing offerings (AWS Lambda, Azure Functions, and Google Cloud Functions). Additionally, all three providers have machine learning tools, but GCP appears to be the most developer-friendly, intuitive and complete when it comes to #Machinelearning and #AI.
The prices between providers are competitive across the board. For our requirements, AWS would have been the most expensive, GCP the least expensive and Azure was in the middle. Plus, if you #Autoscale frequently with large deltas, note that Azure and GCP have per minute billing, where AWS bills you per hour. We also applied for the #Startup programs with all three providers, and this is where Azure shined. While AWS and GCP for startups would have covered us for about one year of infrastructure costs, Azure Sponsorship would cover about two years of CodeFactor's hosting costs. Moreover, Azure Team was terrific - I felt that they wanted to work with us where for AWS and GCP we were just another startup.
In summary, we were leaning towards GCP. GCP's advantages in containerization, automation toolset, #Devops mindset, and pricing were the driving factors there. Nevertheless, we could not say no to Azure's financial incentives and a strong sense of partnership and support throughout the process.
Bottom line is, IAAS offerings with AWS, Azure, and GCP are evolving fast. At CodeFactor, we aim to be platform agnostic where it is practical and retain the flexibility to cherry-pick the best products across providers.
We are hardcore Kubernetes users and contributors. We loved the automation it provides. However, as our team grew and added more clusters and microservices, capacity and resources management becomes a massive pain to us. We started suffering from a lot of outages and unexpected behavior as we promote our code from dev to production environments. Luckily we were working on our AI-powered tools to understand different dependencies, predict usage, and calculate the right resources and configurations that should be applied to our infrastructure and microservices. We dogfooded our agent (http://github.com/magalixcorp/magalix-agent) and were able to stabilize as the #autopilot continuously recovered any miscalculations we made or because of unexpected changes in workloads. We are open sourcing our agent in a few days. Check it out and let us know what you think! We run workloads on Microsoft Azure Google Kubernetes Engine and Amazon EC2 and we're all about Go and Python!
Heroku was a decent choice to start a business, but at some point our platform was too big, too complex & too heterogenic, so Heroku started to be a constraint, not a benefit. First, we've started containerizing our apps with Docker to eliminate "works in my machine" syndrome & uniformize the environment setup. The first orchestration was composed with Docker Compose , but at some point it made sense to move it to Kubernetes. Fortunately, we've made a very good technical decision when starting our work with containers - all the container configuration & provisions HAD (since the beginning) to be done in code (Infrastructure as Code) - we've used Terraform & Ansible for that (correspondingly). This general trend of containerisation was accompanied by another, parallel & equally big project: migrating environments from Heroku to AWS: using Amazon EC2 , Amazon EKS, Amazon S3 & Amazon RDS.
We use Terraform because we needed a way to automate the process of building and deploying feature branches. We wanted to hide the complexity such that when a dev creates a PR, it triggers a build and deployment without the dev having to worry about any of the 'plumbing' going on behind the scenes. Terraform allows us to automate the process of provisioning DNS records, Amazon S3 buckets, Amazon EC2 instances and AWS Elastic Load Balancing (ELB)'s. It also makes it easy to tear it all down when finished. We also like that it supports multiple clouds, which is why we chose to use it over AWS CloudFormation.
Our base infrastructure is composed of Debian based servers running in Amazon EC2 , asset storage with Amazon S3 , and Amazon RDS for Aurora and Redis under Amazon ElastiCache for data storage.
We are starting to work in automated provisioning and management with Terraform , Packer , and Ansible .
A VPS gives the full access that I need, because most of what I do has complex integrations and there is plenty of legacy - very stable, highly tuned code developed over two decades - that I carry with me. My use is also limited to during development, so there is no point going for a full server.
Amazon EC2 is a VPS, except it is cheaper.
Additionally, I used to previously take the code developed on my VPS and deploy it to whatever server the client brought.
With Amazon EC2 the deployment is already done. All that remains it to scale up, add other products like dns, mail, storage and so on, and change the billing so that the client gets invoiced. That makes the process that much more predictable and seamless, and the end result much more stable.
Just started using EC2 myself, but it was the platform used by my previous employer, as well. They are getting easier to use, dashboard improvements over time were well done. Responded fast to outages. They offer a limited free tier which is perfect for my current project, allowing me time to build it to the point where I will need a paid solution. Overall, I'm liking it so far.
Insanely low prices, quite easy to use, and they're fast. Plus they provide great support. And they're integrated with other AWS services, like CloudFront.
Seriously, this is the best service of it's kind out there.
About a year and a half ago (written June 2013) we moved from dedicated servers over to AWS. Thanks to AWS, we no longer have to think on a server level. Instead, we think of everything as a cluster of instances, and an instance is essentially a virtual server where we don’t have to worry about the hardware. It’s a relief to not have to worry about the hardware behind the instances.
The clusters we have are: WWW, API, Upload, HAProxy, HBase, MySQL, Memcached, Redis, and ElasticSearch, for an average total of 80 instances. Each cluster handles the job that its name describes, all working together for the common goal of giving you your daily (hourly?) dose of image entertainment.
Below is a diagram of how they all work together:
We liked a lot of things about Heroku. We loved the build packs, and we still in fact use Heroku build packs, but we were frustrated by lack of control about a lot of things. It’s nice to own the complete stack, or rather as far down as AWS goes. It gave us a lot of flexibility and functionality that we didn’t have before. We use a lot of Amazon technology.
We store the software components that CloudRepo stores for its customers here for the following reasons:
- Data is Encrypted at Rest
- Data is stored across multiple physical locations
- Pricing is competitive
- Reliability is industry leading and our customers need to be able to access their data at all times list text here
In October 2008 we moved to using scribe (now a custom branch), which has served us very well over the past 5+ years that we’ve been using it. We take the logs scribe aggregates and move them into Amazon S3 for storage, which makes using EMR on AWS seamless.
S3 serves as zero-knowledge temporary storage. Files are encrypted in the browser before being uploaded in chunks to S3. When the target recipient downloads them the chunks are reassembled and decrypted in the browser. Files expire after a week and the encrypted chunks are permanently deleted from S3.
I like containers and all, but for zerotoherojs.com I am a one-man band, who also works full time. I don’t have any (dev)ops budget, and therefore I need the reliability and uptime of an actual virtual machine.
That’s where AWS EC2 comes in handy.
Docker containers will be hosted and run on a single Amazon EC2 instance. This will likely be the t2.small or t2.medium instance type as listed here: https://aws.amazon.com/ec2/instance-types/
Because servers. Lots of them. Lots of configurations. Great for mission-specific functions. Video encoding, data aggregation, dedicated processing, mission-critical data stores. Anything you can't hang off your Heroku environment.
Since we generate a static website for our website, AWS S3 provides hosting for us so that we don't have to run our own servers just to serve up static content.
The pricing is great as you only pay for what you use.