L2 support for Elasticache for Redis

[pahud]

Currently there's only L1 resources in aws-elasticache.

Let's have an initial redis L2 resource support.

Use Case

To create elasticache for redis with L2 constructs.

Proposed Solution

Other

• 👋 I may be able to implement this feature request
• ⚠️ This feature might incur a breaking change

---

This is a 🚀 Feature Request

[civilizeddev]

Actually, I have been working on it.
I'll make a pull request as a draft soon.

• cache-cluster
  • redis
    • replication-group
  • memcached
• parameter-group
• subnet-group
• security-group

[pahud]

@civilizeddev wow great. I'll hold my PR then. Hope we can ship it soon.

[iliapolo]

Hi @civilizeddev and @pahud - Thanks for creating this and especially for taking the time to contribute!

@civilizeddev I suspect this is going to be a rather large PR, and might take some time to review and merge...

In the spirit of incremental changes, what do you think about first creating a PR that only contains the README of these new constructs? This will give us a chance to talk about the API and address concerns before actually diving into the code and having to go through one more review cycle.

I know you've already started working on it, but my suggestion is that you pause that for a bit until we converge on the README.

Upside is you will already have the readme all done :)

[iliapolo]

We should also consider this issue: #8180 (Possible with a custom resource that updates the parameter group and assigns a name to it).

[rrrix]

Did @civilizeddev ever get around to building this? I just finished of a lovely (sarcasm) stack using the L1 constructs for a Redis Replication Group. They're not exactly "easy" :)

[awsiv]

Ended up here while trying to create cloudwatch alarms using .metric(...)

Not supported OFC.. would the new L2 construct support getting Metric info?

[otaviomacedo]

would the new L2 construct support getting Metric info?
We still need to design and review this construct. It's too early to tell at this point.

[00Kai0]

Hi guys, do you have any update for this issue?
We need L2 support like lookup api to avoid cyclic reference between stacks.

[Jacco]

I am working on getting the L2 constructs ready for ElastiCache but I ran into some issue regarding support for AWS::ElastiCache::SecurityGroup. It is part of the EC2 Classic support which is retired as of 15 august 2022.

Am I correct in assuming AWS::ElastiCache::SecurityGroup and AWS::ElastiCache::SecurityGroupIngress can be left out in the CDK L2 implementation? Or should support be added for people to import existing old stuff into the CDK stacks. It is still possible to create these resources using CloudFormation.

Also I found that creating new CacheClusters with NodeTypes of the previous generation is not possible. Should the names of the previous generation NodeTypes be in the CDK implementation or should we leave them out and only list the current generation NodeTypes. (I will of course build in an escape hatch for "custom" NodeTypes to support working with and olde version of CDK while supporting newer NodeTypes).

[dbartholomae]

I've just finished the first draft for an RFC to get L2 support going. I'm currently waiting for feedback from the bar raiser, but community outreach will be next :)
aws/aws-cdk-rfcs#456

[dbartholomae]

We are open for community feedback now. The RFC isn't that prescriptive, so we will most likely move ahead quickly instead of waiting for a lot of feedback, but late feedback will still be helpful for the implementation phase.

[tim-finnigan]

After discussing with @pahud and others we decided this should merge into #6908 which is tracking general ElastiCache-related feature requests, and the RFC for an L2 construct can continue being tracked in aws/aws-cdk-rfcs#456.

[github-actions]

⚠️COMMENT VISIBILITY WARNING⚠️

Comments on closed issues are hard for our team to see.
If you need more assistance, please either tag a team member or open a new issue that references this one.
If you wish to keep having a conversation with other community members under this issue feel free to do so.