Designing, implementing, and verifying application-side controls to manage which shard or cluster contains the data and that reads and writes are happening against the shard is probably going to be more expensive than taking advantage of out-of-the-box clustering and replication solution.
Availability begins with the data center. Using any reputable data center would get you things like physical security, redundant power and networking connectivity, fire control systems, and HVAC. You'd need the redundant power and networking to start to achieve the desired uptime, and the other physical safety controls would help in disaster scenarios.
Once you have the data center under control, the mainstream file and data storage tools offer built-in configurations around sharding and replication. These implementations are probably going to be more robustly designed and tested than any in-system features that you design. For open-source tools, they also benefit from many eyes.
99% availability is really a lot of downtime. It's 00:14:24 per day - fourteen minutes and twenty-four seconds. Annually, it's over 3.5 days. Depending on your SLAs, planned downtime may or may not be considered against that 99% uptime. Regardless, that's a lot of downtime.
It would be probably be cheaper and less error prone to use a data storage solution's out-of-the-box sharding and replication functionality. Going with a managed service from a large provider that undergoes audits of their processes and capabilities, like Microsoft, Amazon, or Google, would increase the confidence that the desired uptime is being delivered.
Just as examples: A multi-availability zone deployment of AWS's RDS service for managed relational databases would get you to 99.5% availability. For files, AWS's S3 has a 99.9% monthly availability and grants 100% service credit if the availability is below 95% for a month. Going with services like these and allowing the developers to focus on your core competencies would probably pay for itself pretty quickly while exceeding your more strict availability requirements.