Amazon FSx Reviews

I use Amazon FSx as a shared storage service for Windows, particularly when there are multiple Windows servers and a need for shared storage. I use it when shared resources with different servers, such as Windows Server, are necessary.

The shared storage capability is highly valuable. I can use Amazon FSx to share data across different enterprise environments, and it is extremely useful for medium-sized and large businesses. The ability to easily share anything via IT and for enterprise use is a significant benefit.

Amazon FSx is more costly compared to other storage solutions like EBS or EFS. The auto-scaling feature should be improved, as it currently includes downtime. I need to manually increase the storage, which is not ideal. Integrating FSx with Windows Server is challenging; it's a long process involving Active Directory (AD) setup and synchronization.

I have used Amazon FSx for almost four years.

I rate the stability of Amazon FSx ten out of ten. It depends on the configuration, and if configured for high availability, it is very stable.

I rate the scalability ten out of ten. Amazon FSx is scalable, yet it requires pre-planning to determine the extent needed. The primary scalability concern is with the server rather than the storage aspect.

The initial setup process can be challenging, especially in terms of Active Directory integration. I rate it eight out of ten, there is some difficulty in specific use cases.

The lowest price I have paid is $370 or $380 per month, while the highest can exceed $3,000 per month. The cost is higher compared to other cloud platforms, and it's a significant factor to consider.

I must be aware of my specific use case and choose the solution accordingly. I use FSx when shared storage is required without the need for internet connectivity. It is cheaper to use Amazon S3 when possible. 

I rate the overall solution eight out of ten. Lowering the price would make it better for customers.

Our customers mainly use Amazon FSx for high-performance computing.

Our customers are mainly in the Life Science and Pharma industries.

The majority of people are looking at S3 as their destination with Amazon FSx, as they want to store their data on S3. This is where Amazon FSx helps them to store their data on S3.

Our customers are small and medium businesses.

Amazon FSx integration doesn't involve much with other AWS tools, but we do use it with other high-performance computing where there's a need for higher IO, so it works better.

Amazon FSx is scalable, so there is no problem with its scalability. I'm not sure exactly how we avoid that problem area, but it can be rated as an eight.

At this stage, there aren't many problems with Amazon FSx. Everything else is fine, but when there is a demanding IO requirement, we do go with Weka and other solutions, while for native needs, we prefer FSx.

From my experience, there are areas in Amazon FSx where more performance is needed, as they will be looking for higher IOPS. Sometimes we go with Weka or other solutions due to this need, so it should have more IO capacity when there is a demand.

More performance is needed specifically in the IO area.

I have been working with this solution for almost five years.

I have not faced any issues with the stability of this tool.

Amazon FSx is scalable, so there is no problem with its scalability. I'm not sure exactly how we avoid that problem area, but it can be rated as an eight.

My impression of the support side is good so far. I would rate it an eight.

Positive

Setting up Amazon FSx is easy, and I would rate it a ten.

Deployment does not take much time; it is actually easy.

My customers have seen a return on investment while using Amazon FSx.

My customers see the return on investment mainly for research purposes, as we handle a huge amount of data which requires demanding IO. Whenever they are able to complete their projects, it generates revenue for the business, so it has been good, even though we don't calculate at the project or solution level.

The cost of Amazon FSx is reasonable.

The cost actually depends, as it changes from client to client; it is generally normal.

The cost depends on the storage we use, so it depends on the size.

Sometimes we go with Weka or other solutions due to higher IO needs. At this stage, there aren't many problems with Amazon FSx. Everything else is fine, but when there is a demanding IO requirement, we do go with Weka and other solutions, while for native needs, we prefer FSx.

There is an ongoing project where my customers are exploring the FSx solution, but not yet for AI-driven projects; they plan to in the future.

For those who want to use Amazon FSx, I recommend it as it's very easy to set up; they can start in a few clicks and within a few minutes.

On a scale of one to ten, I would rate Amazon FSx a ten.

We have a few relational databases (RDS) with instances and EFS file systems mounted to them. We use FSx for failover and disaster recovery purposes.

I mainly use it for DR purposes. I also use Boto3, which is a Python framework integrated with AWS Lambda.

We used it for disaster recovery perspective behind a number of resources, like batch services and RDS. These are the main purposes for which we use it. 

And feature-wise, everything seems good. I work at IBM as an architect, currently handling Delta Airlines clients. It's a huge environment; I maintain around 32 applications. Around 22 of those applications are integrated with the FSx system.

In the last month, I've been facing a challenge when doing a failover from FSx side. AWS console does not refresh within a half hour. It sometimes takes more than an hour. So we have to go to FSx command mode to check the status of the file system (read, write, and operational status). That is the main challenge I am facing from the AWS console side regarding the FSx implementation.

I wrote a service case with AWS, but they explained it takes some time for disaster recovery purposes, and they were looking into it. As of now, it's not fixed.

Secondly, I faced some challenges with mirroring from FSx side, which AWS is providing the services for. Sometimes the pool we use to share the volumes is connecting with all CIFS and NFS mount points. So, we are working on it. We have to do a little bit more work on filtering with that image mirroring and the broken issue.

We are not using the console mode. We are using the automation tool Boto3. So, I'm using the FSx module to integrate with Boto3 and Lambda. There are some issues at the sync breaking point, which you can also see on the FSx AWS page.

Some applications are active-passive. That is fine; we can set it to work within five to fifteen minutes. But some applications are in an active-active environment with high availability. So that time frame is not sufficient. So I think the product has to be worked on regarding sync mirroring along with the broken issue.

I have one more thing. FSx is an Amazon product, so it should have some training provided, like the skill builder AWS offers. I expect that we can also get some training or proper documentation for FSx. That's the main concern from the AWS side because AWS provides FSx support. But I haven't seen good FSx documentation in Skill Builder. That would be really awesome for other users as well.

