- Newest
- Most votes
- Most comments
Regarding your last comment:
1. what I would do with Basic Support (Free Tier):
Since Technical Support cases are unavailable to you, I would try these three verified channels to report this critical routing bug:
-
In-App Feedback: Navigate to the AWS Console Mobile App settings and select Feedback / Report a Bug. This routes directly to the mobile development team. Include the App Version, iOS Version, and specific CloudTrail Event IDs.
-
Account Support Routing: You can try to open a support case under the Account and Billing category (available to Basic Support). Explicitly state: "CRITICAL UI BUG CAUSING DATA LOSS" and request the support agent to escalate your CloudTrail evidence internally to the Mobile App/EC2 engineering teams … also this form will reviewed by the Support Team …
2. AWS Acknowledgment: There is currently no public AWS Health Dashboard alert or known issue publication specifically for v3.18.1.211745. Documenting your CloudTrail logs in this community forum is the correct first step, as AWS Community Managers escalate critical trends internally.
3. Should iOS users avoid v3.18.1.211745? To my understanding from what you descripted … Strictly yes! Based on your reproducible CloudTrail evidence documenting TerminateInstances being passed instead of StopInstances, all users should immediately suspend using this specific mobile app version for EC2 state management until AWS releases a documented patch. Continue using the web-based AWS Management Console or AWS CLI.
I understand your concern about instance termination versus stopping. Let me clarify the key differences and what might be happening.
When you stop an EC2 instance, it transitions from running to stopping to stopped. This preserves data on EBS root volumes and data volumes, though data on instance store volumes is lost. A stopped instance can be restarted later.
When you terminate an instance, the action is permanent and irreversible. You can no longer connect to it, and it cannot be recovered. All attached EBS volumes configured to be deleted on termination are permanently deleted, along with all data on instance store volumes.
If you're seeing TerminateInstances API calls in CloudTrail when you believe you selected "Stop," I'd recommend:
- Double-check that you're selecting the correct action in the mobile app interface, as the options may be positioned differently than in the web console
- Verify your instance's shutdown behavior settings - there's a configuration called "instance initiated shutdown behavior" that can be set to either "stop" or "terminate," which affects what happens during certain shutdown operations
- Review whether termination protection was enabled on these instances, as this can prevent accidental termination
For immediate assistance with this issue, please visit the AWS Support Center at https://console.aws.amazon.com/support/ to add detailed correspondence about what you're experiencing. Include your CloudTrail logs showing the API calls. If you need faster response times for production issues, you may want to review your AWS Support plan options.
Going forward, enabling termination protection on critical instances can help prevent accidental permanent deletion, and maintaining regular backups ensures you can recover data if needed.
Sources
Change instance initiated shutdown behavior - Amazon Elastic Compute Cloud
TerminateInstances - Amazon Elastic Compute Cloud
Methods for stopping an instance - Amazon Elastic Compute Cloud
answered 18 days ago
Based on the evidence provided (CloudTrail logging TerminateInstances instead of StopInstances), immediate technical mitigation and proper escalation are required.
Immediate Mitigation:
- Enable Termination Protection: Apply this to all critical EC2 instances immediately. If the Mobile App or any user incorrectly sends a TerminateInstances API call, AWS will explicitly block the action at the API level, preventing data loss.
- Alternative Tooling: Suspend the use of the AWS Console Mobile App for instance state management until this behavior is clarified. Rely strictly on the web-based AWS Management Console or the AWS CLI to issue StopInstances commands.
Escalation Path: Community forums cannot investigate or patch Mobile App routing behavior. This requires a direct escalation to AWS engineering. Open a technical support case via the AWS Support Center and provide the following specific details:
- The exact AWS Console Mobile App version and the mobile OS version (e.g., iOS 17.x).
- The specific CloudTrail Event IDs and Request IDs that document the TerminateInstances execution.
- The affected EC2 Instance IDs.
Thank you for the detailed mitigation steps - very helpful! Termination Protection: Will enable on all future instances Alternative Tooling:Switched to web console only for EC2 management
Mobile App: Suspended use until bug confirmed fixed
Escalation Challenge: Free Tier account = Basic Support only No technical support cases available for priority issues Community forums are primary escalation path for Free Tier users Technical Details Ready for AWS Engineering: Mobile App: AWS Console v3.18.1.211745 Mobile OS: iOS 26.5
CloudTrail Event IDs: Available with complete request/response data Affected Instance IDs: Multiple instances documented What's the best escalation path for Free Tier accounts to reach AWS engineering for critical mobile app bugs? Has AWS acknowledged this specific mobile app version issue? Should all iOS users avoid v3.18.1.211745? Really appreciate the professional guidance on mitigation steps!
Relevant content
asked 8 months ago
asked 3 years ago
Thank you for the response, but this isn't user error or configuration issue. Key Evidence: 30+ successful Stop operations using same mobile app before May 2, 2026 Same session successfully did StartInstances just minutes before the bug CloudTrail shows: User clicked "Stop" → App sent TerminateInstances API (should be StopInstances) 100% reproducible** - tested on additional instance, same bug occurs This is a mobile app bug: The Stop button is sending wrong API call