AWS Certified Solutions Architect - Note (7)


CloudFormation - Template Formats

CloudFormation - Template Anatomy

CloudFormation CheatSheet

  • When being asked to automate the provisioning of resources think CloudFormation.
  • When Infrastructure as Code (IaC) is mentioned think CloudFormation.
  • CloudFormation can be written in either JSON or YAML.
  • When CloudFormation encounters an error it will rollback with ROLLBACKINPROGRESS.
  • CloudFormation templates larger than 51,200 bytes (0.05 MB) are too large to upload directly, and must be imported into CloudFormation via an S3 bucket.
  • NestedStacks helps you break up your CloudFormation template into smaller reusable templates that can be composed into larger templates.
  • At least one resource under resources: must be defined for a CloudFormation template to be valid.
  • MetaData extra information about your template.
  • Description a description of what the template is suppose to do.
  • Parameters is how you get user inputs into templates.
  • Transforms Applies marcos (like applying a mod which change the anatomy to be custom)
  • Outputs are values you can use to import into other stacks.
  • Mappings maps keys to values, just like a lookup table.
  • Resources defines the resources you want to provision, at least one resource is required.
  • Conditions are whether resources are created or properties are assigned.


CloudWatch Logs

CloudWatch Metrics

CloudWatch Events

Custom Metrics and High Resolution Metrics

CloudWatch Alarms

CloudWatch Dashboards

CloudWatch - Availability of Data

CloudWatch Agent and Host Level Metrics

CloudWatch CheatSheet

  • CloudWatch is a collection of monitoring services: Dashboards, Events, Alarms, Logs and Metrics.
  • CloudWatch Logs: log data from AWS services. eg. CPU Utilization.
  • CloudWatch Metrics: Represents a time-ordered set of data points, A variable to monitor eg. CPU Utilization over time.
  • CloudWatch Events: trigger an event based on a condition eg. ever hour take snapshot of server.
  • CloudWatch Alarms: triggers notifications based on metrics when a defined threshold is breached.
  • CloudWatch Dashboards: create visualizations based on metrics.
  • EC2 monitors at 5 min intervals and at Detailed Monitoring 1 minute intervals.
  • Most other service monitor at 1 minute intervals, with intervals of 1 , 3 , 5 minutes.
  • Logs must belong to a Log Group.
  • CloudWatch Agent needs to be installed on EC2 host to track Memory Usage and Disk Size.
  • You can can stream custom log files eg. production.log
  • Custom Metrics allow you to track High Resolution Metrics a sub minute intervals all the way down to 1 second.


CloudTrail - Event History

CloudTrail - Trail Options

CloudTrail to CloudWatch

CloudTrail - Management Events vs Data Events

CloudTrail CheatSheet

  • CloudTrail logs calls between AWS services.
  • governance, compliance, operational auditing, and risk auditing are keywords relating to Cloud Trail.
  • When you need to know who to blame think CloudTrail.
  • CloudTrail by default logs event data for the past 90s days via Event History.
  • To track beyond 90 days you need to create Trail.
  • To ensure logs have not been tampered with you need to turn on Log File Validation option.
  • CloudTrail logs can be encrypted using KMS (Key Management Service)
  • CloudTrail can be set to log across all AWS accounts in an Organization and all regions in an account.
  • CloudTrail logs can be streamed to CloudWatch logs.
  • Trails are outputted to an S3 bucket that you specify
  • CloudTrail logs two kinds of events. Management Events and Data Events.
  • Management events log management operations eg. AttachRolePolicy.
  • Data Events log data operations for resources (S3, Lambda) eg. GetObject, DeleteObject, and PutObject.
  • Data Events are disabled by default when creating a Trail.
  • Trail logs in S3 can be analyzed using Athena.

AWS Lambda

AWS Lambda - Use Cases

AWS Lambda - Triggers

AWS Lambda - Pricing

AWS Lambda - Interface

AWS Lambda - Defaults and Limits

AWS Lambda - Cold Starts

AWS Lambda CheatSheet

  • Lambda’s are serverless functions. You upload your code and it runs without you managing or provisioning any servers.
  • Lambda is serverless. You don’t need to worry about underlying architecture.
  • Lambda is a good fit for short running tasks where you don’t need to customize the os environment. If you need long running tasks (> 15mins) and a custom OS environment than consider using Fargate.
  • There are 7 runtime language environments officially supported by Lambda: Ruby, Python, Java, NodeJs, C#, Powershell and Go.
  • You pay per invocation (The duration and the amount of memory used) rounded up to the nearest 100 milliseconds and you based on amount of requests. First 1M requests per month are free.
  • You can adjust the duration timeout for up to 15 mins and memory up to 3008 MB.
  • You can trigger Lambdas from the SDK or multiple AWS services eg. S3, API Gateway, DynamoDB.
  • Lambdas by default run in No VPC. To interact with some services you need to have your Lambda in the same VPC eg. RDS.
  • Lambda can scale to 1000 of concurrent functions in seconds. (1000 is the default, you can increase with AWS Service Limit Increase)
  • Lambdas have Cold Starts. If a function has not been recently been execute there will be a delay.
comments powered by Disqus