- Newest
- Most votes
- Most comments
Elastic Beanstalk creates an Amazon S3 bucket named elasticbeanstalk-region-account-id for each region in which you create environments. Elastic Beanstalk uses this bucket to store objects, for example temporary configuration files, that are required for the proper operation of your application.
The following table lists some objects that Elastic Beanstalk stores in your elasticbeanstalk-* Amazon S3 bucket. The table also shows which objects have to be deleted manually. To avoid unnecessary storage costs, and to ensure that personal information isn't retained, be sure to manually delete these objects when you no longer need them.
| Object | When stored? | When deleted? |
|---|---|---|
| Application versions | When you create an environment or deploy your application code to an existing environment, Elastic Beanstalk stores an application version in Amazon S3 and associates it with the environment. | During application deletion, and according to Version lifecycle. |
| Source bundles | When you upload a new application version using the Elastic Beanstalk console or the EB CLI, Elastic Beanstalk stores a copy of it in Amazon S3, and sets it as your environment's source bundle. | Manually. When you delete an application version, you can choose Delete versions from Amazon S3 to also delete the related source bundle. |
| Custom platforms | When you create a custom platform, Elastic Beanstalk temporarily stores related data in Amazon S3. | Upon successful completion of the custom platform's creation. |
| Log files | You can request Elastic Beanstalk to retrieve instance log files (tail or bundle logs) and store them in Amazon S3. You can also enable log rotation and configure your environment to publish logs automatically to Amazon S3 after they are rotated. | Tail and bundle logs: 15 minutes after they are created. Rotated logs: Manually. |
| Saved configurations | Manual | Manual |
Part of the S3 pricing is # of API requests.
As you might know, almost everything in AWS is an API call.
Whenever you upload an object to S3, it's a PUT call. If you download / browse or Elastic Beanstalk retrieves a JAR file, it's a GET call.
Of course you can always go to CloudTrail and see who exactly is making those API calls (provided you enabled CloudTrail trail to log S3 data event), but considering you only have ~2k calls, most likely it's due to either you upload your JAR and Elastic Beanstalk's deployment retrieving your artifact from S3.
Relevant content
- asked 6 months ago
AWS OFFICIALUpdated 8 months ago- AWS OFFICIALUpdated 8 months ago
- AWS OFFICIALUpdated a year ago
Thanks RoB -- I had some sensitive Twilio API Keys and Auth Tokens stored in an application.properties file that was included in a .jar file that I deployed to beanstalk and I even had those variables in Environment Properties for my EB application. My twilio account was subsequently hacked recently and I assume it's because my S3 buckets were publicly available. Would that be the case?