I have a template that creates 2 EC2 instances.
I update the template and remove one of the instances from it
Then i run update stack- cloud formation will not remove that ec2 instance right?
This is why I use terraform. Is there a way to make cloudformation behave this way?
Your assumption is not correct.
If you remove the EC2 from your Cloudformation template and then update the stack it will delete the EC2 instance
Related
I have an AWS CloudFormation template where I've defined a AWS::CodeDeploy::DeploymentGroup resource. When I provision that resource, CloudFormation is going above and beyond and actually executing that deployment.
Is there any way to prevent that behavior? I don't want deployments to be performed at the same time that I create the deployment groups.
As per the AWS Cloudformation documentation
it is mentioned that Cloudformation automatically provides stack-level tags to resources.
aws:cloudformation:logical-id
aws:cloudformation:stack-id
aws:cloudformation:stack-name
I could see that for resources like EC2, S3, etc.
But when it comes to EMR I couldn’t see those tags. I need aws:cloudformation:stack-id tag value, so that I can later identify stackId without any hustle.
Isn’t it supported for EMR?
If not what could be workaround? I need to add CF stackId using which I can easily identify the stack for other use.
Note: aws cloudformation describe-stack-resources --physical-resource-id j-XXXXXXXXXXX this is not an option to get stackId because of not having enough IAM politics.
How I'm creating EMR cluster: I have one lambda which invokes CloudFormation using boto3, which then created the cluster.
I checked that on my EMR cluster and CloudFormation. You are correct. Tags are no where to be seen.
Could be oversight on AWS part, as they explicitly write in the docs that only EBS volumes don't have such tags:
All stack-level tags, including automatically created tags, are propagated to resources that AWS CloudFormation supports. Currently, tags are not propagated to Amazon EBS volumes that are created from block device mappings.
The only workaround I can think of is to "manually" create such tags, e.g. using custom resources. Or as you are already using lambda, do it in your lambda after EMR cluster creation.
I have a usecase where the cloud formation has to identify AMI-ID based on tags (passed as inputs to cloud formation template) and likewise create an ec2 instance.
Can I run a script to identify (aws ec2 describe-images --filters "Name=tag:Name,Values=value1" --query 'Images[*].{ID:ImageId}' --output text) AMI-ID via cloud formation and pass it for ec2 instance creation..
Any thoughts or example on how to do this ?
The suggested method by Amazon is provided here: Walkthrough: Looking Up Amazon Machine Image IDs
Summary: you create a custom resource in your CloudFormation template that queries a Lambda function. The Lambda function runs the AMI querying code and returns that to the CloudFormation template.
An alternative method is provided here: Integrating AWS CloudFormation with AWS Systems Manager Parameter Store
In this second method, you use CloudFormation to lookup values in AWS Parameter Store. How you decide what values to put into Parameter store is a different issue.
You cannot run the script as part of your CloudFormation template.
You will need to execute the command before creating the CloudFormation stack to determine the AMI ID. Then pass the final AMI ID into the CloudFormation stack by way of an input parameter.
So it will be a 2-step process. But you can create a script to do it.
I have a CloudFormation template that creates an AWS::ElasticBeanstalk::Environment and an AWS::ElasticLoadBalancingV2::TargetGroup
I would like to associate the AutoScalingGroup that beanstalk creates with the TargetGroup created in my template.
My end goal is doing path-based routing via an ALB to a bunch of beanstalk applications from a single domain (i.e., www.domain.com/foo routes to ebapp1 and www.domain.com/bar routes to ebapp2)
I can actually accomplish what I wish via the CLI:
aws autoscaling attach-load-balancer-target-groups --auto-scaling-group-name "<asg-name>" --target-group-arns "<arn-for-target-group>"
However, I would like to have this association created automatically when I launch my new beanstalk environment via CloudFormation.
I am having trouble figuring out how to translate this into my CloudFormation template. Any pointers?
Your CLI command is related to AWS::AutoScaling::AutoScalingGroup, and if you want to get result as same as your CLI command you can use TargetGroupARNs parameter on AWS::AutoScaling::AutoScalingGroup.
Use the Reference function to get the value of target group arn parameter.
If this is not what you need, and if your command really works, you can call it using UserData or metadata in an instance that you have created on your template to run your CLI command.
I am working on EMR template with autoscaling.
While a static EMR setup with instance group works fine, I cannot attach
AWS::ApplicationAutoScaling::ScalableTarget
As a troubleshooting I've split my template into 2 separate ones. In first I am creating a normal EMR cluster (which is fine). And then in second I have a ScalableTarget definition which fails attach with error:
11:29:34 UTC+0100 CREATE_FAILED AWS::ApplicationAutoScaling::ScalableTarget AutoscalingTarget EMR instance group doesn't exist: Failed to find Cluster XXXXXXX
Funny thing is that this cluster DOES exist.
I also had a look at IAM roles but everything seems to be ok there...
Can anyone advice on that matter?
Did anyone for Autoscaling instancegroup to work via Cloudformation?
I have already tried and raised a request with AWS. This autoscaling feature is not yet available using CloudFormation. Now I am using CF for Custom EMR SecGrp creation and S3 etc and in output tab, I am adding Command line command(aws emr create-cluster...... ). After getting output querying the result to launch Cluster.
Actually, autoscaling can be enabled at the time of cluster launching by using --auto-scaling-role. If we use CF for EMR, autoscaling feature is not available because it launches cluster without "--auto-scaling-role".
I hope this can be useful...