Any reason you're returning a valid interface to a nil pointer? While everyone should be checking the error, CacheOnReadFs checks the interface for nil, and this breaks in hard-to-troubleshoot ways. While I don't think anyone should be ignoring the error, returning a valid interface isn't doing anyone any favors either.

Rather than checking the string, I think it would be better to check the error code:

if err, ok := err.(awserr.Error); ok {
    if err.Code() == "NotFound" {
        return fs.statDirectory(name)
    }
}

Here's a runnable example to play around with (just manipulate the bucket name):

package main

import (
	"log"

	"github.com/aws/aws-sdk-go/aws"
	"github.com/aws/aws-sdk-go/aws/awserr"
	"github.com/aws/aws-sdk-go/aws/session"
	"github.com/aws/aws-sdk-go/service/s3"
)

func main() {
	sess, err := session.NewSession()
	if err != nil {
		fmt.Fprintln(os.Stderr, err)
		os.Exit(-1)
	}

	if _, err := s3.New(sess).HeadObject(&s3.HeadObjectInput{
		Bucket: aws.String("bucketName"),
		Key:    aws.String("/missing/key/"),
	}); err != nil {
		if err, ok := err.(awserr.Error); ok {
			fmt.Println("CODE:", err.Code())
		}
	}
}

This should be done as an integration test. Instead, you could Monkey Patch s3 methods (mock cannot really be done).

// my_test.go
...
monkey.PatchInstanceMethod(reflect.TypeOf(s3Session), "GetObject", s3_mocks.GetObjectMockFn())
...

// mocks_s3.go

type ClosingBuffer struct {
    *bytes.Buffer
}

func (cb *ClosingBuffer) Close() error {
	return nil
}

func GetObjectMockFn() func(_ *s3.S3, _ *s3.GetObjectInput) (*s3.GetObjectOutput, error) {
	return func(_ *s3.S3, _ *s3.GetObjectInput) (*s3.GetObjectOutput, error) {
		cb := &ClosingBuffer{bytes.NewBufferString(`This is the content of a file`)}

		var rc io.ReadCloser
		rc = cb
		rc.Close()

		return &s3.GetObjectOutput{
			Body: rc,
		}, nil
	}
}

Maybe Minio as a semi-functional mock?

Which would mean that your unit tests would depend on Minio, which I'm against.
Your unit tests should not depend on external services to work, but Minio would be a good candidate for integration testing, but then I'd rather connect my tests to a test bucket in s3.
I've had a chat with a few people who run their unit tests as integration tests to avoid to have to re-write parts of their tests, which sounds wrong to me.
Here, we're using the aws sdk, which we assume is stable and has been tested, so what you want to is just test your app logic and mock what functions will return, and allow you to also test how you handle errors you'd not get when aws behaves fine. It gives you more flexibility in your unit tests to catch all edge cases you can think of. I do agree that writing mocks can often add complexity in your tests, but it's worth it.

Yeah, I can see where you're coming from. Using S3 itself as an integration test sounds potentially slow (and $) too, but I guess that depends on a lot of factors.

With mock vs integration... neither way seems to be perfect, both being needed. 😉

Arguably, storage is really really cheap these days, 0.0245 per gb for standard storage.

Can you also update the function name in the comment?

Maybe open a follow/up issue to track this.

On a second thought, this should probably be fixed from the get-go.

Seems to be a thing now

https://godoc.org/github.com/aws/aws-sdk-go/service/s3#GetObjectOutput

This seems like it should be fixed, otherwise Write in existing files is not useful?

For my own info. how is the key managed server-side? Is it fully managed by Amazon?

nit:

return file, nil

awserr is a thing so please try to cast to typed errors

https://docs.aws.amazon.com/sdk-for-go/api/aws/awserr/