Published on · Updated on
Rewrote the guide with current EC2, S3, access, networking, and pricing guidance.
Amazon EC2 and Amazon S3 are common starting points for AWS. This practical guide shows how to launch an instance, give it safe access to S3, and understand the storage, networking, and cost choices behind the setup.
If you want a broader introduction to cloud terms first, see our AWS tutorial for beginners.
EC2 runs application code on virtual servers. S3 stores objects such as uploads, reports, and backups. Used together, they let an application keep compute capacity separate from data storage. First, it helps to understand how EBS—the disk storage commonly attached to an instance—fits beside them.
Think of EC2 as the computer that runs an application, S3 as an object store the application can call to save or retrieve data, and EBS as a disk-like storage volume for an EC2 instance.
An EC2 instance is a virtual server in your AWS account. When you launch one, you choose an Amazon Machine Image (AMI) that supplies its operating system and software, an instance type that sets its compute and memory resources, storage, and network settings. EC2 gives you control over the server; AWS manages the underlying physical infrastructure.
EC2 does not automatically add or remove instances when demand changes. You can scale capacity yourself or configure services such as EC2 Auto Scaling to do it in response to policies or demand.
Amazon S3 is object storage. You put data into a bucket as objects; each object has data, metadata, and a key that identifies it. A key such as images/logo.png can look like a folder path, but S3 is accessed through its API, the AWS console, or tools such as the AWS CLI. It is not an attached disk or a general-purpose file system. Read more in our guide to essential S3 concepts.
S3 is useful for data that an application needs to store and retrieve as whole objects, including user uploads, static assets, reports, and backups. A bucket is created in an AWS Region. Names in the shared global namespace must be unique across accounts in the AWS partition; AWS also offers an account-regional namespace for names reserved to your account. See AWS's current general-purpose bucket naming rules.
EBS volumes provide block storage that an EC2 instance can use like a disk, for example, for its operating system, application files, or a database that needs block storage. An EBS volume normally remains attached when an instance is stopped. What happens on termination depends on that volume's DeleteOnTermination setting: the root volume is deleted by default in common launch flows, while other volume defaults vary. Check the setting and back up anything important before terminating an instance. AWS explains how to preserve EBS data when an instance is terminated.
A simple choice is: use EBS for disk-like storage attached to an instance, S3 for objects accessed through an API, and a file service such as Amazon EFS when multiple Linux instances need a shared mounted file system.
This separation lets you adjust compute independently of stored objects. Multiple instances or other AWS services can use the same bucket when their permissions allow it.
An application on EC2 can call S3 to save a file or read one later. For example, a web service might keep its code and temporary working files on the instance, then store customer uploads in S3. A batch job can read source objects from S3, process them on EC2, and write its results back to a bucket.
An application can use an AWS SDK to call S3, or an operator can use the AWS CLI for a manual transfer.
In either case, permission and network connectivity must both be in place:
A public IP address is not itself permission to read a bucket, and an IAM role does not create network connectivity. Keeping these controls separate makes troubleshooting and security reviews clearer.
The EC2 launch wizard changes over time, but the decisions it asks you to make are consistent. For more detail on the instance, AMI, and network concepts, see AWS EC2 basics.
Create or sign in to the AWS account you will use for practice. You need access to EC2, IAM, and S3 actions to complete the walkthrough. Start at AWS account signup, then review the current Free Tier account plans: eligibility and offers depend on the account's creation date and plan.
A security group acts as a virtual firewall for the instance. Allow only the inbound traffic the exercise needs. For SSH, limit port 22 to your current IP address; do not open it to every IPv4 address. A web server may need HTTP or HTTPS from its intended audience. If you use AWS Systems Manager Session Manager and configure its IAM and connectivity prerequisites, you can connect without opening inbound SSH or assigning the instance a public IP. See AWS's current EC2 connection options.
Review the instance, storage, network, and connection settings, then choose Launch instance. Wait for the instance to pass its status checks before connecting.
For Linux, you can use an SSH client with the key pair selected at launch, or a supported browser-based connection method. The required path depends on the option: SSH needs a route to the instance and an inbound security-group rule, while Session Manager needs the instance role and Systems Manager connectivity. Windows instances use different connection methods. Follow the prerequisites for the method you choose instead of assuming every instance needs a public address.
Use the console, or the AWS CLI after replacing the placeholder with your bucket name:
aws s3 cp ./sample.txt s3://YOUR-BUCKET/sample.txtTo copy that object back to the current directory, use:
aws s3 cp s3://YOUR-BUCKET/sample.txt ./downloaded-sample.txtThe AWS CLI also works on Windows. Install it using AWS's Windows installation instructions, give the instance a role with the needed S3 access, then use a Windows destination path:
aws s3 cp s3://YOUR-BUCKET/sample.txt C:\data\sample.txtAmazon S3 automatically applies server-side encryption with S3-managed keys (SSE-S3) to new object uploads by default. Encryption does not make an object public; access still depends on authorization. New buckets block public access by default, and objects are private unless access is granted. Review the AWS guidance for S3 default encryption and blocking public access.
For software running on EC2, attach an IAM role to the instance. The role supplies temporary credentials to AWS SDKs and the CLI, so you do not need to copy long-lived IAM access keys onto the server. AWS describes the setup in its guide to attaching an IAM role to an EC2 instance.
Grant only the actions the application needs. For example, uploading and downloading a known object requires object-level write and read permissions on the relevant keys; listing a bucket requires a separate bucket-level permission. Avoid broad policies that allow every S3 action on every bucket. The bucket policy, any VPC endpoint policy, and encryption-key permissions can also affect a request, so check those if the role appears to have the right permissions but S3 still returns an access error.
You can test the role from the instance with the two aws s3 cp examples above. Install the CLI if it is not already available in your AMI, and use the EC2 role for credentials instead of running aws configure with a user's access keys.
Instances in a public subnet can reach public AWS service endpoints through an internet gateway when routing and addressing are configured. A private-subnet instance might use a NAT device for general outbound internet access. S3 also supports a gateway VPC endpoint: you add it to the relevant route tables, and instances in that VPC can reach S3 without an internet gateway or NAT device for that S3 traffic. AWS says gateway endpoints have no additional endpoint charge, but access still depends on IAM, endpoint, bucket, and network rules. The endpoint must be in the Region for the S3 bucket.
That endpoint is specifically a route to S3; it does not give an instance general internet access. See AWS's documentation on Amazon S3 gateway endpoints for their scope and limitations.
Amazon provides Mountpoint for Amazon S3, which mounts a bucket for Linux applications and translates supported file operations into S3 API calls. It is designed for workloads such as high-throughput reads of large objects and sequential creation of new objects. Mountpoint does not implement a full POSIX file system or arbitrary in-place and random writes. Its behavior depends on the bucket type and mount options: for example, it can replace existing objects when configured with --allow-overwrite, and S3 Express One Zone supports append-style writes with --incremental-upload and atomic rename. Check the current Mountpoint file-system behavior against your application before using it. For a mounted disk, consider EBS; for a shared file system, consider EFS or FSx. AWS compares object and file storage choices for EC2.
S3 can store static website files such as HTML, CSS, JavaScript, and images. For a typical public site, CloudFront can deliver those files while the bucket remains private: use a regular S3 bucket origin, configure CloudFront Origin Access Control (OAC), and grant the distribution read access in the bucket policy. Keep S3 Block Public Access enabled. CloudFront can serve viewers over HTTPS.
There are two S3 origin configurations that are easy to confuse. An S3 static website endpoint is a website endpoint and requires a different CloudFront origin configuration; it cannot use OAC. For a private S3 origin protected by OAC, use the regular S3 bucket endpoint. Follow AWS's steps to restrict access to an S3 origin with CloudFront.
When an EC2 application creates files that belong in S3, have the application upload them through an AWS SDK or a controlled job that runs on a schedule. Assign the job the same narrowly scoped instance role and make it safe to retry; for important data, monitor failures and test that you can retrieve a backup. The right design depends on whether the application writes each object, exports batches, or moves a large dataset, so avoid treating an S3 mount or manual copy as a backup plan.
There is no single EC2 or S3 price. The total depends on Region, instance type and running time, EBS storage, S3 storage class and requests, data transfer, public IPv4 use, and other resources you add. Stopping an instance stops its compute use, but attached EBS volumes continue to incur storage charges, as described in AWS's guide to EC2 stop and start costs. An Elastic IP address and other supporting resources can also remain billable. Build an estimate with the AWS Pricing Calculator and check the current service pricing before launching.
Do not rely on old claims that every new account gets a particular first-year free allowance. AWS Free Tier offers depend on account creation date, account plan, and eligible usage. Check the offer shown for your own account in the AWS Free Tier documentation and monitor usage in Billing and Cost Management.
When you finish a learning exercise, stop the instance if you need to keep it, or terminate it if you are done. Before termination, verify whether its EBS volumes will be deleted or retained; retained volumes keep accruing charges. Empty and delete any test bucket you no longer need, including object versions if versioning was enabled, then review the account for other resources left behind.
The core pattern is straightforward: EC2 runs compute, an IAM role gives that compute narrowly scoped S3 permissions, and network routing lets it reach the S3 service. EBS remains the instance's disk-like storage, while S3 holds objects that can be accessed through AWS APIs. From here, deepen your knowledge with our guides to EC2 fundamentals and S3 fundamentals, then try a small application that uploads and retrieves one private object.