We were in the process of setting up AWS Config Rules and came across a bug in one of the AWS managed rules. During our conversation with the AWS support person, he has revealed that the AWS Config Rules are processed by AWS Lambda functions behind the scenes.
I am curious to know what other AWS services use AWS Lambda behind the scenes. For example, AWS Systems Manager documents.
Thanks for your time.
Not exhaustive list, but here are some more examples:
AWS::Include Transform which is a macro hosted by AWS CloudFormation, to insert boilerplate content into your templates.
AWS::Serverless Transform which is a macro hosted by AWS CloudFormation, takes an entire template written in the AWS Serverless Application Model (AWS SAM) syntax and transforms and expands it into a compliant AWS CloudFormation template
Secret Manager and its password rotation: If you use your secret for one of the supported Amazon RDS databases, then Secrets Manager provides the Lambda function for you. And Secrets Manager automatically customizes the function to meet the requirements of the specified database.
Related
Sorry, I’m sort of a newbie when it comes to Amazon AWS Cloud so sorry if I sound naïve.
For .NET developers, I’ve used Visual Studio 2019’s AWS Lambda project to code Lambda functions and ultimately deploy it to Amazon AWS cloud
However, my concern is that there is No way to version and/or back up the Configurations for the AWS Services ( i.e., S3 bucket, Amazon SNS & SQS, etc.) that are invoked and/or trigger the various AWS Lambda Functions
The problem is that IT developers who configure said AWS Services have to use the ADFS AWS Services console website’s GUI to configure the various AWS Services, and if someone mistakenly deletes an AWS Services then they lose the configuration settings as well?
How do we go about versioning and/or backing up Configurations for the AWS Services?
There are Infrastructure as a Code frameworks like Terraform and Ansible designed to address that.
You can't really delete an AWS service.
it seems like you guys are kind of "new" to AWS so I will recommend using CloudFormation templates as Infrastructure As Code tool. All the configuration of how your AWS resources are supposed to look like can be added to the template and you deploy the template to create your AWS resources. Its AWS-Native and does not cost you anything.
On top of it, you also want to add your CloudFormation templates to version control system.
We have a few different AWS accounts and I am looking to migrate the SNS configuration from one AWS account to another. Is that possible to migrate?
Many thanks for considering my request.
AWS does not have a 'migrate' capability.
A best-practice is to deploy "infrastructure as code" using CloudFormation or Terraform. Then, when you wish to deploy the same infrastructure to a different AWS Account, simply use the same template to deploy it.
If you did not deploy your initial infrastructure via a template, you might want to use https://former2.com/ to create a template based on existing infrastructure. You can then use that template to deploy the same resources in a different AWS Account.
Is there an AWS equivalent to the Azure Building Blocks CLI?
Doing a Google search has not revealed anything so far.
I'm not familiar with Azure Building Blocks, but based on AWS vs Azure vs Google Cloud: Storage and Compute Comparison, the closest equivalent is AWS CloudFormation.
AWS CloudFormation is a service that helps you model and set up your Amazon Web Services resources so that you can spend less time managing those resources and more time focusing on your applications that run in AWS. You create a template that describes all the AWS resources that you want (like Amazon EC2 instances or Amazon RDS DB instances), and AWS CloudFormation takes care of provisioning and configuring those resources for you. You don't need to individually create and configure AWS resources and figure out what's dependent on what; AWS CloudFormation handles all of that. The following scenarios demonstrate how AWS CloudFormation can help.
If you want a programmatic equivalent to AWS CloudFormation, AWS Cloud Development Kit (AWS CDK):
Use the AWS CDK to define your cloud resources in a familiar programming language. The AWS CDK supports TypeScript, JavaScript, Python, Java, and C#/.Net.
How to export existing configured and tested infrastructure (including AWS Lambda functions, API Gateways, ElastiCache clusters, Cloudwatch rules) to Cloudformation template?
I know about Cloudformer tool, but it supports limited number of AWS services (Amazon VPC, DynamoDB, etc) and don't supports some of services which we use. Which tools and approaches can I use in my case for generating Cloudformation template?
Partial solution: there is ability to export Lambda function to AWS SAM file
and then
We will get YAML file which describes your Lambda function as 'AWS::Serverless::Function'. But there are few things - we can't export Lambda aliases with such approach. Also that doesn't help with API Gateway exporting.
CloudFormer was built for this, however, I agree with #MaiKaY that you should rewrite everything. CloudFormer will create hard-links with IDs, where you have to replace these with references, add parameters and/or mappings. It can help you get started, so you know what you need in the template.
I am trying to clone my aws account(prod) to another account(test) with all resources and configuration I have set up on prod. Is there any best practice to replicate the aws account to another?
This is not possible.
Nor is there an easy way to list all resources in an AWS account.
Each AWS Service (eg EC2, S3, Lambda) have their own API calls to list resources and describe configurations. There is no universal way to request this information.
Best Practice is to only create resources using AWS CloudFormation templates, thereby having full documentation of resources created and the ability to deploy similar infrastructure in other AWS accounts or regions.
Some third-party services (eg https://www.hava.io/) can extract configuration information and automatically create AWS CloudFormation templates. However, these templates only record the configuration of AWS resources -- they do not replicate the content of storage on disks, Amazon S3 or databases.