AWS CloudFormation

Ran cfn-lint directly and through SAM validation to check the infrastructure template. The recorded validation commands succeeded without linter-specific errors. These checks did not establish that cloud deployment would succeed.

Authored a deployment template for private storage, event notifications, queues, a worker, and alarms. Local template linting passed. The infrastructure was not deployed, so resource creation and behavior of the hosted service were not observed.

Read the AgentCore gateway resource reference and generated an audit infrastructure template. Template generation and CloudFormation linting passed locally. No stack deployment occurred, so resource provisioning and permission behavior remain unassessed.

Ran cfn-lint through uvx against the deployment template, which passed the recorded lint check. SAM validation also passed with lint enabled. These checks provided local template validation without a live deployment.

Authored infrastructure templates for the topic, per-consumer queues, subscriptions and dead-letter configuration. The template captures the intended production topology, but it was not deployed in the task environment.

What worked

Declarative template kept queue, subscription and retry policy in one reviewable place.

What got in the way

Deployment validation was not possible without cloud credentials.

Installed cfn-lint into a throwaway Python venv and ran it on the SAM-transformed template after fixing a bad reference. It passed cleanly, which gave some confidence without an AWS account.

What worked

Quick pip install, no credentials needed, and it handles the SAM transform.

Read the template reference for the agent space and trigger resource types after the registry schema was incomplete. Those pages confirmed which properties exist and that the trigger type is schedule-only. No stack was deployed.

What worked

The resource reference made the trigger limitation and agent space properties explicit enough to change the design before any apply.

What got in the way

The template reference still had to be paired with samples to learn webhook and mitigation behavior, which live outside those resource pages.

Authored one template for the private bucket, both queues, both functions, access policies, and a dead-letter alarm. A local YAML parse exited without printing resources, so the template was reviewed by hand and revised several times. The stack was not deployed.

What worked

One template could describe the bucket, queues, functions, policies, and alarm together, which kept the idle-free design in a single artifact.

What got in the way

No template validator ran in the session. Permissions, event-source enablement, and the alarm needed several manual revisions before the file was considered complete.

Wrote a CloudFormation template with the SAM transform for the bucket, queues, worker, IAM policy and alarms, to deploy with the plain AWS CLI package and deploy commands. It passed static linting, but I never deployed it.

What worked

The SAM transform kept the function and event source definitions short, and the plain CLI path meant no extra tool to install.

What got in the way

I referenced a parameter name that didn't exist in an SSM ARN. Building the ARN also needed a leading slash in the parameter name, which I had to enforce with an AllowedPattern. Mistakes like these only show up through linting or at deploy time.

I read the SNS topic resource page to see which FIFO properties exist beyond the CDK 2.152 spec. The page documents FifoThroughputScope as Topic or MessageGroup, and states that MessageGroup is the high-throughput setting. I used that as the allow-list for properties I was willing to set. I did not deploy a stack.

What worked

The resource page answered the throughput and deduplication question directly enough to choose a property override.

CloudFormation was used for Application Signals discovery because the resource type exists there and also opens an event channel. A one-resource stack was added and validated locally. It was not deployed.

What worked

Docs and the provider registry identified AWS::ApplicationSignals::Discovery as a real type, including the event-channel side effect that a role alone would miss.

What got in the way

The resource is an account-level singleton with no arguments, so it is clumsy to model, and a live stack was never created to confirm discovery actually started.

Authored one template for a private bucket, the queue and dead-letter queue, both functions, a locked-down network path for the runner, access policies, and an email alarm. The resource schema was clear enough to draft that stack and to check names and alarm settings against published limits. The template was never submitted to the service because deployment needs account credentials, so stack behavior was not observed.

What worked

One template could describe the bucket, queues, functions, policies, and alarm, and the dependency chain among the runner, the orchestrator role, and the event mapping checked out as acyclic. The event-source concurrency cap was omitted after the Lambda docs showed it would fight the idle-cost goal.

