I am deploying and configuring AWS CloudFront using a yaml file
I receive a message that stated "Encountered unsupported property Indexdocument"
This is the code from my yaml file and the block code. I am following the Cloud Resume Challenge instructional guide on how to complete the cloud resume challenge.
Resources:
MyWebsite:
Type: AWS::S3::Bucket
Properties:
AccessControl: Public Read
WebsiteConfiguration:
Indexdocument: index.html
BucketName: mcderkaderkas-first-website
MyDistribution:
Type: "AWS::CloudFront::Distribution"
Properties:
DistributionConfig:
DefaultCacheBehavior:
ViewProtocolPolicy: allow-all
TargetOriginId: http://mcderkaderkas-first-website.s3-website-us-east-1.amazonaws.com
DefaultTTL: 0
MinTTL: 0
MaxTTL: 0
ForwardedValues:
QueryString: false
Origins:
- DomainName: http://mcderkaderkas-first-website.s3-website-us-east-1.amazonaws.com
Id: http://mcderkaderkas-first-website.s3-website-us-east-1.amazonaws.com
CustomOriginConfig:
OriginProtocolPolicy: match-viewer
Enabled: "true"
DefaultRootObject: index.html
CloudFormation events from stack operations (refresh every 0.5 seconds)
ResourceStatus ResourceType LogicalResourceId ResourceStatusReason
UPDATE_FAILED AWS::S3::Bucket MyWebsite Encountered unsupported property Indexdocument
UPDATE_ROLLBACK_IN_PROGRESS AWS::CloudFormation::Stack cloud-resume-challenge The following resource(s) failed to update:
[MyWebsite].
UPDATE_COMPLETE AWS::S3::Bucket MyWebsite -
UPDATE_ROLLBACK_COMPLETE_CLEANUP_IN_PROGRESS AWS::CloudFormation::Stack cloud-resume-challenge -
UPDATE_ROLLBACK_COMPLETE AWS::CloudFormation::Stack cloud-resume-challenge -
Error: Failed to create/update the stack: cloud-resume-challenge, Waiter StackUpdateComplete failed: Waiter encountered a terminal failure state: For expression "Stacks[].StackStatus" we matched expected path: "UPDATE_ROLLBACK_COMPLETE" at least once
Cloudformation generally provides pretty decent documentation on what to pass where, including for an S3 bucket's website configuration.
In this case I can see you specify a key Indexdocument while the documentation capitalizes Document ie IndexDocument. Yaml, cloudformation, and nearly everything else involving computers is case sensitive (notable exceptions include windows / mac os filesystems with default settings, DNS, and email addresses ). So make sure to get that case right in your Yaml files!
Related
I got a simple cloudformation stack made of only two nested stacks, one for the hosting and serving of a single page application web app and the other for the authentication logic (for now it only define a Cognito user pool resource).
The auth nested stack keeps failing during deployment, but I can't figure out why as not reasonable motivation is given by the command.
I still get the error even after manually deleting the entire stack hierarchy and creating a new one.
After the aborted operation I'm left with the main stack and two empty nested stacks, each one in the DELETE_COMPLETE status.
Running sam validate on the nested stack template gives no error:
> sam validate --template-file nested-stacks/auth.yaml
2023-01-16 12:15:01 Loading policies from IAM...
2023-01-16 12:15:04 Finished loading policies from IAM.
/media/sgratani/Data/tests/AWS/serverless spa/aws_stack/nested-stacks/auth.yaml is a valid SAM Template
nested stack template
AWSTemplateFormatVersion: '2010-09-09'
Description: >
- A Cognito user pool
Parameters: {}
Resources:
UserPool:
Type: AWS::Cognito::UserPool
Properties:
AccountRecoverySetting:
RecoveryMechanisms:
- Name: verified_email
AdminCreateUserConfig:
AllowAdminCreateUserOnly: true
InviteMessageTemplate:
EmailMessage: Your username is {username} and temporary password is {####}.
EmailSubject: Your temporary password
UnusedAccountValidityDays: 30
# AliasAttributes:
# - String
# AutoVerifiedAttributes:
# - String
EmailConfiguration:
EmailSendingAccount: COGNITO_DEFAULT
MfaConfiguration: OFF
Policies:
PasswordPolicy:
MinimumLength: 8
RequireLowercase: true
RequireNumbers: true
RequireSymbols: true
RequireUppercase: true
TemporaryPasswordValidityDays: 7
# Schema:
# - SchemaAttribute
# UsernameAttributes:
# - String
UsernameConfiguration:
CaseSensitive: true
VerificationMessageTemplate:
DefaultEmailOption: String
EmailMessage: Your verification code is {####}.
# EmailMessageByLink: String
EmailSubject: Your verification code
# EmailSubjectByLink: String
sam build output deployment section
Initiating deployment
=====================
File with same data already exists at 0320ec2e303c20d5454978a63234f9ed.template, skipping upload
Waiting for changeset to be created..
CloudFormation stack changeset
-----------------------------------------------------------------------------------------------------------------------------------------------------------------
Operation LogicalResourceId ResourceType Replacement
-----------------------------------------------------------------------------------------------------------------------------------------------------------------
+ Add AppHosting AWS::CloudFormation::Stack N/A
+ Add Auth AWS::CloudFormation::Stack N/A
-----------------------------------------------------------------------------------------------------------------------------------------------------------------
Changeset created successfully. arn:aws:cloudformation:eu-central-1:575288510223:changeSet/samcli-deploy1673867103/a08f41d4-6786-4039-8916-ab73a37a0d1e
2023-01-16 12:05:15 - Waiting for stack create/update to complete
CloudFormation events from stack operations (refresh every 0.5 seconds)
-----------------------------------------------------------------------------------------------------------------------------------------------------------------
ResourceStatus ResourceType LogicalResourceId ResourceStatusReason
-----------------------------------------------------------------------------------------------------------------------------------------------------------------
CREATE_IN_PROGRESS AWS::CloudFormation::Stack Auth -
CREATE_IN_PROGRESS AWS::CloudFormation::Stack AppHosting -
CREATE_IN_PROGRESS AWS::CloudFormation::Stack Auth Resource creation Initiated
CREATE_IN_PROGRESS AWS::CloudFormation::Stack AppHosting Resource creation Initiated
CREATE_FAILED AWS::CloudFormation::Stack Auth Embedded stack
arn:aws:cloudformation:eu-
central-1:575288510223:stack/test-spa-
Auth-IB3AC3208DMY/aa040170-958d-11ed-9
c56-0a7beb596806 was not successfully
created: The following resource(s)
failed to create: [UserPool].
CREATE_FAILED AWS::CloudFormation::Stack AppHosting Resource creation cancelled
ROLLBACK_IN_PROGRESS AWS::CloudFormation::Stack test-spa The following resource(s) failed to
create: [Auth, AppHosting]. Rollback
requested by user.
DELETE_IN_PROGRESS AWS::CloudFormation::Stack AppHosting -
DELETE_IN_PROGRESS AWS::CloudFormation::Stack Auth -
DELETE_COMPLETE AWS::CloudFormation::Stack Auth -
DELETE_COMPLETE AWS::CloudFormation::Stack AppHosting -
ROLLBACK_COMPLETE AWS::CloudFormation::Stack test-spa -
-----------------------------------------------------------------------------------------------------------------------------------------------------------------
Error: Failed to create/update the stack: test-spa, Waiter StackCreateComplete failed: Waiter encountered a terminal failure state: For expression "Stacks[].StackStatus" we matched expected path: "ROLLBACK_COMPLETE" at least once
final nested stacks
Ok, the nested stack template actually had a few errors in it, a test deployment on its own pointed them out as being the main stack lead to a more clear output from sam deploy command.
BTW, don't understand why sam validate didn't alert me, since one of the errors were actually a value type error, eg 'Integer' string instead of an actual integer (copy/paste from docs without updating, my fault).
This had me thinking: what do actually sam validate validates?
I'm trying to create a AWS::MSK::Configuration resource, as described here: https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-msk-configuration.html.
This is my CF template:
Resources:
MSKConfig:
Type: AWS::MSK::Configuration
Properties:
Description: Basic configuration.
Name: test-msk-configuration
ServerProperties: |
auto.create.topics.enable=false
........
It doesn't work failing with the following error:
An error occurred (ValidationError) when calling the CreateChangeSet operation: Template format error: #Unrecognized resource types: [AWS::MSK::Configuration]
I'm not able to find any example with this resource type online. Has anyone ever used it?
Update on 26/03/2022:
I was able to get this deployed. I use the serverless framework for deployment.
MSK-Cluster.yml:
Resources:
ServerlessMSK:
Type: AWS::MSK::Cluster
Properties:
ClusterName: ${self:service}-${self:provider.stage}-msk
KafkaVersion: 2.6.2
BrokerNodeGroupInfo:
InstanceType: kafka.t3.small
ClientSubnets:
- !Ref ServerlessPrivateSubnet1
- !Ref ServerlessPrivateSubnet2
- !Ref ServerlessPrivateSubnet3
SecurityGroups:
- !GetAtt ServerlessMSKSecurityGroup.GroupId
StorageInfo:
EBSStorageInfo:
VolumeSize: 10
NumberOfBrokerNodes: 3
EncryptionInfo:
EncryptionInTransit:
ClientBroker: TLS
InCluster: true
EnhancedMonitoring: PER_TOPIC_PER_BROKER
ConfigurationInfo:
Arn: !GetAtt ServerlessMSKConfiguration.Arn
Revision: 1
MSK-config.yml
Resources:
ServerlessMSKConfiguration:
Type: AWS::MSK::Configuration
Properties:
Description: cluster for msk cluster-${sls:stage}
Name: node-mongo-kafka-experiment-${sls:stage}-config
ServerProperties: ${file('./assets/server.properties')}
server.properties
auto.create.topics.enable=true
default.replication.factor=2
min.insync.replicas=2
num.io.threads=8
num.network.threads=5
num.partitions=10
num.replica.fetchers=2
replica.lag.time.max.ms=30000
socket.receive.buffer.bytes=102400
socket.request.max.bytes=104857600
socket.send.buffer.bytes=102400
unclean.leader.election.enable=true
zookeeper.session.timeout.ms=18000
basically, no base64 was used. I just referenced the file in the deployment and managed to get it up. Hope this helps.
Orginal Answer Below:
I haven't been able to deploy this correctly too. But maybe I can point you in the right direction.I always get back a 400 error with my serverless deployment for this. The only thing I would like to add on here is that serverproperties must be a Base64 encoded string.
https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-msk-configuration.html
My Template (that results in error):
Resources:
ServerlessMSKConfiguration:
Type: AWS::MSK::Configuration
Properties:
ServerProperties: !Base64 |
auto.create.topics.enable=true
NB: Answering due to the fact I don't have reputation to comment.
I managed to fix the 400 issue, it looks like the AWS::MSK::Configuration resource suspects a name. While the documentation says it is not required.
https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-msk-configuration.html#cfn-msk-configuration-name
My template:
KafkaConfiguration:
Type: AWS::MSK::Configuration
Properties:
Name: Kafkaconfiguration
ServerProperties: |
auto.create.topics.enable=false
We are trying create a AWS::WAFv2::IPSet in our SAM template.
WhitelistedIPAddressesIPSet:
Type: AWS::WAFv2::IPSet
Properties:
Description: 'Merchant IPs'
Scope: REGIONAL
IPAddressVersion: IPV4
Addresses: [0.0.0.0/32, 0.0.10.0/32]
The creation of the IP sets is done successfully.
Once creating the AWS::WAFv2::WebACLAssociation.
WAFApiAssociation:
Type: AWS::WAFv2::WebACLAssociation
DependsOn:
- ApiGateway
- WAFWebAcl
Properties:
ResourceArn: !Sub 'arn:aws:apigateway:${AWS::Region}::/restapis/${ApiGateway}/stages/${EnvType}'
WebACLArn: !GetAtt WAFWebAcl.Arn
The CloudFormation failes and does a rollback. Error displayed is as follows:
Resource handler returned
ion message: "AWS WAF couldn?t
perform the operation
because your resource
doesn?t exist. (Service:
Wafv2, Status Code: 400,
Request ID: e337720a-e32c-
4c29-acde-1896855405c9,
Extended Request ID:
null)" (RequestToken: f24d
0488-3016-4030-3a3b-bbb246
66f130, HandlerErrorCode:
NotFound)
We tried different formatting the SAM template of the IP set, to see if that causes the issues, without any success.
Anyone that could share some helpful insights to this issue?
A) You don't need DependsOn if your resource already directly depends on those other resources. In this case it does, so you can remove this property.
B) You'll need to share your whole stack here, not just what is shared because there is likely a problem with your APIGW configuration. Because that failed to be created, it's possible you get this subsequent problem showing up.
Creating the APIGW isn't enough, you need to make sure to actually attach the WAF after the APIGW stage was created and not just the APIGW. In this case replace the ResourceArn with one that references the APIGW Stage. (And further you might need to wait for the stage deployment to finish.)
This is the APIGW template Warren Parad
CDEAPI:
Type: AWS::Serverless::Api
Properties:
# Domain:
# DomainName: !Ref CDEAPIDomainName
# SecurityPolicy: TLS_1_2
# CertificateArn: !Sub 'arn:aws:acm:us-east-1:${AWS::AccountId}:certificate/${CDEAPICertificateArn}'
# EndpointConfiguration: EDGE
# Route53:
# HostedZoneId: !Ref CDEAPIHostedZoneId
AccessLogSetting:
DestinationArn: !GetAtt CDEAPIAccessLogGroup.Arn
Format: >-
{ "requestId":"$context.requestId",
"ip":"$context.identity.sourceIp",
"caller":"$context.identity.caller",
"user":"$context.identity.user",
"userAgent":"$context.identity.userAgent",
"userArn":"$context.identity.userArn",
"requestTime":"$context.requestTime",
"requestTimeEpoch":"$context.requestTimeEpoch",
"httpMethod":"$context.httpMethod",
"resourcePath":"$context.resourcePath",
"path":"$context.path",
"status":"$context.status",
"protocol":"$context.protocol",
"responseLength":"$context.responseLength",
"responseLatency":"$context.responseLatency",
"authorizerLatency":"$context.authorizer.integrationLatency",
"integrationLatency":"$context.integrationLatency",
"integrationStatus":"$context.integrationStatus",
"xrayTraceId":"$context.xrayTraceId",
"errorMessage":"$context.error.message",
"domainName":"$context.domainName",
"domainPrefix":"$context.domainPrefix",
"tokenScopes":"$context.authorizer.claims.scope",
"tokenIat":"$context.authorizer.claims.iat",
"tokenExp":"$context.authorizer.claims.exp",
"cognitoIdentityId":"$context.identity.cognitoIdentityId",
"awsEndpointRequestId":"$context.awsEndpointRequestId",
"arn":"$context.identity.userArn",
"account":"$context.identity.accountId",
"claims-sub":"$context.authorizer.claims.sub",
"waf-error":"$context.waf.error",
"waf-status":"$context.waf.status",
"waf-latency":"$context.waf.latency",
"waf-response":"$context.waf.wafResponseCode",
"authenticate-error":"$context.authenticate.error",
"authenticate-status":"$context.authenticate.status",
"authenticate-latency":"$context.authenticate.latency",
"integration-error":"$context.integration.error",
"integration-status":"$context.integration.status",
"integration-latency":"$context.integration.latency",
"integration-requestId":"$context.integration.requestId",
"integration-integrationStatus":"$context.integration.integrationStatus",
"response-latency":"$context.responseLatency" }
StageName: !Ref EnvType
Auth:
DefaultAuthorizer: CognitoAuthorizer
AddDefaultAuthorizerToCorsPreflight: false
Authorizers:
CognitoAuthorizer:
AuthType: COGNITO_USER_POOLS
UserPoolArn: !Sub 'arn:aws:cognito-idp:${AWS::Region}:${AWS::AccountId}:userpool/${CognitoUserPoolArn}'
I Have a parameter PreferredMaintenanceWindow setup within AWS::RDS::DBCluster in my cloudformation template and it was all good.
Recently I had to add the parameter EnableCloudwatchLogsExport to the template, but when I tried to deploy the stack it failed with the following message:
You currently can't modify MaintenanceWindow with Aurora Serverless.
(Service: AmazonRDS; Status Code: 400; Error Code:
InvalidParameterCombination; Request ID:
bf40fd7e-e599-481a-ac23-b3c68e9794a1)
This is when I didn't even touch that parameter, did anyone faced such issue or any workaround which I can use with CloudFormation
PS: I am aware that I can setup the EnableCloudwatchLogsExport from the CLI but I don't want drift and I would really want it to do it via cloudformatio.
Update:
RDSServerlessDB:
Type: "AWS::RDS::DBCluster"
Properties:
AvailabilityZones:
Fn::GetAZs: !Ref 'AWS::Region'
BackupRetentionPeriod: 3 # Number of days
DatabaseName: !Join ["_", [!Join ["_", !Split [ "-", !Sub '${MasterStack}']], 'fol']]
DBClusterParameterGroupName: "default.aurora5.6"
DBSubnetGroupName: !Ref RDSDBSubnetGroup
EnableCloudwatchLogsExports:
- error
- general
- slowquery
- audit
Engine: "aurora"
EngineMode: "serverless"
# EngineVersion: "5.6.10a"
MasterUsername: "username"
MasterUserPassword: "{{resolve:ssm-secure:/password:1}}"
# Port: 3306
# PreferredMaintenanceWindow: "sun:01:00-sun:03:00"
ScalingConfiguration:
AutoPause: True
MaxCapacity: 32
MinCapacity: 2
SecondsUntilAutoPause: 300
Tags:
- Key: owner
Value: !Ref StackOwner
- Key: task
Value: !Ref Task
VpcSecurityGroupIds:
- Ref: RDSSecurityGroup
It's a bug.
As a work-around, you can temporarily remove (or comment out) PreferredBackupWindow and PreferredMaintenanceWindow from the template. In my testing, the CF update succeeds and both values are left intact on the instance configuration.
There is actually some debate as to what the expected behavior is. The bug report comments say these settings are not supported in serverless mode, but the AWS Documentation and AWS Console don't seem to support that assertion.
Apparently this is a limitation (among many others) of Aurora Serverless v1: https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-serverless.html#aurora-serverless.limitations (it's the last in the list of limitations).
I tried setting it with the AWS CLI v1 and with the AWS Java SDK v2:
software.amazon.awssdk.services.rds.model.ScalingConfiguration scalingConfiguration = software.amazon.awssdk.services.rds.model.ScalingConfiguration.builder().minCapacity(1).build()
final ModifyDbClusterRequest request = ModifyDbClusterRequest.builder().dbClusterIdentifier(clusterIdentifier).preferredBackupWindow("18:00-19:00").scalingConfiguration(scalingConfiguration).build()
final ModifyDbClusterResponse response = rdsClient.modifyDBCluster(request)
It returns the same error regardless.
I'm trying to set a Life cycle configuration for my S3 buckets to expire after 90 days. However, I'm getting an error saying "Property Status cannot be empty" when pushing my CFT stack.
I tried setting a lifestyle config, and putting the expiration in days onto that, but it seems to be failing.
AWSTemplateFormatVersion: '2010-09-09'
Description: Creates S3 Bucket
Resources:
TestBucket:
Type: AWS::S3::Bucket
Properties:
BucketName: !Sub "${AWS::StackName}-test"
AccessControl: Private
LifecycleConfiguration:
Rules:
- Id: DeleteContentAfter90Days
Prefix: ''
Status: Enabled
ExpirationInDays: '90'
I'm getting "Property status cannot be empty" and an update rollback when I check my status in the console.
Status: 'Enabled'
Status should be string value as stated in the documentation
Here is a working example of LifecycleConfiguration:
LifecycleConfiguration:
Rules:
- Id: DeleteContentAfter1Day
Status: 'Enabled'
ExpirationInDays: 1
ExpirationInDays should be a number, not a string
Cloudformation can't take null values, remove this line - Prefix: ''