Where are these infrastructure entries coming from in AWS SAM?

Question

I'm learning SAM, and I created two projects.

The first one, example1, I created it from the AWS web console, by going to Lambda, Applications, and choosing this template:

After the wizard finishes creating the app, it looks like this:

I'm interested in the yellow-highlighted area because I don't understand it yet.

I tried to replicate this more or less manually by using sam init and created example2. It's easy to look at the template.yml it creates and see how the stuff in Resources are created, but how is the stuff in Infrastructure created.

When I deploy example2 with sam deploy --guided, indeed there's nothing in Infrastructure:

Given example2, how should I go about creating the same infrastructure as example1 had out of the box (and then changing it, for example, I want several environments, prod, staging, etc). Is this point and click in the AWS console or can it be done with CloudFormation?

I tried adding a permission boundary to example2, on of the things example1 has in Infrastructure, I created the policy in IAM (manually, in the console), added it to the template.yml, and deployed it but it didn't show up in "Infrastructure".

Answer 1

Part 1: In which I answer your question

Where are these infrastructure entries coming from in AWS SAM?

I replicated your steps in the Lambda console to create a "Serverless API Backend" called super-app. When you press create, AWS creates two CloudFormation Stacks, each with a YAML template. You can view the stack resources and the YAML templates in the CloudFormation console under Stacks > Templates Tab.

1. super-app: the "Resources" stack with the lambda and dynamo resources you managed to replicate.
2. serverlessrepo-super-app-toolchain: the mystery stack with the "Infrastructure" CI/CD resources¹.

Is this point and click in the AWS console or can it be done with CloudFormation?

Yes and Yes. You can use sam deploy (or aws cloudformation deploy) to update the stacks. Or point and click.

Example: update the serverlessrepo-super-app-toolchain template with the SAM CLI:

# compile
sam build -t cicd_template.yaml --region us-east-1 --profile sandbox

# send changes to the cloud
sam deploy --stack-name serverlessrepo-super-app-toolchain --capabilities CAPABILITY_NAMED_IAM --region us-east-1 --profile sandbox 

You must pass in values for the template parameters at deploy-time. The current values for the parameters are in the console under CloudFormation > Stack > Parameters Tab. You can pass them using the --parameter-overrides param in the deploy command. If the parameters are static, I find it easier to pass SAM parameter values in samconfig.toml, which sam deploy will use by default:

# samconfig.toml
version = 0.1
[default]
[default.deploy]
[default.deploy.parameters]
# template default parameters - fill in the template blanks
# Where do the values come from?  the CloudFormation console, Parameters tab
AppId = "super-app"
AppResourceArns = "arn:aws:lambda:us-east-1:1xxxxxx:function..."
ConnectionArn = "arn:aws:codestar-connections:us-east-1:xxxxxx:connection/xxxx3c5c-f0fe-4eb9-8164-d3c2xxxxx6e2"
GitHubRepositoryOwner = "mygithuborg"
RepositoryName = "super-app"
SourceCodeBucketKey = "sample-apps/nodejs/14.x/javascript/sam/web-backend.zip"
SourceCodeBucketName = "prodiadstack-subsystemsn-apptemplatesbucket03axxx-96eem3xxxxxx"
UseCodeCommit = false

If there were changes made in the template, they will deploy. Success!

Part 2: In which I try to convince you to use the CDK instead

SAM and YAML templates are far from dead, but I think it's safe to say that for proficient developers starting out with AWS, the newer AWS Cloud Development Kit is a natural first choice for ambitious applications that need CI/CD and testing. For most of us, editing a 800-line YAML file is not a fun experience.

AWS Infrastructure-As-Code

There are lots AWS and 3rd Party IaaC tools to deploy infra on AWS. Each abstraction is best for somebody sometime. The important thing to remember is that no matter what higher-level IaaC toolset you use, it ends up being deployed as a CloudFormation template. Here are the AWS approaches, oldest to newest:

CloudFormation YAML² templates

The OG, all-powerful, lowest-level approach is to hand-code YAML templates. The Cfn template reference docs are indespensible no matter what tool you use, because that's what gets deployed.

SAM YAML templates

With AWS SAM, you still handcode YAML, but less³. A SAM template is a superset of CloudFormation with some higher-level abstractions for the main serverless components like Lambdas, DynamoDB tables and Queues. The SAM CLI compiles the SAM template to Cfn. It has nifty features like local testing and deploy conveniences.

Cloud Development Kit

The newest, shiniest IaaC approach is the CDK, now on V2. With the CDK, we write Typescript/Python/Java/etc. instead of YAML. The CDK CLI compiles your language code to Cfn and deploys with cdk deploy. It has a bigger set of high-level infra abstractions that goes beyond serverless, and escape hatches to expose low-level Cfn constructs for advanced use cases. It natively supports testing and CI/CD.

AWS CDK workshop including testing and pipelines. Lots of AWS CDK example apps.

---

1. Note that CloudFormation is the ultimate soure of this info. The lambda console makes a cloudformation.DescribeStack API call to fetch it.
2. YAML or JSON
3. SAM also has a marketplace-like repository with reusable AWS and 3rd party components