No matter how you like to participate in developer communities, Pulumi wants to meet you there. If you want to meet other Pulumi users to share use-cases and best practices, contribute code or documentation, see us at an event, or just tell a story about something cool you did with Pulumi, you are part of our community.

Pulumi Community

This is all limited by AWS, not Pulumi. You can't do these things via the SDK or CLI, either.

The lifecycle configuration shouldn't be relevant. If something disappears from the source, then it disappears from the target, so a delete rule isn't important. And you wouldn't want to glaciate the same resource twice, so that's not important either.

The name is interesting. However, it is not something solvable via the AWS SDK, so there's nothing Pulumi could do to fix it, either.

Thank you Paul, oh alright then it makes sense to me now

Then about AWS EFS lifecycle management (<https://docs.aws.amazon.com/efs/latest/ug/lifecycle-management-efs.html>) , there's a huge cost difference keeping EFS data in "Frequent" accessed storage and "infrequent" accessed storage, so we have set lifecycle policies for "primary" EFS as follows (yes this was easily achieved and done using pulumi typescript), but however for the replica it doesn't support it though...

i guess it's probably because due to the limitation you mentioned, AWS SDK doesn't support it perhaps? <https://docs.aws.amazon.com/cli/latest/reference/efs/create-replication-configuration.html>

I think so. EFS replication might not be the best tool for you. Are you using replication for backing up only or parallel (active-active) or redundant (active-passive) access?

Replication isn't really suited for backing up.

ah actually sorry i forgot to mention the context, so the EFS replica will be in the Disaster Recovery site/region (Canada) &amp; therefore the EFS primary will be in the main site (eg: us-east-1) . The intention of having EFS replica is if some disaster happens (By us or AWS) then we failover to the DR region , therefore we will then start using the EFS replica. That's the main goal to achieve

so i would say it's an active/passive setup? :slightly_smiling_face:

Yep. So the failover time is important. If you need seconds, this is your only managed option and you'll need to pay for it; your only other option afaik would be to set up two separate EFS volumes and mirror them using 3rd party software.

If you only need hours, then snapshots and restoring to a new EFS volume during recovery is much cheaper.

If you're in between, then you have a tough choice to make :slightly_smiling_face:

cool, yeah i suppose we go with the managed option as it seems to be the suitable one for our scenario (Few seconds/mins is something our application can cope). Thanks again for your advices Paul, much appreciated.

Going more cloud native will help :slightly_smiling_face: EFS and EBS are services I deal with much less often these days; cloud native services often render them surplus to requirements.

yeah absolutely, high time i guess :slightly_smiling_face: