Amazon S3 Reviews

I have different use cases. One major one is hosting static content for our legacy front-end application. We deploy all the static files to an S3 bucket, which is configured for web hosting. 

Additionally, we have an Akamai layer on top of S3, so all requests first hit Akamai and are then routed to S3, according to our HTML routing, before reaching the backend service.

It's very well secured. We have S3 policies that allow you to write custom policies. These control access to the users and can grant or deny permissions. Additionally, your buckets can be configured as private or public.

Amazon S3 offers multiple beneficial features. One advantage is static web hosting, which eliminates the need for a dedicated server. We also have S3 for storage, where we can upload necessary files for processing. 

Furthermore, it supports an SFTP service, where we set up an SFTP server on top of S3 and use credentials to transfer data from remote locations. 

S3's lifecycle policies are also crucial; they automate the deletion or downgrading of files that are no longer needed. Moreover, we can set permissions to restrict or allow user access to the data.

Using S3, we can load data into databases and trigger AWS Lambda functions, which enhances our operational flexibility.

Sometimes while using S3, I've wished for certain features.

One thing would be automatic replication between buckets, some feature like that.

I have been using it for more than five years. 

It's almost 100% stable. I've never seen S3 go down. It's always available. As mentioned in the documentation, it has 99.999999999% availability.

I would rate the stability a ten out of ten.

There are two aspects to consider regarding S3 scalability. While there is a hard limit of thousands of buckets per AWS account, there's virtually no limit on the amount of data you can store within a single S3 bucket.

Anyone with access to our AWS accounts has the potential to use S3. But in terms of my applications, nearly all of them utilize S3 in some way or another.

The customer service and support are highly skilled and technical. Whenever I have issues with any service, whether it's S3 or something else, I always get a resolution.

The response time is good. I've always been able to connect with an agent and resolve the issue on the spot.

Positive

There's Azure Block Storage and Google Cloud Storage.  

The initial setup is very straightforward. You just need to provide the bucket name, the region where you want it created, and some basic permissions. It's a three or four-step process.

Currently, I use the public cloud for my entire infrastructure. All the deployments are in the cloud.

The pricing is good. The main charges for S3 are data transfer and storage. You can create as many buckets as you need and manage them according to your requirements. Naturally, the more you use any service, the higher the cost.

I find it very useful. It's one of the best services out there. I'd give it a nine out of ten. I would recommend it – every user should utilize it for storage.

We host applications on Amazon Web Services (AWS). We set up EC2 for running various applications and utilize S3 storage for data storage. For databases, we use MySQL and Microsoft API instead of AWS databases.

Amazon S3 is easily scalable and provides fantastic performance, especially in comparison to other cloud solutions like OCI and Azure. Its availability is high, almost at 99%, which is important for ensuring reliable access to stored data.

In terms of security, I struggled with setting permissions and access control initially.

I have been using AWS for five years.

Amazon S3 is highly stable. In my experience, it does not break down and there has been no downtime.

Amazon S3 is easily scalable and performs better compared to other cloud storage solutions.

The AWS support team is great. They have different levels of severity for support cases, and an engineer is assigned based on the severity of the issue.

Positive

I have used Oracle Cloud Infrastructure (OCI) and Azure. S3 provides better scalability and performance compared to these solutions.

I have used OCI and Azure.

The initial setup of Amazon S3 is easy. It provides a user-friendly GUI, and setting up instances is straightforward. All you need is experience to perfect the setup process.

In-house engineers deploy solutions for customers and provide support to banks for AWS deployment.

Amazon S3 is user-friendly for beginners and easy to manage. I would rate Amazon S3 as nine out of ten.

My primary use case for Amazon S3 includes using it for backups and deploying a website on an S3 bucket. Additionally, for my organization, it is used to deploy websites and leverage its architecture for deploying applications.

Amazon S3 has been beneficial because it is cost-effective and simplifies my data management through its life cycle policy, which automatically manages data I no longer need.