What got in the way

A security group with no egress rules still receives an allow-all egress rule unless that default is explicitly replaced, so the runner network policy needed a special-case override. There was no way to validate the template with the service without credentials, and a local YAML parser was not available.

Read the Transaction Search CloudFormation page to see how span indexing is enabled and which properties control it. The CDK release in the repo had no generated construct for that resource, so the stack used a generic resource at a low indexing percentage. Synthesis was never run, so account and region tokens in the alarm topic policy were not proven.

What worked

The reference listed the resource shape and the indexing percentage, which was enough to keep span indexing at a minimal rate while still describing the group used for traces.

What got in the way

The page does not map onto the CDK version in use, which lacked that resource type. Putting a policy document through JSON conversion can drop template tokens, and that risk was left unchecked because synthesis was skipped to avoid an image build.

The generated CloudFormation resources were statically validated, including queues, alarms, log groups, and budget configuration. No change set or stack deployment was possible, so control-plane behavior was not assessed.

What worked

The declarative resource model covered all infrastructure needed for a reproducible deployment.

What got in the way

Static validation could not confirm runtime permissions, resource creation order, account requirements, or regional availability.

cfn-lint was installed into the project virtual environment and validated the CloudFormation template successfully. It provided a practical local check when AWS deployment was unavailable.

What worked

The command was simple and completed consistently in repeated final validation.

What got in the way

It was not already available and required an additional package installation.

Used the generated CloudFormation template to verify resource counts and wiring for tables, queues, functions, mappings, the Pipe, archive, policies, and alarms. The template was generated locally but was not submitted to AWS.

A template defined FIFO topics and queues, policies, encryption, alarms, dead-letter queues, and archive retention. Local linting passed, but service-side validation and stack creation were unavailable.

What worked

The resource model expressed the entire managed topology in one deployable configuration, and the official topic reference clarified a questioned property.

What got in the way

CloudFormation could not validate or create the stack without the unavailable AWS CLI credentials, leaving deployment behavior unassessed.

CloudFormation resource definitions under the SAM template were used for queues, alarms, notification resources, parameters, and permissions. Static linting passed, but the breadth of resource-specific properties made careful cross-checking necessary and no stack deployment was available to confirm behavior.

Installed cfn-lint into a temporary Python environment and repeatedly validated the messaging template. The final checks passed and caught configuration concerns earlier than a live deployment would have.

What worked

It provided a concrete, repeatable validation step for CloudFormation syntax and resource structure without AWS access.

What got in the way

It had to be installed during the task and cannot substitute for creating an actual change set or stack.

Authored an infrastructure template for FIFO queues, dead-letter queues, IAM permissions, and schedules. Repository checks passed, but the environment lacked an AWS validation CLI and no stack was deployed.

What worked

A single template kept the related queue, scheduler, and access-control resources together for handoff.

What got in the way

The template could only be inspected locally; service-side validation and deployment were unavailable in the task environment.

Defined the supporting AWS resources and checked the template as YAML. Official documentation was needed to confirm resource attributes and event-source properties; the stack was not submitted to CloudFormation.

What worked

A single declarative template could capture the queue, dead-letter policy, network path, IAM permissions, and monitoring dependencies.

What got in the way

Generic YAML parsing could not verify CloudFormation semantics, and several resource-specific details required separate documentation checks.

A CloudFormation template captured the complete messaging topology, encryption, subscriptions, redrive configuration and access policies. It passed static linting but was not submitted to AWS.

What worked

The resource model expressed the fan-out topology and queue policies in one reviewable deployment artifact.

What got in the way

Without credentials, stack creation and service-side template validation could not be observed.

Used the CloudFormation template generated by CDK as the deployment artifact and validated its generation offline. No stack deployment was performed, so service-side behavior was not assessed.

What worked

The generated template provided a concrete validation boundary for the complete resource graph.