We should get documentation and training related to FSx. We have a number of resources that AWS provides, but I've seen very little documentation, training videos, or anything else specifically for FSx, even though there's no separate training from FSx like AWS provides in Skill Builder for other tools, technologies, and resources.  

I'd highlight three things. One is during failover. Second is during switchback and switchover. Third is the documentation and training. These three areas are major concerns. In terms of the technology, tool, stability, scalability, and reliability, everything seems good. There's no issue with the tools and technology themselves, just those three things where we need help from the FSx side or AWS side.

I have been using it for four to five years. 

From my experience with FSx, the AWS Console is not refreshing the page as quickly as we or our client expected. 

If we make changes, it should immediately impact FSx console page so we can see the results. Because most people don't have access to the FSx console, they need to go into console mode to check file permissions, status, and other details during failover. That's my major concern. The client also raised this issue, but we don't have a proper explanation for why it's taking more than half an hour when it should be within a minute. So, it all seems good except for these issues. 

So, I would rate the stability an eight out of ten. 

My team has a Poland side with three architects and a Finland side. There are around seven of us on the architect team. From ACS FSx team, there's me and one other person in India. The rest of the team is distributed across America, Europe, and India. So, there are seven people working on FSx automation, including me, and the rest are architects.

I work with enterprise-level clients. It's scalable. It's great that FSx is global. So, in terms of scaling, I would rate it an eight out of ten. 

In public cloud, we can give it a nine out of ten. Because Amazon provides an open platform, you can build your skills, and there are a number of services, support, and automation options available. 

If we compare it with Azure and Google Cloud, they have some limitations, but AWS has no limitations in terms of technology, skills, and other purposes.

Amazon's customer service and support are much better than Google Cloud and Microsoft Azure. That's my personal experience.

Positive

I'm an AWS architect. So, we have a number of resources and services, like EC2 related, RDS related, and other things that work behind the scenes to support the front-end resources. I look at all those things.

It's a nice service, FSx, which we are using mainly for failover and disaster recovery. 

The initial setup is easy. Out of ten, I would rate my experience with the initial setup a nine. It's not that tricky or difficult. But, mirroring, sync point, and failover, there’s one more thing I noticed that we have to work on, and I'm looking into that with support. 

For, failover is fine, but switchover does not provide that service. For example, in SI environment or a dev environment. We are not always going to failover. So, we shouldn't have to rebuild and remount it and set up that entire FSx mount point again. So, on the switchover side, I'm expecting more from FSx.

Failover is all good, except that you have to refresh the page and wait a few hours for the sync to update that AWS console. So, there's one issue on the failover side. 

The second issue is on the switchover side. I'm not seeing any support from FSx for that. Maybe it's there, and I was just not aware. I will get some help from the support team, or someone can help, so that would be better. But on the switchover side, I do not see anything supporting that. FSx itself is good, but on the switchover side, I'm looking for more support.

It's on the Amazon cloud, AWS cloud. We use that mainly for migration purposes. It's a mix, like a hybrid environment, on-premises as well as AWS cloud. Like, we use it 80% in AWS and 20% on-premises.

The deployment was fairly straightforward. It's near about three to five minutes, but it depends on your data, how much data and what the latency is. 

And second, if it's less than one terabyte, so it's taking five to seven minutes maximum.

Because it's not only for sync and breaking mirroring. There are a lot of parts to that Apex that we are seeing. But, if it is less than one terabyte, it takes three to five minutes; if it is more than one terabyte, it takes six to seven minutes. It depends on integration, monitoring integration, mirroring, breaking, and again, reachable, like our environment. So, five to seven minutes maximum. So, time-wise, it's good.

But active-active-wise, we are expecting more. Sometimes, it's fine in SI active-passive mode for five to fifteen minutes. But in active-active mode, it should be less than five minutes. One minute, at least.

Like Oracle and MySQL, FSx works on the same concept. From a DR's perspective, it works well. There are no issues. I haven't experienced any challenges with FSx regarding syncing, mirroring, or other related functionalities. 

I would recommend it to everyone who uses AWS platform for storage purposes. It's a really nice tool, and we get what we expected. 

However, there are those three things: switchover, switchback, documentation, training, and certification. Because this is an AWS-centric storage technology, AWS needs to provide a little bit more elaboration on the tools and technology.

From my side, I recommend it to everyone who uses it for disaster recovery or FSx failover, along with migration. They should use it because it provides the ability to migrate, support, mirror data, and recover data.

Overall, I would rate it an eight out of ten. 

Currently, our use case involves moving shared folders on-premises to FSx for cloud-based storage.

The use of cloud technology saves time by reducing the need for infrastructure maintenance. It allows for dynamic scaling and efficient resource utilization.

FSx operates as an independent service, not tied to any server, which eliminates dependencies between applications for storage. It's managed by the cloud service provider, including backups and administrative work. In case of a disaster, having a backup secondary instance allows for easy recovery.

A direct FTP feature would be beneficial instead of relying on transmission services. Although I haven't worked extensively with FSx, there seems to be room for more improvement.

In the current project, FSx has been used for one to two years.

While FSx is stable, some issues do arise, but the service-level agreement ensures AWS support handles them.

FSx allows dynamic mounting and can be closed dynamically as well, indicating good scalability.

Customer support is satisfactory, and they provide assistance as per the service-level agreement.

Positive

AWS components, including FSx, can be created through the AWS console without the need for any software installation.

The cloud solution saves infrastructure costs and requires fewer maintenance resources compared to having an on-prem data center.

FSx is moderately priced, and the cloud itself offers significant time and cost savings.

I'd rate the solution eight out of ten.