The most valuable feature of Amazon S3 for me is static deployment; it doesn't charge much, and I can integrate CloudFront for DNS and routing. It is very useful and affordable. 

Another valuable feature is versioning, which is critical for data management, allowing data recovery. Moreover, the life cycle policy feature is useful as it automatically manages data, making storage efficient.

The service could improve by offering mobile backups, which would be great since using Google Backup is costly. The complexity of the initial setup due to partitioning data over five GB could also be simplified.

I have been working with Amazon S3 for three months.

Amazon S3 is very stable. I don't worry about data stored in the S3 bucket as it's safe.

Amazon S3's automatic scaling has benefited me, as I don't need to plan storage requirements. I rate scalability as eight out of ten.

I haven't used the technical support team yet, as I have never required it.

Before Amazon S3, I used Google Backup and on-premises infrastructure. I switched due to the cost-effectiveness, scalability, and stability of Amazon S3.

The initial setup was a bit hectic. Uploading data only allows for five GB chunks, creating challenges. Another difficult aspect was managing bucket access policies, which have multiple layers, complicating the setup further.

In my organization, we have one person handling the maintenance of Amazon S3. Implementation involves understanding client architecture, developing cloud architecture, and ensuring security with future requirements.

I don't need to buy infrastructure hardware for backups, which is quite useful and has benefited me.

I rate the pricing as six out of ten. It is somewhat justified due to the benefits, but there is room for reconsideration.

I did not evaluate other options; Amazon S3 was my first choice and currently suits my needs.

New users should not store sensitive data on Amazon S3. Overall, I rate Amazon S3 an eight out of ten.

One of the use cases is to store Veeam backups. It's more complex than Veeam, which is simpler.

S3 is essentially object storage, a place to store data that you can set up however you want. We usually connect to S3 using the API. It requires an access key and a secret key, which we input into the application we're connecting from. Then, that application can see the S3 bucket as if it were local, and we can copy stuff into it.

The best thing about S3 is the security. I can enable encryption at rest using a KMS server, a key management server. Key management servers encrypt data, and you need the key to decrypt it. Without the key, you can't access the data. Amazon allows you to use your own servers or theirs. They offer Amazon encryption, which you decide on when you create the bucket. The bucket also has all the other features like versioning.

We can do versioning and life cycles. The biggest plus for me as a storage admin is the different tiers: standard, infrequent access, Glacier, and Glacier Deep Archive. The differences between these tiers are cost and data retrieval speed. Standard tier data is considered "hot," meaning it's accessible anytime, but it's expensive.

If you want to archive data you won't need often, or if you have ample time to retrieve a backup, the most cost-effective option is Glacier Deep Archive. It's very cheap, but the disadvantage is that when you request data, it takes up to 24 hours to become accessible.

There are no limitations on how much you can store, but the biggest limitation is that you cannot use Glacier Deep Archive from the console. You can't go into the AWS console and copy something directly into Deep Glacier, but you can do it from the command line. If you have programmatic access, there's a command to put data directly into Glacier Deep Archive.

We don't use anything AI on AWS right now. The AI stuff isn't really too useful for us yet. We're just playing around with Copilot from Microsoft, which is more on the Azure side. We haven't leveraged any AWS AI stuff yet. We've basically just been playing around with Amazon Bedrock, but haven't done anything in production with it.

There's a lot of complexity, but that's unavoidable because it needs to be versatile. You have to be able to get the data in many different ways. 

For example, if you need to give just one file to someone outside the office, you can create a temporary pre-signed URL for them to access it. That takes a little bit of fiddling with the settings, but it's not really a disadvantage. It's just part of the system. There's no real way to make that easier. The more secure something is, the more complex it will be.

We're not dealing with it extensively right now. We're studying migrating to AWS resources but haven't moved much yet. We've mainly been doing proof of concepts and testing. S3 is what we've been using the most, though.

It's a little bit harder to get the customer service and support compared to Veeam. Veeam is very good, definitely a ten out of ten. 

Amazon support so far has been maybe a seven out of ten.

Neutral

