MemberJune 2, 2020 at 11:07 am
Hi Tutorial Dojo Team,
Can we insert a file directly into Glacier? The question stated below has gotten me a bit confused. Step 1 of the answer said:
1. Compress and concatenate all of the files for all the completed data sets into a single Glacier archive.
I thought we couldn’t push a file to Glacier directly, instead we must use a S3 Lifecycle Policy to move it to Glacier.
A data analytics company has recently adopted a hybrid cloud infrastructure with AWS. They are in the business of collecting and processing vast amounts of data. Each data set generates up to several thousands of files which can range from 10 MB to 1 GB in size. The archived data is rarely restored and in case there is a request to retrieve it, the company has a maximum of 24 hours to send the files. The data sets can be searched using its file ID, set name, authors, tags, and other criteria.
Which of the following options provides the most cost-effective architecture to meet the above requirements?
MemberJune 2, 2020 at 7:15 pm
Thank you for your feedback.
From this AWS document – https://docs.aws.amazon.com/amazonglacier/latest/dev/uploading-an-archive.html
it still says that we can’t upload directly to Glacier storage class using the Web Console. You can only use the AWS CLI or SDK to upload directly to Glacier.
However, with the recent update to S3 you can now upload objects and select Glacier as the storage class. Therefore, you can directly upload an object to Glacier storage class.
When you upload an Object to the S3 bucket via the Web Console, you can select the Storage Class for your object, and Glacier is available as options.
Kenneth Samonte @ Tutorials Dojo
MemberJune 3, 2020 at 7:49 am
Thanks for the detailed response. I have another question. I have listed the question below.
There was a major incident that occurred in your company wherein the web application that you are supporting unexpectedly went down in the production environment. Upon investigation, it was found that a junior DevOps engineer terminated the EC2 instance in production which caused the disruption of service. Only the Solutions Architects should be allowed to stop or terminate instances in the production environment. You also found out that there are a lot of developers who have full access to your production AWS account.
Which of the following options will fix this security vulnerability in your cloud architecture and prevent this kind of failure from happening again? (Choose 2)
Isn’t it better to have PoweUserAccesss versus full-access? When I think of full-access, I think of full administrator access.
“Add tags to the EC2 instances in the production environment and add resource-level permissions to the developers with an explicit deny on terminating the instance which contains the tag.”
Since this is a production only account, I’m not sure why we add tag in the first place since the question state ” Only the Solutions Architects should be allowed to stop or terminate instances in the production environment.” Shouldn’t simply modifying the IAM role to revoke permission to delete ec2 instances and downgrading from a full-access to powerUseraccess be the appropriate step?
MemberJune 3, 2020 at 7:49 pm
The question did not indicate that the AWS account is “production only” which means that the AWS account is used for production and other functions as well. I know a company like this. Mostly small/medium companies use this setup because they only register one AWS and it will be used for Development, Staging, and Production environments. For whatever reason, they put all their resources on a single AWS account, maybe they want a single billing, a single managing account, a single IAM management, or just a small team managing the whole thing, etc.
The requirement is to allow Developers to have full access, create/delete EC2, stop/start EC2, so that they can test everything they need before going to Production. But they should not be able to terminate or stop “Production” EC2 instance. For this scenario, AWS recommends that you tag your resources, examples: “env:Test” or “env:Prod” or “department:Finance”, etc., then configure your IAM roles permissions to restrict actions based on these Tags. So for this example, the Developers will only have full permissions for EC2 with tag “env:Test”, but they won’t be able to terminate/stop instances with the tag “env;Prod”.
Hope this helps.
Kenneth Samonte @ Tutorials Dojo
Log in to reply.