5

I am creating an AWS stack inside a VPC using CloudFormation and need to create ElastiCache clusters on it. I have investigated and there is no support in CloudFormation to create cache clusters in VPCs. Our "workaround" was to to create the cache cluster when some "fixed" instance (like a bastion for example) bootstrap using CloudInit and AWS AmazonElastiCacheCli tools (elasticache-create-cache-subnet-group, elasticache-create-cache-cluster). Then, when front end machines bootstrap (we are using autoscaling), they use elasticache-describe-cache-clusters to get cache cluster nodes and update configuration.

I would like to know if you have different solutions to this problem.

zorlem
  • 450
  • 3
  • 6
Luciano Afranllie
  • 4,053
  • 25
  • 23

3 Answers3

7

VPC support has now been added for Elasticache in Cloudformation Templates.

To launch a AWS::ElastiCache::CacheCluster in your VPC, create a AWS::ElastiCache::SubnetGroup that defines which subnet in your VPC you want Elasticache and assign it to the CacheSubnetGroupName property of AWS::ElastiCache::CacheCluster.

theon
  • 14,170
  • 5
  • 51
  • 74
6

You workaround is a reasonable one (and shows that you seem to be in control of your AWS operations already).

You could improve on your custom solution eventually by means of the dedicated CustomResource type, which are special AWS CloudFormation resources that provide a way for a template developer to include resources in an AWS CloudFormation stack that are provided by a source other than Amazon Web Services. - the AWS CloudFormation Custom Resource Walkthrough provides a good overview of what this is all about, how it works and what's required to implement your own.

The benefit of using this facade for a custom resource (i.e. the Amazon ElastiCache cluster in your case) is that its entire lifecycle (create/update/delete) can be handled in a similar and controlled fashion just like any officially supported CloudFormation resource types, e.g. resource creation failures would be handled transparently from the perspective of the entire stack.

However, for the use case at hand you might actually just want to wait for official support becoming available:

  • AWS has announced VPC support for ElastiCache in the context of the recent major Amazon EC2 Update - Virtual Private Clouds for Everyone!, which boils down to Default VPCs for (Almost) Everyone.

    We want every EC2 user to be able to benefit from the advanced networking and other features of Amazon VPC that I outlined above. To enable this, starting soon, instances for new AWS customers (and existing customers launching in new Regions) will be launched into the "EC2-VPC" platform. [...]

    You don’t need to create a VPC beforehand - simply launch EC2 instances or provision Elastic Load Balancers, RDS databases, or ElastiCache clusters like you would in EC2-Classic and we’ll create a VPC for you at no extra charge. We’ll launch your resources into that VPC [...] [emphasis mine]

  • This update sort of implies that any new services will likely be also available in VPC right away going forward (else the new EC2-VPC platform wouldn't work automatically for new customers as envisioned).
Accordingly I'd expect the CloudFormation team to follow suit and complete/amend their support for deployment to VPC going forward as well.
Steffen Opel
  • 63,899
  • 11
  • 192
  • 211
  • As you mention I still need to solve how to delete cache clusters when stack is deleted. This may be a reason for using CustomResource. Will take a look. – Luciano Afranllie Apr 03 '13 at 14:52
  • Custom Resource is working nicely for me for this. Much better than the CloudFormation notifications. – rstaveley May 10 '13 at 10:11
0

My solution for this has been to have a controller process that polls a message queue, which is subscribed to the SNS topic which I notify CloudFormation events to (click advanced in the console when you create a CloudFormation stack to send notifications to an SNS Topic).

I pass the required parameters as tags to AWS::EC2::Subnet and have the controller pick them up, when the subnet is created. I execute the set up when a AWS::CloudFormation::WaitConditionHandle is created, and use the PhysicalResourceId to cURL with PUT to satisfy a AWS::CloudFormation::WaitCondition.

It works somewhat, but doesn't handle resource deletion in ElastiCache, because there is no AWS::CloudFormation::WaitCondition analogue for stack deletion. That's a manual operation procedure wth my approach.

The CustomResource approach looks more polished, but requires an endpoint, which I don't have. If you can put together an endpoint, that looks like the way to go.

rstaveley
  • 67
  • 3
  • Looking more at the CustomResource approach, I now realise that you make SNS the endpoint. It is much cleaner using that approach than watching the cloudformation events. No need for hacky Tags, you can pass key values as needed. My solution is a bad one! – rstaveley May 08 '13 at 20:46