The initial setup is complex in the sense that you need to know what will access the data and what won't. That's the biggest issue. For example, let's say you have an EC2 instance that needs to access an S3 bucket, but everything else needs to be locked out. There are several ways to do that, like creating a bucket policy and allowing only the EC2 resource to access it. That requires creating a role.

On the other hand, if you just want a public S3 bucket where everyone has access to unprotected data, like public documentation on a product, that's very easy to set up.

So, it can be as easy or as complex as you need it to be.

I tool care of the solution. It's me and my colleague who is more on the vSphere and storage admin side, and one of the networking guys to help with the networking portion.

Once it's set up, there's really no maintenance.

We don't expect to see ROI at the moment, but we're hoping to see some returns once we start moving data loads to the cloud. Then, we can start decommissioning a lot of the on-premises hardware. We'll need less storage and computing as more gets deployed to the cloud.

The licensing model is complex. If you need your backup data available at all times, but don't access it frequently, there are better options. You could go with S3, but other vendors offer the same thing for much better prices. For example, Wasabi has S3-compatible hot storage and charges a lot less.

The disadvantage of Wasabi is that they don't want you accessing the data frequently. They say you can have it right away if you need it, but if you keep accessing it all the time, you're going beyond their service agreement. At that point, you'd need to go with an Amazon solution.

If you're going to store data in an archive that you don't need to access frequently and can wait up to 24 hours to retrieve, then Amazon is a good solution.

Amazon would definitely be a seven out of ten, where one is the lowest price and ten is the most expensive.

I would recommend it as part of a good backup strategy. The 3-2-1 approach suggests having three hot copies, two cold storage copies, and one off-site copy. That off-site copy could definitely be an S3 bucket. So I would recommend it in that sense.

Overall, I would rate it a seven out of ten because it's great for general storage. If you need to access a lot of data all the time and it needs to be fast, then it's not the best solution. There are better solutions out there.

We use Amazon S3 to store source files. We load the data we ingest from the source system into the solution, which is then consumed on Snowflake.

Amazon S3 is very flexible and provides high storage.

No direct connector is available to connect Amazon S3 with other tools like MicroStrategy. So, I have to use a third party and connect to it.

I have been using Amazon S3 for three years.

Amazon S3 is a stable solution.

Around 50 users from the infrastructure team are using the solution in our organization.

The solution's technical support is pretty good. Although the support team's response time is a little slow, everything else is fine, and they are resolving our issues.

Positive

The solution's initial setup is comparatively difficult because only someone with cloud knowledge can use Amazon S3.

Amazon S3 works on a pay-as-you-go model, and it is worth the money if used to its potential.

The solution is cost-effective because it is based on a pay-as-you-go model, where I can purchase and use it according to my needs.

Our organization chose Amazon S3 because of its scalability, security, and encryption. Since the solution is used for storage, it provides a higher transfer rate to transfer files from one location to another.

Amazon S3 is a good choice for someone with a lot of files and needs a lot of storage with easy computation, scalability, and backups.

Overall, I rate Amazon S3 a nine out of ten.

We use Amazon S3 for data storage purposes. We use the stored data for restoration or backup when there is a data leakage in websites and mobile applications. For enterprise-level applications, the stored data is also used for data analytics, backup, recovery, etc.

The tool helps us with data backup storage of payment files and helps us avoid issues with clients when we miss the data. For instance, in the payment file of my Google client, you can find details of one-to-one transactions like the payment information on the file header, payment ID, payment client ID, group headers, etc. We get these details into the file format of ISO which is the accepted format at JP Morgan & Chase. Once we get the file format, we process it through S3.

In S3, we do the syncing process where everything is automated as per the business logic. The data is sent to S3 after the syncing process. S3 will evaluate the data and the format and store it for backup purposes. Whenever we miss a payment, we can just recover the history from the storage bucket. So it helps us manage the features, cost, and regulatory aspects.

I like the S3 Lambda access point and S3 management console which helps with the filtering and returning of data.

