I have a CloudFormation stack which contains a CloudFront distribution resource. Our organization has subscribed to the AWS Shield Advance service and I would like to add protection to the CloudFront distribution.
I want to add it through the CloudFormation yaml template, so that I don't have to do it manually for every stack. But, it seems CloudFormation wouldn't recognize the AWS::Shield::Protection resource type.
I couldn't find any examples online and I'm wondering whether anyone knows whether it's doable?
Now you have support for it in CloudFormation.
You should use AWS::FMS::Policy .
You are correct. AWS Shield does not appear in the list of CloudFormation Resource Types.
There is, however, a CreateProtection() API call, so you could conceivably write a Lambda function as a Custom Resource in the CloudFormation template that adds protection to:
an Amazon CloudFront distribution, Elastic Load Balancing load balancer, AWS Global Accelerator accelerator, Elastic IP Address, or an Amazon Route 53 hosted zone
Related
I need to retrieve existing data/properties of a given resource by using an AWS Cloudformation template. Is it possible? If it is how can I do it?
Example 1:
Output: Security Group ID which allows traffic on port 22
Example 2:
Output: Instance ID which use default VPC
AWS CloudFormation is used to deploy infrastructure from a template in a repeatable manner. It cannot provide information on any resources created by any methods outside of CloudFormation.
Your requirements seem more relevant to AWS Config:
AWS Config provides a detailed view of the configuration of AWS resources in your AWS account. This includes how the resources are related to one another and how they were configured in the past so that you can see how the configurations and relationships change over time.
An AWS resource is an entity you can work with in AWS, such as an Amazon Elastic Compute Cloud (EC2) instance, an Amazon Elastic Block Store (EBS) volume, a security group, or an Amazon Virtual Private Cloud (VPC).
Using your examples, AWS Config can list EC2 instances and any resources that are connected to the instances, such as Security Groups and VPCs. You can easily click-through these relationship and view the configurations. It is also possible to view how these configurations have changed over time, such as:
When EC2 instance changed state (eg stopped, running)
When rules changed on Security Groups
Alternatively, you can simply make API calls to AWS services to obtain the current configuration of resources, such as calling DescribeInstances to obtain a list of Amazon EC2 instances and their configurations.
In CDK, i see that NAT gateways are represented as CfnNatGateway. I am just whether there is any way to list all the CfnNatGateway.
My purpose is to whitelist the elastic ips of those NAT gateways through CDK.
You could use a Custom Resource, which perform "arbitrary lookups or modifications during a CloudFormation deployment." A Custom Resource is in essence a Lambda that is called during the stack deployments, which you would use to call DescribeNatGateway API, extract the IPs and output the result.
Whether you should do this is a different question. Using a Custom Resource to lookup IPs introduces deploy-time side-effects. Instead, the CDK best practice is deterministic deploys:
Determinism is key to successful AWS CDK deployments. A AWS CDK app should have essentially the same result whenever it is deployed to a given environment.
The CDK would have you lookup the IPs at synth-time:
Since your AWS CDK app is written in a general-purpose programming language, it can execute arbitrary code, use arbitrary libraries, and make arbitrary network calls. For example, you could use an AWS SDK to retrieve some information from your AWS account while synthesizing your app...
Initially a while back created a cloudformation template to create multiple services on a given cluster, setup a aurora rds, redis and a load balancer.
The template was broken so i had to do various manual changes to get it working:
redis was created on the default vpc so had to manually do vpc - vpc peering
added https port forwarding on my alb
cors and various arn inline roles for the s3 bucket
and potentially dozen or so other changes
In the process of rewriting the cloudformation stack so my question is:
Is there a way using the aws cli to reverse engineer my current alb, rds, s3 to get a cloud formation formation template for each them?.
so then i would be able to compare the cloud formation template with the new own and adjust it.
Or is there a way to compare the current cloudformation stack with the current state of the resources and reverse engineer it that way.
Seems as former2 would be the best solution to your use-case:
Generate CloudFormation / Terraform / Troposphere templates from your existing AWS resources
Good afternoon, all:
I have a CloudFormation template that creates an EBS Web Environment with an internal NLB. My plan for this is to then create a VPC Link and API Gateway to proxy to the web worker, essentially keeping the VPC private. I can accomplish this through the Console, and the POC for that works great. But what I would really love to do is take the ARN of the NLB created for the EBS Web Environment, and use that as the output for the CloudFormation template, which I can then use as the input for the CF template that will create the VPC Link. The questions I have are, is this possible, and if so, how do I go about getting the ARN for the NLB in this scenario? I can accomplish the feat in a two-step process; passing the ARN manually as a parameter to the second template. But I'd really like to do it programmatically if possible.
Any links, examples or advice that you can provide on this use case would be very much appreciated.
I want to do something similar but the problem is that the first CF stack that contains the EBS resources actually spins off second CF stack that contains the Web application resources. The NLB is in the second stack.
The second stack template is generated by EBS and you don't have control over it, which means you can't define outputs.
You can use the AWS Cli to list the second stack's resources and look for the NLB resource based on resource type, then grab the ARN. The problem with this is that you don't know the name of the second stack, so would again require the two stage deployment that you describe in your question.
Not much of an answer but I'll keep digging.
Update
This is similar How To Extract Load Balancer Name from Elastic Beanstalk Environment in CloudFormation
You could also create a Customization using the .ebextensions mechanism.
Recently I had to attach a WAF to an ElasticBeanstalk Application Load Balancer. If you create a .config file and place it in .ebextensions configure your environment and customize the AWS resources that it contains. If you haven't given a custom name to any of your resources you can reference it using the standard Resource names found here
(https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/customize-containers-format-resources-eb.html)
NLBs, like ALBs use the same default resource name, so AWSEBV2LoadBalancer is what the doctor ordered.
My config looked like
Resources:
PublicWAF:
Type: AWS::WAFRegional::WebACLAssociation
Properties:
ResourceArn: {"Ref" : "AWSEBV2LoadBalancer" }
WebACLId:
Fn::GetOptionSetting:
OptionName: waf_id
Where Ref returns the Amazon Resource Name (ARN) of the load balancer.
I imagine you could place your Cloudformation for the VPC Link in a .config file for your Elastic Beanstalk App. Fair warning I used YAML for my config, but had to use the JSON format on the Reference function to get it work in my Environment.
ResourceArn: {"Ref" : "AWSEBV2LoadBalancer" }
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.
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.
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.
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.