We were told that, for a full deployment, we will need to copy the properly configured application files into the S3 bucket with the name <YourEnvironmentName>.app.
Considering the initial tests, we are still receiving a 403 error when trying to access the application. Some people believe that by making this S3 bucket public, we will solve this access issue. However, other folks say that we should use CloudFront to restrict access to the S3 origin and better secure the bucket content.
What do you think is the best option? Can you give us a justification for your decision?
Based on intel, we received some guidance on how to solve this…
Well, the first step seems obvious: Go through the process of fixing the environment!
However, a developer on our team has been inspecting the code, and she thinks that there is an easier way for fix Alien Attack.
It was said that if you go to your Cloud9 environment, navigate to the ~/environment/aws-alien-attack/infrastructure/cdk on the terminal, and then run the
cdk command with specific parameters, you can fix the environment.
For example, if you run the command below, CDK indicates that the missing parameter on Systems Manager/Parameter Store - /<envnameLowercase>/session - is going to be created when you use the
cdk deploy command in place of the
cdk diff -c envname=$envname -c sessionparameter=true
Our developer also told us that she identified other parameters that can be passed to CDK via the command line:
kinesisintegration=true, she believes that must be used to automatically deploy the missing integration between Kinesis Data Streams and Lambda.
firehose=true seems to create the missing Kinesis Data Firehose resource, integrating it with the existing Kinesis Data Streams.
deploycdn=true seems that should be used to deploy a CloudFront distribution, and in this case it will make the content at the .app S3 bucket readable via the Cloudfront URL.
She bets that if you execute the command below in an untouched new deployment of Alien Attack, you will be able to fix everything automatically. She hasn’t tried it yet because she is waiting for the approval from the Change Management team.
cdk deploy -c envname=$envname -c sessionparameter=true -c kinesisintegration=true -c firehose=true -c deploycdn=true
Once the deployment finishes, the next step is to move the configured frontend application to the S3 .app bucket, by executing the command below from the ~/environment/aws-alien-attack/infrastructure folder:
You will be able to access the application via your CloudFront Distribution URL, noted in the Amazon CloudFront Console.
In such case, your enviroment is working and you can create a session and play the game from your Cloud9 enviroment, but the content of the ~/environment/aws-alien-attack/application folder is not yet deployed on your S3. However, even if you had it, you still wouldn’t be able to access the application via the static website hosting endpoint of your .app bucket because that bucket is not public.
So, after having the content on your bucket, you have 2 options: to deploy the Cloudfront distribution for your environment, or to make the bucker public readable.
Option 2a: If you decide to deploy Cloudfront…
If you decide to deploy Cloudfront, which should take around 15-20 minutes, you need to execute the command below:
cdk deploy -c envname=$envname -c deploycdn=true
You can check in on the progress of this deployment by navigating to the Amazon CloudFront Console. Once your deployment has completed, your application will be accessible from the associated CloudFront Distribution URL.
Finally, copy the applications to the S3 bucket by issuing the command below from the ~/environment/aws-alien-attack/infrastructure folder :
As result, you will get an output with your properly configured /application/resources/js/awsconfig.js file, a log of the copy of the files to S3 and, if you have deployed Cloudfront, the URL pointing to your distribution which you can use to access your deployment.
… or Option 2b: If you decide to make the objects public in your S3 bucket instead
To do this, you need to create a resource policy for your S3 bucket - maybe using the AWS Policy Generator - that grants permissions to everyone to read objects from your S3 bucket. However, we have heard that this is not best practice to make buckets world readable. What do you think about this? Does this apply to Alien Attack?
After creating and applying the policy, the next step is going to be to move all the code to S3. So, from the ~/environment/aws-alien-attack/infrastructure folder, execute the following command:
In this case, you will access the application via the S3 static website hosting endpoint. Can you find it?
That was quick! While making your S3 objects public took less time, let’s compare the two approaches. Which one was more efficient? Which one was more secure? Can you highlight the benefits? Is it worth waiting for your CloudFront distribution to deploy?
The home page of your CloudFront Distribution URL should look something like this:
This is the end of our journey together… for now. Check back later for more modules and new activities to further improve your Alien Attack Application.