Many customers use this tool. We use it for enterprise application data where we store all cloud-native application production data. You can upload any amount of data and access it from anywhere to deploy the applications. However, the tool needs to improve its performance. Clients can reach more end users if the overall process is faster.

The solution can be a perfect tool if it can add more S3 storage classes and manage the authorized users to one bucket and give access to the storage usage and activity trends.

I have been using the solution for the past two years.

The solution’s stability can have a rating of eight out of ten.

I would rate the solution’s scalability a seven out of ten. Scalability depends on the size of the data which can be zero bytes to five TB which is the largest.

I would rate the customer service and support a nine out ten. 

Positive

AWS S3’s setup is not complex, and in fact, manageable. The number of people required for deployment depends on the data. If it is a Single Page Application with single-page data, then one person is enough for the deployment. However, if there are payment files involved, then you need around three to four people in the team to deploy it on the cloud.

There is ROI with the use of the tool. Organizations can benefit from the tool with their business logic.

The tool is not too expensive considering the various pros.

I would rate the solution a nine out of ten. I am not sure about the solution’s version. It should be either four or five. I have practical knowledge of the tool like its implementation. We store data on the S3 bucket and take it to present to the database. The tool is manageable and maintainable by anyone for their work.

This is a perfect tool for data storage. It is good to use S3 as a storage bucket for data.

We have been using Amazon S3 to store some execution results. I am from a testing background. We use the solution to store execution results and whatever evidence we generate.

The solution's most valuable feature is its security, as it does not provide public access.

The solution could be cheaper. EC2 has a feature called get instant screenshot. It would be good if Amazon S3 had an API to get screenshots or video streaming continuously. There are cases where we want to see what is happening in real-time instead of connecting to Amazon EC2. It would be good if we could watch it like a video stream.

I have been using Amazon S3 for almost five years.

We have seen some downtime in the past four to five years, but it was nothing major. We were sometimes unable to launch the machines through code. We do not have a major production environment. We use it mostly for scenario testing, so the stability issue was okay for us. However, it would not be good if the tool went down when a person was deploying it.

There should be a reason or a log for the solution's downtime. When we make an API call, like SDK, it should throw an error or some information so that we know what exactly happened.

The solution’s initial setup is easy.

We don't use the solution for deployment. We use it to execute the scripts on virtual machines. We have a platform built where we click on something, and then the virtual machines get launched automatically based on a certain AMI image. It takes a lot of time, almost 15 to 20 minutes, to start the machine.

Overall, I rate the solution an eight out of ten.

We use S3 buckets to store logs from the application side. The logs stay on the server for seven days. After that, we transfer them to the S3 bucket, depending on the application, and the logs help us correctly troubleshoot problems. 

We can also host web apps in the historical bug bucket. If you have a domain name from Route 53, you can create a bug bucket over there and whatever is in the web applications folder. About 40 people at my company use S3. 

You don't have to specify your clone, availability clone, or your locations. Everything's over there. They have a receipt for the instance where we have to select the exact location of what we are clicking. The S3 storage capacity is high, and the price is reasonable. 

The free web and DB hosting could be improved. It could be faster when you download huge files from the S3 bucket to your local system. If the S3 bucket availability and performance could be improved, we would consider hosting our database over there. 

We have worked with AWS for two or three years. 

I rate Amazon S3 nine out of 10 for stability. 

We usually don't need much help unless we experience some technical glitches. Amazon has helped us in those instances.

Positive

You can deploy the solution in under 10 minutes. 

The price is based on the size of your files and how long they will be retained. If you want something like a grade 2 segment and 10 GB of data transfers, it's around $0.5. 

We use S3 because all of our applications are on AWS. We have to use everything on the same cloud platform. The cost will be too high if you need to configure things to work across multiple cloud providers. It's highly complicated and expensive to set up cross-routing.  

I rate Amazon S3 eight out of 10. It's highly stable, scalable, and cost-effective. I recommend S3 depending on the customer's requirements. It's good if you need to store a large amount of read-only data. It isn't for block storage that you need to edit, but it's good for storing application logs.