Lono generates CloudFormation templates from a DSL. As a part of the generation process, Lono camelizes the template keys. For example this lono DSL code:
parameter(:instance_type, "t3.micro") resource(:my_instance, "AWS::EC2::Instance", instance_type: ref(:instance_type), image_id: find_in_map(:ami_map, ref("AWS::Region"), :ami), ) resource(:security_group, "AWS::EC2::SecurityGroup", group_description: "demo security group", )
Parameters: InstanceType: Default: t3.micro Type: String Resources: MyInstance: Type: AWS::EC2::Instance Properties: InstanceType: Ref: InstanceType ImageId: Fn::FindInMap: - AmiMap - Ref: AWS::Region - Ami SecurityGroup: Type: AWS::EC2::SecurityGroup Properties: GroupDescription: demo security group
Notice how the keys are camelized. Here are some examples:
|Key in Code||Output Key|
InstanceType: Ref: InstanceType
The convention keeps code looking more natural to Ruby.
Special Cases: Exceptions and Overrides
For most CloudFormation keys and properties the camelized format is exactly what we want. However, some properties and keys do not expect the strictly camelized versions. Here are some examples of special cases:
Moreover, some CloudFormation template resources do not expect camelized keys at all under specific parent keys. An example is API Gateway ResponseParameters. Any structure underneath those keys are left untouched.
You can also add additional special cases your lono project immediately with a
--- special_keys: AnotherSpecialKey: anotherSpecialKey passthrough_parent_keys: - DontDoAnythingUnderThisParentKey
Pro tip: Use the <- and -> arrow keys to move back and forward.